Top-level points included:

• Exasol’s technical philosophy is substantially the same as before, albeit not with as extreme a focus on fitting everything in RAM.
• Exasol believes its flagship DBMS EXASolution has great performance on a load-and-go basis.
• Exasol has 25 EXASolution customers, all in Germany.*
• 5 of those are “cloud” customers, at hosting providers engaged by Exasol.
• EXASolution database sizes now range from the low 100s of gigabytes up to 30 terabytes.
• Pretty much the whole company is in Nuremberg.

*That excludes some money from Hitachi. Exasol’s Hitachi partnership is still in limbo, an apparent casualty of the world economic crisis.

On the technical side:

• As noted in my 2008 post, EXASolution is a columnar, no-head-node MPP (Massively Parallel Processing) DBMS.
• The main way EXASolution compresses data is via dictionary/tokenization. 5:1 is a typical compression ratio before mirroring and so on, out of a 2-10:1 range.
• EXASolution writes data to blocks in memory that are smaller than what is otherwise its preferred size (1/2 to 5 megabytes). These are sent to disk, where merge eventually happens. Exasol insists that write performance has always been fully satisfactory to customers to date.
• EXASolution doesn’t have much in the way of performance tuning knobs. Exasol says they aren’t needed, and says that one really can start an EXASolution POC (Proof of Concept) in a day or so.
• EXASolution doesn’t have much in the way of workload management capabilities, except what’s automagic (e.g., short query bias). However, it does collect statistics you can query via your favorite BI tool.
• EXASolution doesn’t have much in the way of analytic platform capabilities, although there is some Lua-based scripting. However, there’s something NDA in the analytic platform area Coming Soon.*

In general, the whole thing sounds somewhat like ParAccel, at least at a high level.

*Exasol is not and never has been our client, but we can keep secrets for them even so.

Naturally, Exasol believes EXASolution has fine concurrency, with at least one customer routinely running 2000 concurrent users, 200 concurrent sessions (via connection pooling), and 5-10 concurrent queries. Another customer has 3500 Cognos users. 1-200 concurrent queries appears to be the record peak load. Anyhow, Exasol says that plans to offer real workload management could be accelerated if a need were discovered.

Exasol says it almost never loses POCs, but admits that it competes fairly rarely against Vertica and ParAccel, no doubt for reasons of geography. Exasol boasts one visible Sybase IQ replacement (Sony Music).

While Exasol’s sales to date have been in Germany, there are plans to change that soon. At least one sales cycle is well underway in Eastern Europe. Offices in other Germanic countries are planned. Existing customers are planning to deploy additional copies outside Germany. Discussions are underway regarding other geographies, e.g. English-speaking ones.

Let’s try eight categories instead. While no categorization is ever perfect, these each have at least some degree of technical homogeneity. Figuring out which types of analytic database you have or need — and in most cases you’ll need several — is a great early step in your analytic technology planning. 

Enterprise data warehouse (Full or partial)

• Kinds of data likely to be included: All, but especially operational
• Likely use styles: All
• Canonical example: Central EDW for a big enterprise
• Stresses: Concurrency, reliability, workload management

The enterprise data warehouse (EDW) ideal says that you copy all your data into one place, and drive all decision-making from there. Full EDWs are pipedreams. Still, a partial EDW makes sense for most large enterprises, and many indeed already have one. The first product lines to consider for classical EDWs are Teradata, DB2, Exadata, and maybe Microsoft SQL Server, especially if you’re going to stress concurrency and/or operational use cases.

Traditional data mart

• Kinds of data likely to be included: All
• Likely use styles: Business intelligence, budgeting/consolidation, investigative
• Examples: Reporting servers, planning/consolidation servers, anything MOLAP, etc.
• Stresses: Performance, concurrency, TCO

Whether or not you have something like an enterprise data warehouse, it’s common to have lighter-weight data marts as well. A traditional data mart might drive reports and dashboards. Or it might be specialized for budgeting, planning, and/or consolidation.  Some investigative analytics may be in the mix as well.

Any DBMS that can support an EDW can also support a data mart, but it may not be the most cost-effective way to do so. Columnar DBMS might have more attractive performance and TCO (Total Cost of Ownership); the same goes for Netezza. Some of them — e.g. Sybase IQ and Vertica — have excellent track records in concurrent usage as well. Ted Codd pushed what amounts to MOLAP (Multidimensional OnLine Analytic Processing) systems for these use cases. But relational DBMS commonly do a better job, which is one reason most major MOLAP products have wound up at RDBMS companies.

Investigative data mart — agile

• Kinds of data likely to be included: All, especially customer-centric
• Likely use styles: Investigative
• Canonical example: A few analysts getting a few TB to examine
• Stresses: Ease of setup/load, ease of admin, price/performance

Besides the traditional data mart, there are at least two other kinds. Both are focused on investigative analytics, but they’re differentiated by database size.

If you have just a few analysts,* looking at no more than a few terabytes of data (perhaps even just some gigabytes) — and if that data is “single-subject” and fairly homogenous — your watchwords should be “cheap”, “easy”, and “fast”. You don’t need to invest in much hardware, in expensive software, in much administrative effort (the analysts can be their own DBAs),  nor should you endure much set-up time. Just grab a product, grab some data, and start running queries (or extracts into the statistical tool of your choice).

