4 ms·
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 sq
by 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 agoAh, "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 agoIt'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.
- zaphar 12y agoThey make the claim within the broader context of being a sql database. It's perfectly reasonable to consider the claim within that context. Just taking the single phrase without considering the broader context the phrase was made in is not fair to sqlite.
- Dylan16807 12y ago>Do you see "SQL" anywhere in "small, fast, reliable"? You're right! It hasn't baked me a cake, what the hell? Context is key. It's a database, it does database things. A key-value store with no relations is a different beast.
- dragonwriter 12y ago> Do you see "SQL" anywhere in "small, fast, reliable"? I see it all over the place -- the front page of SQLite.org -- where the motto "Small. Fast. Reliable. Choose any three." is presented. Here's the first paragraph of body text from the page: (emphasis added) "SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world. The source code for SQLite is in the public domain." The place they are telling you that the context is "SQL database engines" rather than just "database engines" is the same place they tell you that the context is something related to database engines as opposed to, say, automobiles.
- nnethercote 12y ago> Do you see "SQL" anywhere in "small, fast, reliable"? No. But I do see it in "SQLite".
- aidenn0 12y agoFWIW: I had never heard of MDB, and saw it performed really well on the benchmark, so I decided to look it up. I found this page: http://symas.com/mdb/ http://symas.com/mdb/ They don't even mention sqlite in the comparison section on that page because they compare themselves to other embeddable "key value stores" which sqlite isn't. If you look closely you'll even see that there is even an MDB backend for sqlite. It's not a "no true Scotsman" when the products are so clearly different.
- notacoward 12y agoYes, if you compare it only to things that are exactly like it then it will be in the top percentile. Also the bottom. That doesn't seem very useful. What other embeddable SQL databases should it be compared to? If you don't think this comparison is the correct one, tell me which comparison is. I'll go get the numbers, and I bet I'll still find that SQLite is still neither small nor fast by comparison. Otherwise all this goalpost-moving makes it impossible for anyone to prove anything (not that the pro-SQLite contingent is even trying). Balancing full SQL semantics with being small enough, fast enough, and commendably reliable is an impressive achievement. I respect the SQLite authors for that. If they had picked any three of "small, fast, reliable, SQL" I would never have objected. BUT. THEY. DIDN'T. They left "SQL" out, opening the comparison to others. For many people who need an embeddable database, a key/value or generically table-oriented (but not fully relational/SQL) database is quite sufficient. For them, a claim based on an unstated and irrelevant fourth criterion, against equally unnamed alternatives, is either useless or misleading. But that's apparently the only kind of comparison the herd will accept.
- aidenn0 12y agoI was comparing it to other relational stores, not other embeddable stores. It works both ways too though, it's very small fast and reliable compared to Chrome or Outlook, which both can store data...
- rakoo 12y agoOf course they do compare it with SQLite 3: http://symas.com/mdb/microbench/ http://symas.com/mdb/microbench/