I would like to point out a very important section in the paper on Hekaton on the Microsoft Research site here. I will quote the section in total:
2. DESIGN CONSIDERATIONS
An analysis done early on in the project drove home the fact that a 10-100X throughput improvement cannot be achieved by optimizing existing SQL Server mechanisms. Throughput can be increased in three ways: improving scalability, improving CPI (cycles per instruction), and reducing the number of instructions executed per request. The analysis showed that, even under highly optimistic assumptions, improving scalability and CPI can produce only a 3-4X improvement. The detailed analysis is included as an appendix.
The only real hope is to reduce the number of instructions executed but the reduction needs to be dramatic. To go 10X faster, the engine must execute 90% fewer instructions and yet still get the work done. To go 100X faster, it must execute 99% fewer instructions. This level of improvement is not feasible by optimizing existing storage and execution mechanisms. Reaching the 10-100X goal requires a much more efficient way to store and process data.
This is important because it confirms the difference in a Level 3 and a Level 2 columnar implementation as described here. It is just not possible for a Level 2 implementation with a row-based join engine to achieve the performance of a Level 3 implementation. This will allow the Level 3 implementations: HANA, BLU, Hekaton, and Oracle 12c to distance themselves from the Level 2 products: Teradata and Greenplum; by more than 10X… and this is a very significant advantage.
Related articles
I really like how you critique database platforms. Seemingly more objective than the usual SAP hype and marketing.
Thanks, Bill… I appreciate your seemingly sincere compliment. 😉
I try hard to lay out a picture of the various architectural trade-offs made by each vendor… and then to point out the strengths and weaknesses.
But to again disclose fully… out of respect for my paycheck I will point out only the strengths of SAP products and let the readers find the weaknesses themselves from the architecture.
In other words, I’ll maintain some objectivity on the plus side and not blow marketing foam… but I won’t bash HANA.
I hope this is clear to readers… that they clearly understand my starting point… and that they call me every time they find a mistake.
Thanks again, Bill…
Rob