Aerospike’s storage compression feature provides lossless compression of records written to persistent storage. Aerospike supports three different compression algorithms, which provide superior compression and decompression speed:
- LZ4 – http://lz4.org. Aerospike supports the widely deployed, speed-optimized version of LZ4. There is also an HC (“high compression”) variant, which is slower and not supported.
- Snappy – https://google.github.io/snappy/.
- Zstandard – https://facebook.github.io/zstd/.
Compression is only applied to records that are written to persistent storage, e.g., SSDs. Record data in memory (RAM) is not compressed.
The trade-off of compression is increased transaction latency and higher CPU load, because in addition to accessing the SSD, compression and decompression have to take place. Typically, write latency is affected more than read latency, because compression is more CPU-intensive than decompression.
An algorithm’s performance – speed as well as compression ratio – is highly specific to the data to be compressed. When picking an algorithm, it is good practice to evaluate each algorithm’s performance with records that are representative of real-world data.
An empirical approach towards evaluating the optimal compression algorithm is to configure different compression algorithms on multiple servers and then reviewing the compression percentages between the servers.