[HN Gopher] SQLite - The Session Extension
___________________________________________________________________
SQLite - The Session Extension
Author : thunderbong
Score : 106 points
Date : 2021-12-13 19:20 UTC (3 hours ago)
(HTM) web link (www.sqlite.org)
(TXT) w3m dump (www.sqlite.org)
| melony wrote:
| If the underlying changeset is commutative, then you get a CRDT.
| samwillis wrote:
| I don't think it does with a patchset but maybe could with a
| changeset: > When processing an UPDATE change,
| the following conflicts may be detected: > The target
| database may contain a row with the specified PRIMARY KEY
| values, but the current values of the fields that will be
| modified by the change may not match the original values stored
| within the changeset. This type of conflict is not detected
| when using a patchset.
|
| Also, if you have A and B, both initially the same, modify both
| with an UPDATE on the same existing row, and send and apply the
| patchiest to each other, I think they will overate each other
| and have a different state...
|
| Edit:
|
| I wander if there is a way to add a last_mod column to the
| tables and so only a more recent UPDATE would be executed from
| a patch set? It would only work at the row level but for most
| cases that should be ok. You could always create other tables
| for more granular control.
|
| It looks like you can provide a conflict hander too that can
| replace the update statement, that could be useful for merging
| conflicting changes.
|
| This could be exactly what I want for something!
| api wrote:
| SQLite plus a fast Raft replication and consensus implementation
| is the next Postgres. Change my mind.
| lrem wrote:
| 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.
| thegeekpirate wrote:
| https://github.com/rqlite/rqlite
|
| https://github.com/canonical/dqlite
| tptacek wrote:
| Multi-writer concurrency with sqlite is a giant pain in the
| ass.
| [deleted]
| rocmcd wrote:
| This exists already with 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.
| otoolep wrote:
| 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.
| Conlectus wrote:
| 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 wrote:
| 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.
| howdydoo wrote:
| https://www.sqlite.org/whentouse.html
|
| See: Situations Where A Client/Server RDBMS May Work Better
| [deleted]
| FrostKiwi wrote:
| Now that's some lucky timing! Literally in 12 hours I'm supposed
| to work on how to sync machines without network access, that
| write to SQLite databases.
|
| SQLite never ceases to amaze me.
| roberto wrote:
| NNCP (http://www.nncpgo.org/) can be helpful here as well, in
| conjunction with the SQLite session extension.
| pdimitar wrote:
| Especially the combination of Syncthing and `nncp-xfer` is
| super useful. NNCP usually has strict routing which can be a
| hassle to guarantee (machine D only gets packets from machine
| A if they went through machine B and C first).
|
| Using Syncthing as a central storage for NNCP packets
| circumvents the strict routing requirement.
| rakoo wrote:
| It sounds like litestream (https://litestream.io/) might be
| useful to you here
___________________________________________________________________
(page generated 2021-12-13 23:00 UTC)