ZooKeeper Data Model

1. Overview of the Data Model

ZooKeeper’s data model is a hierarchical tree structure (similar to a file system), where each node is called a znode. Znodes are identified by absolute paths (e.g., /servers/node1) and can store small amounts of data (up to 1MB by default). The tree structure enables organized management of distributed system metadata, such as configuration files, server registries, and lock states. Unlike traditional file systems, znodes combine features of both files (data storage) and directories (child node management).

2. Core Components of a Znode

Each znode consists of three key parts:

• Data: A byte array storing metadata (e.g., server IP, configuration values). Data is atomic—read operations fetch all data, and write operations replace all data.
• Children: A list of child znodes (if the znode is a directory). For example, /servers can have children like /servers/node1, /servers/node2.
• Stat: Metadata about the znode, including:
  • cZxid/mZxid: Creation and last modification transaction IDs (globally ordered).
  • version: Data version (increments on every write).
  • cversion: Child nodes version (increments when children are added/removed).
  • aclVersion: ACL (Access Control List) version (increments when permissions change).
  • ephemeralOwner: Session ID if the znode is temporary (0 for persistent znodes).
  • dataLength: Length of the stored data.
  • numChildren: Number of child nodes.

3. Types of Znodes

ZooKeeper supports four znode types, defined at creation time:

• Persistent Znodes: Exist until explicitly deleted. They persist across client sessions and server restarts, making them ideal for storing permanent metadata (e.g., system configurations).
• Ephemeral Znodes: Tied to the client’s session. They are automatically deleted when the session ends (due to timeout or disconnection). Useful for representing temporary states (e.g., live servers in a cluster—nodes are removed when a server goes down).
• Persistent Sequential Znodes: Persistent znodes with a monotonically increasing sequence number appended to their name (e.g., /tasks/task-0000000001). The sequence number is unique per parent znode and useful for ordered processing (e.g., distributed task queues).
• Ephemeral Sequential Znodes: Ephemeral znodes with sequence numbers. They combine temporary existence with ordering, ideal for distributed locks (ensuring only one client holds the lock at a time) or leader election.

4. Key Features of the Data Model

4.1 Hierarchy and Path Uniqueness

The tree structure ensures logical organization of data. Paths must be absolute (starting with /) and unique—each znode has a single, unchanging path. This prevents naming conflicts and enables precise access to nodes.

4.2 Versioning for Concurrency Control

Every znode maintains version numbers (version, cversion, aclVersion). When modifying data or ACLs, clients must provide the expected version. If the current version doesn’t match, the operation fails (optimistic locking). This prevents concurrent modifications and ensures data consistency.

4.3 Watches for Event Notifications

Clients can register watches on znodes to monitor changes (data updates, child additions/removals, or node deletion). Watches are one-time triggers—when the event occurs, the client receives a notification and must re-register the watch to continue monitoring. This enables real-time coordination (e.g., a client watching /locks gets notified when a lock is released).

4.4 Data Size Limitations

Znodes are designed for small metadata storage (up to 1MB). This constraint ensures fast read/write operations and reduces memory overhead, aligning with ZooKeeper’s role as a coordination service rather than a general-purpose database.