In-memory vs. In-memory: same, yet different
A question I get with some regularity is this: does the SAP Sybase ASE In-Memory database (IMDB) do the same thing as SAP HANA?
A formal answer is “yes”: they both use RAM to deliver better performance.
However, the more practical answer is “no” since the goals these databases are trying to achieve by optimal use of memory, are quite different.
Let me explain.
It is well known that SAP HANA is an in-memory database (if this is news to you, I recommend going to www.saphana.com and start reading). Independently, Sybase ASE has supported an “in-memory database” (IMDB) feature since the release of ASE version 15.5 in 2009. The striking similarity here is the use of the words “in-memory” in both cases, which may suggest that these databases are identical. However, they are not.
First, SAP HANA is entirely based on the notion of caching all data in main memory. Combined with its columnar compression this allows very large databases to be fully cached. In addition, HANA is optimized for a particular family of Intel processors, which gives it these lightning-fast response times we have all witnessed. Due to its ability to access large amounts of memory very rapidly, HANA can dramatically accelerate response times for read operations and aggregations (e.g. SELECT statements), which are the most common types of workload in an analytics environment.
SAP Sybase ASE’s IMDB feature can also be used to fully cache ASE databases in main memory (of the multiple ASE databases in an ASE server you can choose to cache one or more as you like, and as your available memory permits). However, ASE IMDB was designed to speed up throughput of concurrent transactional OLTP workload (see this whitepaper for more background), which works best on an uncompressed row-oriented storage model. ASE IMDB never aimed to speed up the performance or response time of read operations (e.g. SELECT statements), and no improvements should be expected here.
In fact, it is unlikely that better performance will be observed for a single ASE user doing a transaction in an ASE IMDB. The ASE IMDB starts to pay off when multiple users are busy doing small OLTP database transactions concurrently. Technically, this works by cutting some corners in the area of the ASE transaction log: since an ASE IMDB database is not recovered after an ASE shutdown, this knowledge can be used to provide faster concurrent transactional performance and better scalability. Depending on the workload profile, improvements of up to a factor 5-6 have been measured, compared to a classic ASE database (see here for more details).
This also brings us to the price you pay for the improved transactional performance in the ASE IMDB (apart from spending the money to buy the ASE IMDB license option): transactions in an ASE IMDB database are not ‘durable’ (i.e. we lose the ‘D’ in ‘ACID’), since nothing is ever written to disk for an ASE IMDB (transactions in SAP HANA are fully ACID).
At the same time, this allowed the ASE engineers to further streamline ASE’s already advanced buffer management algorithms (like relaxing the strict MRU-LRU chain). It also paved the way for implementing various novel low-level transaction logging optimizations (technical details are described here, should you be interested).
I have not yet mentioned the most attractive aspect of the ASE IMDB – namely, that it is easy to use in an existing system. To an application, there is no difference between a SQL executed in ASE IMDB database or in a classic ASE database. In-memory features from competing database vendors (like Oracle’s TimesTen) could (and can) not offer such application transparency.
Lastly, in case you’d ask: ASE’s #1 SD Benchmark results for 2-, 4- and 8-socket configurations on Intel/Linux do not utilize the ASE IMDB feature. As a result of the non-durable transactions that are implied, the ASE IMDB feature is not supported with SAP Business Suite.