He talks about populating MongoDB with "rows". No one should be using (or benchmarking) a technology unless they understand what it actually is, and what problems it aims to solve.
MongoDB vs. Clustrix Benchmark
31–40 of 67 posts
Re: MongoDB vs. Clustrix Benchmark
#32Winning a benchmark against MongoDB on a non-trivial workload is a little bit like winning the special olympics. I'd be more curious to see how Clustrix performs against Cassandra, Riak or HBase in their respective domains. Those seem to be the more serious contenders when it comes to "Big Data".
i guess rdbms will never show "older tweets are temporary unavailable". because we don't need that, its our special domain! :)
//ps. i am a huge nosql fan dont downvote! :)
Re: MongoDB vs. Clustrix Benchmark
#33Price is the elephant in the room here; NoSQL exists because people aren't willing to pay for real databases. Building yet another expensive (i.e. > $0) database that doesn't even work in the cloud won't help the Web 2.0 crowd.
These folks disagree with you. There are many more behind them. http://gigaom.com/cloud/clustrix-lifts-the-curtain-on-early-... And plenty of folks use MySQL (and PogreSQL to a much lesser extent). You just can't scale those.
Last time I heard, twitter still uses MySQL for the statuses (tweets) table. They did have a plan to migrate to Cassandra, but didn't go all the way through with it. So I find it hard to agree with "you just can't scale those". It may be a lot of work, but for some applications you can scale them.
Edit: twitter cassandra link (don't know if this is the latest): http://engineering.twitter.com/2010/07/cassandra-at-twitter-...
Re: MongoDB vs. Clustrix Benchmark
#34So a guy who is an expert in Clustrix (and knows how to setup, tune, etc) compares it against some other technology that he does not know (and does not know how to setup, tune, etc) and comes to the surprising realization that his technology is better? Where have I seen this before? Oh right.. every time I see "Technology A vs Technology B" comparisons. Naturally his results are in his favor, otherwise he would not h…
In fairness, you don't have to tune MongDB poorly (deliberately or otherwise) to get poor performance with a workload involving substantial numbers of writes; it's well-documented that there is a global lock ( http://www.mongodb.org/display/DOCS/How+does+concurrency+wor... ) that prevents reads during write operations. That said, there are certainly nosql systems with better scaling and concurrency stories* than mong…
Just a point of clarification, but it is a per-server lock, not a global lock across the whole database.
Re: MongoDB vs. Clustrix Benchmark
#35Earlier quoted context omitted.
Excellent point. MongoDB doesn't claim to be any faster than other dbs at the simple stuff (in fact, it's often slower because we haven't had years to optimize everything). The speed gains that people usually see are because they can just fetch one document, instead of doing complex joins or aggregations.
Indeed. A lot of the reason I like document databases so much is that you can solve problems differently (and many times, much more easily) than you could in a relational database. Compare: db.posts.find({tags: {$in: ["foo", "bar"]}}) to: SELECT * from posts JOIN taggings ON taggings.post_id = posts.id JOIN tags ON tags.tagging_id = taggings.id WHERE tags.tag IN ('foo', 'bar'); (Single query tag lookup; naively joins…
> (Single query tag lookup; naively joins the entire taggings and tags tables before limiting with WHERE)
Really? Which modern RDBMS database actually works like this when indexes are available?
Index selection and optimization is a standard feature of even the simplest relational database system. JOINs on keys with high selectivity (especially unique keys) are extremely efficient in modern database systems - in some common cases just as efficient as pulling two columns out of the same table. Subselects are something that several database systems (MySQL, for example) really suck at - but they are easily avoided in most schemas.
> Try the "when all tags match" case ($all in MongoDB), and you'll go grey a few years earlier.
Depending on your database engine, even very large AND chains can be extremely efficiently computed on an indexed column. For larger use-cases, there are good ways to avoid this problem using careful schema design.
There are legitimate reasons why relational databases aren't the solution to every database problem. Claiming issues which clearly do not exist is not a good way to get points for the other side.
Re: MongoDB vs. Clustrix Benchmark
#36Price is the elephant in the room here; NoSQL exists because people aren't willing to pay for real databases. Building yet another expensive (i.e. > $0) database that doesn't even work in the cloud won't help the Web 2.0 crowd.
These folks disagree with you. There are many more behind them. http://gigaom.com/cloud/clustrix-lifts-the-curtain-on-early-... And plenty of folks use MySQL (and PogreSQL to a much lesser extent). You just can't scale those.
You can't scale MySQL/PostgreSQL? Care to expand? (Although Facebook's schema is likely an abomination flying in the face of every normalized form, it does run on MySQL. And it's not like throwing PostgreSQL on a big box doesn't go far.)
Re: MongoDB vs. Clustrix Benchmark
#37Another point to notice: He seems to have run his benchmarks under very trivial data-schemas with a single/simple table. A big (speed, simplicity) advantage of No-SQL is the ability to embed lots of data within the parent model and manage a single table where you would have to manage many in a SQL database. I would be very interested to see a comparison where a large and "real" data model (that contains 6-7 "joined"…
Excellent point. MongoDB doesn't claim to be any faster than other dbs at the simple stuff (in fact, it's often slower because we haven't had years to optimize everything). The speed gains that people usually see are because they can just fetch one document, instead of doing complex joins or aggregations.
Serious question, because I don't know: what's the advantage over a denormalized SQL table?
Re: MongoDB vs. Clustrix Benchmark
#38Earlier quoted context omitted.
These folks disagree with you. There are many more behind them. http://gigaom.com/cloud/clustrix-lifts-the-curtain-on-early-... And plenty of folks use MySQL (and PogreSQL to a much lesser extent). You just can't scale those.
Last time I heard, twitter still uses MySQL for the statuses (tweets) table. They did have a plan to migrate to Cassandra, but didn't go all the way through with it. So I find it hard to agree with "you just can't scale those". It may be a lot of work, but for some applications you can scale them. Edit: twitter cassandra link (don't know if this is the latest): http://engineering.twitter.com/2010/07/cassandra-at-twit…
It's worth noting that Twitter has built a lot on top of MySQL to get to the scale they're at. Take FlockDB for example, https://github.com/twitter/flockdb
So I guess that statement should be written as "you can't scale with just those". :)
Re: MongoDB vs. Clustrix Benchmark
#39Winning a benchmark against MongoDB on a non-trivial workload is a little bit like winning the special olympics. I'd be more curious to see how Clustrix performs against Cassandra, Riak or HBase in their respective domains. Those seem to be the more serious contenders when it comes to "Big Data".
I chose Mongo because it gets a lot more attention on HN than any other database. I don't remember the last time I saw a post on Cassandra on here...
I get the impression that Mongo is simple to use and simple to program for; Cassandra is quite good, but also more complicated.
Re: MongoDB vs. Clustrix Benchmark
#40Sergei, I think it was a mistake to put this post on a blog with no other content. I think it leaves the reader with the impression that this is the only thing you want to contribute to the community... and as other commenters have pointed out that contribution could be perceived negatively. Something to think about next time.
Every blog has a first post. What's so bad about that?