Skip to main content

TimeBase Cluster

Introduction​

A group of TimeBase servers can be organized in a logic cluster. TimeBase Cluster may help you target various goals:

  • Handle big datasets that do not fit on a single machine.
  • Prevent data loss.
  • Scale, when it is necessary to process significant amounts of incoming/outgoing data.

Each server in a TimeBase Cluster is called a Member - a TimeBase instance that embeds a TimeBase Cluster component and a data storage.

TimeBase Cluster uses Raft consensus algorithm to:

  • Elect a TimeBase Cluster leader responsible for making cluster-wide decisions.
  • Build a quorum and avoid split brain.
  • Replicate common metadata (including generic stream information and data locations) to all cluster members.
info

TimeBase Cluster is available just for the TimeBase Enterprise Edition.

Basic Principles​

In TimeBase streams, data can be arranged in partitions called spaces. Each space includes chronologically arranged data blocks.

Blocks include data for certain time ranges (block has startTimestamp and endTimestamp, however endTimestamp might be empty for a new block). Data blocks are not divisible (if a server stores a data block then the server has to store the entire data block).

In a TimeBase Cluster, content of each data block can be replicated to multiple TimeBase servers called block location list or replication chain - an ordered list of TimeBase Cluster members responsible for replication of a specific data block.

  • TimeBase Cluster Leader - current appointed TimeBase Cluster leader.
  • Head Member - the first member in the location list for a specific data block.
  • Tail Member - the last member in the location list for a specific data block.

Tail Members in a block location list always replicate data from a Member that is placed before them in the replication list. For example, servers [A,B,C,D] replicate data from A to B, from B to C, and from C to D. Loader (writer) writes data only to the very first server in the block location list. Only one data loader (writer) can concurrently write data to a single partition. Consumers (readers) read data only from the very last server in the block location list. Such an approach guarantees that messages pass all the servers in the replication list so desired replication factor is reached before any reader gets the message.

  • On this diagram, TimeBase Cluster has 3 servers, and the stream replication factor is 2 - we create two replicas for each block. Arrows represent a replication direction.
  • Blocks are distributed between servers in a semi-random way.
  • There is no notion of partitions on the storage layer. From the storage layer perspective, each local stream contains just some set of blocks.
  • There is no notion about the relationship between blocks in a stream on the storage layer. From the storage layer perspective, all blocks are independent but share the same message schema.