Aerospike (1) - Introduction

Use Cases

Applications such as fraud detection, ad targeting, and digital identity verification share several characteristics:

• More reads than writes
• Random reads
• Low latency

For small datasets, many excellent systems, such as standalone Redis and Cassandra, meet these needs and are easy to operate and manage. As the business grows, however, unpredictable traffic spikes and poor query latency become difficult problems.
Aerospike emerged as a distributed key-value database in 2012. Its stability and low latency encouraged companies to try it. By the release of version 4.0, it had accumulated six years of successful deployments across industries.

Data Model

To me, Aerospike’s data model is similar to HBase’s namespace/table/row/column-family hierarchy.

• namespace
  • A namespace is the top-level container. It determines how its data is stored and supports these settings:
  • Storage location: all data can be stored in DRAM or on SSD
  • Replication factor: determines the namespace’s high availability
  • expire TTL
• sets
  • Sets are optional. Records can be stored with or without a set, and set-scoped secondary indexes can be defined
• records
  • A record is a row, including:
    • key
    • metadata (version, ttl, last-update-time (lut))
    • bins
• bins
  • Contains a name and value, similar to a column name and value

Query Indexes

Aerospike has two types of query indexes, primary and secondary, with different purposes.

• Primary Index
  • Aerospike’s default primary index accelerates queries and prevents data skew. The mechanism hashes each key and uses the first 12 bits as the partition ID, giving a fixed 4096 partitions.
• Secondary Index
  • Like a relational database index, a secondary index is based on a bin. Its indexed value is a list of partition IDs on the current node. Even after an index hit, every record in those partitions must be scanned, so efficiency is limited. Creating a secondary index scans all data and should be done under low load.

Consistency and High Availability

Assume one namespace, a four-node Aerospike cluster, 1024 partitions per node, and a replication factor of 1. Consider these common scenarios:

1. If one node fails, its replica becomes the master and starts finding a new replica node. No data is lost.
2. If two nodes fail and happen to hold the master and replica of the same partition, data is lost and reliability cannot be guaranteed.
3. When a failed node restarts, its in-memory indexes are gone, so it must scan the entire SSD to rebuild them, which is very time-consuming. The cluster rebalances, copying partition data from other nodes to the new node. It rejoins only when ready, without data loss.

Choosing a System

Many key-value databases trade speed against scale. Based on others’ selection experiences, here are some disadvantages of other stores compared with Aerospike.

• Memory-heavy systems such as MongoDB and Redis are too costly to scale quickly and cheaply, and cannot cope with peak traffic.
• Couchbase performs well but does not support UDFs.
• Cassandra cannot guarantee low latency at large data volumes.

Weaknesses

Despite its stability, low latency, and value for money, Aerospike has limitations to consider:

• Rolling starts take too long because the entire SSD must be scanned to rebuild indexes
• Complex data types such as HyperLogLog are unsupported
• Each record must not exceed 1 MB
• Response times fluctuate during rebalancing