• Both on this blog and Reddit, there’s been considerable pushback against my idea that web usage types of user profile data shouldn’t be cluttering up an ACID-compliant database. But there’s also been considerable support, e.g. from Dan Weinreb, who knows quite a lot about huge OLTP systems.
• Meanwhile, RJP supplied details about the JP Morgan Chase Oracle outage that my actual source didn’t know.
• For obvious reasons, IBM wasn’t in a position to talk a lot of IBM/Netezza detail when we happened to chat post-merger-announcement. But they did want to set me straight on SAS being kicked out for SPSS, pointing out that SAS runs in the DB2 database today (scoring, not modeling).
• Product marketer Stephanie McReynolds added on to my post about Aster Data nCluster 4.6 in exactly the way I wish all vendors would. She added information I had been unsure about when I did the post — or had simply left out — and she was fast in doing so. I encourage all vendors I write about to follow her example.
• The comments on my post about Pentaho’s ETL-for-HDFS made the product sound more appealing than the post itself did.
• My August 18 NoSQL post was tailor-made for people to add-on pitches for their own favorite products, NoSQL-oriented websites, etc. A number of interesting such additions showed up accordingly.
• There were many thoughtful responses to my question about how somebody should teach themselves database programming skills. Indeed, whole other blog posts were written and linked back. That’s a great resource if you ever get the question asked by a friend or acquaintance of you.
• The flame war that erupted in response to my comments on vendor and analyst ethics spawned a number of more productive discussions elsewhere.
• Jeff Hammerbacher has made various comments to the effect “Yes indeedy! Hadoop does that too!” (My wording, not his. )
• Alin Dobra reported on some tests suggesting sequential reads remain far faster than random reads even on Flash SSDs.
• Calpont has an ever-slicker website and yet another new marketing VP, but no customers that are easy to detect.
• My July 4 privacy post engendered thoughtful discussion from three of the smartest guys who comment here — Chris Bird, Michael McIntire, and Dan Weinreb.
• IBM and Netezza both added crunchy details to my post about their data compression strategies.
• And for those of you who don’t read my other blogs — last night’s post was a long and optimistic rumination on the future of investigative reporting.

• Aster Data showed me a lot of customer names and deal sizes, across a bunch of industries (mainly enterprise rather than web). Yes, Aster’s market success is for real. (But almost all those details are NDA.)
• Sybase’s product plans for IQ are pretty impressive. (But the most interesting parts are, you guessed it, NDA.)
• I’ve kissed and made up* with ParAccel, now that they’ve replaced their CEO, replaced their marketing chief, and stopped the worst of the marketing nonsense I used to complain about. ParAccel has some interesting plans for ParAccel 3.0 which are, naturally, NDA.
• The Peoplesoft guys are doing it over again at Workday. Only this time, their platform isn’t a relational DBMS. Rather, it’s an in-memory, completely object-oriented data model, with disk used only on a “Just in case the power ever goes out” basis. (Thankfully, nothing at all about our conversation was NDA.)
• I’m finally feeling good about Northscale’s memcached-compatible persistent store Membase. The main reason is that they showed me a near-term path to interfaces that are richer than key-value. Also, Todd Hoff reassured me that even pure persistent memcached has a place.
• Rumor says that even the one app for which Facebook was using Cassandra — in-box search — has been decommissioned. On the other hand, numerous other scale-0ut DBMS (SQL or otherwise) seem to have Facebook footholds. But details are — all together now! — NDA.

*If you know ParAccel’s new marketing exec Michael Weir, you surely guessed I mean that only in a figurative sense.

From elsewhere:

• Daniel Abadi offered his analysis of Kickfire’s demise. In general I agree, but Daniel neglected to mention one hugely important factor — the chicken-egg negative effect of Kickfire’s lack of market or marketing traction. Customers were extremely reluctant to buy from Kickfire because they perceived, correctly, that Kickfire’s survivability was far from assured.
• While the InfiniDB forums suggest that there are at least a couple of production users of Calpont’s free InfiniDB, Calpont seemingly has a long way to go to be even as successful as Kickfire. But Calpont does have a bit of money to spend on lead generation; maybe some day they’ll even have actual customers.
• In a response to a question I messaged over, XtremeData tells me they have actual customers now. Press releases to follow.
• The admiration for the job Mark Hurd did at HP is in my opinion overstated. Sure, the financial/operational management appeared to work, but HP did little on Hurd’s watch to strengthen its reputation or customers’ loyalty. In particular:
  • HP’s analytics efforts have accomplished little.
  • HP’s data warehouse appliance efforts have failed pathetically.
  • From what I hear, HP’s execution in its Exadata partnership was not good.
  • HP’s server business in general is distinguished mainly by HP being a big company.
  • HP’s EDS acquisition has been rocky, not that EDS was sailing so smoothly on its own beforehand.
  • HP’s success in PCs amounts to “arguably, HP sucks a little less than the other guys”.
  • HP’s elite reputation is long gone (admittedly, for the most part that predates Hurd).
