On Friday, May 22nd, 2020, Erik Brandsberg, Chief Technical Officer at Heimdall Data, which is based in Newark, CA, reviewed the Heimdall Distributed Database Proxy (Heimdall Proxy) for the Washington DC CTO Meetup Group. We recorded this event and this video is available on YouTube. We briefly cover what was discussed in this meeting in this post.
I have posted two other articles that are related to this one, and which may be of interest — they are Hidden Gems: Event-Driven Change Notifications in Relational Databases and Scaling Postgres Beyond PostgreSQL PgBouncer & Postgres Pgpool-II: Advanced Traffic Management (which includes a video presentation) — be sure to check them out as well.
What is The Heimdall Proxy?
The Heimdall Proxy is a SQL platform for application developers, database administrators, and infrastructure owners.
Whether deployed on-premises or in the cloud, the Heimdall Distributed Database Proxy helps organizations deliver faster, more reliable, and secure content.
Heimdall Proxy Use Cases
The following examples describe various use cases for the Heimdall Distributed Database Proxy:
- Find Performance Bottlenecks: Heimdall’s analytics provides complete SQL performance visibility (e.g. slow, redundant queries) and offers recommendations to remediate them. For deployment, there are no application modifications or integration work required for installation.
- Increase Scale: Heimdall’s read/write splitting allows customers to make better use of read replicas with ZERO application changes. Heimdall Data is a 5-minute drop-in replacement. Moreover, we guarantee query reads will always have fresh data with our lag detection logic.
- Maximize Uptime: Heimdall is application-aware ensuring connection uptime upon a database failover. Why spend resources developing and re-architecting a solution, when you can use Heimdall and install it in a matter of minutes?
- Strengthen Security: Heimdall provides an added layer of defense, protecting the database from malicious ZERO day attacks. Unlike other solutions, Heimdall’s database firewall does not rely on a pattern or signature matching. It is contextual; alerting and filtering SQL queries that are deemed “abnormal”.
Heimdall Distributed Database Proxy Architecture
Heimdall Data is a distributed database proxy that optimizes from an application perspective. The Heimdall Distributed Database Proxy gives users visibility and control over their SQL environment and can be installed:
- On each application instance
- On a separate proxy tier
- On the database
The Heimdall Distributed Database Proxy is transparent to the application and database.
Next, we’ll take a brief look at caching, read/write split, and automated failover.
Heimdall Database Proxy Caching
Today’s SQL solutions incur data latency from application-database round trips. Caching on the database improves scale, but does not remove the latency. The Heimdall proxy can be deployed as a sidecar process across application instances — this distributed model results in optimal performance and predictive scale.
With Heimdall caching, queries that would have been directed to the database are now cached locally on the application tier. You choose the cache of choice (e.g. Amazon Elasticache, Redis) and Heimdall determines which query results to cache and invalidate. Best of all, caching does not require writing a single line of code.
What Is Database Read-Write Splitting?
🤖 Database read-write splitting is a technique used to improve the performance and scalability of a database by separating read and write operations. In this technique, the database workload is split between two or more databases, with one database dedicated to handling write operations and the other(s) dedicated to handling read operations.
The write database is the primary database, where all the write operations are performed. The read databases are replicas of the primary database and are used for performing read operations. The data is replicated from the primary database to the read databases in real-time or with a slight delay.
This technique is beneficial in applications where there are more read operations than write operations. By separating the read and write operations, the read databases can handle the read requests without affecting the write database’s performance. This improves the overall performance and scalability of the database.
Additionally, read-write splitting also provides fault tolerance and high availability. If the write database fails, a failover mechanism can promote one of the read databases to become the new master database, ensuring that write operations can still be performed. 🤖
Heimdall Database Proxy Read / Write Split
To scale the database tier horizontally with master and read replicas, application modifications are required. Heimdall is SQL aware and routes queries to the appropriate database instances (writes or read replicas). As an added benefit, the proxy supports replication lag detection in order to ensure that fresh data is always served.
Heimdall Proxy Automated Failover
Health checks each database instance. Upon a failure, Heimdall holds the connection as it transitions to the redundant database instance. This results in failovers that are transparent to the application.
Heimdall Proxy: Article Conclusion
There’s a popular saying in Computer Science from Phil Karlton (see also StackExchange) that goes like this:
There are only two hard things in Computer Science: cache invalidation and naming things.
Caching, in general, is a difficult subject in Computer Science and the Heimdall Distributed Database Proxy delivers a wealth of features that benefit an application, in particular an application running in a cloud environment such as Amazon Web Services, the Google Cloud Platform, or in Microsoft Azure.
You must log in to post a comment.