search

LumoSQL / archive1-LumoSQL-on-github

Initial work on SQLite and LMDB integration
https://lumosql.github.io/LumoSQL/
Other
68 stars 14 forks source link

LumoSQL vs ActorDB #37

Closed xet7 closed 4 years ago

xet7 commented 4 years ago

Hi, thanks for your talk about LumoSQL, I found it from https://fosdem.org/2020/schedule/events/

If I did hear correctly from talk, someone in audience mentioned ActorDB. It could be this: https://github.com/biokoda/actordb

Some beginnings of comparison table:

Feature LumoSQL ActorDB
SQLite ✓ ✓
LMDB ✓ ✓
WAL ✗ ✓ info
danshearer commented 4 years ago

Hello and thanks for this. You are correct, and it was a helpful contribution in the talk.

ActorDB is a "distributed SQL database", whereas in these early days of LumoSQL we have definitely not got much further than thinking "if we did add some networking, what might the architecture be?" As you can see in https://github.com/LumoSQL/LumoSQL/blob/master/doc/prior-art.md , there are several different approaches to the problem ActorDB is addressing. I will certainly be adding ActorDB to prior-art.md , and thankyou for the reminder.

Your beginnings of a comparison table highlight the exact architectural point that matters to LumoSQL at the moment, as we figure out where LumoSQL should go next. We found it very interesting to have an SQL database that has eliminated a WAL. ActorDB have chosen the WAL layer in SQLite to implement their backend, see https://github.com/biokoda/actordb_driver/blob/master/c_src/wal.c (kudos to ActorDB for well-documented code.)The LMDB files used by ActorDB are all about making a journalled write log easily available for replication to other nodes. I wouldn't expect, for example, that this architecture would be a natural fit for a mobile phone or other "SQL as a file format" use cases of SQLite. On the other hand, Bedrock illustrates a different approach to the problem of safely replicating SQLite transactions to ActorDB, with different design goals and constraints (but equally not embedded.)

In LumoSQL we are working out just now where the API layers should be and we welcome discussion on this topic.

danshearer commented 4 years ago

I've added ActorDB in prior-art.db and added some discussion of it elsewhere.

Not closing this issue until I have more completely addressed the issue of WAL-layer APIs in docs and project strategy. The WAL layer is one of four points where LumoSQL could insert itself.

danshearer commented 4 years ago

WAL discussion has been addressed in architecture and in docs soon to be pushed. Closing.