• Doug Henschen evidently favors really strong intellectual property protection for software, even forbidding plug-compatible reverse engineering. I agree with Doug up to the point that it should be forbidden to copy proprietary software, but I don’t see why he (or a court) would view such behavior as copying.

• Like Infobright, Calpont’s InfiniDB is a columnar DBMS consisting of a MySQL front end and a columnar storage engine.
• Community edition InfiniDB runs on a single server.
• One of commercial/enterprise edition InfiniDB’s main claims to fame will be MPP support.
• There’s no announced time frame for commercial edition InfiniDB.
• InfiniDB’s current compression story is dictionary/token only, with decompression occurring before joins are executed. Improvement is a roadmap item.
• Indeed, InfiniDB has many roadmap items, a few of which can be found here. Also, a great overview of InfiniDB’s current state and roadmap can be found in this MySQL Performance Blog thread. (And follow the links there to find performance discussions of other free analytic DBMS.)
• One thing InfiniDB already has that is still a roadmap item for Infobright is the ability to run a query across multiple cores at once.
• One thing free InfiniDB has that Infobright only offers in its Enterprise Edition is ACID-compliant Insert/Update/Delete. (Note: I wish people would stop saying that Infobright Enterprise Edition isn’t ACID-compliant, since that point was cleared up a while ago.)
• InfiniDB has no indexes or materialized views.
• However, InfiniDB’s retrieval is expedited by something called “Extents,” which sounds a lot like Netezza’s zone maps.

Being on vacation, I’ll stop there for now. (If it weren’t for Tropical Storm/ depression Ida, I might not even be posting this much until I get back.)

In order for me to get excited about Kickfire, I have to ignore Mike Stonebraker’s voice in my head telling me that DBMS hardware companies have been launched many times in the past are ALWAYS fail (the main reasoning is that Moore’s law allows for commodity hardware to catch up in performance, eventually making the proprietary hardware overpriced and irrelevant). But given that Moore’s law is transforming into increased parallelism rather than increased raw speed, maybe hardware DBMS companies can succeed now where they have failed in the past

Good point.

More generally, Abadi speculates about the market for MySQL-compatible data warehousing.  My responses include:

• OF COURSE there are many MySQL users who need to move to a serious analytic DBMS.
• What’s less clear is whether there’s any big advantage to those users in remaining MySQL-compatible when they do move.  I’m not sure what MySQL-specific syntax or optimizations they’d have that would be difficult to port to a non-MySQL system.
• It’s nice to see Abadi speaking well of Infobright and its technology.
• To say that Infobright went open source because it was “desperate” is overstated. That said, I don’t think Infobright was on track to prosper without going open source.
• While open source and MySQL go together, an appliance like Kickfire loses many (not all) of the benefits of open source.
• Calpont has indeed never disclosed a customer win.  Any year now … (Just kidding, Vogel!)
• In general, seeing Abadi be so favorable toward Vertica competitors adds credibiity to the recent Hadoop vs. DBMS paper.

Anyhow, as previously noted, I’m a big Daniel Abadi fan. I look forward to seeing what else he posts in his blog, and am optimistic he’ll live up to or exceed its stated goals.

• MySQL with MyISAM is fast. But it’s not transactional. Except for limited purposes, MySQL with MyISAM is a pretty crummy DBMS.  Nothing can change that.
• MySQL with InnoDB is transactional. But it’s not particularly fast. MySQL with InnoDB is a pretty mediocre DBMS.  Oracle could fix that, at least partially, over time.
• I don’t know much about Falcon, Maria, and so on. With Oracle winding up owning both MySQL and InnoDB, the motivation for those engines (except as Oracle-free forks) might fade.
• Infobright is the most established of the rest. At the moment I’m not recommending it for most industrial-strength uses unless the user is particularly cash-constrained. But I wouldn’t be surprised if that changed soon.  A cheap, fast, simple columnar analytic DBMS has a place in the world.
• Kickfire is next in line, offering a hardware-based growth path for users who’ve maxed out on what unaided MySQL can do.  It remains to be seen for how many users the desire to keep things simple and stay with MySQL outweighs the desire to avoid custom hardware.  Having Oracle salespeople all over those accounts surely wouldn’t help. Kickfire also has a second market, namely OEM vendors who are mainly interested in the superfast chip. That would probably be pretty unaffected by Oracle.
• Tokutek offers a technical proposition that’s hard to match head-on without going the CEP route.  Users who care are likely to be MySQL shops.  Tokutek’s main challenge is to prove that it sufficiently outdoes competing technical strategies for sufficiently many users. Oracle ownership of MySQL seems pretty irrelevant to Tokutek’s success or failure.
• Calpont offers a kind of lightweight Exadata alternative.  With Calpont’s packaging and positioning perennially unclear, it’s difficult to predict the effect of a particular change — i.e., Oracle buying MySQL — in Calpont’s market environment.
• I haven’t heard from transactionally-oriented ScaleDB since I wrote about them a year ago.  Apparently, they’re rolling out beta product this week, and their venerable techie guru sadly passed away earlier this month.

