5 Signs Your Cache + Database Architecture May Be Obsolete Executive Overview For years using an external caching layer with an RDBMS was the accepted conventional wisdom for attaining performance and reliability. Data was kept in memory by the cache to reduce the amount of time spent querying the underlying data store. As data volumes grew, NoSQL databases were substituted for the RDBMS to provide horizontal scaling to clusters and to keep latency down. Then “Digital Transformation” happened. “The growth in servers needed to handle the In the blink of an eye, simple web applications have become systems of growth in data could no longer be funded by engagement (SoE) that are now serving billions of objects, with millions the growth in revenue.” of contextual data points and enabling rich interactions and -CTO, Digital Identity Firm engagement - all in a few milliseconds. Data has grown in both velocity and volume - the more data, delivered faster, the richer the engagement and the better the decision. Larger datasets of up to 40TB to 100TB are now common, according to Forrester Research1, and there is no end in sight to data growth or to transaction velocity. The only way to support modern velocities simultaneously with deal with growing data volumes that much data in the cache is to be stuck in a never-ending cycle of adding cache nodes and deploying increasingly -complex cache management systems and strategies. This approach ignores the high cost of external DRAM caching layers as their continual expansion is , for core principles that huge and growing data sets mean an external caching layer is unfundable over time and requires significant investments in managing complex data lifecycle issues such as cache consistency and correctness which are not core non-core issues. Translation: the cache is unaffordable, untrustable, and unstable at those volumes. It’s time to challenge conventional wisdom. Even though it’s still common practice today, the harsh reality is that using an external cache layer as a fundamental component of a System of Engagement (SoE), where huge scale, ultrafast response, and rock-solid reliability are critical success factors, is a last decade approach for solving next decade problems. Instead of more memory, or a better cache, perhaps what’s needed is a better data architecture - one which uses the fact that systems of engagement typically don’t require; and doesn’t rely on an external caching layer for performance, reliability, or scale: Hybrid Memory Architecture. Forrester defines hybrid memory architecture as a database architecture that combines the use of DRAM and SSD and combines DRAM's parallelism and SSD's fast, random bulk storage capability to provide near DRAM performance with SSD reliability and lower cost, including integrated internal DRAM caches. A hybrid memory database provides automation to simplify the access and processing of data, and support for transactional, operational and analytical workloads. It leverages SSD and flash natively in an optimized and engineered manner. Fortunately, the Aerospike database, built with hybrid memory architecture, allows you to eliminate that external caching layer while simultaneously handling internet-scale data volumes at sub-millisecond response times and with significantly fewer servers. It is used in production and trusted by industry-leading organizations to power their Systems of Engagement. 1 “Forrester Study on Hybrid Memory NoSQL Architecture for Mission-Critical, Real-Time Systems of Engagement” 2017 Forrester Research, Noel Yuhanna © 2017 Aerospike, Inc. All rights reserved. Aerospike and the Aerospike logo 2525 E. Charleston Road, Suite 201 Are trademarks or registered trademarks of Aerospike. All other names and Mountain View, CA 94043 trademarks are for identification purposes and are the property of their respective owners. Tel: 408 462 AERO (2376) www.aerospike.com 5 Signs Your Cache + Database Architecture May Be Obsolete 5 Signs Your Cache + Database Architecture May Be Obsolete What are the 5 signs your external cache + database architecture may be obsolete? Your caching nodes are growing at an uncontrolled pace and you’re preparing yet another 1 unplanned budget variance request - Is your growth in data volume or access patterns driving ever-larger caching clusters (30 nodes or more)? - Are you frequently requesting budget for more memory or servers, over and above your original projections? It takes hours or even days to repopulate your cache after a disruption, and that is now part of 2 your daily operations - Do you frequently hold new nodes or servers out of production while the cache gets repopulated? For how long? - Are you worried that your data will be out of date while the cache gets rebuilt? You have implemented a cache-first architecture, but you still can’t meet your SLAs. 3 - What’s causing you to miss your SLAs? At what cost? - Even if you are meeting your SLAs today, will you be able to meet them as your data and customer size grows? Your cache has grown to where you need clustering - and that scares you 4 - Do you have the time, talent, and experience to rearchitect your new system for clustering? - Are you worried that the new architecture may not support further - especially unexpected - growth? You’ve “solved” your cache stampede problem by code revision - again – and you now have to 5 update code libraries; or push a cache proxy update – again - Do you experience cache stampede often? - Have you tried different algorithms to solve the problem? - Is it becoming hard to convince your development groups to use the “latest” fix for this problem? What Is Hybrid Memory Architecture and Why Is It important? The cache + database architecture was never designed to handle the volume and latency requirements for today’s systems of engagement. An RDBMS just doesn’t scale horizontally and time-consuming complex joins and queries are rarely necessary. First-generation NoSQL databases are built for horizontal scale but can’t maintain sub- millisecond response times. 5 Signs Your Cache + Database Architecture May Be Obsolete Why is hybrid memory architecture important? “Hybrid memory architecture is a new approach that leverages both volatile memory (DRAM) and nonvolatile memory such as SSD and flash to deliver consistent, trusted, reliable and low-latency access to support existing and new generations of transactional, operational, and analytical applications. Implementing this type of architecture allows organizations to move from a two-tier in-memory architecture to a single-tier structure that simplifies the movement and storage of data without requiring a caching layer. Early-adopters are seeing several benefits to their business like a lower cost of ownership, huge reductions in their server footprint, simplified administration and improved scalability.”2 Hybrid memory architecture has the following characteristics: 1. Stores indices in memory (DRAM) and data on SSD storage, reducing server count by as much as a factor of 10. 2. Has multi-threaded, massively parallel systems for predictable performance. 3. Significantly improves uptime and availability, without complex and error-prone manual DevOps processes. 4. Automatically distributes both data and traffic to all the nodes in a cluster. Clients automatically do load balancing for improved performance and correctness. 5. Provides better data consistency, because external cache unreliability is no longer an issue.3 Aerospike Database hybrid memory architecture eliminates the need for the out-dated and costly external cache layer; it’s the best way to architect systems of engagement. The result is significantly better performance, reliability and uptime, as well as simplified datacenter operations. “The business benefits of making this leap (to hybrid memory architecture) can be far-reaching and position an organization for the next wave of digital business growth in a world of instant analytic insights on real-time data.”4 Five Signs Your Cache + Database Architecture Is Obsolete Sign #1: Your caching nodes are growing at an uncontrolled pace and you’re preparing yet another unplanned budget variance request As your business grows, so does your data and the size of your cache, at a rate that’s directly proportional. As the value of engagement increases, new applications and projects clamor for database access, increasing transaction volumes and cache working set sizes. Server counts need to keep up, even though budgets were set at the beginning of the year. When growth happens beyond expectations it must be addressed or your System of Engagement won’t be able to keep up. 2 “Hybrid Memory Architecture Drives Real-Time Systems of Engagement” Forrester Research, May 2017 3 Ibid. 4 “Delivering Digital Business Value Using Practical Hybrid Transactional/Analytical Processing” Gartner, Inc. Published: 27 April 2017 ID: G00314780 5 Signs Your Cache + Database Architecture May Be Obsolete As noted above, our customers who were using the old cache + database architecture found that funding this growth was simply unsustainable. Business growth means a non-linear growth in data as more information is compiled or queried per customer and per transaction. Add to that the use of additional data sources for better analysis (more data is always considered better when it comes to transactional analytics) and your cache will rapidly and happily expand to consume the budget available - and then some. The operative word here in the quote to the left is “when” and “When your cache runs out of not “if.” The companies at the marquee 2017 Redis conference memory…” who presented “solutions” to their cache management issues -(overheard from multiple presenters at ranged in size from a few dozen employees to some of the RedisConf2017) largest, well-known companies on the planet. They all acknowledged that the issues and strategies for dealing with cache management were serious and common enough to warrant presenting them to other users. No one using an external cache, it seems, is immune from the challenge of running out of memory.