• IBM is already serious about supporting multiple database management systems. DB2 on open systems is IBM’s flagship DBMS. But DB2 on mainframes and at least one flavor of Informix seem to be getting maintained and enhanced fairly seriously as well. And IBM has further DBMS products as well (e.g., DB/2 on the AS/400). There’s little reason to think IBM would orphan MySQL or any other DBMS product.
• IBM is very open-source-friendly. For a company that grew up for decades on proprietary software — and still is a huge software products vendor — IBM is very serious about open source. If you doubt that, I have two words for you: “Linux” and “Eclipse”.
• MySQL might finally get its industrial-strength act together. IBM is good at database management and good at open source. MySQL becoming a no-apologies transactional DBMS would obviously put pressure on Ingres, PostgreSQL, and EnterpriseDB, although there surely would be lots of happy talk about the open source DBMS market being validated, lifting all the vendors and so on. Also, a better MySQL could be bad news for Microsoft SQL Server too.
• Sun has a lot of DBMS partnerships right now. Obviously, Sun owns MySQL, and has partnerships with MySQL storage engine vendors such as Infobright and Kickfire. Sun also has a substantial partnership with Greenplum, and a Barneyesque* one with ParAccel. And of course Sun has strong working relationships with major database vendors such as Oracle and Sybase. What’s more, on a case-by-case basis, Sun may cooperate in the field with yet other DBMS sellers. E.g., I’ve confirmed at least one instance of a Sun sales rep recommending a Kognitio DBMS.
• IBM partners with outside DBMS vendors too. You’d think IBM’s gazillion DBMS product lines would be enough. But nooooo. I frequently hear rumblings of IBM’s hardware or services operations working with other DBMS products as well. (This is, of course, actually to their credit.)
• Short-term, there probably would be little effect on partnerships. Greenplum runs on Sun’s Thumper/Thor line of boxes. DB2 doesn’t, and certainly isn’t optimized for same. In the short term, to sell Thors, Sun would presumably continue to sell Greenplum.
• Longer-term, there could be a DBMS rationalization. DB2, Informix, MySQL + storage engines, and big independent vendors such as Oracle and Sybase would surely always get attention. That’s a lot. There might not be room for much mind share for many database products and vendors beyond that list.

*A Barney partnership is one in which two or more vendors get on stage and do a song and dance about how much they love each other, with little substance beyond that.

Related links

• Larry Dignan thinks the IBM/Sun deal is sensible and ripe to happen.
• Dana Gardner thinks otherwise.
• Matt Asay seems to agree that IBM understands the open source business.
• Before IBM acquired it, solidDB was scheduled to provide a serious MySQL transaction processing engine.

For that matter, the observation is no doubt true in many other product categories as well. But in the analytic database management arena, where there are literally 10-20+ competitors with different, non-stupid approaches, it seems most particularly valid. Here are some examples of what I mean.

Hash partitioning distribution. In shared-nothing or shared-not-very-much database architectures, multiple processors pull data off disk in parallel. Ideally, it will be the case that for each long-running query, the amount of data retrieved at each node is almost identical. That way, each node is done at the same time, with no wasteful waiting.

Consequently, data should be distributed more or less randomly across the nodes. That can be done through “round-robin” allocation — each node takes a turn in strict order receiving new records or blocks. Or it can be done by hashing on a particular key — in essence, by assigning data to different disks depending on the value in some particular field or combination of fields.

Hash partitioning distribution is a wonderful optimization. For most large tables, there’s a obvious join key that will be relevant to a significant fraction of all long-running queries. Pre-hashing on that key saves a huge step in the execution of hash joins involving that key, and hence can provide a significant reduction in the total query processing workload. Nor is this benefit confined to single-fact-table or single-primary-key schemas. When different kinds of data are stored in the same warehouse, each large fact table can be hash partitioned distributed on its own key.

