[Question] Feasibility of implementing a SQL Layer using SQLite's Virtual Table mechanism? about foundationdb HOT 2 CLOSED

Hi, @edwinyzh! Could you ask this same question over to the community forums? https://forums.foundationdb.org You can login using your GitHub account.

We've set up the forums as the go-to place for community discussion and answering questions, and we're largely using GitHub issues to track tasks. So if it's OK, I'll close this individual issue for now -- but hope to see you on the forums. Thanks!

from foundationdb.

Ok, I see, please close it. And I'd like to attache a reply I got from voidmain @hacker News for the very same question I posted on HN:

Long before we acquired Akiban, I prototyped a sql layer using (now defunct) sqlite4, which used a K/V store abstraction as its storage layer. I would guess that a virtual table implementation would be similar: easy to get working, and it would work, but the performance is never going to be amazing.
To get great performance for SQL on FoundationDB you really want an asynchronous execution engine that can take full advantage of the ability to hide latency by submitting multiple queries to the K/V store in parallel. For example if you are doing a nested loop join of tables A and B you will be reading rows of B randomly based on the foreign keys in A, but you want to be requesting hundreds or thousands of them simultaneously, not one by one.

Even our SQL Layer (derived from Akiban) only got this mostly right - its execution engine was not originally designed to be asynchronous and we modified it to do pipelining which can get a good amount of parallelism but still leaves something on the table especially in small fast queries.

from foundationdb.