I dismiss these NoSQL tools as being immature because they are immature. I'm in the process of migrating away from a NoSQL solution named like a piece of fruit. I was able to crash it by doing something WILD AND CRAZY. I created an index on a live system. Known bug. Not documented in the wiki. That was fun.

If these NoSQL solutions delivered on what they promised, or came close, that'd be one thing. But, at least with the DB that sounds like a fruit, the promise of all this distributed computation was for naught. MapReduce is the only way to distribute calculations across multiple nodes. However, MapReduce was not only the slowest way of munging data, but it still has/had major concurrency issues because it relies on process level locking. Not to be deterred I took a look at people who had been trying to use this distributed goodness (a.k.a. sharding). I was frightened away by the numerous complaints about this fruit-like database's inability to keep the partitions balanced, resulting in massive contention for the process lock on one node. That's an immature code base.

Or you could read the TFA. CouchDB is simply not mature enough for any semblance of high availability. Most of the downtime was credited to CouchDB being unstable. But, more importantly, as I've already outlined in another post on this story, distributed computation with NoSQL stuff ain't all it's cracked up to be. The reason it's being pushed so hard by the NoSQL camp is because that's the only way these products can scale in the first place. The reason you don't see stuff like that in more mature products is because fancy concepts like MVCC or finer grained locking mean that you typically don't need to distribute calculations.

Anyhow. At this point the only way we've been able to keep any semblance of performance (and we've got a tiny data set) has been to pull as much logic out of the NoSQL parts as possible. IOW it's a dumb key-value store... and if all you need is a key-value store, BDB's got you covered (and it's already way more mature).

RTFM.

If you need to narrow down your search, look for the phrase "To avoid blocking concurrent transactions that obtain numbers from the same sequence".

Right. Inserts still lock at the table level, however. Your move.

Looks a whole lot like table level locking to me.

And with InnoDB you still get table locks every time you update an autoincrement field. Performance then drops like a fucking rock. Anyway, that's when you move to Postgres.

So the thing is, traditional joins (on, say, Postgres or MySQL) aren't blocking operations. You can run more than one at a time. MapReduce (as well as writes, any aggregation, and any use of JavaScript) are blocking operations on Mongo. They block the entire mongo process. The MapReduce case gets around this with a bit of cooperative multitasking (yielding every few hundred or thousand rows), but writes, aggregation, and other use of javascript do not. So there's already a much bigger need to distribute MapReduce on Mongo than there is to distribute a JOIN on an SQL database.

Plus, MapReduce on Mongo is painfully slow, so you'll need to break things down into really small partitions to scale at all. Aggregating 800,000 documents (group by + sum) took me about 20 seconds with Mongo using the existing aggregation framework (which is universally credited with being faster than the MapReduce case). Porting the whole thing over to an SQL database allowed me to a.) not block the entire freaking process and b.) run the query in about 800ms.

So, sure, we could have partitioned the data and spread it across multiple nodes. Maybe that would have been faster (but you can only run MapReduce across multiple nodes, using the existing aggregation framework you can only operate on one node). Dunno. But it would have been a lot more expensive since we would have required more hardware to accomplish the same thing that an SQL database is optimized for.

The reason that "they" mock JOINs is because you simply can't do that efficiently with Mongo.

Well, no. If you're dealing with "big data", you still need to evaluate which tool is appropriate for the task. If you're calling it "NoSQL", you're probably referring to a rather immature set of products designed to pander to people looking for teh new hotness. If you're looking for a key-value store, mature solutions like Berkeley DB have been around for ages.

It's not that key-value stores don't have their place, it's that people running around chanting the NoSQL mantra are really just reinventing the wheel. Poorly.

Unfortunately the developers of these "NoSQL"databases seem to have the same idea. I'm working with one that shill remain nameless but sounds oddly like a piece of fruit right now. The generally accepted best practice for scaling is to pull as much of the logic out of the database layer. While there are fancy aggregation pieces, they're all impossibly slow (and hamper concurrency). Argh.

So BlackBerry OS 11 or 12 will have e-mail too? Or will it have to be tethered to a PlayBook? When most people think of BlackBerry, they think of e-mail. I don't care how good it is, if they omit major features in the first release of a product... that's bad. It's like the dev phone not having a real keyboard. I'm sure some later phones will have keyboards, but look at how many commenters here love their BlackBerries for having the best keyboards out there. If RIM is going to throw away their core strengths... why bother? They're targeting a whole market demographic that just doesn't give a flying fuck about RIM or BlackBerry.

http://iphonecto.com/2010/07/07/ios4-wireless-app-distribution-finally-iphone/

Seriously, it took one search to find that you're posting incorrect information. I'll be kind and not make jokes about why one would care about OTA app deployments on BlackBerry when there are no apps. I've nothing invested either way in BlackBerry anything, but you've failed to list anything that BES can do that's its competition cannot.

Obvious astroturf is obvious. Sigh.