Entries (RSS)
ParAccel Demonstrates 200X Compression!
January 11th, 2010 by BarryCategories: Barry
True? Not Really.
I recently watched the CEO of a major database company claim that the latest version of their product delivers 10X-50X data compression for data warehousing.
Yes, ParAccel recently created a 200TB dataset that loaded into 1TB compressed. This is actually no big deal because the dataset was very highly redundant. I expect our competitors could achieve the same degree of compression with the same dataset.
However, and this is important, real-world data is just not that redundant!
The recent blog post, Partway There, penned by my colleague, Rick Glick, prompted some comments, one of which I would like to explore in detail. I’d like to explain why ParAccel typically expects at least a 10X benefit over Oracle Exadata. For customers with wide tables, the difference is often a 100X benefit.
First, let’s establish some key points:
What a great time to work with data—quantities are exploding at an ever-increasing rate and new approaches to analyze and search through vast oceans of data spring up continuously. Change is constant as old architectures and approaches are revisited and improved upon. As analytic processing approaches are tested, both old and new, they will either continue on or become discarded.
ParAccel has made it clear to the public that we use columnar storage to achieve superior analytic query performance. At the risk of being heretical, I think the recent discussion in the blogosphere of whether an analytic database uses columnar storage or doesn’t may be a red herring. Why should customers really care about how database products store data? If I drive a car I only want to know how fast it goes, how easy it is to drive, and how much it costs. Should I really care whether it’s fueled by carbon or hydrogen as long as they are both cheap and readily available?
TPC challenges happen. They can occur over a number of things, including documentation errors in the published results, human errors by the auditor during the verification process, hardware or software pricing errors (usually omissions), or procedural errors by the database or hardware vendor.