Minor highlights of the Calpont technical story include:

• Calpont plans to offer a MySQL storage engine for analytic database processing. Thus, Calpont will compete with Infobright, Kickfire, and perhaps Tokutek.
• Like Infobright and Kickfire, Calpont is building a columnar engine.
• Calpont plans for there to be both shared-everything and shared-nothing versions of its product. The shared-everything version may be ready sooner. At least some form of scale-out should be available from the get-go.
• Despite being columnar, Calpont hasn’t implemented compression yet. Naturally, fixing that is a high priority.
• Like Infobright, Calpont is starting out by only processing some SQL statements itself, leaving the rest to the native MySQL engine. Also like Infobright, Calpont plans before long to process most or all SQL itself.
• Calpont’s software takes execution plans generated by MySQL and executes them — well, differently than MySQL would have. This required “small” modifications to MySQL’s open source code. Development chief John Weber conjectures that Kickfire and Infobright made similar modifications for similar reasons.
• I forgot to ask if/when Calpont will have ACID compliance.
• Calpont plans to support both 1-gig and 10-gig Ethernet for its networking.
• Calpont is working on a UDF (User-Defined Function) framework, with the first language being C++.

So far, that’s all pretty standard stuff. What’s most unique about Calpont’s design is its multi-tier architecture. Like Oracle Exadata, Calpont has both a server tier (the Director and User modules) and a storage tier (the Performance modules — yes, I think those names are all atrocious). Compared to Exadata, however, Calpont does relatively more of the total work on the storage tier and less on the server level. Specifically:

• The Director modules are MySQL instances. The User and Performance modules are Calpont code.
• The User modules receive intermediate result sets from the Performance modules and redistribute them as needed. User modules also feed final results up to the Director module to be sent back to the application that requested them.
• Performance modules read and write data, perform joins and aggregations, and so on.
• Modules can be distributed among physical nodes as you wish. You don’t actually have to have dedicated nodes for each kind of module.
• Calpont’s scalability has been tested up to 8 nodes running Performance modules (64 cores), and the results were highly linear.

]]> http://www.dbms2.com/2009/04/20/calpont-update-you-read-it-here-first/feed/ 0 http://www.dbms2.com/2008/09/06/sans-vs-das-in-mpp-data-warehousing/ http://www.dbms2.com/2008/09/06/sans-vs-das-in-mpp-data-warehousing/#comments Sat, 06 Sep 2008 05:45:33 +0000 Curt Monash http://www.dbms2.com/?p=524 Generally speaking:

• SANs (Storage Area Networks) are pulling ahead of DAS (Direct Attached Storage).
• Much of the growth in storage is due to data warehousing.
• MPP (Massively Parallel Processing) is pulling ahead of SMP (Symmetric MultiProcessing) for high-end data warehousing.
• MPP architectures are commonly shared-nothing.
• Shared-nothing entails DAS.

But if you think about it, those facts don’t exactly add up.

The freshest take I have on the subject right comes from Vertica, with whom I met on Wednesday. It turns out that while Vertica initially thought DAS would be the only viable way to go, quite a few Vertica customers actually run SANs. A big Vertica installation these days is 10 nodes and 10-20 TB of user data, while a small one might be 1/10 that size. Within that range, SANs do just fine, as long as they have sufficient bandwidth, which commonly equates to 4 gigabit HBAs (Host Bus Adapters). One point Vertica noted is that SANs commonly have lots of cache and 15K RPM disks, which sounds higher-end than the storage hardware I usually hear about in DAS configurations.

Also interesting is CEO Jeff Vogel’s view over at Calpont. Jeff’s roots are in storage, and in response to my recent blog post mentioning storage issues he sent over a note I got permission to publish here. It says:

