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)?
MongoDB 2.6 Released
51–60 of 119 posts
Re: MongoDB 2.6 Released
#52Earlier quoted context omitted.
High volume of writes
Isn't that supposed to be the ideal use case for Mongo though?
Not for single-server performance. The database level lock severely limits MongoDB's single server performance. Just look up the sysbench benchmark comparing MongoDB with TokuMX (which I work on)
Re: MongoDB 2.6 Released
#53Earlier quoted context omitted.
Really? Have you ever tried to search for specific content in structured documents on a filesystem?
I have, and found what I was looking for. What am I doing wrong?
How much data were you grepping for? How much time did it take? How did you transmit those results over the network?
Or does your data fit in one csv file?
Re: MongoDB 2.6 Released
#54A 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.
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.
Re: MongoDB 2.6 Released
#55Can 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)?
Upgrade notes are here: http://docs.mongodb.org/master/release-notes/2.6-upgrade/
"the upgrade from MongoDB 2.4 to 2.6 is a binary-compatible drop-in upgrade: shut down the mongod instances and replace them with mongod instances running 2.6."
Re: MongoDB 2.6 Released
#56So 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
I would stay with CouchDB. Its web interface if really good for inspecting and debugging what is inside the database. Really good for development.
Also it has a very nice HTTP interface so can talk to it straight from the Web via a proxy.
Re: MongoDB 2.6 Released
#57Earlier quoted context omitted.
I don't know anything about MongoDB but can you give an example where DB level locking is a problem?
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.
Re: MongoDB 2.6 Released
#58Can 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)?
Authentication is the main thing to be aware of (no data rebuild), but full notes here:
http://docs.mongodb.org/master/release-notes/2.6-upgrade/
And, you have to be on 2.4 first (I know you said you are, but best to make sure for others)
Re: MongoDB 2.6 Released
#59Re: MongoDB 2.6 Released
#60I have never understood how the definition of "Document Database" is different from "File System".
Really? Have you ever tried to search for specific content in structured documents on a filesystem?
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/bar3 /bar/by_foo/foo1 /bar/by_foo/foo2
If I am not mistaken, this accurately describes the limits of MongoDB in terms of mapping relations. I'm not a Mongo expert because no one could convince me otherwise to date, somebody correct me?