Live data from Hacker News

MongoDB 2.6 Released

blog.mongodb.org

61–70 of 119 posts

Re: MongoDB 2.6 Released

#61
post #25

Earlier quoted context omitted.

I was reading somewhere that Mongo can't do document level/record level locking because of mmap'ed files. The whole database is memory mapped. And mmap doesn't understand underlined data structure, it views the whole file as a large single blob. Ditching mmap will not be that easy, cause most of the speed and simplicity of Mongo comes from using mmap.

mmap does complicate things. A traditional database often works using write ahead logs. The log holds changes made to the database over time - so when you want to write a change to your DB, you put 'I'm changing value x.y to 50' in your WAL. Sometime later the actual data pages holding the modified x data structure can be written out to disk. If you have a crash before the data pages get written out, you can 'replay'…

Just to note, the MongoDB journal is basically a write ahead log and has been around since 1.8. It's not simple, you are correct, and involved remapping portions of memory privately, and leads to some inflated numbers on the virtual memory reporting side. There's a great write up here:

http://blog.mongodb.org/post/33700094220/how-mongodbs-journa...

Re: MongoDB 2.6 Released

#63
post #25

Earlier quoted context omitted.

I was reading somewhere that Mongo can't do document level/record level locking because of mmap'ed files. The whole database is memory mapped. And mmap doesn't understand underlined data structure, it views the whole file as a large single blob. Ditching mmap will not be that easy, cause most of the speed and simplicity of Mongo comes from using mmap.

Yes, and an important limitation stems from this as well. For a tool like Redis, it's fairly easy for me to accept the limitation that my data size can't exceed available RAM. But for an indexed document store with full-text query capabilities, it's a lot harder to for me to accept that limitation.

Are you implying that a performant Mongo DB must keep all data in RAM? That's not true. We've got almost 1TB in a Mongo DB, and we sure don't have that much RAM.

You do have to be able to keep your indexes in RAM, but that's much less limiting.

Re: MongoDB 2.6 Released

#64

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

Be sure to check out RethinkDB as well, which is pretty much mongo with a MUCH nicer query interface and saner locking.

http://rethinkdb.com/ http://rethinkdb.com/docs/comparison-tables/

Re: MongoDB 2.6 Released

#66

Earlier quoted context omitted.

High volume of writes

High volume of writes from MANY producers. From 1 producer, it doesn't matter. Though the point of mongo is to be webscale which implies to me many writers.

What makes the single producer (writer?) case different from multiple, in the context of the effect on readers?

If there is a single high-volume data pump, for example machine generated data, will readers be affected by a continuous "fire hose" of incoming data?

Re: MongoDB 2.6 Released

#67
The main reason I use MongoDB on Node is the maturity of the Mongoose ORM - I've used Node-ORM 2, BookshelfJS, and SequelizeJS and none of them felt as mature as Mongoose.

Re: MongoDB 2.6 Released

#68

Can someone with more MongoDB experience give me your thoughts on the upgrade difficulty here? Worth doing soon, or waiting for a point release? Does this require a data rebuild/update process (coming from 2.4)?

IMO unless you desperately need one of the new features I would hold off a few weeks. With a release this big I'd expect there will be some bugs and wouldn't be surprised to see 2.6.1 shortly.

Re: MongoDB 2.6 Released

#69

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

Have a look at this: https://github.com/johnwilson/bytengine . It could have been built with CouchDB however some features such as ad-hoc querying and partial document updates make MongoDB a more compelling choice (albeit prone to some scalability issues until mongodb version 2.8 hopefully lol!).

thanks! I'll take a look at it.

I use elasticsearch for adhoc querying : http://daemon.co.za/2012/05/elasticsearch-5-minutes/

And couchdb does have atomic in-place updates, http://wiki.apache.org/couchdb/Document_Update_Handlers

I used the latter recently to track the last view-time on images, as well as to build a schema migration routine in like 100 lines of code.

edit fixed link

Re: MongoDB 2.6 Released

#70
post #64

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

Be sure to check out RethinkDB as well, which is pretty much mongo with a MUCH nicer query interface and saner locking. http://rethinkdb.com/ http://rethinkdb.com/docs/comparison-tables/

I've had it recommended a few times now. I'll add it onto the pile =)
Post reply on HN