*If you have dozens or even hundreds of analysts hitting the same database, you’re probably back to the more concurrency-oriented scenarios outlined above.

Infobright is often cost-effective among columnar analytic DBMS. Other vendors might cut you a price break as well. If you have multiple terabytes of data, don’t rule out Netezza’s lowest-end products (even if they’d really rather sell you something bigger). Or, if you’re in the sub-terabyte range, maybe you can get by with an in-memory BI tool such as QlikView, and not do anything special on the DBMS side at all.

Investigative data mart — big

• Kinds of data likely to be included: All, especially customer-centric, logs, financial trade, scientific
• Likely use styles: Investigative
• Canonical example: Single-subject 20 TB – 20 PB relational database
• Stresses: Performance, scale-out, analytic functionality

But if you’re looking at tens of terabytes of relational data, or even more, you really do have a “big data” problem. Performance and scalability are major challenges, usually best addressed by MPP (Massively Parallel Processing) systems, such as Netezza, Vertica, Aster Data, ParAccel, Teradata, or Greenplum. Performance POCs (Proofs Of Concept) are a big part of the buying process. Vendor price negotiations are crucial too.

Actually, in the low tens of terabytes you might be able to get away with a shared-disk system that has excellent compression — e.g., columnar products like Sybase IQ, Infobright, or SAND, rather than just Vertica and ParAccel.

Assuming you have affordable, scalable query performance, the competitive differentiator can switch to additional analytic functionality. Aster, Netezza, ParAccel, Vertica, and Greenplum either offer full analytic platforms, or seem to be on the path to doing so. Teradata, which now owns Aster Data, offers substantial built-in analytic capability in its traditional products as well, and the same goes for Sybase IQ.

Continued in Part 2, where we cover some of the more difficult use cases.

• Vertica has a bunch of customers, including seven with 1 or more petabytes of data each.
• Vertica has progressed down the analytic platform path, with Monday’s release of Vertica 5.0.

And of course you know:

• Vertica (the product) is columnar, MPP, and fast.*
• Vertica (the company) was recently acquired by HP.**

*Similar things seem true of ParAccel, but most of the other serious columnar analytic DBMS aren’t actually MPP (Massively Parallel Processing) yet. More precisely, they have  shared-everything architectures, especially on the storage level.

** Vertica says it has a “staggering” pipeline now that it’s been with HP for a few months.  I also gather that the post-merger HP/Vertica appliance product line formally rolled out last week.

As for product maturity:

• Vertica 4.0 cleaned up a lot of stuff.
• Vertica 5.0 goes further in a variety of areas, notably clustering administration and database tuning/design.

But here’s something I hadn’t fully realized — Vertica claims concurrent usage as a competitive strength. By this I mean:

• Vertica says that it has some customers with 1000s of users, in BI/dashboarding kinds of applications.
• Vertica asserts it can support 1000 users on a single appliance rack.
• Vertica tries to drive POCs (Proofs Of Concept) towards testing concurrency.

This is all consistent with a user example I blogged about last year.

That said, while Vertica introduced respectable workload management features in Vertica 4.0, its main claim to concurrency is simply speed — if each query ends quickly, you never have to execute all that many of them at once.

Anyhow, there will (or at least should be) articles written about Vertica 5.0, and I may not be that easy to find for comment, what with Enzee Universe and all. So here are a few Vertica soundbites:

• Having seven petabyte-level commercial users is an impressive testament to Vertica’s scalability. I think only Teradata could best that number among analytic DBMS, unless you want to count Hadoop/Hive.
• Vertica’s analytic platform capabilities are new, and initially not as rich as Aster Data’s or Netezza’s, especially in the area of language support. But they’re a good first step.
• Judging by the examples of EMC/Greenplum and IBM/Netezza, Vertica’s honeymoon period at HP is likely to last for a while. (Edit: That said, not all is peachy at EMC/Greenplum.)

The Gartner 2010 Data Warehouse Database Management Systems Magic Quadrant is out. I shall now comment, just as I did to varying degrees on the 2009, 2008, 2007, and 2006 Gartner Data Warehouse Database Management System Magic Quadrants.

Note: Links to Gartner Magic Quadrants tend to be unstable. Please alert me if any problems arise; I’ll edit accordingly.

In my comments on the 2008 Gartner Data Warehouse Database Management Systems Magic Quadrant, I observed that Gartner’s “completeness of vision” scores were generally pretty reasonable, but their “ability to execute” rankings were somewhat bizarre; the same remains true this year. For example, Gartner ranks Ingres higher by that metric than Vertica, Aster Data, ParAccel, or Infobright. Yet each of those companies is growing nicely and delivering products that meet serious cutting-edge analytic DBMS needs, neither of which has been true of Ingres since about 1987. 

The general list of “market forces, end-user expectations and vendors’ resulting solution approaches” at the top of the 2010 Gartner Data Warehouse Database Management System Magic Quadrant article is a mixed bag. Following Gartner’s order, I’ll address those first, and particular companies cited afterwards. Specific items and comments include:

