Crate linera_views

This module is used in the Linera protocol to map complex data structures onto a key-value store. The central notion is a views::View which can be loaded from storage, modified in memory, and then committed (i.e. the changes are atomically persisted in storage).

The package provides essentially two functionalities:

• An abstraction to access databases.
• Several containers named views for storing data modeled on classical ones.

See DESIGN.md for more details.

The supported databases.

The databases supported are of the NoSQL variety and they are key-value stores.

We provide support for the following databases:

• MemoryStore is using the memory
• RocksDbStore is a disk-based key-value store
• DynamoDbStore is the AWS-based DynamoDB service.
• ScyllaDbStore is a cloud-based Cassandra-compatible database.
• ServiceStoreClient is a gRPC-based storage that uses either memory or RocksDB. It is available in linera-storage-service.

The corresponding trait in the code is the common::KeyValueStore. The trait decomposes into a common::ReadableKeyValueStore and a common::WritableKeyValueStore. In addition, there is a common::AdminKeyValueStore which gives some functionalities for working with stores. A context is the combination of a client and a base key (of type Vec<u8>).

Views.

A view is a container whose data lies in one of the above-mentioned databases. When the container is modified the modification lies first in the view before being committed to the database. In technical terms, a view implements the trait View.

The specific functionalities of the trait View are the following:

• context for obtaining a reference to the storage context of the view.
• load for loading the view from a specific context.
• rollback for canceling all modifications that were not committed thus far.
• clear for clearing the view, in other words for reverting it to its default state.
• flush for persisting the changes to storage.

The following views implement the View trait:

• RegisterView implements the storing of a single data.
• LogView implements a log, which is a list of entries that can be expanded.
• QueueView implements a queue, which is a list of entries that can be expanded and reduced.
• MapView implements a map with keys and values.
• SetView implements a set with keys.
• CollectionView implements a map whose values are views themselves.
• ReentrantCollectionView implements a map for which different keys can be accessed independently.
• ViewContainer<C> implements a KeyValueStore and is used internally.

The LogView can be seen as an analog of VecDeque while MapView is an analog of BTreeMap.

Modules

• batch
  The definition of the batches for writing in the database. A set of functionalities for building batches to be written into the database. A batch can contain three kinds of operations on a key/value store:
• collection_view
  The CollectionView implements a map structure whose keys are ordered and the values are views.
• common
  The definitions used for the KeyValueStore and Context. This provides several functionalities for the handling of data. The most important traits are:
• dynamo_db
  A storage backend for views based on DynamoDB
• hashable_wrapper
  Wrapping a view to compute a hash.
• journaling
  The code to turn a DirectKeyValueStore into a KeyValueStore by adding journaling. Journaling aims to allow writing arbitrarily large batches of data in an atomic way. This is useful for database backends that limit the number of keys and/or the size of the data that can be written atomically (i.e. in the same database transaction).
• key_value_store_view
  The implementation of a key-value store view.
• log_view
  The LogView implements a log list that can be pushed.
• lru_caching
  The LRU (least recently used) caching.
• map_view
  The MapView implements a map with ordered keys. The MapView implements a map that can be modified.
• memory
  Helper definitions for in-memory storage.
• queue_view
  The QueueView implements a queue that can push on the back and delete on the front.
• reentrant_collection_view
  The ReentrantCollectionView implements a map structure whose keys are ordered and the values are views with concurrent access.
• register_view
  The RegisterView implements a register for a single value.
• rocks_db
  A storage backend for views based on RocksDB
• scylla_db
  A storage backend for views based on ScyllaDB This provides a KeyValueStore for the ScyllaDB database. The code is functional but some aspects are missing.
• set_view
  The SetView implements a set with ordered entries.
• test_utils
  Helper types for tests.
• value_splitting
  The code for handling big values by splitting them into several small ones.
• views
  The definition of the View and related traits.