5 ms·

SQLite plus a fast Raft replication and consensus implementation is the next Postgres. Change my mind.

by api 5y ago

howdydoo 5y ago
https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html See: Situations Where A Client/Server RDBMS May Work Better
thegeekpirate 5y ago
https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite https://github.com/canonical/dqlite https://github.com/canonical/dqlite
deleted 5y ago
[deleted]
rocmcd 5y ago
This exists already with rqlite: https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite As much as I love the idea, Raft is not a silver bullet and can break in strange and inconspicuous ways that may be difficult to fix. It can also lead to subtle inconsistencies in the data depending on what data you are putting in it. Overall it may be good in some situations, but I doubt it will dislodge Postgres in any meaningful way.
- Conlectus 5y ago
  Wouldn't this be true of any form of replication, including whatever Postgres uses? Or is the proof of correctness for Raft weaker than some other class of consensus? Edit: from rqlite's FAQ > Raft is a Consistency-Partition (CP) protocol. This means that if a rqlite cluster is partitioned, only the side of the cluster that contains a majority of the nodes will be available. Disconcertingly, this sounds like they assume that only one side of a partition can contain a majority of nodes. This isn't true if the partition is partial, eg A<-->B, B<-->C, A<-/->C.
  - otoolep 5y ago
    rqlite creator here. rqlite (and Raft) doesn't assume this. All it states is that for the cluster to make progress i.e. apply a change in a consistent manner, at least a quorum of nodes must be online and in contact with the Leader (which is one of the online nodes). Every node in a rqlite cluster knows what size the cluster is and therefore requires that (N/2)+1 nodes acknowledge the change before that change is committed. The Leader node performs this coordination. The scenario you outlined above is obviously possible. But in that event the cluster is down -- the Leader (let's say it's node A) cannot contact a quorum of nodes. No changes can be made to it.
    - Conlectus 5y ago
      Gotcha, that makes sense. I look forward to digging into the code myself :).
- otoolep 5y ago
  What inconsistencies do you mean, precisely? I think you need to provide a clear example of what you mean, to understand what you're getting at. In my experience, any inconsistencies would be due to misuse of Raft, not something intrinsic to Raft itself.
  - rocmcd 5y ago
    Thanks for chiming in, Philip! I’m a big fan of your work. I was referring to the issues around determinism in queries. These are easy enough to catch if you’re aware of them, but it pushes more onus onto the application layer / devs (not that it’s necessarily a bad thing, just a trade-off).
- pstuart 5y ago
  rqlite is nice but it's got limitations that made me look elsewhere. https://dqlite.io/ https://dqlite.io/ does it in C and allows for transactions and can be used for the Go sql.DB object.
deleted 5y ago
[deleted]
tptacek 5y ago
Multi-writer concurrency with sqlite is a giant pain in the ass.
- le-mark 5y ago
  Multiple reader single writer out performs Postgres in my testing, by a large margin.
- pstuart 5y ago
  The writers need to be serialized but it's not that big a pain.
- mst 5y ago
  There are, nonetheless, lots of situations where I would have reached for pg automatically a few years ago where I now stop and think about which of the two is going to fit my use case better. The comment you're replying to is saying rather more than that, and I don't endorse it, but the shift in the possibility space is still both fascinating and impressive. (also I love sqlite's tendency to use pg as a syntax template, it seems like an example of two projects with significantly different goals playing to each others' strengths in a beautifully positive sum game fashion)
lrem 5y ago
SQLite is not a high throughput database. Trying to work around this with cool tech is not likely to make it better than a boring solution, like using a high throughput database in the first place.
- bob1029 5y ago
  My SQLite usages are able to saturate my NVMe storage devices in many test cases. Not sure what exact criteria you are using for "high throughput" here. Perhaps you are not familiar with the additional WAL journal mode or synchronization flags?
- cryptonector 5y ago
  SQLite3 is not a high-write-concurrency database, but not a high-throughput DB is less clear, and it's not at all clear that it can't be hacked on to go faster. If you take a sharding approach to concurrency, you might just be happy with no write concurrency: one process/thread per-CPU / storage slice, and fix everything else upstairs. It's not a crazy approach, and it might be the approach many would take if they could start from scratch. In fact, it's the approach Spanner takes, for example.
remram 5y ago
Adding Raft and replication will make your database more available but strictly slower and not any more concurrent. If SQLite is not good enough for you now it probably wouldn't be any good for you then.
penberg 5y ago
I don't know if SQLite + Raft is going to be the next Postgres, but it's certainly an interesting solution for a variety of use cases where you don't need your data _partitioned_ on multiple machines (but still want it to be replicated for availability and fault tolerance). As others point out in this thread, there's already rqlite for Go, sqlite for C, and now we've open sourced our work on bringing SQLite and Raft to Rust: https://glaubercosta-11125.medium.com/winds-of-change-in-web-data-728187331f53 https://glaubercosta-11125.medium.com/winds-of-change-in-web...

