Fighting The NoSQL Mindset

http://www.yafla.com/dforbes/The_Impact_of_SSDs_on_Database_Performance_and_the_Performance_Paradox_of_Data_Explodification/

by jbyers • 16 years ago

113 76 16 years ago

yafla.com

The full title of this post is "The Impact of SSDs on Database Performance and the Performance Paradox of Data Explodification" but I thought the first heading summed it up better.

vyrotek• 16 years ago

Great article. I have to admit though, I'm a huge fan of SQL Server :) I would love to see more in depth comparisons.

learnalist• 16 years ago

I too am a huge fan of SQL, what mysql and postgres has given to the world and how it has inspired and set seeds in many of us to use open source, contribute to open source.

I am dipping my toes into couchdb, just to see what all the noise is about.

Still getting my head around map,reduce and the fact im writing in javascript. All that aside the biggest exciting factor for me.

It is so much easier to write custom functions for it than SQL. ( Mysql, and yes I only tried via phpmyadmin )

WorkerBee4• 16 years ago

I too am a huge fan of SQL

Uh, he said "fan of SQL Server", which is Microsoft's SQL product. Fans of SQL Server tend not to be fans of mySQL at all, since SQL Server makes mySQL look like a "bottom-feeder" in the original poster's words. Not that I disagree.

stingraycharles• 16 years ago

I'm getting more and more annoyed by these kind of articles. Why are people talking about NoSQL and relational databases as if they're solving the same problems? There is no "NoSQL" mindset to fight against, and there is no "RDBMS" mindset to fight against: the only mindset to fight against, is a mindset that says a silver bullet exists.

henriklied• 16 years ago

I do not have the vocabulary to explain how much I agree with you. Haven't we gotten to the point where people understand what "use the tool that fits your need" means?

dagheti• 16 years ago

Your criticism of this article is off the mark (though it may apply to other articles). The entire point of this article is that he is trying to replicate the exact same problem that Digg was reporting using a different RDBMS and discussing what that means.

Maybe his numbers are off and his technique is wrong, but this article isn't making a one-sized-fits-all mistake.

tristan_juricek• 16 years ago

Uh, using language like "bottom-feeder RDBMS" and saying that an engineering team is using it "horribly incorrectly on clearly comically deficient hardware" makes this article highly biased, and trollish.

It's pretty clear that this guy things Digg is a bunch of idiot engineers - I mean, why else allude to "rudimentary comp. sci. knowledge"?

These articles might have a central point, but when it's surrounded by a bunch of opinion, it like watching TV news (e.g., Fox News). The real information gets drowned out.

CWIZO2• 16 years ago

I agree with you! And on that note I would like to see more articles that describe problems that NoSQL stuff is good at. This is probably the main reason why there is so much confusion. Everybody is talking about how great cassandra/mongodb/couchdb/... is, but nobody tells you where and how to actually use it.

drhodes• 16 years ago

What I'd like to see are articles that discuss design techniques. Like, how to incrementally develop a key store db without inconsistencies? There's no schema so .. I'm worried about partial records after adding values to the non-schema.

First these addresses didn't have a zipcode field, but now they do. What about relationships between records, isn't there going to be redundant data? What if the user changes their email in the account record, do I have to manually update their contact record? This is what foreign keys are for. OMG, Where am I ... Where's the exit? We're all gonna die!

That's basically what I go through every time I think about it. It's a big scary fully loaded gnarly nested hash table aimed directly at my foot.

Nelson69• 16 years ago

Yes! That's the same stuff I've been smelling. I look at stuff like documents Google has published and Hadoop and I do think to myself that map-reduce and some of the massively distributed stuff could potentially teach RDBMs some new tricks. Then I see these articles and they're all about someone converting a blog from MySQL to MongoDB.

I'd love to see the technical details of how Digg used MySQL, why it was slow and why NoSQL is better, how they use it. The more of this I see and the less real information the more I think they didn't know what they were doing in the first place.

wvenable4• 16 years ago

> Why are people talking about NoSQL and relational databases as if they're solving the same problems?

If you can switch from one to the other and back again, how are they not solving the same problems?

josephruscio2• 16 years ago

Just because you can pound a screw into the wall with a hammer doesn't mean it solves the same problem as a screwdriver.

sjs3• 16 years ago

used to solve a problem != meant to solve a problem

Let's bring up the age-old vehicle analogy. Any vehicle fundamentally solves the the same problem but that's naïve outlook that doesn't acknowledge any specific use-cases. I can drive a truck down the street to get a Coke or ride my bicycle across Canada but that doesn't mean bicycles and trucks are meant to solve the same problem. The differences are obvious when you need to move a pallet of Coke (or 50).

nhebb• 16 years ago

NoSQL vs. RDBMS debates are like traffic accidents. I slow down to look, but I'm happy I'm not involved.

steveklabnik8• 16 years ago

I have a feeling that "I made up a random database as big as Digg's, and look, I'm getting 1000x the speed!!!" would kind of tend to imply that you're not accurately replicating their problem.

