Live data from Hacker News

MongoDB 2.6 Released

blog.mongodb.org

111–119 of 119 posts

Re: MongoDB 2.6 Released

#112
post #21

Earlier quoted context omitted.

Everything will segfault under certain circumstances.

The only reasonable assumption is circumstances that do not involve hardware failure, the binary being compiled incorrectly, the source code being modified or replaced by someone downstream, the libraries it is using being corrupt or having been replaced by ABI-incompatible variants... none of these are reasonable circumstances; one would then further assume that the person posting has run into reasonable circumstanc…

Exactly; well said. It's been about a year but basically I had a replica set where sometimes one replica or the other would segfault and I'd have to manually delete its data files and re-replicate, after which it was fine. Happened about every few months. It was clearly based on application behavior and not an inherent system problem such as those you listed.

Re: MongoDB 2.6 Released

#114
post #12

With this release aggregation framework got super powerful. Now it returns a cursor. Now we can get the aggregation results and iterate over them. No more 16mb result limitation as well...

Can you elaborate for people who don't understand the feature? Is the aggregation result large because of grouping?

Well, aggregation in MongoDB allows you to write sql like queries, and before 2.6 if aggregated result was > 16mb it was throwing an error, but now it gives you a cursor. Now you can fetch the results and send to another collection. For an example aggregation query in mongo have a look here: http://docs.mongodb.org/manual/tutorial/aggregation-zip-code...

Re: MongoDB 2.6 Released

#115
post #75

Earlier quoted context omitted.

You are referring to using an index, correct? Because grep is absolutely, madly efficient for a doing a full search. The index portion of a file system are called files and directories. Several file names can refer to the same data. Those are called hard links. So with hard links, I can refer to a Foo by their related Bar. /foo/foo1 /foo/foo2 /foo/by_bar/bar1 /foo/by_bar/bar2 /foo/by_bar/bar3 /bar/bar1 /bar/bar2 /bar…

Grep is essentially the slowest way to search content. It has to read every byte. You can do much better with term/field indexing. Why would you be calling grep from an online application anyway?

Grep doesn't read every byte.

Re: MongoDB 2.6 Released

#116

Earlier quoted context omitted.

It's 700/month (otherwise your product isn't needed because no-sharding? postgresql can do most of the stuff) the hosted version is upto 8gb ram, don't you think that's low ? sqlserver + oracle are also insane

$700 annually. Please read well before you misrepresent us. By the way Partitioning by Hash and Range as we have stated means "Sharding"

the 700$month was mistyped

what i meant is that the correct price is 700 and not 350 since the 350 pricing doesn't include sharding/clustering

Re: MongoDB 2.6 Released

#117

Mongo haven't updated their feeds for Ubuntu. I wonder how long they will take to do so?

They have now. However 2.6 uses different package names, configuration file name, log file etc. It is generally mongod instead of the earlier mongodb (eg before it was /etc/mongodb.conf and is now /etc/mongod.conf).

This means no automatic upgrades to 2.6, and sysadmin action to correct config file name etc.

Re: MongoDB 2.6 Released

#118
post #75

Earlier quoted context omitted.

Grep is essentially the slowest way to search content. It has to read every byte. You can do much better with term/field indexing. Why would you be calling grep from an online application anyway?

Grep doesn't read every byte.

I used the word "read" and not the word "compare" for a reason.

You are missing the big picture here of linear search versus indexed search. Optimizations in grep don't magically make it better than O(n).

Re: MongoDB 2.6 Released

#119

So i've been trying to find an the ideal case for mongodb, because I have to teach a nosql database to some people I am mentoring. I'm leaning heavily towards couchdb though. http://daemon.co.za/2014/04/when-is-mongodb-the-right-tool

-> an ideal use case: capture and store unstructured data, typically tweets. Tweets structure is json based, quite complex with many field and substructure. It's incredibly to store and manipulate such data with Mongodb without even knowing all the details of the fields! It's also a good use case beacause mongodb is fairly good at adding data, pretty bad at deleting data.

same with some others document json oriented database (like elastic search), but mongodb is a good compromise in many area, the query language is easy to understand and powerful, the biggest issue being the diffculty to do complex computation and aggreagation: mapreduce help, aggreagation framework helps too, but in this area SQL is generally much faster for instance.

Post reply on HN