Cassandra.

Cassandra places its nodes on a logical ring of tokens, and each node owns one or more token ranges. Cassandra hashes a row's partition key into a token and stores the row on the node that owns that range. This is consistent hashing.

There is no master node, so there is no single point of failure. Nodes share cluster state through the gossip protocol, so each node knows about every other node and can handle any request. Each row is replicated to several nodes for fault tolerance.

A tombstone is a marker Cassandra writes when you delete data. Deletes can't remove data from every replica at once, so Cassandra records the delete as a new write with a timestamp.

A tombstone is kept for the table's gc_grace_seconds, which defaults to 10 days. That grace period lets a replica that missed the delete receive it through repair, so the deleted data can't come back as a zombie. After the grace period, compaction removes the tombstone and the data it covers.

Too many tombstones slow down reads, because a read has to scan past them.

Cassandra stores several copies of each row on different nodes, so the data survives node failures. The replication factor (RF) sets how many copies exist. With an RF of 3, each row lives on 3 distinct nodes.

Each keyspace has a replication strategy that picks the nodes for the copies. SimpleStrategy is meant for test clusters, and NetworkTopologyStrategy is for production, with one or more datacenters.

Every replica can accept writes, and no copy is the primary. A client can send a request to any node, which acts as the coordinator and forwards it to the replicas that store the data.

The partition key picks a row's partition and the nodes that store it, and the clustering key sorts the rows inside that partition. Cassandra hashes the partition key to pick the replica nodes, and every row with the same partition key lives in one partition.

CREATE TABLE events (
    user_id UUID,
    event_time TIMESTAMP,
    event_type TEXT,
    data TEXT,
    PRIMARY KEY (user_id, event_time, event_type)
);

Here user_id is the partition key, and event_time and event_type are clustering keys. All events for one user are stored together, sorted by time and then by type.

An efficient query gives the full partition key, because by default CQL refuses a query that would scan every partition. It can then restrict the clustering keys in the order they are declared, such as every event after a given time. You fix the clustering order when you create the table and can't change it later.

The Cassandra Query Language (CQL) has native types for single values and collections for groups of values. You can also define your own types and use tuples.

The native types:

• Text: TEXT, VARCHAR and ASCII.
• Small integers: TINYINT and SMALLINT.
• Large integers: INT, BIGINT and VARINT, which has no size limit.
• Other numbers: FLOAT, DOUBLE and DECIMAL, a variable-precision decimal.
• Time: TIMESTAMP, DATE and TIME.
• DURATION for a length of time.
• Identifiers: UUID and TIMEUUID.
• BOOLEAN for true or false, and BLOB for binary data.
• INET for an IP address.
• COUNTER, which you can only increment or decrement.
• VECTOR, an array of floats for vector search, added in Cassandra 5.0.

The collections are SET<type> for sorted unique values, LIST<type> for values ordered by position that allow duplicates, and MAP<key_type, value_type> for key-value pairs.

User-defined types (UDTs) group named fields, and tuples group values without names.