The storage blog underscores the increasing importance of efficient storage capacity and the impact that mixed workloads have on DW performance. It’s also front and center on the single biggest issue facing the growth prospects of the DW industry – Concurrency/User scalability. Storage efficiency and mixed workload variation have implications to cost . The single biggest cost issue in the data center is storage. It’s also a huge management cost issue. Energy consumption has only made the issue worse. Notwithstanding the issues associated with data access and availability, the proliferation of DW storage throughout the enterprise will bring business users and storage administrators together around a common storage services strategy. What emerges is a DW infrastructure strategy that incorporates storage management disciplines that have existed for years as part of a larger effort centered on Information Lifecycle Management (ILM) principles. The true benefits of ILM were only possible after companies went through the painful process of consolidating and centralizing their storage. Consolidation was made possible with the advent of the storage area network (SAN). There’s a reason why an overwhelming majority of all raw storage shipped into the enterprise is connected to a SAN.

From my perspective, the storage blog raises some important lessons for DW vendors and offers some interesting parallels. SANs made it possible for Unix and midrange OS servers to become part of the consolidated storage effort. As a result, we saw spectacular growth in applications attached to those servers. As a consequence, DAS retreated and is less than 20% of the market for warehouse and analytics. According to IDC over 50% of warehouse and analytics application storage in 2007 was midrange and is expected to top 60% within 5 years. The ‘Servers’ parallel here is Users. For DW applications to take off in a material way, we’ll need to solve the User scalability issues associated with cost, access and workload flexibility. Back to the “storage” future.

While the new DWA players have done a good job of addressing DBMS performance, scalability and costs, they don’t go far enough. Asset utilization, infrastructure flexibility and storage policies that govern data are fundamental concerns that DBMS players will need to contemplate at the architecture level. For example, while compression should be part of any solution, it’s only one storage cost dimension of a multi-faceted puzzle to asset utilization and, conversely, doesn’t fully address the broader issues mentioned in the blog. Up to now, these issues haven’t slowed DW sales, but you can hear the train in the distance.

We’re down a path on a crucial subject and we’ll be hearing a lot more from the storage players as to how the benefits of storage management will play out with DBMS solutions. As an industry, we’ll need to move beyond quid-pro-quo reference architectures and begin to think about how database behavior can help storage vendors lower costs, increase asset utilization, improve flexibility and in return, bring more Users into the game. A rising tide lifts all boats.

The base-case MPP DBMS architecture is one in which there are two kinds of nodes:

• A boss node, whose jobs include:
  • Receiving and parsing queries
  • Optimizing queries, determining execution plans, and sending execution plans to the nodes
  • Receiving result sets and sending them back to the querier
• Worker nodes, which do their part of the query execution job and eventually ship data back to the head

In primitive forms of this architecture, there’s a “fat head” that does altogether too much aggregation and query resolution. In more mature versions, data is shipped intelligently from worker nodes to their peers, reducing or eliminating “fat head” bottlenecks.

Exceptions to the base case include Vertica and Exasol. In their systems, all nodes run identical software. At the other extreme, some vendors use dedicated nodes for particular purposes. For example, Aster Data famously has special nodes for bulk data loading and export. Greenplum has a logical split between nodes that execute queries and nodes that talk to storage, and is considering offering the option of physically separating them in a future release.

The basic tradeoffs between these schemes go something like this:

• If there are more kinds of dedicated nodes, real-time load-balancing is harder; you’re more likely to have idle capacity.
• If there are more kinds of dedicated nodes, you can optimize hardware better, by using different kinds of hardware for different kinds of nodes. Potentially, this is a bigger factor if some kinds of nodes have dedicated disks attached and some don’t.

Calpont, which hasn’t actually shipped a DBMS yet, has an interesting twist. They’re building a columnar DBMS in which the querying work is split between a kind of worker node, which does the query processing, and a storage node, which talks to disk. These nodes are not in any kind of one-to-one correspondence; any worker node can talk with any storage node. Calpont believes that in the future some of the storage node logic can migrate into storage systems themselves, in almost a Netezza-like strategy, but on more standard equipment.

The Calpont story may actually make more sense in a shared-disk storage-area-network implementation than for a fully shared-nothing MPP, but that’s a subject for a different post.

• Aster Data
• Calpont
• DATAllegro
• Greenplum
• Infobright
• Netezza
• ParAccel
• Teradata
• Vertica

All of those are Monash Advantage members.

If you care about all this, you may also be interested in the rest of my standards and disclosures.

Philip Howard’s recent article has a lot more meat than that, including the perplexing bit of info that Calpont is starting out with a shared-everything architecture. Based on that, as well as the company’s prior technical efforts, we can probably conclude they’re focused on rather small warehouses.