For almost all databases on almost all shared-nothing vendors’ systems, hash partitioning distribution is the way to go. Even so, a couple of products don’t even bother supporting it. Oracle Exadata isn’t going to perform joins of that kind anyway until data is moved from the storage to the database tier, so hash partitioning distribution has no benefit in Exadata’s multi-tier architecture.  Kognitio, while not having such a clean proof of why hash partitioning distribution is utterly beside the point, thinks the costs of violating strict randomness outweigh the costs in its silicon-centric approach.

Indexing alternatives. More generally, analytic DBMS generally differ from OLTP DBMS in that they’re optimized to run more table scans and fewer updates and pinpoint queries. I’ve written about that many times, even coining the phrase index-light to encapsulate the story. The general idea is that if you’re retrieving a lot of rows per query, it becomes inefficient to keep spinning the disk to ensure you get only the rows you want. You get a lot more bytes/second doing sequential than random reads, so if a sufficiently large fraction of the rows are ones you actually want, it’s better to just scan them all.

If you’re going to follow an extreme form of that approach (e.g. Netezza, DATAllegro), you might as well have huge block sizes for your data (1megabyte+). If you think indexes of various kinds will actually be useful a reasonable fraction of the time, you might go with smaller sizes, such as 128K, which is what Teradata and HP (Neoview) favor.

Meanwhile, columnar vendor Vertica recreates some of the benefits of indexes by storing the same column in multiple sort orders. And that leads me to the next point.

High availability/failover alternatives. Most analytic DBMS mirror the data on-the-fly. But strategies differ. Some just rely on a storage vendor’s technology; others build in their own forms redundancy.

Particularly interesting is Vertica’s approach. Not only does Vertica allow multiple copies of the data to each be used for querying; it encourages the storage of the same columns in different sort orders, with the optimizer obviously choosing to query the copy that’s sorted in the way most useful for a specific query’s execution plan.

Redundancy and failover strategies are tightly tied to other administration issues too. For example, Aster Data and other vendors brag, with varying degrees of emphasis, that a new node can be added to a system, and the whole thing reconfigures itself automagically with zero down time. Similarly, different systems respond differently to node failure, in terms of metrics such as time to reestablish normal operation, performance hit (if any) after normal operation resumes, performance hit before normal operation resumes, and time window (if any) that redundancy is lost — so that a second failure would crash the whole system.

Bottom line: There never will be an analytic DBMS that simultaneously possesses all highly desirable architectural attributes for the product category.

Less successful to date are efforts in the area of pure database software-as-a-service.  It seems that if somebody is going for SaaS anyway, they usually want a more complete, integrated offering. The most noteworthy exceptions I can think of to this general rule are Kognitio and Vertica, and they only have a handful of database SaaS customers each. To wit:

1.  Kognitio has built a lot of its marketing around database SaaS, which it calls DaaS for data-as-a-service, and runs primarily from its own facility.  On a small sample size, it reports a very roughly 50-50 split in new business activity (that’s customers/prospects, not revenue) between DaaS and conventionally licensed software.

2.  Vertica has expressed high hopes for its Amazon cloud offering. Actual production usage has so far only matched part of that, but it isn’t exactly zero either. Specifically, marketing chief Dave Menninger writes by email:

In addition to approximately a dozen POCs running on the cloud at any point in time we have five customers using the cloud on a regular basis. Three of these customers do short lived projects so they start up instances, run them for the duration of a project, and shut them down. They are three different types of orgs: govt agency, pharma consulting org and SaaS provider.