• “Increased demand for optimization techniques and performance enhancement.“ Gartner seems to be saying that data warehouse DBMS buyers want lists of specific, esoteric performance features. Well, buyers always want their DBMS to run fast, and they’d like the products to be mature enough to have been through a few rounds of Bottleneck Whack-A-Mole, but otherwise I’m not sure I’d put that at the top of my list.
• “The argument made by purchasing departments that buying power increases when dealing with a single, incumbent vendor.“ I agree that vendor consolidation and account control are a huge part of the Oracle, Microsoft, IBM and even Teradata stories. (Vertica can prove it’s 10X more price-performant than Oracle and still not get the business.) But it’s not just about price negotiations; once annual maintenance is included, one has to squint pretty hard to see Oracle as a low-cost alternative. Also important is reducing the number of total product-specific skill-sets needed on the IT staff.
• “Prepackaged, prebalanced warehouse environments delivered using data warehouse appliances.“ Yep. To varying extents, Oracle, Microsoft, Teradata, and IBM are all committed to designed-hardware strategies.
• “Expectations for the delivery of on-site POCs.“ Honestly, not as many buyers insist on on-site Proofs of Concept as should. Still, Oracle is shameful in its reluctance to do them. (Teradata tries to avoid them too, for obvious reasons of expense, but is much more gracious about capitulating when the buyer insists.)
• “Cost controls and data warehouse performance management.“ See next comment.
• “Demands for delivering a fully mixed workload.“ I’d have phrased the workload management and administrative tools points rather differently than this, but so be it.
• “Demands for departmental analytics delivered quickly via data marts.“ Agreed. Data-mart-only installations are a huge part of the market of the analytic DBMS market. Data mart spin-out is also important.
• “Wider indexing and fast performance within clusters of data, delivered via column-based solutions.“ This bizarrely seems to conflate column stores and parallel processing (both of which are of course highly important).
• “A wave of new data warehouse implementers seeking fast-track, low-risk delivery.“ Well, yes. Netezza noticed that quite some years ago. And by now the long-gestation EDW (Enterprise Data Warehouse) is widely disliked.
• “Global organizations seeking distributed solutions as potential architecture.“ If this is the MPP point, it’s oddly phrased. If this is a suggestion that data warehouses should be partitioned across wide-area networks, it’s just plain odd. If it’s a reiteration that departments like to control their own data marts, I agree. And if it’s a comment on keep-data-in-the-country privacy laws, it could be the most prescient thing Donald Feinberg has said in many years.

Long though it is, that list of general items and issues for the 2010 Gartner Data Warehouse Database Management System Magic Quadrant has some gaps. Most glaringly, I don’t see any references to advanced analytics in general, or even to the specific case of integrated predictive analytics. There’s also nothing about solid-state memory or other storage-technology considerations, although in fairness it’s still early days for much of what vendors conceive of as competitive differentiation in those respects.

Here are some vendor-specific comments on the 2010 Gartner Data Warehouse Database Management System Magic Quadrant:

• It’s pretty bizarre to compare 1010data to database.com or Microsoft Azure. Kognitio would be a better choice. So would cloud-hosted instances of Vertica, Aster Data nCluster, or others.
• Gartner’s comments on Aster Data and nCluster are actually pretty reasonable.
• Gartner’s comments on EMC/Greenplum are a bit Kool-Aid-drinky, and don’t account for the inevitable flailing that occurs right after an acquisition. But otherwise they’re pretty reasonable.
• I don’t take IBM’s super-comprehensive-all-inclusive architectural stories as seriously as Gartner does.
• I don’t take Netezza’s small stable of OEM partners as seriously as Gartner does. I also don’t share Gartner’s optimism for the continuation of Netezza’s NEC partnership in the face of IBM’s Netezza ownership.
• I’m even more skeptical about illuminate than Gartner is.
• I’m delighted that Gartner has adopted my phrase machine-generated data (Infobright is one of several firms pushing that one).
• “Only open-source column-store DBMS” is a bit exaggerated, but Infobright is indeed the only one with serious traction, or offered by a serious analytic DBMS vendor.
• What Gartner said in connection with Ingres is too inaccurate to deserve detailed attention.
• While Gartner’s write-up of Kognitio is a bit confused, that’s excusable. Kognitio’s strategy changes often.
• I’m not persuaded by the claim of low Microsoft TCO. The days when Microsoft’s tools were vastly better than the competition’s are long gone. And using an OLTP DBMS for data warehousing generally takes more people effort than using something more purpose-built.
• Gartner is right to ding Oracle for high prices, high people costs, and unwillingness to do onsite POCs.
• Gartner is right that Exadata is a huge improvement over non-Exadata Oracle data warehousing.
• Gartner is right to suggest that Exadata can easily handle data warehouses over 20 terabytes in size, but wrong to suggest that software-only Oracle also can. Just because the pain is less than it was with earlier releases of Oracle doesn’t mean it isn’t still bad.
• Gartner’s comments on ParAccel are pretty reasonable.
• Gartner’s comments on compression in connection with SAND make no technical sense (tokenization is a key form of columnar compression, not an alternative to it). Also, SAP’s acquisition of Sybase is a business challenge for SAND, not a technical one.
• Unless I’m forgetting something, Sybase IQ has no more in-database data mining than any other Fuzzy Logix partner does.
• Gartner failed to note that, like other DBMS dating back to the 1990s and before, Sybase IQ is more complex to administer than some newer products are.
• Gartner’s take on Teradata is pretty reasonable.
• Gartner’s take on Vertica, while sloppy, is basically sensible. However, Gartner failed to note that Vertica is a laggard in non-query analytics. (I am sure those deficiencies are being addressed, but Vertica’s competitors are moving ahead as well.)

