Aerospike is an open source distributed Key-Value NoSQL database. It supports flexible data schemas and ACID transactions. The architecture consists of three layers:
- Client Layer: This layer includes the open source client libraries with Aerospike APIs, track nodes in the cluster and are aware of where data reside in the Aerospike cluster.
- Clustering and Data Distribution Layer: This layer oversees cluster communications and automates capabilities like fail-over, replication and cross data center synchronization.
- Data Storage Layer: This layer is responsible for storing the data in DRAM and Flash.
InfoQ spoke with Brian Bulkowski, Aerospike co-founder and CTO, about the NoSQL database architecture, advantages and its limitations.
InfoQ: There are many NoSQL solutions -- what problem does Aerospike solve?
Brian: Aerospike solves the key-value problem for application developers. They should consider Aerospike when they would use a Key Value NoSQL Database with Sharding capability. It’s built to survive serious internet loads, as deployments with many successful companies have proven. It’s not an analytics database, or a replacement for Hadoop.
Aerospike has seen great success for user profile stores and session management at high scale but retailers doing personalization, security projects using real-time data, dynamic cell phone billing, and many other projects are finding cases where Aerospike is the best choice.
By publishing the Aerospike source code, and with recent addition of user-defined functions, secondary indexes, and aggregations for statistics gathering, Aerospike can be chosen as the database for applications that need scalable performance.
InfoQ: How does Aerospike database compare with relational databases?
Brian: Aerospike was written from scratch as a distributed database that excels at key-value use. Relational databases became full featured, but lost speed and scale for primary key use. Yet, primary key use - where data is de-normalized for performance - is the most important single feature for internet application developers.
Relational databases are good multi-purpose tools, however, trouble in scaling, slow joins, the complexity of maintaining relationships and fixed schemas reduce application performance and developer agility. This is why caches and sharding have been used for many years to build real-world exciting applications.
SQL has not yet adapted to several key developer needs. Polyglot language use focuses on use of list and map abstractions, and more advanced structures like Documents. NoSQL databases give developers what they want by promoting lists and maps as high level datatypes, and allowing access across multiple languages. Small improvements, such as being able to easily update and read from a record (UPDATE and SELECT) atomically, make developers' lives easier.
Unlike relational database implementations, Aerospike takes advantage of the latest hardware – multi-core, multi-CPU servers and flash memory (PCIe cards and Solid State Drives or SSDs) – and a distributed shared nothing architecture that can scale out to handle billions of objects, terabytes of data and millions of transactions per second. SSDs are available in all public clouds today, and give in-memory performance at a fraction of the cost of RAM. A “High Scalability” blog lays out the reasoning.
InfoQ: How does it compare with other NoSQL databases?
Brian: Some popular NoSQL databases promote high performance, but still require a cache technology to solve problems with simultaneous reads and writes. Aerospike's in-memory performance leads to simpler application development, and also simpler deployment. If you're using NoSQL instead of MySQL for performance and scale, you need an in-memory database with proven performance.
Yet, in-memory open source caches like Memcache and Redis don't scale easily. Performance is high, but they have unsophisticated persistence models, and require an all-DRAM build out. Adding a new server requires splitting data manually to avoid periods of low performance.
Aerospike was designed from the first line of code to support not just RAM, but also Flash (SSDs). Instead of paging memory from RAM to Flash, it takes a hybrid approach, with allocated indexes and data stored either in RAM or in SSDs. We find that for each deployment, some data is best placed in RAM, and some in Flash, which is easy to support in Aerospike.
Other NoSQL databases implement only delayed consistency, but Aerospike runs by default with synchronous replication, providing single row ACID properties. Read committed is the most useful ACID level, and provides programmers with the reality that a read after a write returns the correct answer. Aerospike implements distributed isolation techniques consisting of latches and short-term record locks to ensure isolation. The mechanisms for providing durability in Aerospike consists of replication to multiple nodes using both RAM and persistent storage, and every transaction update is written to multiple locations on the cluster before signalling commit success. Details can be found in this Very Large Data Bases conference paper.
Aerospike has made a strong commitment to moving processing closer to data through user defined functions,functions run on the server, rather than the client). A distributed code manager allows modules to be safely uploaded to the cluster, then very efficiently executed in-database. This feature is used to reduce network traffic. For example, to add an element to a list in the database, list management can be written as a simple UDF, essentially extended the database with custom operations.
Other NoSQL databases require manual sharding, manual fail-over, maintenance windows etc. MongoDB and HBase provide auto-sharding, but MongoDB requires operator selection of a shard key to identify the data to be sharded and HBase involves selection of a RegionSplitPolicy from among a set of policies. Aerospike, however, is self-healing and automates several features, including failover and the rebalancing of data, drastically reducing maintenance. In Aerospike deployments, there has not been a need for maintenance windows - operations such as backups and upgrades can be done while the database cluster is still servicing requests.
InfoQ: What are the best use cases or applications to use Aerospike as part of the solution?
Brian: Aerospike is the database of choice for low latency applications such as optimization and personalization of advertising. The real-time bidding advertising system - which runs auctions for a majority of advertisements seen on the Internet - relies on application servers which use the recent behavior of a cookie, combined with deeper user understanding generated from huge Hadoop analytics databases. This type of big data application has the requirement to both respond to REST API requests in a few milliseconds, and also write recent behavior to a front-edge database. Aerospike is used as a user profile store, server side cookie store, real-time context store, device ID store and for ID-mapping, by platforms that must store billions of items and read and write predictably, within 1 millisecond. Further, Aerospike provides single row ACID properties that are often necessary for financial transactions.
Aerospike has been used by retailers to generate dynamic content - to give offers and deals while someone is browsing - and come up with optimal recommendations for products. Snapdeal, for example, was using MongoDB running in RAM as a cache, but found its performance lacking. Now, they use Aerospike, which has allowed their developers to make more database calls per page, and build a visually richer and more profitable web experience.
We are finding that caching itself is becoming old school. Many social media company - from Pinterest to Twitter - use persistent in-memory key value stores as the core element in their data infrastructure - without a cache.
Today, nearly every platform needs to offer 24/7 uptime in order to maintain user experience quality, meet Service Level Agreements, and remain up through maintenance and backup procedures. Many Aerospike customers start with a relatively small cluster. When use of their applications not just increases but explodes, they find that they can scale up by easily adding servers. There is no need to restart the existing nodes or clients, schedule downtime, etc.
InfoQ: Is there a persistent backend database in Aerospike architecture or is it a purely in-memory database?
Brian: Aerospike is persistent. When using RAM, the typical configuration writes data to disk as well. As data is not read from disk, there is little performance impact. When using Flash/SSDs, data is written synchronously to the master and replica copies of data. The data is queued and written to the disk in a block write, so all copies are persisted and there is no performance impact.
InfoQ: What type of monitoring support is available?
Brian: There are multiple ways to monitor Aerospike. The Aerospike Monitoring Console (AMC) provides a comprehensive dashboard for monitoring cluster activity. It comes pre-installed with Aerospike virtual machines available through vagrant, and registered Amazon AMIs.
Aerospike supports plug-ins for Nagios and Graphite - these plug-ins are written in Python and can be used as a template for other systems.
InfoQ: What are the limitations of using Aerospike?
Brian: Aerospike may not be the best choice when:
- The workload is will always be read only
- The workload is for batch analytics and rotational media (HDDs) are more cost effective
About the Interviewee
Brian Bulkowski, Aerospike co-founder and CTO has 20-plus years experience designing, developing and tuning networking systems and high-performance Web-scale infrastructures. His career includes several pioneering technical roles at Novell, Liberate and Aggregate Knowledge. Brian has a B.S. degree in Mathematics and Computer Science from Brown University.
