ACID
Atomicity, Consistency, Isolation, and Durability (ACID) are properties used to define databases and the guarantees that they offer. Traditionally, they’re associated with transactions, but transactions aren’t required for achieving ACID guarantees. For a complete overview of ACID components, check out Wikipedia’s article on ACID. We designed TileDB from the beginning to ensure ACID guarantees.
Atomicity
TileDB offers atomicity through how it handles writes by using commits. A commit ensures that any read operations can’t see write operations until TileDB writes a commit corresponding to a particular write operation.
Consistency
TileDB’s consistency guarantees depend on the underlying storage system. TileDB handles eventually consistent systems by design, like some object stores. With read-after-write systems such as Amazon S3’s original design, TileDB handles consistency by ensuring that you can access only the writes with a corresponding commit. This ensures that every query, read or write, has a consistent view of the data, based on what TileDB finds when you open an array.
Isolation
TileDB uses multiversion concurrency control to ensure isolation between operations in a lock-free manner. As described in Arrays Foundation: Writes, every write is immutable. This ensures that one write operation doesn’t affect any ongoing read operations. Additionally, TileDB’s use of fragments provides an LSM-tree-like structure, which is a well-known pattern for ensuring isolation without the need for locking.
Durability
Durability guarantees come from the atomic writes in TileDB with its use of commits. A commit is the last step in a write operation, and TileDB performs commits in an atomic manner, based on the underlying storage system. TileDB guarantees that once data is committed, it will endure. TileDB’s use of multiversion concurrency control and fragments offers durability by ensuring that it never updates or appends data to an existing file. TileDB writes any file stored inside it exactly once.