• On the data warehouse side Exadata can alleviate screaming pain points.
• In OLTP consolidation, Exadata mainly can save money. (Yes, I just said a product from Oracle can save customers money, and I meant it. You may stop laughing at any time.)

Doug did overstate when he said that columnar architectures give 100X or more compression. That doesn’t happen. Yes, columnar compression can be >10X in a variety of use cases, while pre-Exadata Oracle index bloat can approach 10X at times; but even if you’re counting that way I doubt there are many instances in which it actually multiplies out to >100.

In other Exadata news, the long-standing observation that Oracle doesn’t like to do on-site Exadata POCs still holds true. A couple of existing Oracle users — one rather well-known — recently told me that Oracle won’t let them text Exadata except on Oracle premises. In one case, this is a deal-breaker keeping Exadata from being considered for a purchase, and Oracle still won’t budge.

Finally, I’m pretty sure that this “new” Softbank Teradata replacement Oracle has been touting since September as competitive evidence — which Doug’s article also references — isn’t quite what it sounds like. I believe Teradata’s version of the story, which somewhat edited goes like this: 

• The Oracle Exadata decision at Softbank Mobile was driven by business management in spite of Teradata being recommended by the technical team.
• To reiterate, the data warehouse project team recommended Teradata over Oracle.  The Teradata proposal was well received in terms of TCO, performance, ease of use and safety of transition, etc. against Oracle Exadata.  However, the technical team’s recommendation was overruled due to the business mandate to standardize on Oracle throughout the company.
• SoftBank Mobile has over 800 Oracle specialists in IT departments and Software subsidiaries.
• The Exadata performance is being compared to the existing production system.  Teradata was NOT invited to benchmark a current generation system.
• Also, Softbank Mobile is a reseller of Oracle.

Teradata went on to clarify:

Here are some key points regarding the Teradata systems at SoftBank:

• Two Teradata systems:  Production #1 - 32 nodes.  Production #2 - 12 nodes.
• Production #1 had nodes ranging from ~3-7 years old.
• Production #2 had nodes that were ~8 years old.
• Teradata V2R5 was end of life at the time of replacement.
• We did not get a chance to compete for this business.

Bottom line: Oracle’s big competitive replacement of Teradata systems was against 3-8 year old boxes that the customer’s technical staff recommended be replaced by more Teradata gear.

• This is a very long post.
• Even so, to keep it somewhat manageable, I’ve cut corners on completeness. Most notably, two important areas are entirely deferred to future posts — advanced-analytics-specific architecture, and in-memory processing (including CEP).
• The subjects here are not strictly parallel. The distinction between major add-on modules and “turtles all the way down” core architectural choices is rarely crystal-clear — Mike Stonebraker’s recent post notwithstanding — and I’ve mixed subjects of varying degrees of “fundamentalness” pretty freely.
• There’s a long list of links at the end, pointing at posts that help explain or give examples of specific features named in the body of the text, somewhat like unnumbered footnotes.

OK. In my opinion, the four drop-dead requirements for an analytic DBMS are:

• Relational/SQL support. That’s how you get great flexibility in more or less easily constructing queries, as well as connectivity to a vast number of tools. In a few cases, I guess MDX might suffice as an alternative.
• Sufficiently great query performance, on the queries you’re actually going to run, for however many concurrent users you actually will have.
• Sufficiently high data loading throughput and sufficiently low data loading latency.
• Sufficiently favorable TCO (Total Cost of Ownership), all things considered, where “all things” at a minimum includes software license, software maintenance, hardware, power, people costs for administration, and people costs for development.

Depending on your use case, you might have additional make-or-break requirements. Possible areas include:

• Additional query functionality, of course with good performance. Specific examples include:
  • ANSI-standard SQL features that are not universally supported (e.g. windowing).
  • Geospatial datatype support.
• Further high-performing integrated analytics, such as:
  • Data mining/machine learning modeling and scoring.
  • Other mathematical functions, such as linear algebra, optimization, or Monte Carlo simulation.
  • Extensibility via MapReduce and/or sufficiently robust user-defined function (UDF) capabilities.
• Platform support that matches your needs.
• Security, auditability, and/or high-performance encryption.

Other possibly important features — but ones that would usually go on “nice to have” rather than “must have” lists — include:

• Yet more query functionality, in areas such as:
  • Non-standard SQL extensions (e.g. temporal ones)
  • Specific prepackaged UDFs.
  • Cross-column text search.
