Can I use SS as the system of record for traditional ACID RDBMS implementations like transaction-heavy banking & telecoms use cases?
I read somewhere that persistence for rowstore OLTP SS implementations are through “snapshots” & “logs”. What does this actually mean?
Thank you very much.
Regards,
Warren
Hi Warren,
Today, SinglestoreDB only supports read committed isolation level, but otherwise has all the properties of an ACID database. Committed transactions are written to a transaction log which is replicated to other hosts (and optionally fsynced to disk if the database is created with synchronous durability) before the transactions is acknowledged as committed to ensure durability.
Support for isolation levels higher then read committed is coming next year.
-Adam
Hi, Adam.
Thanks for replying.
The fsyncing or persisting to disk of in-memory rowstore data, what is the default frequency of this? Can it be configured to be as real-time as possible, i.e., aside from writing to WAL, persist in the data file on disk right away? Is this something desirable for mission-critical use cases like financial/banking applications?
Thanks again,
Warren
The default configuration is to replicate synchronously and persisted to disk asynchronously. So this means any writes are replicated on another host before the transaction is acked as committed while at the same time being written to disk asynchronously as fast as the disk can write them out. So there isn’t a precise frequency of writing to the disk in async durability. Unless there is a huge burst in writes, the disk writes happen right away - within a few ms of commit (or even before the commit is acked). If disk writes do get far enough behind the workload (so there is a build up of data not written to the log) we will eventually throttle commits to allow the disk to catch up.
If you want commits to also flush to disk, then you can create your database with sync durability.
CREATE DATABASE XXXX WITH SYNC DURABILITY
The performance overhead of sync durability in most cases is not very noticeable (10-20% - its very workload dependent).
Warren, also, in-memory rowstore updates are fully persistent and transactional, even though the data is in memory. This is because we log the update before acknowledging commit. To make restart recovery faster, we also periodically write the in-memory rowstore state to a snapshot file.