The LevelDB Store is a file based persistence database that is local to the message broker that is using it. It has been optimized to provide even faster persistence than KahaDB. It's similar to KahahDB but instead of using a custom B-Tree implementation to index the write ahead logs, it uses LevelDB based indexes which have several nice properties due to the 'append only' files access patterns :
- Fast updates (No need to do random disk updates)
- Concurrent reads
- Fast index snapshots using hard links
Both KahaDB and the LevelDB store have to do periodic garbage collection cycles to determine which log files can deleted. In the case of KahaDB, this can be quite expensive as you increase the amount of data stored and can cause read/write stalls while the collection occurs. The LevelDB store uses a much cheaper algorithm to determine when log files can be collected and avoids those stalls.
You can configure ActiveMQ to use LevelDB for its persistence adapter - like below :
The directory which the store will use to hold it's data files. The store will create the directory if it does not already exist.
The number of concurrent IO read threads to allowed.
If set to false, then the store does not sync logging operations to disk
104857600 (100 MB)
The max size (in bytes) of each data log file before log file rotation occurs.
4194304 (4 MB)
That maximum amount of log data to build up before writing to the file system.
Set to true to force checksum verification of all data that is read from the file system.
Make the store error out as soon as possible if it detects internal corruption.
The factory classes to use when creating the LevelDB indexes
Number of open files that can be used by the index.
Number keys between restart points for delta encoding of keys.
6291456 (6 MB)
Amount of index data to build up in memory before converting to a sorted on-disk file.
4096 (4 K)
The size of index data packed per block.
268435456 (256 MB)
The maximum amount of off-heap memory to use to cache index blocks.
The type of compression to apply to the index blocks. Can be snappy or none.
The type of compression to apply to the log records. Can be snappy or none.
For tuning locking properties please take a look at Pluggable storage lockers
- Replicated LevelDB Store An extended version of this store which self replicates to other broker nodes to increase message availability.