ANTs Software is finally making some sense
ANTs Software is in essence a “public venture capital” outfit, with over $100 million in market capitalization and negligible revenue. It also features some interesting ideas in OLTP data management, a new management team (as of last year), and a new strategy. ANTs’ new strategy, in my opinion, stands a better chance of success than its predecessor, which in essence was to tell large enterprises “Throw out Oracle and use ANTs DB instead for your most mission-critical OLTP apps, because it’s faster, cheaper, and compatible.”
There actually are two prongs to ANTs’ new strategy. One of them, however, is a Big Secret that the company adamantly insists I not write about, notwithstanding that it is pretty much spelled out in this press release. The other is high-performance OLTP for specialized apps, in defense, telecom, financial trading, etc. The best way to summarize what “high-performance” means is this: When I asked what the technical sweet spot for ANTs DB, Engineering VP Rao Yendluri said “Half a million updates per second.” Read more
| Categories: ANTs Software, Memory-centric data management | 3 Comments |
Lessons from EnterpriseDB
I had a nice conversation yesterday with Jim Mlodgenski of EnterpriseDB, covering both generalities and EnterpriseDB-specific stuff. Many of the generalities were predictable, and none were terribly shocking. Even so, I am dressed as Captain Obvious, and shall repeat a few of the ones I found interesting below:
| Categories: EnterpriseDB and Postgres Plus, Mid-range, OLTP, Open source, Structured documents, Theory and architecture | 2 Comments |
What’s going on at Calpont?
It’s been quite a while since anything substantive-sounding emerged from Calpont. They now have an odd one-page web site, with essentially no substance other than a tagline suggesting they’re shipping product (not bloody likely) and the names, titles, and email addresses of the president and seven vice-presidents. Only two of those officers were listed on the May, 2006 version of the site. Does anybody have an idea what may or may not be going on?
(Quick refresher: Calpont was developing a SQL processing chip, and designing an appliance around it. Whether this appliance would have disks or be all in-memory changed from time to time, a flexibility that was made possible by the apparent fact that none of these boxes actually shipped.)
| Categories: Calpont, Data warehouse appliances, Data warehousing | 2 Comments |
HP Neoview — smoke or fire?
The consistently outstanding blog Serious About Consulting has a detailed article about HP Neoview. I must admit, however, to some skepticism about the Neoview project. Edit: As of September, 2008, that’s a dead link, and the blog has been replaced by spam junk. Part of this is just the fact that a data warehouse appliance outfit that’s never gotten around to briefing me — ever — clearly doesn’t have its marketing act together. 😉 Also, I’ve never heard much about them competitively from anybody except Greenplum.
That said — as Jerry Held reminded me in a recent Vertica-related call, there’s no cosmic architectural reason why they couldn’t make it work. And if anybody’s going to see HP first competitively, it’s going to be Sun/Greenplum and maybe Teradata, and I’ll confess to not having chatted with Teradata for approximately six months.
Oracle/Google/Apple merger – wow! Just — wow.
If rumors are to be believed, Oracle, Google, and Apple are close to agreeing on a mega-blockbuster three-way merger. Just the personality combinations are amazing, starting with close friends Jobs and Ellison — perhaps the two greatest entrepreneurs of Silicon Valley, and both with impeccable taste – and the traditionally sloppy, generation-younger Page and Brin. But let’s jump straight to some of the possible business and technology ramifications.
The Macintosh could become a serious Windows competitor. The Mac is quietly making an enterprise comeback anyway. Business intelligence, dashboards, and the like are constantly in the throes of UI re-invention. (I have some articles I the works about why the industry never seem to get them right, but in the mean time here is my UI overview article from last year.)
Whole new generations of personal/pervasive computing devices could evolve. Apple obviously is a huge personal-electronic-device player with the iPod and upcoming iPhone. Google has looked into cell phones as well. Designing cool devices will not be a problem. The issue is making them integrate really well with enterprise systems. I favor speech interfaces, myself.
Enterprise information management could be transformed. Oracle is batting about 0-for-the-decade in search. Google has is selling a lot of not-terribly-useful low-end enterprise search boxes. There’s room for both to do a lot better. Ex-Oracle executive Dennis Moore has some good ideas in that regard.
Related link
- Scoble has details on part of the story.
There’s one catch, however: On April 1, rumors generally should not be taken too seriously.
| Categories: Google, Oracle | 2 Comments |
White paper — Index-Light MPP Data Warehousing
Many of my thoughts on data warehouse DBMS and appliances have been collected in a white paper, sponsored by DATAllegro. As in a couple of other white papers — collected here — I coined a phrase to describe the core concept: Index-light. MPP row-oriented data warehouse DBMSs certainly have indices, which are occasionally even used. But the approaches to database design that are supported or make sense to use are simply different for DATAllegro, Netezza (the most extreme example of all) or Teradata than for Oracle or Microsoft. And the differences are all in the direction of less indexing.
Here’s an excerpt from the paper. Please pardon the formatting; it reads better in the actual .PDF Read more
| Categories: Data warehouse appliances, Data warehousing, DATAllegro, EMC, Theory and architecture | 4 Comments |
Oracle, Tangosol, objects, caching, and disruption
Oracle made a slick move in picking up Tangosol, a leader in object/data caching for all sorts of major OLTP apps. They do financial trading, telecom operations, big web sites (Fedex, Geico), and other good stuff. This is a reminder that the list of important memory-centric data handling technologies is getting fairly long, including:
- Object caching (e.g., Tangosol, Progress ObjectStore)
- In-memory RDBMS (e.g., Oracle TimesTen, Solid BoostEngine, McObject eXtremeDB)
- Stream processing (e.g., Progress Apama, Streambase)
And that’s just for OLTP; there’s a whole other set of memory-centric technologies for analytics as well.
When one connects the dots, I think three major points jump out:
- There’s a lot more to high-end OLTP than relational database management.
- Oracle is determined to be the leader in as many of those areas as possible.
- This all fits the market disruption narrative.
I write about Point #1 all the time. So this time around let me expand a little more on #2 and #3.
Read more
Will database compression change the hardware game?
I’ve recently made a lot of posts about database compression. 3X or more compression is rapidly becoming standard; 5X+ is coming soon as processor power increases; 10X or more is not unrealistic. True, this applies mainly to data warehouses, but that’s where the big database growth is happening. And new kinds of data — geospatial, telemetry, document, video, whatever — are highly compressible as well.
This trend suggests a few interesting possibilities for hardware, semiconductors, and storage.
- The growth in demand for storage might actually slow. That said, I frankly think it’s more likely that Parkinson’s Law of Data will continue to hold: Data expands to fill the space available. E.g., video and other media have near-infinite potential to consume storage; it’s just a question of resolution and fidelity.
- Solid-state (aka semiconductor or flash) persistent storage might become practical sooner than we think. If you really can fit a terabyte of data onto 100 gigs of flash, that’s a pretty affordable alternative. And by the way — if that happens, a lot of what I’ve been saying about random vs. sequential reads might be irrelevant.
- Similarly, memory-centric data management is more affordable when compression is aggressive. That’s a key point of schemes such as SAP’s or QlikTech’s. Who needs flash? Just put it in RAM, persisting it to disk just for backup.
- There’s a use for faster processors. Compression isn’t free. What you save on disk space and I/O you pay for at the CPU level. Those 5X+ compression levels do depend on faster processors, at least for the row store vendors.
| Categories: Data warehousing, Database compression, Memory-centric data management, QlikTech and QlikView, SAP AG | 6 Comments |
Mike Stonebraker on database compression — comments
In my opinion, the key part of Mike Stonebraker’s fascinating note on data compression was (emphasis mine):
The standard wisdom in most row stores is to use block compression. Hence, a storage block is compressed using a single technique (say Lempel-Ziv or dictionary). The technique chosen then compresses all the attributes in all the columns which occur on the block. In contrast, Vertica compresses a storage block that only contains one attribute. Hence, it can use a different compression scheme for each attribute. Obviously a compression scheme that is type-specific will beat an implementation that is “one size fits all”.
It is possible for a row store to use a type-specific compression scheme. However, if there are 50 attributes in a record, then it must remember the state for 50 type-specific implementations, and complexity increases significantly.
In addition, all row stores we are familiar with decompress each storage block on access, so that the query executor processes uncompressed tuples. In contrast, the Vertica executor processes compressed tuples. This results in better L2 cache locality, less main memory copying and generally much better performance.
Of course, any row store implementation can rewrite their executor to run on compressed data. However, this is a rewrite – and a lot of work.
| Categories: Columnar database management, Data warehousing, Database compression, Sybase, Vertica Systems | 8 Comments |
Mike Stonebraker explains column-store data compression
The following is by Mike Stonebraker, CTO of Vertica Systems, copyright 2007, as part of our ongoing discussion of data compression. My comments are in a separate post.
Row Store Compression versus Column Store Compression
I Introduction
There are three aspects of space requirements, which we discuss in this short note, namely:
structural space requirements
index space requirements
attribute space requirements.