Aerospike Now Offers Strong Consistency with NoSQL Database
Aerospike’s speedy NoSQL database has traditionally been used to power applications where high performance matters more than data correctness. With yesterday’s unveiling of a fourth version of the database, Aerospike added the option to prioritize data consistency, thereby opening up new uses for the database.
Aerospike’s key-value store uses a unique combination of DRAM and Flash to give it a performance edge over traditional disk-based databases. Specifically, it indexes keys in DRAM, while storing values in Flash-based solid state disks (SSDs). The database’s speed has primarily been utilized by enterprises in the ad tech, gaming, and financial services space to build an array of applications, including fraud and churn analysis, real-time ad bidding, risk management for banks, and revenue assurance for telcos.
Increasingly, Aerospike is being considered for systems of engagement (SoE) type of applications, which allow enterprises to interact with customers or prospects and to offer them additional services, usually over Web and mobile interfaces. Analytics are often a big part of the SoE story. Social media engagement is too.
An SoE application can be viewed as the opposite of system of record (SoR) type of application. SoR apps are typically transactional in nature, and are usually powered by a relational database that features full guarantees of ACID (atomicity, consistency, isolation, durability) compliance. A problem arises, however, when enterprise want to expand their SoEs. Often times, they find themselves going back to the SoRs to get the “best” data, or building a high-speed cache in front of the relational database to get that data quickly.
As a result, enterprises are seeing workloads increase significantly on SoEs. However, even with caches, the performance does not suffice. Aerospike’s solution to that dilemma is to build more ACID features into its database, thereby enabling them to build high-performance SoEs out on the edge that don’t need to constantly go back to the SoR databases to ensure that the data is correct.
“Systems that provide strong consistency are typically slow and unable to provide the real-time engagement needed in these situations,” Aerospike Founder and Chief Development Officer Srini Srinivasan writes in a blog post. “Aerospike’s recent efforts have been heavily focused on solving the problem of providing a strongly consistent system that is also capable of high performance.
Aerospike does not offer full ACID guarantees yet. But it is on the roadmap. And when the ACID roadmap is completely built out, customers building SoEs will be able to get the same type of guarantees that SoR systems have offered.
“Our focus has been around supporting high performance transactions so we have very much prioritized availability over consistency,” says Aerospike’s head of marketing, Satish Iyer. “But today we’ve announced that we’re going to be strongly consistent, without sacrificing performance, which we think is a big deal.”
Iyer says that databases powering transactional and analytical systems are becoming more alike, especially in light of the need to analyze data as soon as possible. “That necessitates data stores like Aerospike, where you can actually do these things faster,” he tells Datanami. “Especially now with Apache Spark, you want to be able to analyze data on the flight much more quickly than store massage, manipulate, and spit out information.”
The rise of containers and microservices architectures is also helping to expand demand for databases that can provide high speed and consistency guarantees, Iyer says. “A lot of these services are only accessing the piece of the data they require,” he says. “This is a way for enterprise systems to partition and make sure that this data is available closer. This is a huge trend.”
This trend is particularly visible in finance and capital markets, where regulations require enterprises running SOEs to ensure that the data they use is correct, and that privacy and security standards are not being violated, while still allowing for innovation. “We believe that, a lot of times, that consistency has become a requirement now,” Iyer says.
It’s about building the technological underpinnings to allow SOE applications to behave more like SOR applications, because relational databases aren’t likely to learn SOE tricks. “So we can not just be fast, but we can allow the whole development of microservices applications, while also being strongly consistent,” Iyer says. “In some way, we believe that’s the way things are going because the SORs of today may not be ready for those changes.”