8 ms·

Fighting The NoSQL Mindset

113 points by jbyers 17y ago

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 17y 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 17y 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 )
  - WorkerBee 17y 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 17y 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 17y 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 17y 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 17y 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.
    - wvenable 17y ago
      MySQL is a good product, but it does have some significant failings when it comes to getting top-notch performance out of indexes. Digg's description of their entire setup seems a bit unusual -- from how they've defined their tables to their query methods. It seems at least somewhat likely that they were not making optimal use of their technology. I'd be curious what the traffic/content difference between Digg and Stackoverflow is. Stackoverflow uses an architecture very similar to what Forbes proposes here and they have plenty of capacity on rather unremarkable hardware.
      - jbellis 17y ago
steveklabnik 17y 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 17y 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_bates 17y 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?
    - jpcx01 17y ago
      I think the parent author's main point is they used a defective RDBMS as a representative example of all. MySQL does not do certain things well. However many mature RDBMS's have solved these problems and its worth pointing that out before you drop the entire class of tools for the next shiny tech.
psadauskas 17y 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.
- jpcx01 17y 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 17y 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 17y 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 17y ago
Where are the writes?
- rbranson 17y 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_bates 17y 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?
    - skorgu 17y ago
      Cassandra is hugely biased towards making writes fast [1] and there's no indication in either Digg article that they (somehow) changed that fact in their deployment by tuning. Digg loads the complexity during the write by denormalizing but that load is on the application server not the data store. [1] http://spyced.blogspot.com/2010/01/cassandra-05.html http://spyced.blogspot.com/2010/01/cassandra-05.html
sjs 17y 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."
deleted 17y ago
[deleted]
rbranson 17y 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_bates 17y 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.
- houseabsolute 17y 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 17y 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 17y ago
  I was going to mention the same thing: there isn't even a mention of the word concurrency in the whole article.
- WorkerBee 17y 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.
Confusion 17y 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 17y 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 17y ago
Judging from the comments here, people don't seem to know basic database or rdbms concepts or usage.
rythie 17y 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 17y ago
And then suddenly your nice MSSQL database machine explodes, leaving you wondering why you didn't go for a fault tolerant system.
- WorkerBee 17y 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.

113 points by jbyers 17y ago

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 17y 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 17y 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 )
- WorkerBee 17y 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 17y 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 17y 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 17y 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 17y 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.
  - wvenable 17y ago
    MySQL is a good product, but it does have some significant failings when it comes to getting top-notch performance out of indexes. Digg's description of their entire setup seems a bit unusual -- from how they've defined their tables to their query methods. It seems at least somewhat likely that they were not making optimal use of their technology. I'd be curious what the traffic/content difference between Digg and Stackoverflow is. Stackoverflow uses an architecture very similar to what Forbes proposes here and they have plenty of capacity on rather unremarkable hardware.
    - jbellis 17y ago

steveklabnik 17y 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 17y 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_bates 17y 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?
  - jpcx01 17y ago
    I think the parent author's main point is they used a defective RDBMS as a representative example of all. MySQL does not do certain things well. However many mature RDBMS's have solved these problems and its worth pointing that out before you drop the entire class of tools for the next shiny tech.

psadauskas 17y 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.

jpcx01 17y 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 17y 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 17y 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 17y ago

Where are the writes?

rbranson 17y 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_bates 17y 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?
  - skorgu 17y ago
    Cassandra is hugely biased towards making writes fast [1] and there's no indication in either Digg article that they (somehow) changed that fact in their deployment by tuning. Digg loads the complexity during the write by denormalizing but that load is on the application server not the data store. [1] http://spyced.blogspot.com/2010/01/cassandra-05.html http://spyced.blogspot.com/2010/01/cassandra-05.html

sjs 17y 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."

deleted 17y ago

[deleted]

rbranson 17y 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_bates 17y 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.
houseabsolute 17y 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 17y 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 17y ago
I was going to mention the same thing: there isn't even a mention of the word concurrency in the whole article.
WorkerBee 17y 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.

Confusion 17y 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 17y 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 17y ago

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

rythie 17y 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 17y ago

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

WorkerBee 17y 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.