Guys, please check his Wikipedia page before starting some random rambling. This guy is a living legend and has several of the most prestigious awards. He also is/was an entrepreneur and large DB corp CTO. Oh, and a very early open source advocate and developer. Among many other things.
Don't say something stupid just because you like NoSQL. In fact, he was an early and strong critic of the one-size-fits-all commercial RDBMS solutions.
[...] These papers presented reasons and experimental evidence
that showed that the major RDBMS vendors can be outperformed
by 1-2 orders of magnitude by specialized engines in the data
warehouse, stream processing, text, and scientific database
markets.
1-2 orders of magnitude, that is in the range of 2-99 times faster.
And in particular, if you didn't read at least 5 of his papers you can't pretend to have a clue about how database engines, and in particular the major RDBMS, work.
Thanks.
[A n00b DB engine writer, currently working on a non-SQL database]
PS: If I get to achieve 10% of what he did so far in his life I'd consider my life amazing. And he is still making new things. Respect!
I'm a bit shocked by your post. So because he is a living legend one should not say nothing before reading all the papers cited even if from the article his point is already clear and one may say something meaningful even as a modest developer?
I'm going to say one for instance: the article's main point is about the fact that because of a threaded and disk-based architecture you can't get much faster than well engineered SQL architectures. For instance Redis is completely excluded from this reasoning, being in-memory and single-threaded.
Another point: where are the numbers? For instance I can trivially give proof that Redis can handle 150,000 operations/second per core in a decent Linux Box. I want to know what's the performance of the SQL solutions cited in the article.
Another one: all the SQL solutions cited in the article are names I never heard before of today. NoSQL DBs are tar.gz you can download for free from sites and compile now without paying nothing.
> the article's main point is about the fact that because of a threaded and disk-based architecture you can't get much faster than well engineered SQL architectures.
I disagree. His main point is that current SQL databases are slow not because they use SQL but because their implementations suck. He then lists 4 areas where the implementations spend most of the time and argues that all of them can be eliminated (how this should be done is explained in the linked paper).
> Second, many No SQL systems are disk-based and retain a
> buffer pool as well as a multi-threaded architecture. This
> will leave intact two of the four sources of overhead above.
That's not always true.
For the other points, please give me the download link of this SQL database that can scale without problems (I want an opensource one since I'm a cheap startup).
Also scalable != fast, it only means that adding more nodes I can scale, possibly almost linearly, but again for startups that are cheap it is also very important how many boxes you are going to need, so it's important to have numbers about this superior SQL engines to do some math.
That said the article is interesting, as the idea is more or less that in theory it's possible to build SQL databases that are very scalable and that mostly our problems in the past where about poor implementations. I guess this is true, but I can't imagine how an ACID SQL system is without overhead compared to a key-value store, even when the right technology is used for the implementation. The only fix for this is to show numbers.
Well also I don't think at all avoiding SQL is a bad idea, but the author wrote in this article he is going to show how the other NoSQL claim is false (the claim is that SQL sucks at modeling a lot of problems).
Anyway the author resembles a lot Adam from Battlestar Galactica and this is a good point.
> For the other points, please give me the download link of this SQL database that can scale without problems (I want an opensource one since I'm a cheap startup).
He didn't say that there are such systems, but that he expects them in the next years.
> so it's important to have numbers about this superior SQL engines to do some math.
In the paper he talks about speedups of 1-2 orders of magnitude compared to current OLTP systems.
> I can't imagine how an ACID SQL system is without overhead compared to a key-value store, even when the right technology is used for the implementation.
If he is right, then there should be no big difference (maybe 10-20%) between a SQL system and a key-value store, assuming that both offer the same ACID guarantees, because most of the complexity lies in the ACID guarantees and not in the data-storage itself.
> Well also I don't think at all avoiding SQL is a bad idea, but the author wrote in this article he is going to show how the other NoSQL claim is false (the claim is that SQL sucks at modeling a lot of problems).
"I want to know what's the performance of the SQL solutions cited in the article."
Vertica will happily arrange for a demo, and they even have a fast track for getting a cluster up on ec2. Teradata, Greenplum and the others you're dealing with the traditional enterprise sales process (bleh).
"all the SQL solutions cited in the article are names I never heard before of today."
This is sort of the point. While they may only be represented in the enterprise market rather than in FOSS, there are linearly scalable database products available today. For businesses that have the funding, these can have huge advantages over the options being birthed by NoSQL (as well as drawbacks).
And the larger point is that the majority of the OSS world working on NoSQL (or Mysql Cluster for that matter) is somewhat ignorant of the parallel database research of the 80's. I'd suggest starting with the position paper "End of an Architectural Era", and then continuing with DeWitt's publications.
Don't say something stupid just because you like NoSQL. In fact, he was an early and strong critic of the one-size-fits-all commercial RDBMS solutions.
1-2 orders of magnitude, that is in the range of 2-99 times faster.And in particular, if you didn't read at least 5 of his papers you can't pretend to have a clue about how database engines, and in particular the major RDBMS, work.
Thanks.
[A n00b DB engine writer, currently working on a non-SQL database]
PS: If I get to achieve 10% of what he did so far in his life I'd consider my life amazing. And he is still making new things. Respect!