History[04]

Originally etcd was started for two use cases: reboot coordination and application configuration. CoreOS used etcd to coordinate reboot of CoreOS cluster and avoid that all nodes in the cluster rebooted at the same time. Also, etcd was used to store application configuration, so whenever a server starts or restarts or whenever application configuration is updated, the server receives application configuration from etcd.

Checkpoints[01]

etcd provides a snapshot to avoid increasing logs.

Concurrency Control[01]

Data Model[01]

etcd stores data as a multiversion key-value pair. Each mutative operation (e.g. PUT) creates a new version and does not change older versions. Previous versions are also accessible until they are compacted.

Indexes[01]

etcd creates an in-memory btree index for keys and provides range operations.

Isolation Levels[01]

Joins

Logging[02][05]

The documentation mentioned that etcd used WAL to recover from a failure but did not mention what kind of information it logs. According to the source code, it seems to log a gRPC request in WAL.

Query Compilation

Query Interface[01]

etcd accepts a request via a gRPC remote procedure call.

Storage Architecture[01]

etcd stores a key-value pair in a persistent disk as the b+ tree structure sorted by a key.

Storage Model[01]

etcd stores physically data as a key-value pair. The key is consist of a 3-tuple: major, sub, type. Major stands for a key and its version. Sub contains the identifier among the modification request. Type is an optional and one use case is for a tombstone. The value contains a delta from a previous version.

Stored Procedures

System Architecture[06]

etcd does not require shared resource and works with independent resources. A typical deployment model is to use a cloud service such as AWS and set up the cluster with multiple virtual machines.

Views