• Despite heavy emphasis on the word “sharding,” dbShards’s scale-out is transparent to the application programmer. E.g., in dbShards + MySQL, the APIs are more or less the same ones you’d expect for MySQL (JDBC, etc.)
• If the DBMS underneath is ACID-compliant (e.g., MySQL + InnoDB), then the dbShards version is ACID-compliant too.
• Beyond those basics, I forgot to check the fine details of dbShards’ MySQL (or PostgreSQL) syntax support. Todd Hoff, however, did not forget.
• dbShards keeps copies of each shard on two different servers, via asynchronous log-shipping. This allows for failover in both planned and unplanned outages.
• dbShards wants you to distribute big tables among shards via a “shard key,” which is a lot like the distribution key in MPP analytic DBMS. You’re encouraged to replicate small, low-update-volume tables across each shard.
• Cory says that dbShards has good join performance when – you guessed it! – everything being joined is co-located shard-by-shard, because the tables were distributed on the same shard key and/or replicated across each shard. Cory can’t imagine why you’d want to do an inner join under any other circumstances.
• The basic dbShards query execution model is: A query comes in; it’s parsed; a shard key is automagically detected (one hopes); the “global configuration file” is checked to see which shard to ship the work off too. I forgot to ask whether lookup was done via a hash table (the obvious guess) or something else. The programmer can put hints in the code comments to direct the sharding, but Cory asserts those aren’t needed very often.
• Cory says that insert performance with dbShards + MySQL + InnoDB is 1500-3000 inserts per shard per second, scaling almost linearly with the number of shards. I forgot to ask how many shards this had been tested for.
• If you want blazing dbShards performance, Cory’s base-case figure is 25 gigabytes of data per node, so that the most commonly used indexes can camp out in memory. (I forgot to ask what kind of hardware he was assuming per node.) This is if you’re going to be doing joins or aggregrations. If it’s just single-row inserts and updates, or if your performance requirements are lower, you can go with 10X that figure.
• Cory tells stories wherein going from an unsharded database to 4 or so shards took database re-indexing time down 50X or more. Apparently, such tasks can be exponential or even super-exponential with database size over InnoDB. (That said, I’d be surprised if all large InnoDB users suffered from that problem to the same degree.)
• dbShards’ customer workloads are all >= 50% reads. This is reflective of dbShards’ design priorities.
• As long as it can be in charge, dbShards is happy to interface to whatever kind of database backup software you want to use on a node by node basis. (dbShards wants to drive your backup software for you so that it can be sure the replicas are handled properly.)
• It’s “fairly common” for dbShards to be paired with memcached. I forgot to ask whether memcached typically lived on its own pool of servers, or on the same pool that runs dbShards.
• Future DBMS options under consideration for dbShards include Oracle and (unspecified) in-memory.

Business highlights for CodeFutures and dbShards include:

• dbShards’ price is $5000/server/year, including support and OEMed MySQL, with stated quantity discounts up to 40%.
• dbShards cloud pricing is different (on a usage basis).
• dbShards has 6 or so customers, half each on-premises and in the cloud. One of them is Facebook. (Those “100s” of customers mentioned on the dbShards website are for a fairly unrelated product.)
• CodeFutures has been at this 2 ½ years or so. There is no venture capital in the company.
• Early deals dbShards deals have evidently involved a fair amount of professional services.
• Counting contractors, Code Futures has 10-12 people, which has been as high as 15.
• Target dbShards customers are as you’d expect. Cory says he’s actually been more successful getting early-adopted money out of Web companies than Wall Street firms.
• There are a couple of dbShards PostgreSQL customers for greenfield applications. Most dbShards customers and prospects, however, are looking to scale out existing apps.
• Despite its connection to open source DBMS, there’s nothing open source about dbShards itself.

Analytic technology isn’t only for you. It’s also for your customers, citizens, and other stakeholders.

I am not referring here to what is well understood to be an important, fast-growing activity — providing data and its analysis to customers as your primary or only business — nor to the related business of taking people’s data, crunching it for them, and giving them results. That combined sector — which I am pretty alone in aggregating into one and calling data mart outsourcing — is one of the top several vertical markets for a lot of the analytic DBMS vendors I write about. Rather, I’m talking about enterprises that gather data for some primary purpose, and have discovered that a good secondary use of the data is to reflect it back to stakeholders, often the same ones who provided or created it in the first place.

