In April I started looking at HANA as a competitor. Then I was the Field CTO in EMEA for the Greenplum Division of EMC. At that time I posted a blog here on the topic of HANA vs. Exalytics. I would like to reiterate the ideas in that post for this audience. So let’s consider what Exalytics is and what it isn’t, consider what the HANA database is and what it isn’t, and consider where there may be overlap and competition. Finally in the space were the two products might compete, consider where one or the other might have an advantage based on architecture… not on marketing. I hope that you will find this piece fair and factual.
To define Exalytics I’ll use the definition offered by a leading Exalytics proponent and an Oracle partner, who participated in the early release program: Ritman Mead. They say: “Oracle Exalytics uses a specially-enhanced version of Oracle TimesTen, Oracle’s in-memory database, to cache commonly-used aggregates used in dashboards, analyses and other BI objects.” To see that I did not take the quote out of context you can see the entire article here or go to the Ritman Mead Exalytics Test Center here. You can also confirm this yourself by reading the Oracle documentation on Exalytics although there it is stated in a more fuzzy way. Note that as you read the documentation you will see that the base data has to live in another DBMS instance and it is that instance that needs to derive the “commonly-used aggregates”. So, Exalytics is an OLAP engine that stores cubed data in-memory for fast access.
You might wonder why this cache is required why these basic OLAP queries need an assist? It turns out that Exadata has some issues. More details can be found here in a post by a leading Exadata performance expert. There are two videos at this site. The first describes the problem and the second demonstrates the problem using an Oracle demonstration as the example. I highly recommend both these videos be viewed by anyone who has, or is considering, Exadata.
HANA is a full-fledged DBMS architected in-memory based on a column-store with massively parallel threading upon a shared-nothing scheme. I know that this sounds like marketing mush but in these components of architecture lay the differences that are relevant to our comparison:
- In-memory is what HANA shares with Exalytics. Both systems provide extreme performance by eliminating I/O.
- Column store provides HANA with the ability to compress the data beyond what can be achieved with just row store. Exalytics offers a dictionary compression scheme they call hybrid columnar compression but the name is misleading. Exalytics is not a column-oriented DBMS. Column orientation also provides HANA with the ability to utilize the processors more effectively by keeping data in the internal processor cache. This can provide a 200X performance improvement over reading from main memory (see here) but we’ll just say that it gives HANA a boost.
- HANA is massively parallel. This means that on a single query HANA can get all of the cores working. If these products are running on a 4X10 40-core server HANA will run 30X-40X faster on a single query than a single-threaded implementation. Plus the boost from above.
- HANA is a shared-nothing implementation. This means that you can scale up to solve bigger problems. On a fat server with 512GB of main memory both HANA and Exalytics can store around 256GB of compressed user data (actually Exalytics store less… see here and here). If you need to add more data to Exalytics you are skunked. You can split your cube and route queries appropriately but you cannot join between Exalytics instances and each query can use only the processing of one server. With HANA adding data is simple you just re-partition the data across all of the processors. The change is transparent and each query will use all of the processing power on both servers. Exalytics is not scalable.
- HANA is a DBMS. You can do whatever is required. JOINs, stored procedures, in-database analytics, whatever is required. In fact, HANA dynamically derives OLAP structures at query time, negating the need for pre-aggregation or materialization. But to compare apples-to-apples, you could pre-aggregate data into an OLAP structure in HANA and execute the same exact cube queries that Exalytics supports with the columnar boost, with the efficient CPU utilization, with scalability, and with all of the features of a DBMS.
If there is a place where HANA and Exalytics compete it is in the processing of OLAP cube queries. Any implication that Exalytics can solve other database problems is misleading. Any suggestion that Exalytics is Oracle’s answer to HANA is misguided. HANA is so much more than a facility “to cache commonly-used aggregates used in dashboards”. Exalytics should be screaming fast in-memory is a powerful architecture but based on the other architectural components HANA will be faster even in the narrow space where Exalytics, Oracle’s OLAP accelerator, plays.