10 ms·
Things I wish I knew about MongoDB a year ago
- nickzoic 14y agoThe count({condition}) one is a worry. I'm guessing it is slow in the case where it has to page the index in in order to count it. I wonder if it is still a problem where the index is used a lot anyway. A fix in MongoDB would seem a lot better solution than having everyone implement their own hacky count-caching solution. EDIT: Actually, looking at the bug reports, sounds like maybe lock contention on the index? The master/slave replication problem seems bad but I think it can be worked around (for my particular project) with a flag on the user session ... if they've performed a write in the last 30 seconds, set slaveOkay = false. Users who are just browsing may experience a slight delay in seeing new documents but users who are editing stuff will see their edits immediately.
- tomschlick 14y agoI'm so glad this wasn't another case of someone just ranting about using mongo for the wrong purpose and being mad about it a year later.
- trafficlight 14y agoI also appreciate how he pointed out positive things that he just wasn't aware of initially.
- deleted 14y ago[deleted]
- dia80 14y agoGenuine question: In what use cases does mongo kick mysql's ass? I've used it a couple of times in hobby projects and enjoyed not maintaining a schema. I read so many of these 'gotcha' style articles and for example one commenter here wants to have a manual "recently dirty" flag to combat the master / slave lag mentioned in the article. I know it's faster (tm) but once you have to take in to account all this low level stuff you have to worry about yourself wouldn't it just be better to rent/buy another rack of mysql servers and not worry about it? Look forward to learning something...
- alexro 14y agoIMO there is no rational explanation to this phenomena other than: people are different. Some get bored with stored procs and want same hassle but in another form.
- morsch 14y agoA cynical but insightful description of many kinds of progress and change. ;)
- taligent 14y agoYes. There is no rational explanation for people using the right tool for the right job. Let me guess. You would build a skyscraper using a trough and cement in a bucket ?
- jamesaguilar 14y agoAre you trying to give us an idea of what it's like to build an even moderate sized app without transactional consistency and with mapreduce? Because that is what it sounds like to me.
- diminoten 14y agoMongo isn't so important to this question as ODB vs RDBMS. Here's some light reading: http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis... MongoDB is just ODB, and MySQL is just RDB. Besides, postgres is the real future!
- dleblanc 14y agoNot sure what Wu-Tang has to do with this, but.... Seriously though, is Mongo an ODB, or a document oriented database? ODBs/OODBs imply a much different use-case and functionality, and I think we ought not conflate the two.
- 14y ago
- lars512 14y agoThe inconsistent reads in replica sets is something we've come across with MySQL read slaves as well. I think it's a gotcha of that whole model of replication, rather than a MongoDB-specific issue.
- jbert 14y agoOne way to resolve it is to mark that user or session (or even just request) "sticky to the master" for long enough to cover your normal replication delay. When we saw it before, ensuring that a given request which issued a write also read from the master was sufficient. (sub-second replication delay).
- mgummelt 14y agoThis may help in the majority of the cases, but many applications also can't tolerate inconsistent reads across users/sessions.
- mgummelt 14y agoI'm not aware of any database that solves this problem. Is there one? As far as I know, mysql reads must be distributed to the slaves at the application level, which has no knowledge of master/slave inconsistency. I suppose the time delta between master and slave can be queried, but that still doesn't protect from race conditions/inconsistent reads. This is actually why we chose to only utilize slaves for data redundancy rather than read throughput at my last company. Inconsistent reads weren't tolerable.
- orthecreedence 14y agoRiak does. You say, when writing, "please don't return until this data is replicated on 2 servers." And when reading, "please only return a successful read if this data is read from 2 servers." So you have R = 2, W = 2, R+W = 4, and if your replication (N) val is 3, you're fine (you're always going to get consistency if R+W > N). Riak is cool.
- 14y ago
- nevinera 14y ago>Range queries are indexed differently If I'm reading your description right, this is hardly mongo-specific. Try it in mysql, for example: (index is [:last, :first]) select first from names where last in ('gordon','holmes','watson') order by first; An index is an ordering by which a search may be performed - to illustrate, the index for my small table looks pretty much like this: gordon, jeff holmes, mycroft holmes, sherlock watson, john Unless the first key is restricted to a single value, it can't order by the second key without performing at least a merge-sort. They aren't in that order in the index.
- foobar2k 14y agoHe never said it was mongo specific
- nevinera 14y ago>Things I wish I knew about MongoDB a year ago The post reads as a series of criticisms about mongo. I don't love mongo, but I'm not aware of any data store that can perform that type of query purely from an index. Now, the description was vague enough that he could have been describing a real bug I'm not aware of - at one point I've seen MySQL decide to use an index for sorting instead of for filtering when that query plan was 500x slower. If mongo has a bug like that one, disregard my comment please. :-)
- deleted 14y ago[deleted]
- chris123 14y agoIs MongoDB more marketing hype than quality product? I've heard it before and this article seems to point in that direction as well.
- lmm 14y agoYes, but only because it has ~infinite marketing hype. It isn't and shouldn't be a general replacement for a RDBMS; it makes some interesting sacrifices for performance that you have to understand before using it. But it is very much a quality product; it makes some easy things very easy and some very hard things possible.
- kokey 14y agoI think it's generally full of gotchas similar to that of SQL databases like MySQL and Oracle. In fact, most of the issues mentioned in this article, like delayed replication, indexed queries and using 'explain' are issues I've had to deal with in MySQL and Oracle. Most of these databases are fine out of the box for small scale use, but when you scale up you have to deal with these 'gotchas' like indexing, partitioning, bulk loading, and having to profile everything etc.
- bengaoir 14y agoI wish I knew that it sucked.
- jameswyse 14y agoOne thing I love MongoDB for is it's geospatial indexing abilities: http://www.mongodb.org/display/DOCS/Geospatial+Indexing http://www.mongodb.org/display/DOCS/Geospatial+Indexing Was a really nice surprise when I was building a location based web app.