Two financial services companies use the cloud as spare resource/capacity.  When they need additional computing resource or capacity they will temporarily move some projects onto the cloud with the anticipation of moving them back off once the capacity constraint is relieved (new hardware arrives, other projects or systems come to an end, etc.

3.  1010data offers its data warehousing product by remote service only.  However, unlike Gartner I’m not totally convinced 1010data should be regarded as comparable to DBMS vendors; perhaps it’s more like a SaaS business intelligence provider.

Edits:

• A comment below says Gerry Cohen wrote Nomad too.
  
• Kognitio commented on Twitter that they actually use DaaS to mean Data warehouse As A Service.

Like almost every other contender in the market,* Kognitio WX-2 queries disk-based data in the usual way. Even so, WX-2′s design is very RAM-centric. Data gets on and off disk in mind-numbingly simple ways – table scans only, round-robin partitioning only (as opposed to the more common hash), and no compression. However, once the data is in RAM, WX-2 gets to work, happily redistributing as seems optimal, with little concern about which node retrieved the data in the first place. (I must confess that I don’t yet understand why this strategy doesn’t create ridiculous network bottlenecks.) How serious is Kognitio about RAM? Well, they believe they’re in the process of selling a system that will include 40 terabytes of the stuff. Apparently, the total hardware cost will be in the $4 million range.

*Exasol is the big exception. They basically use disk as a source from which to instantiate in-memory databases.

Other technical highlights of the Kognitio WX-2 story include:

• WX-2 is designed for shared-nothing MPP. But like most other shared-nothing vendors, Kognitio often winds up supporting SAN-in-a-box disk arrays.
• WX-2 is fairly silicon-heavy. In a typical installation, 8-core nodes will each manage 140-300 gigabytes of disk. I get the impression WX-2 is more CPU- than disk-bound, which may be why Kognitio has little interest in disk-based data compression.
  
• WX-2 has complete equality among nodes; there is no head/queen. For example, any node can receive, optimize, or compile a query.
• WX-2 compiles queries into low-level code. Roger says this reduces code path length by a factor of 10.
• WX-2′s optimizer is aware of what data is in RAM. A WX-2 DBA can deliberately replicate part or all of the database to RAM, in a way that the optimizer is aware of. This is not an ordinary cache, although I forgot to ask whether there’s also an ordinary cache in addition.. Roger says that most WX-2 clients use this capability.
• Typical WX-2 installations have a little less than one data storage process per disk assigned to a node. Those disks that set aside a little space for the actual software get mirrored in their entirety, and the default is one process for that mirrored pair and one process for each other disk.
• Typical WX-2 installations have one query execution process per core.
• WX-2 has its own RAID-like scheme, rather than relying on RAID from storage providers.
• For those who care about such things, Kognitio claims WX-2 has linear scalability.

Non-technical highlights include:

• Kognitio is privately held. The investors at this point seem mainly to be two individuals, one of whom is Geoff Squire of Oracle fame.
• Kognitio has $16 million in revenue. Almost $10 million of that is in the WX-2 business.
• Kognitio names 14 customers for WX-2, all of whom are references.
• Long little more a UK national champion, Kognitio now has four WX-2 customers in the US market.
• Current business activity is about 50-50 license and SaaS (which Kognitio calls DaaS for Data As A Service).
• Installed WX-2 customers top out around 10 terabytes of user data. But a 50 terabyte deal has been sold, and a 100 terabyte deal looks really good in the pipeline.
• On the strength of two academic customers, genetic research is a bit of a focus vertical for Kognitio right now. Or, since Kognitio also has a university astronomy deal, we could say science is a focus market overall. (Their slides also mention oil & gas.)
• Most other WX-2 users fall into the usual verticals – telecom, analytic outsourcing, media/advertising analysis, retailing, etc.

]]> http://www.dbms2.com/2008/12/14/kognitio-and-wx-2-update/feed/ 2 http://www.dbms2.com/2008/11/07/big-scientific-databases-need-to-be-stored-somehow/ http://www.dbms2.com/2008/11/07/big-scientific-databases-need-to-be-stored-somehow/#comments Fri, 07 Nov 2008 18:36:21 +0000 Curt Monash http://www.dbms2.com/?p=619 A year ago, Mike Stonebraker observed that conventional DBMS don’t necessarily do a great job on scientific data, and further pointed out that different kinds of science might call for different data access methods. Even so, some of the largest databases around are scientific ones, and they have to be managed somehow. For example:

