blocks.store.buffer
Buffer stores provide logical block storage which uses two backing stores to implement a buffer. New blocks are written to the buffer store, which can be flushed to write all of the blocks to the primary store. Reads return a unified view of the existing and buffered blocks.
Buffer stores provide logical block storage which uses two backing stores to implement a buffer. New blocks are written to the _buffer_ store, which can be flushed to write all of the blocks to the _primary_ store. Reads return a unified view of the existing and buffered blocks.
blocks.store.cache
Cache stores provide logical block storage backed by two other stores, a primary store and a cache.
Blocks are added to the cache on reads and writes, and evicted with a least-recently-used strategy to keep the cache under a certain total size. Operations on this store will prefer to look up blocks in the cache, and fall back to the primary store when not available.
Because the caching logic runs locally, the backing cache storage should not be shared among multiple concurrent processes.
Cache stores provide logical block storage backed by two other stores, a _primary store_ and a _cache_. Blocks are added to the cache on reads and writes, and evicted with a least-recently-used strategy to keep the cache under a certain total size. Operations on this store will prefer to look up blocks in the cache, and fall back to the primary store when not available. Because the caching logic runs locally, the backing cache storage should not be shared among multiple concurrent processes.
blocks.store.file
File stores provide block storage backed by a local filesystem. Each block
is stored in a separate file under the root. File block stores may be
constructed using a file://<path-to-root-dir> URI. Both relative and
absolute paths are supported.
Under the root directory, the store keeps a block data in a subdirectory alongside some layout metadata and a landing directory:
$ROOT/meta.properties
$ROOT/blocks/111497df/35011497df3588b5a3...
$ROOT/landing/block.123456789.tmp
In many filesystems, performance degrades as the number of files in a directory grows. In order to reduce this impact and make navigating the blocks more efficient, block files are stored in multiple subdirectories consisting of the four byte prefix of the hashes of the blocks stored in them. Within each directory, blocks are stored in files whose names consist of the rest of their id digest.
In addition to the blocks, a meta.properties file at the root holds
information about the current storage layout for future-proofing. This
currently holds a single layout version property, which is always "v1".
File stores provide block storage backed by a local filesystem. Each block
is stored in a separate file under the root. File block stores may be
constructed using a `file://<path-to-root-dir>` URI. Both relative and
absolute paths are supported.
Under the root directory, the store keeps a block data in a subdirectory
alongside some layout metadata and a landing directory:
$ROOT/meta.properties
$ROOT/blocks/111497df/35011497df3588b5a3...
$ROOT/landing/block.123456789.tmp
In many filesystems, performance degrades as the number of files in a
directory grows. In order to reduce this impact and make navigating the
blocks more efficient, block files are stored in multiple subdirectories
consisting of the four byte prefix of the hashes of the blocks stored in
them. Within each directory, blocks are stored in files whose names consist
of the rest of their id digest.
In addition to the blocks, a `meta.properties` file at the root holds
information about the current storage layout for future-proofing. This
currently holds a single layout version property, which is always `"v1"`.blocks.store.memory
Memory stores provide process-local storage backed by a map in a ref. Blocks
put into this store will be fully read into memory to ensure the content is
present locally. Memory block stores may be constructed usin the mem:- URI
form.
This store is most suitable for testing, caches, and other situations which call for an ephemeral block store.
Memory stores provide process-local storage backed by a map in a ref. Blocks put into this store will be fully read into memory to ensure the content is present locally. Memory block stores may be constructed usin the `mem:-` URI form. This store is most suitable for testing, caches, and other situations which call for an ephemeral block store.
blocks.store.replica
Replica stores provide logical block storage which writes to multiple backing stores. Lookups will try the backing stores in order to find blocks.
Replicas are useful for ensuring durability across stores and for shared caches, where some external process controls cache eviction.
Replica stores provide logical block storage which writes to multiple backing stores. Lookups will try the backing stores in order to find blocks. Replicas are useful for ensuring durability across stores and for shared caches, where some external process controls cache eviction.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close