• Nice administrative tools, in areas such as:
  • Single-query performance/optimization.
  • Authorization/permission.
  • Workload management.
  • Data mart spin-out.

So what kinds of architectural choices (or major features) should one look to to support such features? On the performance side there are many candidates, including:

• Specialized indexes, more commonly found in older DBMS. Leading examples include star and especially bitmap indices, both of which I was already writing about back in the 1990s. Ditto materialized views, which aren’t exactly indices, but are closely related.
• Partition elimination. Single- or multi-level range partitioning can cause whole regions of the database never to be checked in a particular query’s evaluation. (That’s a good thing.) The functionality popularized by Netezza as zone maps does something similar, without requiring the partitions to be chosen in advance.
• Scan-friendliness. If a query runs a long time, it may include a lot of (full or partial) table scanning. Assuming you rely on spinning disk — as opposed to solid-state memory — one way to improve your sequential-scan throughput far above your random-read throughput is to support large block sizes.
• Parallelism. It’s possible to screw up even multi-core parallelism, but the big issue is multi-server. In particular:
  • An analytic DBMS must avoid a “fat head” bottleneck, either because there is no head node at all directing things, or else because data redistribution algorithms are sufficiently mature as to not overload it. (In naive parallel DBMS implementations, intermediate query results get sent back to the head node to be, for example, JOINed together. This is not a good thing.)
  • Multiple analytic DBMS vendors have chosen to develop custom data transfer protocols, for more reliable performance than they can get from TCP/IP. Examples include Teradata, Netezza, and ParAccel.
• Predicate pushdown. Predicate pushdown takes several forms, in all cases having the goal of executing certain simpler database operations — predicate evaluations — close to the data, thus minimizing I/O or upstream processing.
  • Netezza famously offloads the first part of predicate evaluation to FPGA (Field-Programmable Gate Array) chips.
  • At least in theory, I like the Exadata form of node specialization, in which a tier of server nodes does the first part of the processing, with the results being sent to a second upstream database tier. But it’s not obvious that any RDBMS vendor has done a great job with it. Oracle is famously secretive about Exadata’s track record, and as of this writing apparently still resists on-site benchmarks. Calpont hasn’t accomplished much. And MarkLogic of course doesn’t sell an RDBMS.
  • There’s reason to think predicate pushdown would help exploit flash memory, although I’m not sure vendors are moving in a direction that will let us find out.
• Columnar data storage. Columnar storage is pretty much the ultimate in predicate pushdown, and advantageous in many analytic query scenarios. (Main exception: When you’re bringing back the majority of a row anyway, you might as well fetch the thing pre-assembled.) As Mike Stonebraker points out, columnar storage should not incur serious row-ID overhead, and ideally should be available for multiple sort orders on each column.
• Compression. This, rightly, is another of Mike Stonebraker’s favorite features. Database compression is hugely important, for I/O and in silicon alike. (And it can also save money on storage.) There are a broad variety of compression techniques, suited for different kinds of data, different kinds of queries, or different points on the storage saving/decompression performance tradeoff spectrum.
• Flexible storage. Not all data is best stored the same way, even if it’s in the same database. Some is destined for columnar-friendly use cases, other for whole row. Some is compressed ideally by one technique, some by another. And so on. Some database managers do a good job of letting different parts of the database (even within the same table) be stored in different ways.
• Query pipelining. There are a lot of steps to query execution, in both the fine-grained sense (a whole lot of rows) and the coarse-grained (all but the simplest execution plans feature a number of operations each). FPGA-based vendors XtremeData and Kickfire used the innate parallelism of an FPGA to pipeline query execution. Kickfire failed, and XtremeData hasn’t sold many systems, but that doesn’t mean it isn’t a good idea. Kickfire’s assets were sold to Teradata. Meanwhile, VectorWise’s very name speaks to its (Intel-based) vector processing architecture.
• Result set reuse. Instead of mixing together different steps of the same query, how about mixing together the same step in different queries, so that you don’t have to repeat it? As a simple example, suppose two queries need to do the same table scan. Well then, it would be nice to only do the scan once. In most cases, query workloads are too diverse for result set reuse of that kind to be very important; still, it’s a cool feature, which Teradata calls synchronized scan.
• Suitably optimized execution engine – column, row, whatever. (This is Mike Stonebraker’s “inner loop” point generalized.)
• Well-factored query optimizer. No matter what, it’s good for a query optimizer to have been through a few rounds of Bottleneck Whack-A-Mole. Beyond that, an optimizer with sufficiently convenient hooks can have cool and occasionally valuable features such as:
  • On-the-fly query re-planning. Do part of the query, rerun column statistics, and re-plan the query if appropriate.
  • Not-so-black-box optimization. Work interactively with the DBA to find the best query plan.
  • Query rewriting. Any decent optimizer will take a complex query and produce an execution plan that in some cases looks quite unlike the original query. Some optimizers go further in rewriting the query first, essentially to psych themselves into coming up with a better plan.

You can’t do much with an analytic database unless you get data into it in the first place. Thus, performance in writing and loading data are important, and there are a number of architectural decisions that can be helpful in those regards.

