Package com.linkedin.davinci.store

Class AbstractStorageEngine<Partition extends AbstractStoragePartition>

java.lang.Object
com.linkedin.davinci.store.AbstractStorageEngine<Partition>
All Implemented Interfaces:
StorageEngine<Partition>, Closeable, AutoCloseable
Direct Known Subclasses:
BlackHoleStorageEngine, InMemoryStorageEngine, RocksDBStorageEngine, VeniceStoreCacheStorageEngine
public abstract class AbstractStorageEngine<Partition extends AbstractStoragePartition> extends Object implements StorageEngine<Partition>
A base storage abstract class which is actually responsible for data persistence. This abstract class implies all the usual responsibilities of a Store implementation,

There are several proposals for storage-partition model:

1. One storage engine for all stores 1.1 One store uses one database, i.e. all partitions of the store will be in one database. 1.2 One store uses multiple databases, i.e. one partition per database. 2. Each store handled by one storage engine 2.1 All partitions of the store will be handled in one database (current Voldemort implementation) 2.2 One partition per database (Sudha suggests) 3. Each partition handled by one storage engine (original proposal before today’s discussion, super high overhead)

The point of having one storage engine(environment) or one database for one partition, is to simplify the complexity of rebalancing/partition migration/host swap. The team agreed to take (2.2) as default storage-partition model for now, and run performance tests to see if it goes well.