• Microsoft just put out an overwrought press release. The substance seems to be that Pan-STARRS — a Jim Gray legacy also discussed in an August, 2008 Computerworld article — is adding 1.4 terabytes of image data per night, and one not so new database adds 15 terabytes per year of some kind of computer simulation output used to analyze protein folding. Both run on SQL Server, of course.
• Kognitio has an astronomical database too, at Cambridge University, adding 1/2 a terabyte of data per night.
• Oracle is used for a McGill University proteonomics database called CellMapBase. A figure of 50 terabytes of “mass storage” is included, which doesn’t include tape backup and so on.
• The Large Hadron Collider, once it actually starts functioning, is projected to generate 15 petabytes of data annually, which will be initially stored on tape and then distributed to various computing centers around the world.
• Netezza is proud of its ability to serve images and the like quickly, although off the top of my head I’m not thinking of a major customer it has in that area. (But then, if you just sell software, your academic discount can approach 100%; but if like Netezza you have an actual cost of goods sold, that’s not as appealing an option.)

Long-term, I imagine that the most suitable DBMS for these purposes will be MPP systems with strong datatype extensibility — e.g., DB2, PostgreSQL-based Greenplum, PostgreSQL-based Aster nCluster, or maybe Oracle.

1.  Dave Shuttleworth of Edge Associates, a UK consultancy, told me that his firm had done a number of installations in the UK over the past 2 1/2 years.  He believes Kognitio has a few UK sales in that time period, and Teradata — at least that he’s aware of — have had no new UK customers in that time frame at all.   (This dovetails with other indications I’d had that Netezza is strong in the UK.)

2.  Giovanni Faccioll of ICare, an Italian Netezza partner, said that Netezza had gotten 4 customers in Italy in a relativity short period of time.  By way of contrast, he thinks Teradata only has 15 or so Italian customers, despite many years of trying.

Note:  I haven’t run either of these data points by Teradata, which surely has different information about those markets.

Netezza’s own list of international offices is here.  The Germanic operation is just getting set up; ditto South Korea and India (the latter is not even on that list yet).  The first whole-rack sale in Japan was just two quarters ago, with the first two-rack one coming last quarter.  There also are 5 Netezza systems installed in Slovenia, of all places, at a total of 2 or 3 customers.

• Sun partners with both Greenplum and ParAccel.

• HP sells Neoview, and also is partnered with Vertica.

• EMC (together with Dell in North America and Bull in Europe) sells DATAllegro. Now EMC is also entering a partnership with ParAccel.

• Teradata is pretty far down the road toward releasing a low-end product.

In addition, multiple hardware vendors have “reference architecture” technical arrangements with Oracle, to try to capture some of the benefits of appliances. And IBM is constantly in partnership discussions with data warehouse specialists, notwithstanding having multiple data warehouse offerings of its own.

Positioning of these various offerings is confused. Part of the reason is the large vendors’ postures “We’re big and trustworthy, and those little upstart vendors aren’t – until the moment we partner with one of them.” Part of the reason is the small vendors’ stances of “We can do all things for all people – and by the way, 9 of the 14 customers we’ve ever had are all doing pretty much the same thing.” And part of the reason is just an industry penchant for secrecy.

To a first approximation, I think there are two sensible ways to define the tiers. In each case, we’re talking about what kinds of databases the various products are suited for.

• Criterion S (for “Size”). “Bigger than Oracle can handle” vs. “Small enough that Oracle can handle it” (but that depends on what the definition of “handle” is).

• Criterion U (for “Usage”). “Full enterprise data warehouse” vs. “big honking data mart”.

But those are very different classification rules – many products that might be upper-tier by Criterion S are lower-tier by Criterion U, and vice-versa. For example:

• Teradata’s current products are at the upper end by either criterion. Even so, a significant fraction of older Teradata installations are below 5 terabytes or even 1 terabyte in size.

• More generally, Teradata emphasizes Criterion U. Hence any future low-end products will surely be positioned as lower-tier by that criterion. Beyond that, I wouldn’t be surprised if release is delayed, with the final version of those products being different than what previously leaked. E.g., they might well be designed to compete with newer vendors that are upper-tier by Criterion S.