• Row-based architecture. Column stores have obvious advantages for query, but in a naive column store implementation you have tremendous overhead, pulling the rows apart and storing them in many different columns. This is particularly the case for small, frequent updates.
• Batched writes. The classic way to deal with column stores’ data writing challenges is to batch data in memory, then bang it to disk only occasionally. Hopefully the data is available seamlessly for query in RAM before the disk-banging occurs. This technique is by no means restricted to analytic and/or columnar use cases, but the single best-known example may be Vertica’s Read-Optimized Store (disk)/Write-Optimized Store (RAM) pairing.
• Lack of indices and materialized views. Indexes and materialized views can help query speed, albeit at the cost of disk space and administrative effort. But maintaining them multiplies the difficulty of loading data in the first place.
• Lockless or optimistic-locking concurrency model. Locking models suitable for OLTP  can be ridiculous for analytic databases, blocking queries for no good reason. Fortunately, there are alternatives.
• Append-only updating. When I/O volumes are high, append-only updating can give an important performance improvement over update-in-place, assuming you have sufficiently good algorithms for garbage-collection/clean-up. If I/O volumes are so low that you don’t care about the performance benefits, maybe it would be nice to have the “time-travel” feature that’s a potential byproduct of MVCC (Multi-Version Concurrency Control). Neither part of this observation applies solely to analytic DBMS.
• Parallel load (no fat head). It’s not just query execution that can get bottlenecked at a “head node;” the same can happen with loads, batch or otherwise. That’s not a good thing. Thus, various parallel analytic DBMS vendors have set up ways to load data directly to the nodes where it’s going to be stored.
• Specialized load nodes. Aster Data nCluster features specialized data loading nodes, although Aster has introduced a more conventional kind of parallel load as well.

And of course, all of the above need to be implemented in the context of well-configured combinations of hardware, networking, and software.

Topics I know I’ve left out include advanced-analytics functionality, and in-memory processing (CEP or otherwise). Also missing are specifics of compression algorithms — or indeed of anything else. I’m sure there’s much else missing besides, so please point out the most glaring omissions in the comment thread below.

Related links:

• Why even in-database scoring can be important (May, 2010).
• Three big myths about MapReduce (October, 2009).
• Why you might ever want to integrate MapReduce into your DBMS (August, 2008).
• The future of data marts, specifically data mart spin-out. (June, 2009).
• Netezza offers both zone maps and clustered base tables (June, 2010).
• Oracle Exadata Storage Indexes are like Netezza zone maps (January, 2010).
• How Netezza uses the FPGA (August, 2010).
• Oracle is reluctant to do on-site Exadata POCs (February, 2009). As of the end of 2010, that doesn’t seem to have changed.
• The Netezza and IBM DB2 approaches to compression (June, 2010, which is before IBM acquired Netezza).
• The secret sauce to Rainstor’s extreme compression (May, 2009, when Rainstor was still called Clearpace).
• The row-based/columnar distinction gets blurred, e.g. by Vertica FlexStore (August, 2009).
• And by Greenplum (October, 2009). Also contains the observation that even row-style compression works better when data is stored columnarly.
• And by Aster Data (September, 2010).
• Teradata is particularly aggressive about query rewrite (August, 2009).
• Netezza’s logless, lockless architecture (September, 2006).
  

• ParAccel asserts that PADB is much faster than other analytic DBMS — even close competitors such as Vertica — on especially complex queries. “60-way joins” were mentioned. So was the flattening of correlated subqueries.
• ParAccel also claims industry-leading performance on simpler queries, but not by the same (or perhaps even particular large) margins.
• Mercifully, ParAccel no longer claims to have never, ever lost on performance in a customer evaluation. But it still says that is very close to being true.
• Major reasons ParAccel gives for PADB’s high performance include:
  • Like Vertica, Sybase IQ, and others, PADB uses a columnar architecture.
  • ParAccel thinks PADB’s newest query optimizer — fondly named Omne — is outstanding.
  • ParAccel’s PADB compiles its queries.
  • In general, ParAccel is just performance-obsessed.
• One could also mention:
  • ParAccel’s PADB runs smoothly in-memory, if that’s what you want.
  • ParAccel also offers a Flash option for PADB.
  • Like many other analytic DBMS vendors, ParAccel has created a custom networking protocol. (ParAccel has talked about that altogether too much in the past.)
  • Like Vertica, ParAccel’s PADB generally decompresses data as late as the particular compression scheme used allows. (Well, actually, that’s not one ParAccel mentions unless asked.)
  • ParAccel has long encouraged one to put part of one’s database on direct-attached storage as a kind of persistent cache, plus all of it on a storage-area network, because PADB can optimize its scans to go against both physical stores.
  • ParAccel’s PADB does encryption a block at a time, rather than a row at a time, so there’s very little overhead to using the encryption feature.
