Is LevelDB a Database?

I think you’re talking about a relational database. LevelDb is not that. I don’t think you need those features for folder browsing though.

It’s not even a database…

1 Like

That’s disingenuous. It is a place to store data, and that makes it a database. The folks at Google who invented it and put the “DB” in the name would also want you to appreciate that.

1 Like

Then you might call Excel a “database,” too.

Even better reason to be highly skeptical of it.

Lots of things have “DB” in the name. It does not make them so. It’s a key-value store, and not a very good one at that apart from, possibly, some very specific use cases inside of Google. It’s not even fully maintained anymore.

Look here:

This is the first page of the leveldb documentation on GitHub…

It’s a damn database…

I’m not saying LevelDb is not a database, but their own docs are not the best arbiter. (The official name of North Korea is “Democratic People’s Republic of Korea”.)

3 Likes

A database being a database is not so much about technical attributes but rather the developers’ intent for its use. If it’s a technology whose principal intent is to store data in a way that is more or less separate from the use of that data, developers will generally categorize it as a database.

Apart from that, I take no issue with your distaste for LevelDB at all. One may not like something, and one has every right, but that doesn’t change what something is - let’s take Nickelback as an example…

:cold_face:

:man_facepalming: It is a rather stupid key-value store. It is a database by some very loose definition. But then so is an INI file or a box with spare and unneeded cables in my garage (I am pretty sure there are some parallel printer cables with Centronics connectors, but, making the analogy quite apt, it’d take me a day to find out for sure).

Really, if anyone came to me proposing to use LevelDB as a database for any kind of system that needs to handle searchable interconnected sets of information, I’d throw them out the door with a “strong no-hire” .

I can sort of understand not using a proper RDBMS in a project like Roon if you do not have sufficient relational algebra skills and don’t quite know what your schema will end up looking like (although it is the only proper way of doing it). But jeez, at least use something that does relationships and indices!

1 Like

SO I guess if one drives nails in with a microscope that makes it into a hammer…

Only in the widest and most loose definition (but again, then a Word document with your shopping list is a “database” too). Generally when we talk about databases we’re talking about something more than a library that lets you look up a single value by a key. You could build a database out of it (and there are a few built on top of LevelDB) but unless you are angling for a promotion at Google there is no reason to do that – there is a vast number of existing products, both free and commercial, which already provide well-tuned and tested functionality that would fit Roon just fine. You could do it with MUMPS, which is 1960s tech, and I have a very strong hunch it would work better than the LevelDB implementation…

Oh, and let’s not!!

No, because that information is not generally intended to be used by another system or application. Same for Excel. And in scenarios like Access or FileMaker, the data is segregated—maybe abstracted is a better word—to one extent or another, from the UI that is used to interact with it.

Are we really arguing this? This is how we use our time?

Database’s, or the definition of “Database”, has more to do with the way data is put into the datastore, how it is retrieved, and if that data is optimized in anyway to make one of those two, or both, things faster. LevelDB is designed for fast data retrieval. The “tree” or index that is created and the way it keeps a large portion of recently retrieved objects resident in memory makes it a database.

Is Excel a database? No (well, yes, it can be but I will say no as I’m trying to get my co-workers to stop using it this way. But, there are ways O365 has taken Excel to a point it can be and is being used as a database. Like to the backend of PowerApp and Sharepoint apps). It has no data optimization techniques. That does not stop my co-workers from using it like a database.

Is Word a database? No. Again, storing things in XML with no optimization of data input / retrieval.

LevelDB is excellent because it’s portable, allows for direct access via the application (you don’t need to run a server), and is fast for data retrieval. Where LevelDB kind of falls down is that it isn’t designed with data resilience built-in as that’s left to the user. There are forks of LevelDB that try to deal with this.

But, to say that LevelDB isn’t a database because it’s key-value storage is misunderstanding different database types. There are lots of ways to store data. There are lots of ways to make that data relate or purposely not make it relate. It all depends on the goals of why you want to store and retrieve data.

Now, can we get back to the music?

1 Like

If LevelDB is a “database”, then any file system is also a database – a key-value store used by other applications. LevelDB is simply an abstraction of a file system.

The word “database” was coined in the early 1960s to describe something more complicated and more useful than a file system. Key-value databases recapitulate the various problems database pioneers like Bachman and Codd spent the 1960s and 1970s trying to stamp out! Multiple keys, data anomalies, lack of indices, multiple record types, etc. Bachman described the simple key-value store (a glorified hash table) as being “one-dimensional”. He emphasized that programmers needed to navigate an N-dimensional space and that databases needed to be appropriately structured to support that.

1 Like

It’s intended to be used b you, searching for things you still need to buy, and crossing out (updating) ones you’ve already bought. So it’s only a minor difference from what LevelDB provides.

Probably better than arguing SQ differences between releases of Roon…

It’s a data store. Supposedly, sort of fast, but it has no indices other than the key to look up the valuer by.

People have been using Excel as a database since the very first version. It’s the scourge of IT. There are even ODBC and OLEDB drivers for it. So it’s probably more of a database than Level.

It’s also pretty much useless for accessing the data in a way you did not foresee when you started with it.

And embedded portable databases you can use with a .Net application are dime a dozen.

Funny how a “key value” isn’t one of the database models in that article.

In any case, this is more of a semantic discussion…

1 Like

Most of things like LevelDB are bad rehashes of what has been around since 1960s written by people who are very good at algorithms but not so good at knowing what happened before they were even born. And at Google this is a good way to get promoted, promotion process being in no way related to doing anything useful.

A friend of mine is kind of a serial database entrepreneur, and the things he says about the complexity of modern graph and relational databases are enlightening. Lots of exploitation of specific hardware features to increase performance.

Maybe it was written by an intern.

Is leveldb a database. Yes, it is.

The question really should be, imho, was leveldb the right database for this job? What we don’t know is what the original database requirements were for Roon. @ipeverywhere mentioned portability as a potential reason for it’s use, and that I’m pretty certain was a factor. There are others which we are not privy to that informed Roon’s decision to use it. Without knowing what the goals were/are, its hard to evaluate the decisions made.

3 Likes