TimothyFitz• 16 years ago

Agreed. Reading the digg article I'm interpreting their perf claim to mean "on a loaded server in our cluster, if we try to do this query on a cold cache it takes 1.5 seconds to complete", because this is exactly how I would measure the performance.

When I test the performance of a query, I query a live mysql node (or at least a live replicated standby) of some data that's not actively being used (to give a realistic "cold-cache" scenario, even though the caches aren't necessarily cold).

If digg used this method, it would completely account for performance discrepancy. Digg did not release a benchmark, and trying to treat their findings as a repeatable benchmark is wrong.

gill_bates7• 16 years ago

>Digg did not release a benchmark, and trying to treat their findings as a repeatable benchmark is wrong.

Yet they released record counts, schema, and then performance numbers, and then used their results to demonstrate the failure of the RDBMS (which they led into by saying that it, as some given philosophy, optimizes writes at the cost of reads, hence their poor read performance).

Many of the comments in here are baffling. Digg specifically used the hammer of NoSQL to pound the nail of their database needs, replacing MySQL. They've made a big deal about this. So why the noise about "they're different, man?" And now the petty whines about benchmark methodology when Digg made concrete claims about RDBMS systems?

ars• 16 years ago

Or it implies that digg did a bad job.

spamizbad• 16 years ago

You'd have a pretty low opinion of digg engineers to think they'd optimize that poorly. Which the article author does.

It's actually pretty depressing to see content like this from an alleged Database expert. I've never been able to get 1:1 results between "lab" tests and actual deployments, and I've gone to much greater lengths than the author to simulate workloads.

gill_bates7• 16 years ago

Digg couldn't do a rudimentary join. I'm sorry but if you can read their original entry and not picture an almost comical scene, that you are out of your league.

Now the Joe Plump or whatever guy is telling people that you should sort in PHP. That is the level of expertise of Digg.

steveklabnik8• 16 years ago

I didn't read their original entry. I read an article that was basically "Hurf durf, Digg is retarded, I can do better at home. NoSQL is stupid."

I actually flagged the parent article. It's a troll, and not worth anyone's time. RDBMS is good sometimes. NoSQL is good sometimes. Do we really need _another_ holy war?

madair• 16 years ago

Perhaps you missed the point of the whole exercise: To respond to a high-profile yet poor representation of RDBMS performance.

The OP repeated this reasoning more than once.

He showed that the facts cited by Digg do not make sense unless we take into account poor database technology, poor database configuration, or poor database skills, or all three.

Perhaps you disagree with that. However, that's not what you said above. The OP also discussed the nature of this micro-benchmark, and it's relevance despite his own poor knowledge of the actual data characteristics.

So in other words, he has already directly addressed your concern in advance, more than once on that too as a matter of fact. Considering that fact, you haven't actually responded to his article, you just wrote a "tends to" point about micro-benchmarks, I think it's pretty clear that Dennis Forbes knows a thing or two about benchmarks.

Blah blah blah to empty air, this comment page is pretty much a fact-free and nuance-free flame war anyway, so what's the point, sorta embarrassing for the esteemed HN crowd.

regularfry• 16 years ago

It would have helped the author's case to try (at least approximately) replicating Digg's performance problem on a local MySQL install before switching technologies - that would have given some indication that he'd made the right assumptions about the problem and wasn't testing something unrelated. No matter how good the author is (and I've got no reason to suspect that he's anything other than a top-rate engineer), it's awfully easy to be led down a blind alley on this sort of problem.

steveklabnik8• 16 years ago

> you just wrote a "tends to" point about micro-benchmarks

I am not a database guy. I also don't know enough about Digg's set up to say with authority if these comments make sense. So I specifically wrote "I feel," "tends to," and "imply" because I'm not comfortable making an absolute statement about the issue.

However... I don't see how this test is in any way relevant. a 30GB database? Running on totally different hardware?

In any case, re-reading the article again, I see that relevance paragraph now. I guess I missed it the first time around between all of the flaming, trollish comments about both NoSQL and MySQL. But I still don't see how we can extrapolate this test in any way to imply anything about Digg's practices at all. Then again, it's 8:30am.

psadauskas• 16 years ago

After experiencing how easy it is to get started on and develop against MongoDB, I feel like RDBMS are a premature optimization. Its so much easier to evolve your data model, and write arbitrary queries, and its plenty fast enough for 90% of the web apps out there. Save the RDBMS for when you have relational data that needs to be faster, or whatever other feature you happen to need for that part of your app.

jpcx012• 16 years ago

Great point. The thing I'm interested in on these new data storage technologies is at the low level, rapid development, early stage (low traffic) portion of a project since thats where I'm at.

I'd rather be able to remove barriers like having to design a schema, and get some early efficiencies to develop my app fast and iterate.

Though, my experience in scaling every site that needed to be scaled has concluded with sharding. So MongoDB sort of fits there as well with its autosharding capabilities.

