- Enterprise Edition (EE): Max 256 nodes (Ver 5.x+)
- Community Edition (CE): Max 8 nodes, with total data size limits
- Maximum 32 namespaces per cluster
- Choose AP mode or SC mode (SC mode is EE only)
- Maximum 128 devices per namespace per node (Ver 4.2+)
- Maximum ~549.7 billion records per namespace per node (
2^39)
- CE Limit: Max
2^32 records
- Namespaces can be added/removed using a rolling upgrade (Ver 3.13+)
- Namespaces contain:
- Records, Indexes, and Policies
- Namespace Policies dictate:
- How data is stored
- Number of replicas for a record
- When records expire
- Multiple namespaces can be defined, each with different storage configurations
- Namespaces have their own storage engine
- Write queue management for device-based storage:
max-write-cache: Defines pending write buffer limit before failing writes
- Write cache calculation:
# of devices * max-write-cache
- Example:
- 3-node cluster, 1 namespace, 4 devices per node
max-write-cache=64 MiB, write-block-size=1 MiB
- When pending blocks exceed 256 MiB, writes fail with:
write fail: queue too deep
- Error Code 18: Device Overload
- Maximum 1023 set names per namespace
- Set name limits:
- Maximum 63 characters
- Cannot be deleted
- Sets are metadata, not storage segregators:
- Searching for records in a set requires scanning all records in the namespace's Primary Index (PI)
- Sets behave like tablespaces but lack schemas
- Dynamic column/bin addition (like MongoDB)
- Maximum 8 MiB size per record (dependent on
write-block-size)
- Primary Index (PI) stores:
- Device ID (8 bytes) (Max 128 devices)
- Offset & size (limits partition size to 2TB, record size to 8MB)
- Max 32,767 bins per record
- Record Metadata Includes:
- LUT (Last Update Time)
- GEN (Generation Count)
- TTL (Time-To-Live)
- Strong Consistency (SC) mode adds extra bits for record state tracking
- Records function like key-value pairs (similar to MongoDB objects)
- Supported Data Types: Boolean, String, Integer, Double, BLOB, List, Map, GeoJSON, HyperLogLog (JHLL, v4.9.0.11+)
- Max Bins per Namespace: 65,535 (Ver 5.x+)
- Bin Name Limit: 15 characters
- Bin names cannot be deleted
- Bins behave like columns in RDBMS
- Data type is determined by the stored value
- Structure (64 bytes per entry):
- Digest (20 bytes): Used for partitioning
- Set ID (2 bytes): Max 1024 sets
- TTL (4 bytes): Determines expiration
- Last Update Timestamp (5 bytes)
- Generation Counter (2 bytes)
- SSD Record Pointer (8 bytes)
- Memory Pointer (8 bytes)
- Lookup Process:
- Client sends digest (hash of
(key + type + set)) to server
- Server finds digest in PI, retrieves data location
- PI is stored in shmem for fast restarts
- PI can be derived from the disk itself after a hard reboot
- Sprigs (RB-Trees) store PI entries in memory for fast lookups
- Used for querying records by bin values
- Automatically updated when indexed values change
- Faster than full scans; stored in DRAM
- Each node contains its own local index, including master and replica records
- Supports one-to-many relationships
- Tracked via System Metadata (SMD)
- Client sends sindex request to any node
- Forwarded to the SMD principal node
- Propagated to all nodes
- Nodes apply changes and rebuild sindex
- Tracks records based on LUT (Last Update Time)
- Compares LUT to partition's LST (Last Shipped Time)
- Replica writes are also tracked for failover recovery
- Deletes & expirations can be replicated if configured
- Process repeats continuously
- Single network request for multiple records
- Not a multi-record transaction
- Grouped by Partition ID
- Multiple operations on a single record
- ACID-compliant; executes under a record lock
- Aerospike uses log-structured storage
- Writes sequentially, causing fragmentation over time
- Defragmenter process:
- Runs constantly
- Reads blocks below
defrag-lwm-pct
- Moves valid records to defrag write queue
- Flushes every 3s to mark blocks free
- Replicas/migrations are handled separately
- High disk utilization may slow defrag efficiency
โ
Namespaces define storage policies & constraints
โ
Taints, Labels, and PI affect how data is managed
โ
Records and bins work like flexible key-value pairs
โ
Aerospike ensures high performance with indexing & batch operations
โ
XDR enables efficient multi-datacenter replication
โ
Defragmentation optimizes SSD longevity & efficiency