4 ms·

> Small. Fast. Reliable. Choose any three. Nice tag line.

by rbobby 12y ago

notacoward 12y ago
Cute, but inaccurate. Small? Not quite. http://symas.com/mdb/microbench/ http://symas.com/mdb/microbench/ Fast? No again. http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html Note that LevelDB itself isn't exactly the speed king here. It's just the clearest example. To its credit, SQLite does fare well when it comes to reliability. https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf https://www.usenix.org/system/files/conference/osdi14/osdi14... So ... choose one? (Downvotes from those who despise facts in ... oops, already happened.)
- erikb 12y ago
  I disagree. You can be not the smallest and still be small, etc. Still I think people should not downvote because they disagree. Especially the links in that post are quite valuable!
  - notacoward 12y ago
    Yes, it can be small without being the smallest, but such a claim should at least require being smaller than average/median for the category. In that example, it had a much larger footprint than the majority. If not for the inclusion of Brobdingnagian BDB, it would have been the largest. If I want to claim I'm strong, it's not sufficient for there to be only one who is weaker. Among embeddable databases, SQLite has no real claim to be small or fast. Its strengths lie elsewhere.
    - erikb 12y ago
      Seems reasonable. What is its strength if not being small?
- zaphar 12y ago
  Within the space of sql databases they get all three. Writing to /dev/null beats leveldb anyday, only problem is I can't get the data back out. A leveldb to sqlite comparison doesn't is unfair to both leveldb and sqlite.
  - notacoward 12y ago
    Ah, "no true Scotsman" rears its head again. Why limit the space to SQL databases? Many applications that need an embeddable database don't specifically need SQL. You're right that comparing LevelDB to SQLite isn't quite fair to either, but they invited the comparison with a slogan that makes comparative claims. It's not unfair to provide citations relevant to those claims, which you don't seem to have done BTW.
    - dragonwriter 12y ago
      > Ah, "no true Scotsman" rears its head again. Why limit the space to SQL databases? "SQL" is probably generally less important than relational, but either might be an important category. > Many applications that need an embeddable database don't specifically need SQL. And yet, many do, or at least need a relational store. To make comparisons, you have to define the category you are making them within; of course, any such category may not be the appropriate one for some comparisons -- either too narrow, too broad, or the right size but divided on the wrong axis -- but that's a matter of where the comparison is relevant. OTOH, its simply wrong to say that a claim is wrong simply because it isn't based on your preferred categorization.
      - notacoward 12y ago
        It's equally wrong to say the claim is correct because it's based on somebody else's preferred categorization. Do you see "SQL" anywhere in "small, fast, reliable"? They made a broad claim. They should be the ones to provide evidence or clarification. Why are those standards only applied to those who point out that the claim is unproven? That seems a lot like changing the terms of the argument (asymmetrically!) to fit a preordained conclusion.

> Small. Fast. Reliable. Choose any three. Nice tag line.

by rbobby 12y ago

> Small. Fast. Reliable. Choose any three. Nice tag line.

Cute, but inaccurate. Small? Not quite. http://symas.com/mdb/microbench/ http://symas.com/mdb/microbench/ Fast? No again. http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html Note that LevelDB itself isn't exactly the speed king here. It's just the clearest example. To its credit, SQLite does fare well when it comes to reliability. https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf https://www.usenix.org/system/files/conference/osdi14/osdi14... So ... choose one? (Downvotes from those who despise facts in ... oops, already happened.)

erikb 12y ago
I disagree. You can be not the smallest and still be small, etc. Still I think people should not downvote because they disagree. Especially the links in that post are quite valuable!
- notacoward 12y ago
  Yes, it can be small without being the smallest, but such a claim should at least require being smaller than average/median for the category. In that example, it had a much larger footprint than the majority. If not for the inclusion of Brobdingnagian BDB, it would have been the largest. If I want to claim I'm strong, it's not sufficient for there to be only one who is weaker. Among embeddable databases, SQLite has no real claim to be small or fast. Its strengths lie elsewhere.
  - erikb 12y ago
    Seems reasonable. What is its strength if not being small?
zaphar 12y ago
Within the space of sql databases they get all three. Writing to /dev/null beats leveldb anyday, only problem is I can't get the data back out. A leveldb to sqlite comparison doesn't is unfair to both leveldb and sqlite.
- notacoward 12y ago
  Ah, "no true Scotsman" rears its head again. Why limit the space to SQL databases? Many applications that need an embeddable database don't specifically need SQL. You're right that comparing LevelDB to SQLite isn't quite fair to either, but they invited the comparison with a slogan that makes comparative claims. It's not unfair to provide citations relevant to those claims, which you don't seem to have done BTW.
  - dragonwriter 12y ago
    > Ah, "no true Scotsman" rears its head again. Why limit the space to SQL databases? "SQL" is probably generally less important than relational, but either might be an important category. > Many applications that need an embeddable database don't specifically need SQL. And yet, many do, or at least need a relational store. To make comparisons, you have to define the category you are making them within; of course, any such category may not be the appropriate one for some comparisons -- either too narrow, too broad, or the right size but divided on the wrong axis -- but that's a matter of where the comparison is relevant. OTOH, its simply wrong to say that a claim is wrong simply because it isn't based on your preferred categorization.
    - notacoward 12y ago
      It's equally wrong to say the claim is correct because it's based on somebody else's preferred categorization. Do you see "SQL" anywhere in "small, fast, reliable"? They made a broad claim. They should be the ones to provide evidence or clarification. Why are those standards only applied to those who point out that the claim is unproven? That seems a lot like changing the terms of the argument (asymmetrically!) to fit a preordained conclusion.