Aerospike: Up and Running

Chapter 5. Architecture

Since you are just starting to use Aerospike, this chapter will not explain how the database is built. However, knowing some key aspects of how Aerospike works under the covers will help you understand why you do certain things with it and how to get the most out of its capabilities.

This chapter focuses on three major topics—scale out (horizontal scaling), scale up (vertical scaling), and how transaction management with strong consistency is accomplished on this distributed system.

Scale Out

To linearly scale performance latency and throughput, Aerospike must scale out on multiple commodity computers, aka nodes. To do this, Aerospike has several fundamental principles built into its heart. These foundational pillars affect how everything works in the database. The key goal of the scale-out architecture is to maintain a uniform distribution of data across data partitions and across nodes. Combined with the ability to support elasticity using dynamic addition and removal of nodes, this architecture ensures that the system avoids hot spots (overworked nodes or network connections) while providing excellent performance (both high throughput and extremely low latency) with linear scalability.

Shared-Nothing Database Cluster

Aerospike is a shared-nothing database, meaning that each node in a cluster does not share anything with the other nodes. The database cluster consists of a set of commodity server nodes, each of which has CPUs, memory (RAM), rotational ...