Chronicle QBM

Chronicle QBM is an in-memory key-value store designed for low-latency and multi-process applications, particularly in trading and financial markets.

Features

• Ultra-low latency: Chronicle QBM achieves median read and write query latencies of less than 1 microsecond in certain tests.

• High concurrency: Write queries scale efficiently up to the number of hardware execution threads available on the server. Read queries never block each other.

• Optional persistence to disk.

• Optional replication (commercial feature): Enables replication from one to N other servers across LAN or WAN.

Unique features

• Multiple processes can access a Chronicle QBM concurrently. At the same time, the data store is in-process for each of the accessing processes. Out-of-process approach to IPC is simply incompatible with Chronicle QBM median latency target of < 1 μs.

• Replication

Chronicle QBM has two meanings:

• language-agnostic data store (specification).

• implementation of this data store for the JVM (source). Currently, this is the only implementation.

From the Java perspective

ChronicleMap is a ConcurrentMap implementation which stores the entries off-heap, serializing/deserializing key and value objects to/from off-heap memory transparently. Chronicle QBM supports:

• Key and value objects caching/reusing for making zero allocations (garbage) on queries.

• Flyweight values for eliminating serialization/deserialization cost and allowing direct read/write access to off-heap memory.

Primary Chronicle QBM use cases

• Replacing slower key-value stores, like Redis and Memcached, when used within a single server.

• Replacing similar JVM-centric solutions, like Coherence and Hazelcast, for speed and/or certain Chronicle QBM features which those solutions lack.

• Moving parts of the application-state out of the Java heap for either:

  • Reducing the heap size, for reducing garbage collection pressure, or fitting 32 GB, for using CompressedOops.

  • Inter-process communication.

  • Persistence.

  • Replication across servers.

• Drop-in ConcurrentHashMap replacement; Chronicle QBM performs better in some cases.

What guarantees does Chronicle QBM provide in ACID terms?

• Atomicity - single-key queries are atomic if Chronicle QBM is properly configured, multi-key queries are not atomic.

• Consistency - doesn’t make sense for key-value stores

• Isolation - yes; for both single- and multi-key queries.

• Durability - no; Chronicle QBM can be persisted to disk, but with no guarantee as to how frequently this happens. This is under the control of the OS. All data is guaranteed to be written to disk when the Map is closed.

• Clustering and replication for Chronicle QBM is provided by Chronicle Queue Enterprise.

What is the data structure of Chronicle QBM?

Simply put, a Chronicle QBM data store is a big chunk of shared memory (optionally mapped to disk).

It is split into independent segments; each segment has:

• an independent memory allocation for storing the entries

• a hash table for search

• a lock in shared memory (implemented via CAS loops) for managing concurrent access.

See Chronicle QBM data store design overview for more information.

Chronicle QBM is not

• A document store. There are no secondary indexes.

• A multimap. Using a Chronicle QBM collection as a multimap is technically possible, but often leads to problems. See StackOverflow answer for details. Developing a proper multimap, using Chronicle QBM’s design principles is possible.

Please contact us at [email protected] if you would consider sponsoring such development.

Chronicle QBM does not support:

• range queries.

• iteration over the entries in alphabetical order.

• sorting of keys.

• LRU entry eviction.