Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's Time to Stop Building KV Databases

buttondown.com

Post reply on HN
Print view View original

61–64 of 64 posts

Re: It's Time to Stop Building KV Databases

#61

Post by em-bee »

em-bee wrote: post #54
funcDropShadow wrote: post #50

Earlier quoted context omitted.

Object stores are not filesystems. They have a paths, but they are not hierarchical.

unless it's a hierarchical object store, like the one i am using.

thinking more about this, the difference between a hierarchical and non-hierarchical storage i the existence of additional indexes representing the hierarchy.

in most filesystems files are addressed by an inode. and directories are just lists of inodes. if you remove those then you end up with a KV store: inode->file.

consequently i see no difficulty to convert a KV store into a hierarchy by adding the necessary tables/directories representing the hierarchy.

Re: It's Time to Stop Building KV Databases

#62

Post by mamcx »

Spivak wrote: post #8

Finally! Someone else reaching the conclusion that the query planner is really annoying and for most queries I would just like to skip it. I don't want the dynamic nature of the planner. I don't want to send SQL over the wire, I want to send the already completed plan that I either generated or wrote by hand. So many annoying performance bugs are because the planner did the slow thing. Just let me write/adjust it.

Is weird, but what the OP was asking for, actually exist before in the case of FoxPro and similar tools.

In Fox, you write more or less `physical query plans` as syntax:

   USE customer  && Opens Customer table
   CLEAR
   SCAN FOR UPPER(country) = 'SWEDEN'
      ? contact, company, city
   ENDSCAN
And what it make this even better, is that you can also write `SQL` so you can have the best of both worlds.

BTW, I think this idea can be move even further and my take is at https://tablam.org

Re: It's Time to Stop Building KV Databases

#63

Post by funcDropShadow »

em-bee wrote: post #61
em-bee wrote: post #54

Earlier quoted context omitted.

unless it's a hierarchical object store, like the one i am using.

thinking more about this, the difference between a hierarchical and non-hierarchical storage i the existence of additional indexes representing the hierarchy. in most filesystems files are addressed by an inode. and directories are just lists of inodes. if you remove those then you end up with a KV store: inode->file. consequently i see no difficulty to convert a KV store into a hierarchy by adding the necessary tabl…

In a hierarchically system renaming a directory is an O(1) operation, in a non-hierarchical system with paths it is an O(n) operation.

Re: It's Time to Stop Building KV Databases

#64

Post by em-bee »

funcDropShadow wrote: post #63
em-bee wrote: post #61

Earlier quoted context omitted.

thinking more about this, the difference between a hierarchical and non-hierarchical storage i the existence of additional indexes representing the hierarchy. in most filesystems files are addressed by an inode. and directories are just lists of inodes. if you remove those then you end up with a KV store: inode->file. consequently i see no difficulty to convert a KV store into a hierarchy by adding the necessary tabl…

In a hierarchically system renaming a directory is an O(1) operation, in a non-hierarchical system with paths it is an O(n) operation.

the KV store i am talking about doesn't use paths, it uses IDs. the paths are in a hierarchical directory that is added on top of the KV store, or alongside of it. the result is a filesystem.
Post reply on HN