• Netezza has clearly made it into the upper tier by the Size criterion. Most of its installations are lower-tier by Criterion U, but it trumpets a few exceptions that it describes as “enterprise data warehouses” in success stories.

• DATAllegro is upper tier by Criterion S — more so than any other vendor except Teradata, in that there are at least two credible stories of DATAllegro warehouses at or above the quarter-petabyte mark. Even so, DATAllegro is still mainly in the lower tier by Criterion U. I.e., the most natural use of DATAllegro technology is to build Very Big data marts.

• Vertica is a purely lower-tier Criterion U player, given its focus on single fact table schemas. But it’s well on its way into the upper tier by Criterion S.

• Dataupia straddles the boundary of the tiers by Criterion S. That is, it’s meant to offload existing Oracle, SQL Server, or DB2 databases, or in some OEM cases to be a cheaper alternative. That sounds lower-tier. On the other hand, it has one 120 terabyte reference, which puts it squarely in in the upper tier. By Criterion U it’s pretty lower-tier.

• ParAccel seems lower-tier by either criterion. And I’m too burned out on ParAccel’s secrecy to probe hard for exceptions.

• Oracle, MS SQL Server, et al. are – pretty much by definition – lower-tier by Criterion S, but upper-tier by Criterion U.

• HP Neoview is obviously meant to get to the higher end by both criteria. But like most specialty products, right now it’s further along by the Size criterion than the Usage one. Even so, it seems no further along by Criterion S than partner HP’s partner Vertica is.

• Greenplum has clearly gotten to the upper tier by the Size criterion. But like most of the competition, it still seems to be in the lower tier by Usage.

• Infobright is in the lower tier by either criterion. (They don’t even have an MPP offering yet.)

• Kognitio KX2 is in the lower tier by either criterion. However, Kognitio aspires to move up when measured by Usage.

• The last time I looked, Sybase IQ was lower tier by either criterion.

Related links:

• A quick survey of data warehouse management technology
• Data warehouse appliances — fact and fiction

Please subscribe to our feed!

I think that’s missing the point. Most OLTP databases are pretty small. Or, if they’re big, they get that way through a lot of transactions. In the first case, hosted management is cheap. In the second case, hosted management is taking care of a large burden for you.

Indeed, even data warehouse SaaS has a market, which should be a huge plausibility market for any other kind of database SaaS. Part of it exists for regulatory reasons — there’s a whole lot of CRM analysis using credit data that maybe shouldn’t be imported onto the analyzer’s premises. But Kognitio insists, apparently with a small amount of customer evidence backing it up, that there’s a general SaaS market for data warehousing as well.