• ParAccel says that PADB has no indexes, materialized views, etc., notwithstanding that I heard something different from Barry Zane a few years ago. This is the basis for ParAccel’s claim that no tuning (or at least very little) is required, or indeed even possible …
• … and similarly, it is the reason ParAccel encourages prospects to do ad-hoc queries in their POCs (Proofs Of Concept), at least when Vertica is the competitor.
• However, ParAccel’s PADB has rather complex initial set-up. This has been the basis for widespread skepticism about ParAccel’s “no tuning” claim. ParAccel is working to automate that away, but admits to being only part-way through the process.
• Highlights of ParAccel’s data writing strategy include:
  • PADB sends data transactionally to disk.
  • PADB usually sends data to disk a block at a time, because it is coming in fast enough for that to work out (either due to bulk load or streaming).
  • PADB is append-only …
  • … so PADB has a garbage-collection mechanism called Vacuum. Right now Vacuum has to be started manually, but doesn’t block reads and writes; full background garbage collection is of course a roadmap feature.
  • As is natural for append-only systems, ParAccel’s PADB has MVCC (MultiVersion Concurrency Control) and snapshot isolation.
• Name a compression method, and PADB probably has it — 13 in all by ParAccel’s count, including dictionary/token, run-length encoding, Delta, LZ, and so on.

Tracking ParAccel’s customer success has long been difficult. The 2009 Gartner Magic Quadrant claim of ~20 ParAccel customers seems odd to everybody, including ParAccel. ParAccel’s own reporting of customer wins around then was quite confusing. And ParAccel’s customer count a year before that was extremely low. But ParAccel’s Michael Weir just rounded up some figures for me, namely:

• ParAccel has 30+ revenue-recognized customers, not counting OEMs, OEMs’ customers, or paid POCs.
• 2 ParAccel customers have > 100 TB of user data.
• 7 ParAccel customers have > 10 TB of user data.
• The largest ParAccel cluster is 28 nodes and growing.

Naturally, Michael went on to note that even relatively small databases can have high value.

One last note: ParAccel has approximately 78 employees.

• How quickly and cost-effectively does it execute SQL?
• What analytic functionality, SQL or otherwise, does it do a good job of executing?

And so, in undertaking such a selection, you need to start by addressing three issues:

• What does “speed” mean to you?
• What does “cost” mean to you?
• What analytic functionality do you need anyway?

Key elements of cost* include:

• Software license and maintenance
• Hardware purchase cost, maintenance, electric power, and computer room burden
• Database and system administration
• (For some uses cases) Programming

*Assuming a classical in-house IT shop, where products are typically bought rather than leased/rented. With outsourced and/or monthly-fee structures, the details change but the principles remain the same.

Most of that can be evaluated pretty well via a spreadsheet, although things can get a bit tricky when you get to people costs, which are a large fraction of the whole. In particular, different analytic DBMS product suites have great, high-performance support for different (and often rapidly growing) sets of functionality – basic and advanced SQL, statistics, and more. Figuring out which ones will be best for your programmers, and how significant the differences are — well, that’s a lot like any other programming language evaluation, and those are rarely neat or clean-cut.

But when it comes to evaluating speed, there’s no substitute for a well-designed proof of concept (POC). Many analytic DBMS and appliance vendors are happy to let you do a POC, on your own premises (or remotely if you prefer), under your control, at no cost to you. And that’s great. It is crucial that a POC be run either by you, by a consultant* answerable to you, or – if you decide the vendor must run it for you – at least with you watching every step of the way and knowing exactly what is being done. Appliance vendors do find it cheaper to run POCs on their own premises, so a certain reluctance to ship you a box is understandable. But make no compromises about the transparency of a POC, or about your control of exactly what it is that gets tested.

*Since I sell consulting services for users evaluating analytic DBMS, I naturally am biased to think that consultants can be very useful in the process. But whether you should use them a little (sanity check), a medium amount (work with you through the process), or heavily (actually drive the process for you and/or execute the POCs) is very dependent upon your specific situation.

So far as I’ve been able to tell:

• Netezza loves to ship boxes to prospects for POCs, and have them set up the boxes and do POCs themselves. That’s a big reason why Netezza wants to call attention to this subject.
• Oracle has generally been pretty reluctant to ship Exadata boxes out for POCs. That’s the other reason Netezza wants to call attention to the issue.
• Open source vendors make it easy for you to download and test at least their community editions.
• Vertica makes it pretty easy for you to test its software too (download or cloud).
• ParAccel has generally insisted on running POCs itself, although it will do so on your premises if you insist.
• Teradata naturally tries to do POCs on its own premises, but doesn’t insist too hard. (Edit: Randy Lea of Teradata says that Teradata is now doing over half its POCs onsite.)
  

Most of the criticisms I’ve heard of vendors’ POC practices have been directed at Oracle or ParAccel.

For most POCs, it’s a good conceptual template to form and then test a hypothesis to the effect of:

• For a given technology product assemblage (brand of DBMS, number of nodes, etc.), and
• For a given level of human effort (e.g., administrative effort), you can
• Run a given a workload, with
• Satisfactory and satisfactorily consistent response times

Sometimes absolute throughput and price/performance are important secondary considerations; sometimes they’re less germane. But either way, it’s almost always right to focus primarily on the questions of “What do I want this system to do?” and “What do I think we’re going to have to invest in it?” By way of contrast, it’s often misleading to focus too much on questions like “What’s the one number that best describes the performance of this system?” — even if you customize that calculation for your environment – or, even worse, “How much speed-up can I get on my single worst Query from Hell?”