For now I’ll call this category stakeholder-facing analytics, as the shorter phrase “stakeholder analytics” would be ambiguous.* I first picked up the idea early this decade from Information Builders, for whom it had become something of a specialty. I’ve been asking analytics vendors for examples of stakeholder-facing analytics ever since, and a number have been able to comply. But the whole thing is in its early days even so; almost any sufficiently large enterprise should be more active in stakeholder-facing analytics than it currently is.

*Comments as to what the category should be called are welcome below.

Examples of stakeholder-facing analytics include:

• Enterprises report back on the business customers do with them. For example:
  • Credit card companies provide reports on spending back to their credit card holders, especially small businesses.
  • So do office supply retailers.
  • Brokerage firms provide reporting back to their small-institution customers.
• Governments expose information to their citizens online.
  • In an early example, New York City restaurant ratings were put online.
  • Putting SEC filings online has has been a huge success.
  • The Obama Administration has committed to putting large amounts of information online.
• Regulated companies (such as utilities) could be required to put data online directly, without even using the government as an intermediary.
• Some part of Fox — perhaps MySpace Music? — offers free access to a PostgreSQL extract from its Greenplum database to each of its largest advertisers.
• Google Analytics offers some basic BI for free to website owners everywhere.
• Anybody from web hosting companies to public utilities could open their kimonos and allow their customers to track adherence to actual or implied SLAs (Service Level Agreements) in areas such as uptime, length of outage, responsiveness, and the like.

So what cool examples do you have of stakeholder-facing analytics?*

*Yes, this is an invitation to drop links to case studies into the comment thread below.

Nonetheless, OLTP/general-purpose data management startup activity has recently picked up, targeting what I see as some very real opportunities and needs. So as a jumping-off point for further writing, I thought it might be interesting to collect a few observations about the market in one place.  These include:

• Big-brand OLTP/general-purpose DBMS have more “stickiness” than analytic DBMS.
• By number, most of an enterprise’s OLTP/general-purpose databases are low-volume and low-value.
• Most interesting new OLTP/general-purpose data management products are either MySQL-based or NoSQL.
• It’s not yet clear whether MySQL will prevail over MySQL forks, or vice-versa, or whether they will co-exist.
• The era of silicon-centric relational DBMS is coming.
• The emphasis on scale-out and reducing the cost of joins spans the NoSQL and SQL-based worlds.
• Users’ instance on “free” could be a major problem for OLTP DBMS innovation.

I shall explain.

Big-brand OLTP/general-purpose DBMS have more “stickiness” than analytic DBMS.

• OLTP applications are more complex than analytic ones, and hence more tightly wired into particular brands of DBMS. For example, third-party packaged OLTP applications are typically portable among only a few brands of DBMS. But third-party business intelligence tools, and the BI “applications” built in them, are more easily and widely portable.
• Specific technical observations such as “OLTP apps tend to use stored procedures, which are DBMS-specific” or “OLTP apps tend to have lots and lots of tables” serve to underscore the first point.
• An enterprise’s highest-value data is commonly the financial stuff handled by its core OLTP systems, so those are the last things they want to mess around with just to get some cost savings. Security, high availability, and so on are major considerations that can outweigh cost.

By number, most of an enterprise’s OLTP/general-purpose databases are low-volume and low-value. Indeed, “OLTP” is often a misnomer, which is why I tend to go with “general-purpose” or some similarly wishy-washy phrase instead.

• In theory, this is a ripe area for what I’ve called mid-range DBMS.
• The big brand vendors try hard to keep as many of those databases for themselves as they can. Enterprise-wide license pricing helps. Going forward, so will virtualization/consolidation strategies, such as Oracle’s Exadata-centric approach.
• A variety of mid-range DBMS alternatives beyond the big brands have technical merit, at least in some cases and configurations – MySQL, PostgreSQL, Intersystems Cache’, and so on.
• The only such mid-range DBMS alternative with much large enterprise business momentum, however, appears to be MySQL.

“General-purpose” might be a better term than “OLTP” anyway.

