“There are only two hard things in Computer Science: cache invalidation and naming things.” ~Phil Karlton
Caching is complex and engineering intensive. Because it requires manual configuration (i.e. What to cache and invalidate), managing cache systems have been burdensome. This article explains how Heimdall Data auto-caches safely without any code changes.
- Studies have shown a 20% improvement in page-load-time increased conversion rates by 20%
- Improve application response times
- Reduce database costs: Fewer queries to the database results in fewer licenses and hardware (fewer cores licensed)
- Increase horizontal database scaling
What Should I Cache?
When implementing caching, there is a typical checklist:
- What is safe to cache?
- Will caching give me a performance benefit?
- How can I maintain cache freshness?
What is safe to cache? For a postal delivery code, the table rarely changes and is safe to cache for an extended period of time, without impact. This would not apply for monetary account balances that changes often. The cacheability depends on the freshness and synchronization that any cache solution provides. What are the guarantees that a write made on one node will be updated on another node immediately? Without such guarantees, caching can become very risky, and will likely break an application. A caching solution needs to be adaptive and adjust to changing conditions for optimal performance.
While databases have some cache functionality (e.g. Query plan and buffer pool cache), it does not solve network latency as queries still hit the database servers.
Getting warmer: Some deploy additional caches on the application side such as Redis, Amazon ElastiCache or Hazelcast: These are SQL caches in front of the database to improve application performance while offloading database processing. They lower the memory pressure on the buffer pool and improve the efficiency of queries that are processed by the database server.
Application-level caching, however, is manual and prone to errors. Developers still need to determine what to catch and what to invalidate, frequently monitoring the changes in data patterns and adjusting accordingly. ORM frameworks provide SQL caching, but they do not synchronize invalidations across cache nodes, nor guarantee consistent data across the application tier. What if there was a solution that automated caching, ensuring reliability and synchronization data across cache nodes?
Figure 1: Heimdall Data Caching Architecture
Engineering teams spend up to 20% of their resources on building and maintaining a cache subsystem. Heimdall Data solution:
- Intelligent auto-caches, requiring no changes to the database, application or ORM framework
- Intelligently caches in two tiers: 1) In-memory and 2) Cache of your choice (e.g. Redis, AWS ElastiCache). Our machine learning algorithms, cache only if there is a performance benefit and automatically invalidates
- Supports on-premise and cloud (Azure, AWS) environments
Heimdall Data works with any application, including 3rd party applications as no code changes are required. Just connect the application to the proxy which connects to the database on its behalf.
Beyond caching, read replica failover, and read/write split is supported. See Figure 2 below. How is Heimdall Data caching unique?
- Automatic invalidation; no more stale data
- Automatic tuning of what NOT to cache
- Distributed cache deployment: Heimdall is installed on each application server, eliminating network latency to the database
- Supports SQL Server, PostgreSQL, MySQL, and Oracle
Figure 2: Heimdall Data SQL Optimization Platform
Today’s caching solutions lack invalidation logic beyond TTL or require complex configurations. It is a risky, time-consuming, manual process. Heimdall intelligently caches and invalidates taking the risk and guesswork out. Here’s how:
- Choose storage of choice (e.g. In-memory, Redis, Hazelcast)
- Install the Heimdall software into each application server
- Walk through the Heimdall configuration wizard
- Auto-caching and auto-invalidation begin towards the storage you chose