The fundamental rule of POC construction is: Model your entire use case as best you can. That means you need to consider, at a minimum:

• Your whole concurrent query, other analytic, and low-latency update workload (peak).
• Your whole query, analytic, load, backup, and maintenance workload (ongoing).
• Partial-failure scenarios.
• Your core SLAs (Service-Level Agreements).

Of course, that’s not as easy as it sounds. Presumably, the main reason you’re getting a new analytic DBMS is that you want to do new kinds of analysis. By the very nature of analytics, you won’t know what analytic operations are most useful until you try them out and see what their results are. On the other hand – if you haven’t done considerable thinking about how you’re going to use your new analytic database, how did you ever get funding for the project in the first place?

Seriously, I could write multiple posts, each as long as this one (but more application-oriented), about how to upgrade your analytic capabilities (and which fool’s gold to avoid). But this has gotten pretty long already, so for now I’ll just stop here.

Note: My clients at Netezza asked me to write something short about POCs they could use as a kind of foreword to some collateral, where by “short” they meant single-paragraph or something like that. They’re great clients, so I said yes, under the condition I could also use it as a blog post. Except … this post didn’t turn out to be nearly as short as they envisioned. Oops.

Related links

• My February, 2009 slide deck on how to select an analytic DBMS is in many parts still pretty current

• VectorWise is indeed a shared-everything analytic DBMS.
• The VectorWise front-end is Ingres. Ingres VectorWise supports almost all SQL that Ingres does (there are a few edge-case exceptions).
• Conversely, Ingres VectorWise doesn’t support any SQL Ingres doesn’t, most notably SQL-99 Analytics. Naturally, SQL-99 Analytics is a roadmap item for Ingres/VectorWise.
• Ingres VectorWise 1.0 is pretty purely columnar. There’s a bit of PAX, but it’s mainly automagic/under the covers. The one user-controlled exception I understood was that one can ensure that composite keys are stored together.
• The main Ingres VectorWise performance secret sauce ingredients we touched on were:
  • Vectorization of operations (hence VectorWise’s name).
  • Compression that is tuned for speed rather than to minimize storage utilization.
• We unfortunately didn’t have time to revisit the other big part of the Ingres VectorWise performance story, namely clever design for modern microprocessor architectures. High-level generalities about that do pervade the Ingres VectorWise press release, but – well, they’re very high level.
• Unlike Vertica but like most other columnar DBMS vendors, Ingres VectorWise wants you to store your data once. You can index-organize the data. You can also organize multiple tables in the same order, to make joins among them fast.
• Support for actual join indexes is an Ingres VectorWise roadmap item.
• As do ever more analytic DBMS, Ingres VectorWise has something akin to Netezza zone maps.
• When I asked Peter what had changed most from the initial VectorWise development plan, other than the above, he basically said that their performance priorities had shifted a bit. Specifically, he said.
  • They had originally been “blinded” (his word) by the TPC-H benchmark, but figured out that they were overly focused on it. (Well, duh.)
  • They learned about the importance of other things such as data loading speeds.

]]> http://www.dbms2.com/2010/06/11/ingres-vectorwise-technical-highlights/feed/ 1 http://www.dbms2.com/2010/04/16/story-of-an-analytic-dbms-evaluation/ http://www.dbms2.com/2010/04/16/story-of-an-analytic-dbms-evaluation/#comments Sat, 17 Apr 2010 02:56:56 +0000 Curt Monash http://www.dbms2.com/?p=1900 One of our readers was kind enough to walk me through his analytic DBMS evaluation process. The story is:

• The X Company (XCo) has a <1 TB database.
• 100s of XCo’s customers log in at once to run reports. 50-200 concurrent queries is a good target number.
• XCo had been “suffering” with Oracle and wanted to upgrade.
• XCo didn’t have a lot of money to spend. Netezza pulled out of the sales cycle early due to budget (and this was recently enough that Netezza Skimmer could have been bid).
• Greenplum didn’t offer any references that approached the desired number of concurrent users.
• Ultimately the evaluation came down to Vertica and ParAccel.
• Vertica won.

Notes on the Vertica vs. ParAccel selection include:

• ParAccel sent an engineer on-site to do a proof-of-concept (POC), and generally competed very hard for the deal.
• Vertica dropped by for a sales call once, and let XCo do the Vertica POC itself.
• Not surprisingly, XCo got the impression that Vertica was easier to set up and administer than ParAccel.
• Also, when ParAccel emphasized architectural features such as custom “backplane” and compiled queries, XCo got the impression – right or wrong – that ParAccel’s performance was more brittle or situational than Vertica’s.
• ParAccel was modestly faster than Vertica in the POC. (I think — Vertica’s numbers were described as being “very competitive.”)
• In multiple ways, Vertica gave the impression of greater product and vendor maturity than ParAccel.

My contact continues to be interested in all things Greenplum, and has recommended Greenplum Single-Node Edition to his analyst colleagues.