3 ms·

> 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 architect

by cx01 17y ago

> 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).

antirez 17y ago
Yep but I read in the article: > 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.
- cx01 17y ago
  > 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). He's going to do that in the next blog entry.

by cx01 17y ago

antirez 17y ago

Yep but I read in the article: > 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.

cx01 17y ago
> 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). He's going to do that in the next blog entry.