Open slingamn opened 5 years ago
Redis and MySQL both sound cool. Which one we go with for the primary store is just personal preference it feels like. One thing I really like about bunt is the general interface, feels nice and slick and simple to work with.
Cassandra has a table abstraction (so it's possible to iterate over every row of a table) and a Go driver: https://github.com/gocql/gocql
Cassandra can do compare-and-swap for documents via "lightweight transactions": https://docs.datastax.com/en/cql/3.3/cql/cql_using/useInsertLWT.html
Here's some skepticism about whether Cassandra can be operated successfully with small numbers of nodes: https://stackoverflow.com/a/27779449
although it actually sounds to me like it's perfectly viable to do, e.g., a 2-node cluster with "RF=2 (all data replicated), write CL=2 and read CL =1 [...] if a node is down, you can only read but not write"
Cassandra may not be a good fit for repeated update of documents (updates are implemented as setting a "tombstone" flag to invalidate the old row, then creating a new one; compaction runs later to clean up the old rows): http://cassandra.apache.org/doc/4.0/operating/compaction.html
Update: I'm leaning away from Cassandra for this because of reports that it scales down poorly (as in, it's hard to run a Cassandra node with less than a gigabyte of RAM available).
If we do anything here, we're doing MySQL (same as history, although we would allow the use of a separate logical database). But this is no longer a very high priority because it no longer blocks HA (buntdb can be made HA using k8s volumes).
Just wanted to put forward that sqlite would probably be a good alternative to mysql, its a lot-less resource intensive, and sqlite3 driver for go already exists.
sqlite has a similiar structure and tools exist to convert mysql dumps to sqlite already, so existing users could easily convert existing databases to sqlite.
These do not have to be the same database. We should continue to support buntdb for application data, so as to have a batteries-included way of spinning up a single server. So we should have some kind of abstraction layer covering the database --- probably at the macroscopic operation level ("persist this channel"), but maybe at a lower level ("store this value under this key").
Some things to think about: