PDP 22: BK based Storage (Tier 2) for Pravega

Proposal for implementation of BK based storage (Tier-2) for Pravega

Status: Under Creation

Related issues:

Motivation

There are multiple reasons for which users or Pravega may want a Tier-2 based on Apache bookkeeper. Here are a few of these:

1. Trial deployments: The user just wants a very small distributed Pravega deployment without the hassle of deploying and managing a tier-2 storage. Currently Pravega needs a deployment of tier-1 (Apache Bookkeeper) as well as Tier-2. This may be too much of effort to try out Pravega initially.
2. Deployment with small footprint: Users may want to use Pravega for not storing data long term. By using Apache Bookkeeper as Tier-2, they can use it as a temporary tier-2 for the short life time of the data.
3. Two BK deployments: User deploys two Apache bookkeeper deployments, one configured for storing small amount of data on fast disks. This is used as tier-1. Another is configured to use relatively slower disks which can store large amounts of data.

Approaches

1. Write data only once to bookkeeper: Currently data is written to tier-1 in the form of durablelog and then written to Tier-2 permanently. If user has single deployment of Apache bookkeeper, it may make sense to store data directly in tier-1 instead of storing the data in the form of durablelog and then writing to tier-2 If the user is using the same instance of apache bookkeeper deployment, it may be inefficient to write to the same deployment as a durablelog and then come back and write to the same as a tier-2 storage. Status: This needs more discussions and change in basic approach. This needs to be discussed further.
2. Use Apache bookkeeper as any other tier-2 We have decided that we will go with option 2.

Storage Ledger:

Apache bookkeeper provides low level primitives for a write ahead log. We need to build infrastructure around it called "Storage ledger" to ensure that it can be used as a general purpose storage implementation. Irrespective of the approach above, a storage ledger implementation is necessary. Here are some of the interfaces that we need to implement the Storage interface:

1. Append at an offset / end
2. Read at a given offset (Random access for read)
3. Concat (atomic if possible)
4. Truncate (optional currently)
5. Update read/write permission
6. Store metadata Currently Pravega already has one implementation of Managed ledger in BookkeeperLog.java. This is more geared towards the durable log implementation and does not have a good amount of behavior as expected from storage interface. Open Question: Shall we improve the existing managed ledger to implement a generic storage OR implement a different managed ledger for tier-2 purpose.