SQLite plus a fast Raft replication and consensus implementation is the next Postgres. Change my mind.

by api 5y ago

SQLite plus a fast Raft replication and consensus implementation is the next Postgres. Change my mind.

https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html See: Situations Where A Client/Server RDBMS May Work Better

thegeekpirate 5y ago

https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite https://github.com/canonical/dqlite https://github.com/canonical/dqlite

deleted 5y ago

[deleted]

rocmcd 5y ago

This exists already with rqlite: https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite As much as I love the idea, Raft is not a silver bullet and can break in strange and inconspicuous ways that may be difficult to fix. It can also lead to subtle inconsistencies in the data depending on what data you are putting in it. Overall it may be good in some situations, but I doubt it will dislodge Postgres in any meaningful way.

Conlectus 5y ago
Wouldn't this be true of any form of replication, including whatever Postgres uses? Or is the proof of correctness for Raft weaker than some other class of consensus? Edit: from rqlite's FAQ > Raft is a Consistency-Partition (CP) protocol. This means that if a rqlite cluster is partitioned, only the side of the cluster that contains a majority of the nodes will be available. Disconcertingly, this sounds like they assume that only one side of a partition can contain a majority of nodes. This isn't true if the partition is partial, eg A<-->B, B<-->C, A<-/->C.
- otoolep 5y ago
  rqlite creator here. rqlite (and Raft) doesn't assume this. All it states is that for the cluster to make progress i.e. apply a change in a consistent manner, at least a quorum of nodes must be online and in contact with the Leader (which is one of the online nodes). Every node in a rqlite cluster knows what size the cluster is and therefore requires that (N/2)+1 nodes acknowledge the change before that change is committed. The Leader node performs this coordination. The scenario you outlined above is obviously possible. But in that event the cluster is down -- the Leader (let's say it's node A) cannot contact a quorum of nodes. No changes can be made to it.
  - Conlectus 5y ago
    Gotcha, that makes sense. I look forward to digging into the code myself :).
otoolep 5y ago
What inconsistencies do you mean, precisely? I think you need to provide a clear example of what you mean, to understand what you're getting at. In my experience, any inconsistencies would be due to misuse of Raft, not something intrinsic to Raft itself.
- rocmcd 5y ago
  Thanks for chiming in, Philip! I’m a big fan of your work. I was referring to the issues around determinism in queries. These are easy enough to catch if you’re aware of them, but it pushes more onus onto the application layer / devs (not that it’s necessarily a bad thing, just a trade-off).
pstuart 5y ago
rqlite is nice but it's got limitations that made me look elsewhere. https://dqlite.io/ https://dqlite.io/ does it in C and allows for transactions and can be used for the Go sql.DB object.

deleted 5y ago

[deleted]

tptacek 5y ago

Multi-writer concurrency with sqlite is a giant pain in the ass.

le-mark 5y ago
Multiple reader single writer out performs Postgres in my testing, by a large margin.
pstuart 5y ago
The writers need to be serialized but it's not that big a pain.
mst 5y ago
There are, nonetheless, lots of situations where I would have reached for pg automatically a few years ago where I now stop and think about which of the two is going to fit my use case better. The comment you're replying to is saying rather more than that, and I don't endorse it, but the shift in the possibility space is still both fascinating and impressive. (also I love sqlite's tendency to use pg as a syntax template, it seems like an example of two projects with significantly different goals playing to each others' strengths in a beautifully positive sum game fashion)

lrem 5y ago

SQLite is not a high throughput database. Trying to work around this with cool tech is not likely to make it better than a boring solution, like using a high throughput database in the first place.

bob1029 5y ago
My SQLite usages are able to saturate my NVMe storage devices in many test cases. Not sure what exact criteria you are using for "high throughput" here. Perhaps you are not familiar with the additional WAL journal mode or synchronization flags?
cryptonector 5y ago
SQLite3 is not a high-write-concurrency database, but not a high-throughput DB is less clear, and it's not at all clear that it can't be hacked on to go faster. If you take a sharding approach to concurrency, you might just be happy with no write concurrency: one process/thread per-CPU / storage slice, and fix everything else upstairs. It's not a crazy approach, and it might be the approach many would take if they could start from scratch. In fact, it's the approach Spanner takes, for example.

remram 5y ago

Adding Raft and replication will make your database more available but strictly slower and not any more concurrent. If SQLite is not good enough for you now it probably wouldn't be any good for you then.

penberg 5y ago

I don't know if SQLite + Raft is going to be the next Postgres, but it's certainly an interesting solution for a variety of use cases where you don't need your data _partitioned_ on multiple machines (but still want it to be replicated for availability and fault tolerance). As others point out in this thread, there's already rqlite for Go, sqlite for C, and now we've open sourced our work on bringing SQLite and Raft to Rust: https://glaubercosta-11125.medium.com/winds-of-change-in-web-data-728187331f53 https://glaubercosta-11125.medium.com/winds-of-change-in-web...