Hacker News Reader

Comment by asutherland | Hacker News Reader

The SQLite numbers are not going to be realistic here given that "no SQLite transactions" are used and the write-ahead-log is probably not used. Assuming defaults are used, that means "PRAGMA synchronous=FULL" and "PRAGMA journal_mode=DELETE" (so no Write-Ahead-Log). This means every mutating statement is potentially going to result in multiple fsync() operations. See https://www.sqlite.org/pragma.html for context.

View on HN

This is one example of the pitfalls of making decisions "based on data", as is now the fad. Turns out that your data probably sucks or doesn't measure what you think it does. It's better to not know than to know the wrong thing. A posteriori data analysis can be great, but nothing can beat a priori understanding. Ideally, you should be using your data to get to that understanding, not replace it.

Great point. The phrase "garbage in, garbage out" seems relevant.

I always like reading comments on these types of analyses, since they often use the author's data to help me understand what might have been overlooked (which I often would have overlooked also!).

I didn't use any of the sophisticated stuff at all. As article states, I did it like what a typical programmer might have done if he wanted to do some basic key-value storage.

Please put a note in your article explaining this. SQLite is literally 10x faster using the WAL vs standard mode. And while you're at it, please consider an index on the SQL server and SQLite tables, so the reads are faster as well.

I would love to see the article updated using SQLite's PRAGMA journal_mode = WAL and PRAGMA synchronous = NORMAL. Then it would be a much more fair comparison.

Please don't give programmers a license to be lazy and not learn about their tools!!! If this article is trying to inform, or give benchmarks, it should not come to invalid conclusions without explaining the tradeoffs.

Yep have tried it with WAL and it still doesn't beat LevelDB. Thanks for the lazy suggestion I added disclaimer on top of the page right away!

But what is the point of your page? If it's to make recommendations then go a step further and include changing a setting or two for better recommendations.

Considering your background and endorsement of nosql databases, it comes off as more of a puff piece if you don't actually try to make the other db's run fast. It especially seems that way when you tout it as "blazing fast compared to any other storage solutions", and then proceed to test it in one narrow setup.

That noted, you said that you used the default settings, and I'd be curious if there are settings for LevelDB that could be changed to make it faster.

I'd be interested if you did more tests explore more than just one particular setup.

Edit: I realized that this may have come off a little negative. Overall I think it's nice, but seems less applicable than you make it seem.

So--this is really more of a statement of how the typical programmer doesn't RTFM than a comparison of the capabilities of the technologies.

SQLite is NOT a key/value store, it's a full featured SQLDB, and hence the default parameters are set to serve this purpose.

Comparing it to levelDB is like comparing redis to postgres with default value.

You can use postgres as redis. You can actually use the key/value store engine and tweak the settings to get very nice performance out of it. But it's not the default behavior.

Reply on news.ycombinator.com