• I don’t have a link, but it’s widely agreed that over half of the processing on an “OLTP” enterprise app is commonly reporting and so on.
• “Operational BI” is progressing by fits and starts, but it is progressing.
• Anything customer-facing — web-based, call center, or otherwise — is likely to include a heavy dose of “real-time” analytic optimization.

Most interesting new OLTP/general-purpose data management products are either MySQL-based or NoSQL.

• VoltDB is the main exception that jumps to mind.
• This isn’t true in the analytic DBMS area, where Netezza, Greenplum, Aster, Vertica and others started from PostgreSQL’s code, APIs, or both.

It’s not yet clear whether MySQL will prevail over MySQL forks, or vice-versa, or whether they will co-exist.

• MySQL is a limited product without all the third-party storage engines that are being developed.
• Oracle’s promise of MySQL good behavior has an expiration date.
• None of the MySQL front-end alternatives are remotely mature yet.

The era of silicon-centric relational DBMS is coming.

• I think “silicon” means “solid-state memory” as much as or more than it means “RAM,” but that’s not yet certain.
• What is pretty certain is that, thanks to Moore’s Law, some kind of silicon will increasingly replace disk.
• Oracle’s increasingly Flash-centric story is a challenge to everybody.
• RAM-centric VoltDB will launch fairly soon. (By the way, while VoltDB still has a lot in common with H-Store, they’re not exactly the same thing. And H-Store research is progressing too.)
• RethinkDB is being developed, focused directly on solid-state memory. Based on the sparse information available online, RethinkDB sounds somewhat like a dumbed-down H-Store.
• New disk-based vendors may never optimize their use of disk, instead targeting a solid-state future. (E.g., I think Akiban should and quite well might follow this path.)

The emphasis on scale-out and reducing the cost of joins spans the NoSQL and SQL-based worlds. We hear that from the NoSQL guys all the time. But I also just heard it from Akiban.

Users’ instance on “free” could be a major problem for OLTP DBMS innovation. Vendors of new OLTP data management technologies often feel obligated to open source their products, notwithstanding the historical lack of revenue in the open source OLTP DBMS market. As just one of many examples, Nova Spivack wrote:

I have recently seen some new graph data storage products that may provide the levels of scale and performance needed, but pricing has not been determined yet. In short, storage and retrieval of semantic graph datasets is a big unsolved challenge that is holding back the entire industry. We need federated database systems that can handle hundreds of billions to trillions of triples under high load conditions, in the cloud, on commodity hardware and open source software. Only then will it be affordable to make semantic applications and services at Web-scale.

I hear similar things from other startups, who evidently believe they need and/or are entitled to enjoy sophisticated, high-performance, zero-cost, specialized database management technology.

Greenplum Single-Node Edition:

• Is free of charge, although you can buy support.
• Has no restrictions on use, production or otherwise.
• Has no restrictions on database size.
• Is closed-source.

For those who want free, terabyte-scale data warehousing software, Greenplum Single-Node Edition may be quite appealing, considering that the main available alternatives are:

• General-purpose open-source DBMS, such as PostgreSQL and MySQL (lacking analytic DBMS performance and features)
• Infobright Community Edition (the other best choice – Infobright’s commercial sales success indicates the solidity of Infobright’s technology)
• Rough research-project code and other other questionable open source offerings
• Crippleware from other commercial analytic DBMS vendors (e.g., Teradata)

For example, comparing PostgreSQL-based Greenplum with PostgreSQL itself, Greenplum offers:

• The ability to scale out queries across all cores in your box (and no, pgpool is not a serious alternative)
• Storage alternatives such as columnar (I am told that EnterpriseDB recently stopped funding a project for a PostgreSQL columnar option)

Greenplum would surely also argue that its software is superior to PostgreSQL in parallel load, compression, MapReduce integration, and general fit-and-finish. I imagine that in some (perhaps not all) cases it would be right. PostgreSQL’s main technical advantages over Greenplum would probably lie in the area of datatype extensibility.

The main target users for Greenplum’s Single-Node Edition are obviously individual enterprise power users or very small analytic teams. I.e., it’s people with a data mart need that a central data warehouse isn’t meeting. Potential benefits to Greenplum include:

• Adding value to its Enterprise Data Cloud story
• Seeding the market for future enterprise sales
• Depriving competitors of revenue, perhaps at enterprises too small to ever be paying Greenplum customers

