When should you use Heimdall Data?
  1. Redundant, slow queries: Caches SQL results to the grid-cache of your choice, offloading database processing and improves response times.
  2. Horizontal database scale-out: Read/write split for better use of read replicas without code changes. Ensures fresh data for ACID compliance with replication lag detection.
  3. Connection Pooling: Minimizes backend on connections to the database. Two-tier control to limits per user and per database server connections.
  4. SQL Performance Analytics: Identifies the SQL bottleneck: Application? Database? Network latency?
  5. 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.
  6. Database Firewall: Detects and blocks SQL injection anomalies. There are no signature or profile updates. Our proxy prevents ZERO day database attacks.
Does Heimdall Data support all databases (SQL and NoSQL)?
Heimdall Data supports most all relational database (e.g. MySQL, Postgres, Amazon RDS, Oracle, SQL Server, MariaDB). Our solution is transparent to the application and database. We are a software add-on installed on application servers.

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)?
Yes. Heimdall Data works with ORM’s.

An ORM (Object-Relational Mapping) is a tool that queries and manipulates data from a database using an object paradigm. Below are the added benefits of Heimdall Data:

  1. 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.
  2. 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.
  3. 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 Data 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 Data solution 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 Data cache solution provides custom recommendations on exactly what to cache, taking out the guesswork for application owners. With Heimdall’s “One-click optimization”, caching policies are immediately enabled without any programming, and can be disabled just as fast.

But what makes Heimdall Data unique in the industry is its auto-cache AND auto-invalidation capability. Our algorithms determine what queries to cache while invalidating to ensure maximum performance and data integrity.

Are you supported in AWS 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 an Advanced Technology partner of AWS Marketplace and is installed in your EC2 application instance. WIth our AWS configuration wizard, we automatically connect to Amazon Elasticache and Amazon Aurora/RDS. Just point to our storage of choice (in-memory or Elasticache) and RDS data source, and we will take it from there.

Heimdall Data is also supported on Azure and Google Cloud Platform.

Why Heimdall Data if we are already deployed in AWS?
Heimdall Data enhances an already existing application-database in AWS in 3 ways:

  1. 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.
  2. Better usage of RDS read replicas: When read replicas are created, the developers must modify the application to bring new database servers online. 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.
  3. Persistent connection automated failover: Amazon RDS/Aurora 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.
  4. 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. 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?
Absolutely. Working alongside the application caches and web caches, the Heimdall cache provides additional for performance benefits, particularly for dynamic content. Application level caches may have constrained parameters (e.g. per session) limiting the caching required for optimal performance. Because Heimdall caches at the data access layer, it sees the unrestricted flow traffic going to the database and optimizes performance that other cache systems will not be able to detect.

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)?
Middleware products provide flexibility of data interfaces for integration and management. Also, users of middleware require users to program to an API. From its inception, Heimdall Data’s value proposition is to be transparent, requiring ZERO application code level changes so that there is no integration work by the customer. Additionally, Heimdall Data is focused on improving application performance and scale, not on supporting multiple access methods (e.g. SOAP, REST, ODBC) like middleware vendors. Heimdall Data complements and is compatible with middleware products.
What makes the Heimdall Data High Availability failover unique compared to Oracle and existing load balancing solutions?
  1. 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.
  1. 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.
  1. 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?
Although application dependent, we have found that enabling Heimdall caching or Heimdall HA failover consumes minimal server load. On the average, initial estimates show single digit percentage load of CPU and RAM when Heimdall is enabled.
How is Heimdall Data different from Hibernate ORM (Object-Relational Mapping) framework?
Heimdall is a SQL optimization platform that supports caching, security, and high availability. Heimdall Data can work together with Hibernate and make your environment more scalable and higher performing.

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?
A customer can purchase Heimdall Data as an annual subscription license or on a per usage basis.
Is Heimdall Data suitable for deployments in the cloud?
Heimdall is ideal for the cloud. In cloud deployments, application and database instances can be geographically dispersed, causing network latency resulting performance issues.
Heimdall caching offloads the database. We achieve this by caching SQL on the application side. Deployment is distributed across application nodes.
Does the use of Heimdall invalidate the support contracts for databases?
While vendors have their own policies, the answer should be no. As we are operating above the vendor JDBC level, Heimdall is comparable from a support point of view to being part of the application itself, not part of the database access layer, at least as far as the database is concerned. Another way to put it is if you change your own code, will this invalidate a database’s support license? This is in contrast with devices and systems that operate at the protocol level, which may need to be certified to access the database to maintain support.
Our Web Application Firewall is used protect against SQL attacks.
SQL injection attacks trick the application into performing adversely. Because this form of attack is dependent the application behavior, there are cases where the WAF or application does not see such an attack. Hence, the Heimdall solution will act as a last line of defense for SQL data leakage.
How does Heimdall Data benefit Big Data?
Big data generally refers to how data is processed on multiple computing systems, and how a client can access the data from such systems (e.g. sharding). As Heimdall operates above the actual access layer for the data, it offers benefits much like any other database, as long as the underlying access driver is JDBC compliant, including visibility of what queries are taking the most time to process, which in a big data environment may be significant.