When should you use the Heimdall Proxy?
- Repetitive, duplicate queries: Caches SQL results to the grid-cache of your choice, offloading database processing and improves response times.
- Horizontal database scale-out with Strong Consistency: Read/write split for better use of read replicas without code changes. Ensures fresh data with replication lag detection.
- Connection Pooling: Minimizes backend connections by a ratio of 1000:1. Two-tier control to limits per user and per database server connections.
- SQL Performance Analytics: Identifies the SQL bottleneck: Application? Database? Network latency?
- Database Disaster Recovery: SQL-aware failover solution for Postgres, SQL Server, MySQL, MariaDB, Oracle and DB2; persists connection during a failover resulting in minimal application errors and reconnects.
- SQL Firewall: Detects and blocks SQL injection anomalies. There are no signature or profile updates. Our proxy prevents ZERO day database attacks.
How are you different from other Database Proxies (Pg-Bouncer, ProxySQL, RDS Proxy)?
Summary of how Heimdall Proxy uniqueness:
- Read/Write splitting with ACID Compliance
- Automated Query Caching and Splitting for queries in transactions.
- 2-tier Connection Pooling: Per-user and Per-database
- X Other proxies do not guarantee data consistency, nor support multiple proxies as a single unit.
- Check out this webinar
Does Heimdall Data support all databases (SQL and NoSQL)?
Heimdall Data does not optimize for NoSQL databases at this time. However, Heimdall can support SQL-to-NoSQL dialect translation giving developers access to multiple data sources.
Is Heimdall Data compatible with ORM (Object Relational Mapping)?
An ORM () is a tool that queries and manipulates data from a database using an object paradigm. Below are the added benefits of Heimdall Data:
- Heimdall Data is installed as data access layer after the ORM in the data flow towards the database and caches SQL result sets. We are transparent to ORMs.
- While ORM’s has SQL caching functionality, the user must choose which queries to cache. Heimdall automates caching and invalidation and has proven to improve performance alongside ORM’s.
- Heimdall Data aggregates caches nodes as a single cluster across application servers for efficient cache management. ORM’s caching is on a per application server basis and data is not synchronized upon updates.
How is Heimdall Proxy used as a transparent caching solution?
Heimdall Data is not a cache. Heimdall provides the caching logic for existing grid-cache vendors. The operational elegance of the Heimdall Proxy is that it does not require any application code changes. This is ideal for those deploying 3rd party applications (e.g. HR, manufacturing, finance) requiring performance optimization and high availability. Installation takes 5 minutes.
For application developers, cache policies are typically coded into their application code. This creates inefficiencies: 1) Trial and error of what to cache, and 2) Longer development cycles. The Heimdall cache solution automates caching with “one-click”. Our algorithms determine what queries to cache and invalidate to ensure maximum performance and data integrity.
Do you support Cloud Providers or On-premise?
Whether in cloud service providers or on-premise environments, Heimdall Data can be supported. As long as you can install software into your application server, we will provide SQL optimization.
Heimdall Data is a technology partner of AWS, Azure, and Google Cloud and is installed as a separate proxy tier. For AWS, our configuration wizard detects Amazon Elasticache and Amazon RDS via IAM roles. Just point to your storage of choice (in-memory or Elasticache) and RDS instances, and we will take it from there.
Why Heimdall Data if we are already deployed in AWS?
Heimdall Data enhances an already existing application-database in AWS in 3 ways:
- Auto-caching / Auto-invalidation: If you already deployed SQL caching (e.g. in-memory, Elasticache, Redis), Heimdall Data will make your caching better performing and more reliable. Our caching algorithms will only cache the queries that provide a performance benefit. We will also ensure your cache nodes are synchronized and up-to-date so that there is no stale data. You get all of this without code changes.
- Better usage of RDS read replicas: When read replicas are created, the developers must modify the application to appropriately route queries. Also, AWS reader endpoints are based on DNS, which can result in all the connections going to a single replica instead of an even load distribution across replicas. The Heimdall Proxy is not based on DNS and directly interfaces with the Amazon RDS API to track health status and state. This allows us to evenly load balance across RDS instances.
- Heimdall supports read/write split which will route queries to the appropriate database server. It is a simple configuration policy on the Heimdall console requiring zero code changes.
- Persistent connection automated failover: Amazon RDS supports automated failover. However, Heimdall’s SQL failover is from an application perspective. When Heimdall detects an unhealthy database instance, it will queue up the current connection and gracefully failover to the replicate database. This results in minimal to no application errors and exceptions.
- Seamless AWS integration: Heimdall is tightly integrated with Amazon Elasticache, RDS/Aurora, CloudWatch, and Redshift. Our configuration wizard provides a user-friendly console to connect Heimdall to your AWS components. All integration is without code changes.
Heimdall Data is available in the AWS Marketplace and is installed in your EC2 application instance. With the Heimdall-AWS configuration wizard, we automatically connect to Amazon Elasticache and RDS based in IAM roles. Just point to our storage of choice (in-memory or Elasticache) and RDS data source, and we will take it from there.
But we already cache at the business object and web level. Does Heimdall Data still add benefit?
Web level caching is static content. And, one can only start streaming static content once the dynamic pieces have been generated. It is that dynamic content from the database that Heimdall optimizes.
How is Heimdall Data different from middleware (IBM, Oracle, Microsoft, , Tibco)?
What makes the Heimdall Data High Availability failover unique compared to Oracle and existing load balancing solutions?
- The Heimdall Data HA failover solution is database vendor neutral. For customers who deploy multiple data sources, Heimdall can be used as a common platform for automated database failover. Heimdall Data supports databases such as MySQL, PostgreSQL and Oracle. Additionally, customers do not have to purchase piecemeal solutions as Heimdall is a platform for supporting 1) SQL optimization, 2) Automated failover and 3) SQL security.
- Solutions in the market today (e.g. TCP load balancer) are not application aware. The TCP load balance may successfully failover to a redundant database, but if the application time out and be forced to reconnect. The Heimdall Data Resiliency Platform is application aware ensuring that upon a database failover, the application connection will be maintained and is at top performance.
- Heimdall Data can automate the failover on the master node for disaster recovery. We do not support database replication or slave promotion.
How much CPU and RAM load does Heimdall take up on the application server?
How is Heimdall Data different from Hibernate ORM (Object-Relational Mapping) framework?
From a SQL context, Hibernate requires the user to program to its APIs. Hibernate can interface with grid caches and manipulate SQL queries. Heimdall Data can do the same but is deployed transparently, requiring zero application code level changes. Heimdall is much easier to manage and deploy. Moreover, the performance of Hibernate is no comparison to that of Heimdall Data. Heimdall was architected to increase application performance and offer a platform of services (i.e. SQL optimization, HA, and security)
What is the pricing model for Heimdall Data?
Is Heimdall Data suitable for deployments in the cloud?
Heimdall caching offloads the database. We achieve this by caching SQL on the application side. Deployment is distributed across application nodes.