In addition, I see free Greenplum as a charity offering that could be appealing to scientists who face PostgreSQL performance limitations.

Related links

• Greenplum Free Single-Node Edition press release (I’m quoted)
• MySQL Performance blog on MonetDB and Infobright community edition
• PostgreSQL’s restriction to one core per query
• Infobright’s restriction to one core per query

The basic idea of HadoopDB is to put copies of a DBMS at different nodes of a grid, and use Hadoop to parcel work among them. Major benefits when compared with massively parallel DBMS are said to be:

• Open/cheap/free
• Query fault-tolerance
• The related concept of tolerating node degradation that isn’t an outright node failure.

HadoopDB has actually been built with PostgreSQL. That version achieved performance well below that of a commercial DBMS “DBX”, where X=2. Column-store guru Abadi has repeatedly signaled his intention to try out HadoopDB with VectorWise at the nodes instead. (Recall that VectorWise is shared-everything.) It will be interesting to see how that configuration performs.

The real opportunity for HadoopDB, however, in my opinion may lie elsewhere. Rather than trying to compete with parallel relational DBMS, HadoopDB might do more good parallelizing more specialized kinds of database engines. How about, for example, a massively parallel XML manager to compete with MarkLogic? Or a massively parallel array processor other than the still-nascent SciDB? Or, even more to the point, something that parallelizes a yet-more-specialized scientific data management engine? That kind of area is where I suspect the potential for HadoopDB really lives.

]]> http://www.dbms2.com/2009/09/13/hadoopdb/feed/ 4 http://www.dbms2.com/2009/09/10/what-could-or-should-make-oraclemysql-antitrust-concerns-go-away/ http://www.dbms2.com/2009/09/10/what-could-or-should-make-oraclemysql-antitrust-concerns-go-away/#comments Thu, 10 Sep 2009 14:53:23 +0000 Curt Monash http://www.dbms2.com/?p=879 When the Oracle/MySQL deal was first announced, I wrote:

I can probably come up with business practices that could make things very hard on Oracle/MySQL competitors … but I haven’t found a compelling antitrust trigger on my first pass over the subject.

Subsequently, there’s been a lot of discussion about whether or not Oracle can use control of MySQL to make life difficult for third-party MySQL storage engine vendors.

Now that the European Commission is delaying the Oracle/Sun deal, explicitly because of Oracle/MySQL antitrust fears.  That is, the European Commission wants to be reassured that an Oracle takeover of MySQL won’t unduly impinge upon the future availability of open source/low cost DBMS alternatives.  This raises that natural question:

What could Oracle do to assure concerned parties that its ownership of MySQL won’t unduly hamper open-source-based DBMS competition?

I think that’s indeed the crucial question. The Oracle/Sun deal has enough momentum at this point that it both should and will be allowed to happen — perhaps with safeguards — rather than banned outright. If  you have concerns about Oracle’s pending acquisition of MySQL, you should speak up and outline what kinds of regulatory safeguards would alleviate the problems you foresee.

More or less obvious possibilities include:

• Divest MySQL. This is obviously an extreme measure, but it surely would work.
• Provide some money and trademark rights to MySQL forkers. If MariaDB and Drizzle were put into strong competitive positions with MySQL today, it’s hard to argue how regulators could object to any future Oracle maneuverings Oracle might envision with the GPLed side of MySQL.
• Offer a standard, attractive, long-term deal to MySQL bundlers. The commercial/non-GPL version of MySQL is a requirement for appliance vendors (surely), OEM vendors (probably), and storage engine vendors (maybe — I disagree, but I’m evidently in the minority).
• Strengthen PostgreSQL. Realistically, that’s not going to be part of any Oracle/MySQL resolution, so I’ll leave it as a subject for another time.

The downside to Continuent Tungsten ’s stripped down architecture is that it doesn’t solve the most extreme performance scale-out problems. Instead, Continuent focuses on the other big benefits of keeping your data in more than one place, namely high availability and data loss prevention (i.e., backup).

Continuent has been around for a number of years, starting out in Finland but now being based in Silicon Valley. For most purposes, however, it’s reasonable to think of Continuent and Tungsten as start-up efforts.

As you might guess from the references to Finland and MySQL, Continuent’s products are open source, or at least have open source versions. I’m still a little fuzzy as to which features are open sourced and which are not. For that matter, I’m still unclear as to Tungsten’s feature list overall …