• With one exception, Kognitio WX2 gets data on and off disk in the simplest possible way. Data goes on via round-robin partitioning. It comes off via table scans (with no indexes at all).
• The exception is that WX2 lets you put local bitmapped indexes on each disk, which Kognitio thinks are useful for cardinalities up into the 1000s. These indexes record which data values appear anywhere in a block, so the system knows which blocks it needs to scan. The benefit is similar to that of a Netezza zone map, but less, in that the Kognitio bitmap only works well for equalities and not ranges.
• The bitmaps are compressed. Otherwise, Kognitio uses no compression. They tried compression in the past and it didn’t go well.
• Where Kognitio gets fancy is in RAM. WX2 can have tables or views in memory that are kept synced up with disk. (Or even run purely in memory, an extreme transience that seems useful mainly for ELT.) These tables can be replicated, hashed, or whatever as makes sense.
• The biggest (measured by data) WX2 customer has bought a license for 9 ½ terabytes of user data. Kognitio expresses optimism about competing in the 10s of terabytes range, and thinks its technology actually scales up to the 100s of terabytes.
• Typical Kognitio WX2 configurations have a couple of hundred gigs of user data per CPU core. The biggest current system measured by nodes has 300 servers. (A past system had 900.) If you multiply that out it would seem there’s an extra zero, so I presume the servers in question are particularly small and well-aged.
• Kognitio stresses that WX2 runs on a broad variety of systems, just so long as the chips are x86 and the operating system is one of Kognitio’s preferred flavors of Linux. Blades, SMP nodes — WX2 doesn’t care. The nodes can even have heterogeneous hardware, although that’s sub-optimal since system performance is gated by the least powerful node. Kognitio seems to think that the cutoff for where bigger boxes are better than blades is probably in the 30-50 terabyte range, although as noted above that’s mainly a theoretical point right now.
• Kognitio also stresses a diversity of deployment models. WX2 runs on server farms in the cloud. You can install it on hardware of your choice. Or Kognitio will build a turnkey system for you, out of the brand of hardware of your choice.
• WX2 running over solid-state disks is likely not in the cards. Due to Kognitio’s lack of compression, this would be a very expensive solution.
• Kognitio is proud of its “plug-ins,” which amount to user-defined functions. There’s one on the price list for telecom call repricing that sounds a lot like what one member of the Netezza Developer Network is doing. There’s also a set of half a dozen for astronomical research, which I’m hoping somebody from Kognitio will describe in an email I can post.
• Kognitio’s sales have been focused in the UK. There’s one US customer, whose name I forget. John Thompson has been hired back into the company to expand US operations, but that seems to be waiting for a VC round to complete. Large hardware companies and systems integrators seem to play a big part in Kognitio’s distribution strategy.

Numerous data warehouse specialists offer traditional row-based relational DBMS architectures, but optimize them for analytic workloads. These include Teradata, Netezza, DATAllegro, Greenplum, Dataupia, and SAS. All of those except SAS are wholly or primarily vendors of MPP/shared-nothing data warehouse appliances. EDIT: See the comment thread for a correction re Kognitio.

Numerous data warehouse specialists offer column-based relational DBMS architectures. These include Sybase (with the Sybase IQ product, originally from Expressway), Vertica, ParAccel, Infobright, Kognitio (formerly White Cross), and Sand. Their products are generally available in software-only formats, although Vertica and ParAccel package their offerings as appliances too.

There are some array-based MOLAP (Multidimensional OnLine Analytical Processing) systems left. But the major ones are all now at Oracle, Microsoft, and IBM. Essbase wound up at Oracle, via the Hyperion acquisition. Express went to Oracle long ago, and got tightly integrated into the Oracle DBMS. Microsoft Analysis Services contains a MOLAP engine federated to Microsoft SQL Server. Applix‘s memory-centric TM1 went to Cognos, which had a couple of other MOLAP engines as well; Cognos is being bought by IBM.

There aren’t any star-schema specialists of note left. Most of them – actually just two, namely Red Brick and Stanford — merged into Informix a decade ago. Informix was later bought (in two stages) by IBM. Star schemas are now just a feature of general-purpose systems.

Of course, every general-purpose relational database management system can be used for a lot of analytic purposes. That’s the whole reason Codd introduced the relational model. What’s more, the leading SMP/shared-everything DBMS – Oracle, DB2 mainframe, and to a lesser extent Microsoft SQL Server – can be used even for very large databases, if you partition carefully and write your SQL code accordingly.

That’s 14 vendors already, without mentioning Calpont (hasn’t briefed me recently enough), HP (ditto, and partly working through Vertica), Sun (working through Greenplum and ParAccel), Attivio, the memory-centric engines of BI vendors such as QlikTech and SAP (not exactly database management), or the complex event/stream processing vendors such as Coral8, StreamBase, or Progress Apama (ditto). Methinks there’s some consolidation ahead.

Yet more links:

• Why Oracle and Microsoft are losing in VLDB data warehousing
• Three ways Oracle and Microsoft could catch up in MPP data warehousing
• IBM is oddly weak in the data warehouse market
• Some very big Teradata sites
• Extensive and overlapping coverage of Netezza, Vertica, database compression, and column-oriented database architectures.
• DATAllegro as an exemplar of non-proprietary index-light MPP data warehouse appliances
• An old article on Oracle’s integration of Express.