undefined | Better HN

0 pointsznpy3y ago0 comments

if i was an sqlite user, i really wouldn't care at all about google switching from sqlite to that thing in chrome.

From the readme:

> LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values.

it's a completely different thing from sqlite. sqlite is a relational database (which can also do key-value storing, I guess).

my educated guess is that google started with sqlite, then reached the peak usefulness *within chrome* and only then switched to developing its own custom solution.

if anything, this is a testament to sqlite and how far you can go with it before needing a custom solution.

0 comments

rasz3y ago

Thats nice and all, but Im a Chromium user who wants to manually audit and edit my \User Data\Default\Local Storage. That wasnt a problem in sqlite days, tons of tools available. Switch to leveldb not only made that difficult (one paid GUI tool in existence afaik), but also introduced a change in localstorage behavior. Chrome localStorage used to return entries sorted by key, this is no longer the case.

IX-1033y ago

I believe Chrome has deprecated LevelDB at this point. It turns out that LevelDB doesn't work well when you need many different databases in a single application. So all new Chrome storage is SQLite. At least until they find something better...

znpyOP3y ago

Whatever, blame it on chrome/chromium.

We’re talking sqlite here, your comment is off-topic.

vlovich1233y ago

A key-value store can underpin a SQL layer. Look at CockroachDB's usage of RocksDB (which is a descendant of LevelDB). Seems like a fair comparison to compare BTrees and LSM approaches. The latter work better because they align more closely with how solid state storage works. BTrees require a fair bit of pointer chasing for reads and are expensive to modify.

j / k navigate · click thread line to collapse