Hacker News Reader

Comment by spullara | Hacker News Reader

If you are willing to optimize for a KV store with distributed transactions you can do a lot better than putting a SQL layer on top of it.

View on HN

Not sure what you mean by that. Consus seems to be directly inspired by Google's Spanner, which famously has an SQL layer, F1, on top.

It does, but unless you know it is on top of a distributed KV store and design your schema and queries around that you will suffer horrible performance issues. Also, F1, similar to FDBs implementation, forces you to model your databases differently than you would in a "normal" oltp relational database.

Almost every single host SQL solution I know of is built on a B-Tree for at least some of its properties. A B-Tree is nothing more than a lexicographically sorted key-value store.

Consus is a lexicographically sorted key-value store.

Where you will hit performance bottlenecks is when your query planner/executer makes traditional assumptions about performance that do not hold across machines.

A good SQL implementation on top of a kvs should not force you to accommodate it any more than your current "normal" databases subconsciously train you to accommodate your disks (hint: they do).

I would be very surprised if anyone is still running their primary data store on "disks" that cares about performance. BTW, look at the design of F1 and you will see that they do object like hierarchical storage of related tables to ensure that they don't have to go cross partition for queries.

Reply on news.ycombinator.com