My client actually signed a deal for EnterpriseDB’s Postgres Plus Advanced Server and GridSQL, but unwound the transaction quickly. (They say EnterpriseDB was very gracious about the reversal.) There seem to have been two main reasons for the flip-flop.  First, it seems that EnterpriseDB’s version of Postgres isn’t up to PostgreSQL’s 8.4 feature set yet, although EnterpriseDB’s timetable for catching up might have tolerable. But GridSQL apparently is further behind yet, with no timetable for up-to-date PostgreSQL compatibility.  That was the dealbreaker.

The current base-case plan is to use generic open source PostgreSQL, with scale-out achieved via hand sharding, Hibernate, or … ??? Experience and thoughts along those lines would be much appreciated.

Another option for OLTP performance and scale-out is of course memory-centric options such as VoltDB or the Groovy SQL Switch.  But this client’s database is terabyte-scale, so hardware costs could be an issue, as of course could be product maturity.

By the way, a large fraction of these updates will be actual changes, as opposed to new records, in case that matters.  I expect that the schema being updated will be very simple — i.e., clearly simpler than in a classic order entry scenario.

• After much prodding, Greenplum finally gave me clear list pricing. Greenplum perpetual licenses list at $16K/core or $70K/terabyte. Annual maintenance is 22% of purchase price. Alternatively, one can buy an annual subscription on either basis, at 50% of the perpetual license purchase price. Of course, that’s just list. Quantity discounts are de rigeur.
• Greenplum had about 65 paying customers at the end of Q1. I’ve forgotten how that jibes with a figure of 50 customers last August.
• Greenplum claims rich functionality in standard SQL. In particular, Greenplum says “lots” of customers are using SQL 2003 OLAP. Greenplum further says it has “comprehensive” SQL-92 and –99 support.
• Greenplum Release 3.3 has “more flexible” compression, which Greenplum bravely asserts is now fairly close to columnar compression in effectiveness. (Aster Data and other row-based vendors make similar claims.)
• Greenplum Release 3.3 contains few performance enhancements for analytics, fixing an OLAP edge case that wasn’t previously parallelized — relevant buzzwords include grouping, aggregates, and DISTINCT, apparently in combination with each other — and speeding up sorts.
• Greenplum’s data loading story goes something like this:
  • Greenplum has an external tables facility that, in principle, could be used to index and query on tables outside Greenplum. It’s almost never actually used for that. However, external tables is the main way to load data into Greenplum from another relational DBMS.
  • A huge benefit of loading Greenplum via external tables is that you can load in parallel without passing the data through the master node.
  • Another benefit is that you can do ETL by building a view on the foreign database, then loading that view verbatim into Greenplum. (I guess this is an exception to Greenplum’s ELT orientation.)
  • In addition, Greenplum has something called Scatter/Gather which puts daemons on the hosts for flat files, allow the files to be loaded into Greenplum in parallel.
  • Like many data warehouse DBMS vendors, Greenplum tells you that if update volumes are high enough, you should bang them into something else and then feed the data warehouse in microbatches. Greenplum’s recommendations for the “something else” are PostgreSQL or file systems. Apparently, this is happening at some Greenplum telco customers. In one case, latency is only 15 seconds.
• In general, Greenplum asserts that very little work is done at the Greenplum master node, and the Greenplum master node isn’t a bottleneck.
• Greenplum proudly promises that its customers will never have to do dump/restore for any release, even the big more-than-point ones that only come around every few years.
• Greenplum added some Greenplum-awareness features to the pgAdmin III Postgres administration tool, which seems to be the most widely used tool with Greenplum today.
• Greenplum says it has 10-gigabit switches running in the lab, but doesn’t need them. For now it’s sticking with its “handful of commodity 1-gigabit switches” strategy.
• Greenplum MapReduce news and commentary include:
  • I’ve only ever gotten a single clear example of Greenplum MapReduce production use. But multiple Greenplum users are actively developing in MapReduce, judging by their dialog with the company.
  • Greenplum 3.3 has some MapReduce ease-of-use/programming upgrades, in low-glitz areas such as error-handling.
  • Greenplum’s current MapReduce language support is: Perl, Python, R, and C. Java didn’t make it into Release 3.3
  • Greenplum agrees with the MapReduce skeptics’ claim that you can in principle do anything in UDFs (User-Defined Functions) you can in MapReduce, but believes that sometimes doing it in MapReduce turns out to be easier.

]]> http://www.dbms2.com/2009/06/05/greenplum-update-release-3-3/feed/ 10 http://www.dbms2.com/2009/05/22/yet-more-on-mysql-forks-and-storage-engines/ http://www.dbms2.com/2009/05/22/yet-more-on-mysql-forks-and-storage-engines/#comments Fri, 22 May 2009 06:15:34 +0000 Curt Monash http://www.dbms2.com/?p=790 The issue of MySQL forks and their possible effect on closed-source storage engine vendors continues to get attention.  The underlying question is:

