FAQ

When should you use Heimdall Data?

Heimdall Data ideal for the following use cases:

  1.  Multiple application servers accessing a database: Heimdall caches SQL in a distributed fashion on application servers offloading database processing. Heimdall deployment removes the network latency between application-to-database for maximum application performance.
  2. Horizontal database scale-out: Deploy read replicas with a single policy; no more code changes
  3. Database Disaster Recovery: An off-the-shelf failover solution for MySQL, MariaDB, Postgres, Oracle, & SQL Server.
  4. Database Firewall: Our machine learning algorithms, detect and block SQL injection anomalies. There are no signature or profile updates. Heimdall Data will prevent a ZERO day database attack.

 

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 Hibernate?

Yes. Heimdall Data can work with Hibernate:

  1. Heimdall Data is installed at data access layer alongside Hibernate and caches SQL result sets. We are transparent to Hibernate.
  2. While Hibernate caches SQL queries, it requires the user to choose which queries to cache. Heimdall automates caching and invalidation and provides additional performance.
  3. Heimdall Data aggregates caches nodes as a single cluster across application servers for efficient cache management. Hibernate caching is on a per application server.

 

How is Heimdall Data used as a transparent cache?

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 industry is its auto-cache AND auto-invalidation capability. Our machine learning 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 available in the AWS Marketplace and is installed in your EC2 application instance. WIth our 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.

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 machine learning 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. Advanced Amazon RDS failover: Because RDS failover is at the DNS level, connection timeouts will occur resulting in customer dissatisfaction and potential loss of revenue. Heimdall Data’s database failover is transparent to the application and the will not result in connection drops.
  3. Better usage of RDS read replicas: When read replicas are created, the developers need to adjust the application to 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.

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 insuring 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.

In 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 a one-time perpetual license or pay ongoing on a per usage basis. Both scenarios are supported.

Is Heimdall Data suitable for deployments in the cloud?

Absolutely. As cloud deployments cause database instances to be geographically dispersed, network latency between application to database will cause performance issues.
Heimdall is a must for cloud deployments; as it 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.