Earlier quoted context omitted.
TokuMX, which I work on, has document level locking and compression right now.
trying amisaserver found it somewhere in the comments below. claims to have MVCC.
TokuMX does have MVCC
MongoDB 2.6 Released
41–50 of 119 posts
Re: MongoDB 2.6 Released
#42Re: MongoDB 2.6 Released
#43Re: MongoDB 2.6 Released
#44A lot of hype... And we still have db level locking. If document level is too difficult, at LEAST do collection level (not that it is too much better, but least it some real improvement).
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.
It doesn't use mmap for locking though - and in any case one database is already multiple files (2GB max). There are internal data structures used by MongoDB and the database itself takes care of locking, mmap just gets the data into memory.
Re: MongoDB 2.6 Released
#45mongodb is the best database in the whole wide world at the moment. I encourage everyone to jump in mongodb for agile web scale development with full big data capability.
I truely can not tell if this comment is meant to be flamebait, buzzword-laden sarcasm, or NoSQL fanboy-ist.
Obvious sarcasm (https://www.youtube.com/watch?v=b2F-DItXtZs)
Re: MongoDB 2.6 Released
#46So 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!).
Re: MongoDB 2.6 Released
#47So 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
While MongoDB has many use cases, it's just perfect if you need to pass over JSON to your JavaScript. Or need JSON output for any other reason.
Re: MongoDB 2.6 Released
#48So 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
Well, for teaching purposes, independent of suitability for a use case there are multiple courses available for free here:
And, more node.js specific (but also offline capable, and available any time):
Re: MongoDB 2.6 Released
#49A lot of hype... And we still have db level locking. If document level is too difficult, at LEAST do collection level (not that it is too much better, but least it some real improvement).
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' your WAL file to redo all the lost changes.
Unfortunately, a central requirement of a write ahead log is that the data pages must not get written before the WAL. If that were to occur, and there were a crash, the system wouldn't know that it had to undo the changes to the data pages, leaving you with corrupt data. mmap generally doesn't provide the ability to pin your dirty pages in memory - they're subject to getting flushed any time the system is under memory pressure - so it makes logging a lot more complicated to get right.