Suppose Oracle wants to make life difficult for third-party storage engine vendors via its incipient control of MySQL?  Can the storage engine vendors insulate themselves from this risk by working with a MySQL fork?

As laid out most clearly in a comment thread to a previous post*, Mike Hogan (CEO of ScaleDB) believes closed-source storage engine vendors can use a MySQL fork without running afoul of the GPL. In a nutshell, what he proposes is an inbetween layer of software, itself open-sourced, that on one side interfaces with MySQL, and on the other side talks cleanly enough to storage engines that it doesn’t infect them with the GPL.

*For some reason, the identical comments have also appeared one by one on a Stephen O’Grady blog post, with links back to the original thread. I did not actually post the comments attributed to me, so I presume there’s some automated process going on.

The most natural way for such software to be created would be obviously be in connection with the new Open Database Alliance.  So Matthew Aslett of the 451 Group asked the ODA’s two founding CEOs — Peter Zaitsev of Percona and Monty Widenius of Monty Program AB — what they thought on the subject.  He got rather different-sounding answers.  Zaitsev in effect said “Yes, Mike Hogan’s idea probably works, but one never knows for sure when there are lawyers involved. ” Widenius in effect said “Nope. A license would have to be purchased from MySQL.”

On a first reading that all looks discouraging, but let’s probe further. In particular, let’s invoke the open source community’s famous distinction between two kinds of freedoms: “Free as in speech and free as in beer.” “Free as in speech” takes care of most technical fears — there’s no way Oracle can directly stop forkers from creating their own version of MySQL.

True, third-party storage vendors might have to compete with Oracle’s own storage engines, where Oracle has four kinds of competitive advantage:

• General business clout
• A whole lot of database development expertise
• The opportunity to build tight hooks between MySQL’s generic front end and Oracle’s own preferred back end(s)
• Alternatively, the opportunity to foot-drag on MySQL development and thus sabotage the third-party storage engine market altogether

But the first two of those points are exactly what independent DBMS vendors already have to deal with when they compete with Oracle, many of them quite successfully (especially in the analytic DBMS market). Ditto, really, for the third one. And the fourth is exactly what forking takes care of.

The situation for “Free as in beer” is not quite as clean.  Could Oracle could successfully charge a financial “tax” on every closed-source MySQL storage engine sale, prohibitive or otherwise — even the ones running with forked MySQL rather than Oracle’s code line?  Mike Hogan says No, Monty Widenius says Yes, and Peter Zaitsev isn’t sure. I find Hogan’s argument fairly persuasive, but he and I are probably in the minority.

So let’s suppose Widenius’ pessimistic view is correct. Right now it seems that MySQL charges a non-prohibitive tax those engine vendors are perfectly happy to pay.  If Oracle made drastic increases in those charges, it could face all sorts of PR, business, and even legal adverse consequences. So the risk that Oracle cripples the MySQL storage engine vendors strictly through licensing fees seems relatively low.

One last question complicates all this even further — why would the storage engine vendors want to rely on MySQL-compatible front ends indefinitely anyway? The whole point of specialized storage engines is to do things very differently from generic MySQL, so I’m not clear on what kind of user technical skills argument there is.  For most uses, the Postgres interface is as good or better than MySQL’s. Perhaps a third open source front-end flavor could eventually become popular.  And by the way, Monty Widenius himself wrote:

The reason we decided on the name “Open Database Alliance” was to be able to include companies and people working on all other open source database in the Alliance.

This is work in progress. We will make this clear on the Alliance web site ASAP.

Interesting times indeed.