Apache BookKeeper for Pulsar

BookKeeper for Pulsar

Updated January 2023

As discussed in a previous article, “What is Apache Pulsar?”, Pulsar is a two-layer system with Pulsar brokers acting as the serving layer and Apache BookKeeper bookies providing the persistent storage layer. 

In this post we will review BookKeeper’s role, important terminology, and an introduction to configuring Ledgers.

Apache BookKeeper Basics

BookKeeper is used as the persistent storage layer for Pulsar.  Like Pulsar, BookKeeper was developed at Yahoo.  BookKeeper is designed to be a reliable, high-performance storage system. 

BookKeeper stores log entries, or records, in Ledgers.  Each log entry stored in a Ledger is an indivisible unit of data.  

Ledgers store an ordered sequence of log entries. They are append-only and immutable data structures.  In other words, data cannot be changed, which is an important feature for real-time message streaming. Also, no new records can be appended to a Ledger after it is sealed.

Log entries include metadata fields, including the entryId.  The entryId for a log entry must be unique within a Ledger.   There is also an authentication value used to identify corrupt entries.  

In addition to message data, the subscription positions for individual consumers are also persistently stored in BookKeeper.  These subscriptions positions for consumers are referred to as cursors.  These cursors are stored in Ledgers making tracking scalable.

Configuring BookKeeper Ledgers

Ledgers have three configurable components, the Ensemble size, the Write quorum size, and the Ack quorum size.

A ledger is created with a specified number of bookies.  This initial set of bookies makes up the initial ensemble (E) for a ledger. Log entries are replicated across some or all of the multiple bookies that make up the Ensemble.  

For each entry to the ledger the entry is replicated a specified number of times. This value is referred to as the write quorum size (Qw).  The maximum number of times an entry can be replicated is equal to the total number of bookies in the ensemble.  

If there is an ensemble size of 3, that means 3 bookies for that ledger, and a write quorum size of 3, then each entry will be replicated on each of the 3 bookies in the Ledger.

A third and final component to the ledger configuration is the ack quorum size (Qa).  This value sets the number of bookies an entry must be acknowledged on.  

To continue our example just used, if the ack quorum size is 3, then the entry must be acknowledged on all three bookies in the ensemble to be completed.  

In some cases it makes sense to have the ack quorum size be one less than the write quorum size to improve latency.

Final Notes on BookKeeper Ledgers

The bookies in the ensemble can change over time, for instance in the case of a bookie failure and a new bookie taking its place.

BookKeeper is designed to manage thousands of Ledgers all with simultaneous reads and writes.  Bookies can isolate read and write operations by using multiple disk devices.  This prevents latency of reads occurring from concurrent write operations.

As a last piece of terminology, BookKeeper has a property called Fencing.  Fencing allows only a single Pulsar broker to write to a ledger.  This architecture is important because it removes the issue of split-brain problem that other technologies can endure.

Apache Pulsar Support Services

If you are interested in 24/7 support, consulting, and/or fully managed Pulsar services, you can find more information on our Apache Pulsar services page

Schedule a call with a Pulsar solution architect.

Published by

Dattell - Kafka & Elasticsearch Support

Benefit from the experience of our Kafka, Pulsar, Elasticsearch, and OpenSearch expert services to help your team deploy and maintain high-performance platforms that scale. We support Kafka, Elasticsearch, and OpenSearch both on-prem and in the cloud, whether on stand alone clusters or running within Kubernetes. We’ve saved our clients $100M+ over the past six years. Without our guidance companies tend to overspend on hardware or purchase unnecessary licenses. We typically save clients multiples more money than our fees cost in addition to building, optimizing, and supporting fault-tolerant, highly available architectures.

Leave a Reply