Vitaly• 16 years ago

nosql databases do not free you from having to design your schema! they do free you from having to run migrations, but those are trivial while you are small, migrations are only a problem when you have huge tables. With nosql dbs you can skip migrations and do 'repair on read' schema changes, but you still need to design your schema. and coming from sql world, designing nosql schemas can be a lot of pain since you have to change your perspective completely. and crazy naming (of cassandra and other big-table derivatives) doesn't help either: wtf is column family, etc :).

DennisP• 16 years ago

Exactly. If Cassandra fits my needs, I've got a fast, trivially-scalable database that basically needs no administration, for free. Why would I spend money on a commercial sql database?

That said, Cassandra won't always fit my needs. Sometimes I really do need sophisticated queries and arbitrary transactions. I've been enjoying this guy's articles, because he's bringing up a lot of good performance tips for those times when a relational database is the right tool for the job.

astrec• 16 years ago

Where are the writes?

rbranson2• 16 years ago

Exactly what I'm asking. Anyone can make read benchmarks fast. He's adding index optimizations such as clustering that kill write performance. Balance please.

gill_bates7• 16 years ago

The original Digg entry specifically makes the entire point that Digg is willing to sacrifice write performance to improve read performance (which they did to a massive degree with Cassandra), and then demonstrated how absolutely horrendous their read performance was.

Need more be said? Seriously?

sjs3• 16 years ago

> Alternately you can just clutch onto NoSQL and bleat about how it changes all of the rules anyways, which is the route quite a few have decided to pursue.

Bath water and baby gone without a second thought.

Not to mention that later the author says:

> SSDs change everything.

To which I say: "Or you can clutch onto SSDs and bleat about how they change all of the rules anyway, which is the route this author has decided to pursue."

rbranson2• 16 years ago

Silly us. The engineers at Google and Amazon also don't know what they're doing either. They should go back to computer science class and let the big boys and SQL Server run the shop.

gill_bates7• 16 years ago

Wow, did the article say somewhere that Google and Amazon don't know what they're doing? I don't believe it did. In fact I think it quite specifically questioned some performance claims that aren't valid.

houseabsolute4• 16 years ago

It's a different problem. I can get a database that holds 30 GB, although I suspect the actual DB was much larger. I can't get a database that holds >PB.

schammy• 16 years ago

The problem with this article is that he is testing as ONE ACTIVE USER, as if only one person was ever using digg at any given time. Of course the queries are going to return thousands of times faster. Try replicating digg's actual environment, which I know nothing of, but I know the site gets a ton of traffic and probably has between 10-50,000 users online at any given time.

Now run the same queries you were doing again on your test machine, but simulating 50K users online at once. Oh, and don't forget about thousands of writes per second, which was conveniently not part of this test. What's that you say? The performance is suddenly complete shit? Color me shocked.

wanderr• 16 years ago

I was going to mention the same thing: there isn't even a mention of the word concurrency in the whole article.

WorkerBee4• 16 years ago

Oh, and don't forget about thousands of writes per second, which was conveniently not part of this test. What's that you say? The performance is suddenly complete shit?

I'm not convinced that read performance has to suffer for writes. Reads don't have to block writes or block for writes - use the NOLOCK hint.

Confusion2• 16 years ago

These examples always end up being "we moved from MySQL to NoSQL" rather than "We moved from Sybase ASE to NoSQL"

That's because there's a zillion MySQL installs out there, with users that talk about them. On the contrary, there are a lot less Sybase installs out there and their (corporate) users don't talk about them. Go figure that you only hear about MySQL. But please, keep on spreading the FUD; that just gives us the edge of using a free, OSS, system.

DISCLAIMER: This is not a high-fidelity reproduction of Digg's situation

And it's probably not even a low-fidelity reproduction. The article gives us no reason to suppose he actually knew or understood the problem Digg had. He just shows that it was not a trivial one, as that would've been easy to solve.

quicksilver03• 16 years ago

Equating MySQL with the all of the other RDBMS systems out there seems the other cardinal mistake of those discussions. Just do

sed s/NoSQL/NoMySQL/

and avoid the confusion.

apower• 16 years ago

Judging from the comments here, people don't seem to know basic database or rdbms concepts or usage.

rythie• 16 years ago

Cassandra is about scaling writes not reads.

MySQL is slow on writes because you'll get a random write for every index you maintain (+the table it's self). MySQL's replication will help scale reads but does nothing for writes. Cassandra is actually said to be slower on reads and it's thought people will already be using memcache so it's not a problem.

The article doesn't seem to have any writes going on while he is reading.

sliderr• 16 years ago

And then suddenly your nice MSSQL database machine explodes, leaving you wondering why you didn't go for a fault tolerant system.

WorkerBee4• 16 years ago

There is lots of stuff in SQL server for backups, hot spares, clustering. It can be fault-tolerant if you set it up that way. I wonder if you knew about that functionality, and if not, why make claims in ignorance.

Fighting The NoSQL Mindset

Related Stories