Actually, what I’m mainly going to do is quote a very long email that Continuent’s current CEO/former CTO Robert Hodges sent me, and which I lightly edited. 

As you know we use replication to build clusters of database replicas for open source DBMS, primarily MySQL. We have two products:

Tungsten Replicator – Tungsten Replicator is the basic data movement part of Tungsten.  We are going to release it as a separate product this year and push most features into open source to increase usage.

Tungsten Enterprise – Cluster management and connectivity based on master/slave replicas.  Tungsten Enterprise is commercially licensed on a subscription basis.

I guess that means Continuent’s essentially failed legacy multi-master replication product has — unsurprisingly — fallen by the wayside.

Here are the major use cases we solve.

Note that operational ease is much higher on the list than performance. Note also that Robert naturally compares Continuent Tungsten to his worst competitor, rather than any of the other interesting start-ups’ products.

1. Better MySQL Replication. Tungsten Replicator significantly extends the built-in MySQL replication to handle the following sub-use cases related to master/slave replication. Tungsten is basically a configurable message-processing engine that does database replication.

1.1 Failover with multiple slaves. Tungsten has global transaction IDs, so if you have a failure you can promote the most advanced slave from a pool of slaves to master and point all others to it.  MySQL replication by contrast tracks location using pointers into the master file system, so when the master disappears the slaves lose track of their position. This use case comes up both locally as well in building DR sites.

1.2 Replication between MySQL versions. Tungsten has minimal dependencies on MySQL versions and can replicate from versions 5.0/5.1/5.5 to versions 4.1/5.0/5.1/5.5. MySQL replication by contrast at best replicates up to the next version and either cannot replicate down or has limitations on replicating down version. This comes up commonly in migrations, for example going from MySQL 4.1 to 5.1.

1.3 Heterogeneous replication.  Similarly, Tungsten can replicate out of MySQL into other databases such as PostgreSQL (we are currently implementing this for a large SaaS) as well as Oracle and drizzle (currently very basic and not regularly tested but available for polishing when engagements show up). This comes up commonly when users need to move reporting data out of MySQL into something more civilized for analytics. Greenplum is popular, for example; we are working on that now.

1.4 Multi-master replication. Tungsten can consolidate from multiple masters into a single slave.  We also support topologies involving bi-directional replication with slaves on each master, including ability to promote slaves to take over from its master. MySQL replication cannot do this. These topologies are required for reporting as well as systems that have configuration or process merchant data across sites.

1.5 Parallel replication.  Tungsten has shard-based parallel replication from the MySQL log, which is essential to get around slave lag problems. In addition, we can spread replication processing load flexibly across CPUs and even different hosts. MySQL replication is single-threaded with a hard-coded processing path and cannot spread work across CPUs, processes, or hosts to optimize resource usage or deal with delays due to i/o.

And more operational stuff.

2. Zero-downtime upgrade.   Tungsten Enterprise enables applications to implement “daylight maintenance” by taking slave databases transparently offline, upgrading/maintaining them, and bringing them back online again. This is critical for 24×7 systems that cannot afford to go down for a day in order to upgrade from MySQL 5.1 to 5.5.

Tungsten provides the management commands to make this possible, for example a simple “switch” command that flips a master/slave pair without stopping applications. Tungsten also provides the necessary connectivity, namely transparent, high-performance proxies that hide the location of master and slave databases.  Finally, Tungsten Replicator provides underlying flush transactions that allow us to confirm that all user transactions have safely reached slaves before switching the master.

Now we get to performance, but read-only, and even then only for limited use cases.

3. Performance scaling. Tungsten Enterprise can load balance reads across slaves which unloads the master and utilizes otherwise idle slaves. The performance increases can be quite impressive–for reads that are highly I/O intensive you get linear scaling as you add slaves. It is less beneficial for simple key lookups, especially when databases are fully memory resident.

We have a couple of ways to do this but they basically use transparent proxies or a JDBC library to split reads and writes automatically by examining incoming transactions. For this to work most effectively applications have to follow certain conventions for their transactions. However, they are very simple and many applications do them already. For example, under our “SmartScale” load balancing only auto-commit reads are eligible for automatic load balancing.  We don’t try to load-balance reads within transactions as this would lead to errors for many applications.  Our performance scaling capabilities will grow better as our parallel replication capabilities improve–a big problem with MySQL replication is slaves tend to lag the masters in busy systems, hence cannot be used as easily for reads that require current information.

Yet more operations.

4. Automated administration and failure recovery. Tungsten Enterprise allows users to do complex operations like switch master/slave or take database nodes on and offline.  Also many operations like failover or recognizing new slave nodes occur automatically.  This reduces labor enormously both on the part of administrators as well as the effort to implement such operations in the first place.

Tungsten enables this use case in two ways.  It has built-in procedures for management tasks (switch, backup, restore, online, offline, etc.)  Tungsten also has built-in monitoring that feeds a rules engine containing rules to handle master failure, slave failure, new slave appearing, etc.   These execute automatically, though users can turn off features like automatic failover at their discretion.

5. Disaster Recovery Sites.  Tungsten Enterprise allows users to set up and and manage DR sites containing up-to-date database copies.   The key features that enable this are automatic VIP management (we use a virtual IP to allow the DR site to continue receiving updates even as the master moves on the main site) as well as global transaction IDs in the replicator, which ensure local and remote slaves do not become confused about their position regardless of how failure occurs.  I have a full write-up of the architecture in the following article:

http://scale-out-blog.blogspot.com/2010/10/mysql-disaster-recovery-with-tungsten.html

Finally it’s time to raise questions about Continuent competitors.

I hope this answers your questions and is not too late.  I read with interest your post on DbShards.  One interesting problem I have never quite figured out with their architecture is how to ensure requests are serialized.  They intercept requests at the library level and apply them both locally as well as in a log that can be applied to other databases.  The big problem with this approach is transaction ordering.  You either have to accept extremely slow performance (e.g., by single-threading all updates) or applications have to generate order independent updates, which means a significant rewrite to follow these conventions.  Otherwise you end up with slaves that look different from the master.  Either way it greatly limits the market.

Schooner has always impressed me as being the most interesting play of those you are covering.  It’s interesting they bailed out of hardware.  Appliances for MySQL strike me as a non-starter.  SSD integration has been very rapidly explored and commoditized by members of the MySQL community–people like Mark Callaghan and Peter Zaitsev are more hardware driven than any database people I have ever worked with.  The fact that the code that accesses storage devices is completely open helps drive this kind of behavior.  Schooner still is going to have a problem that MySQL users are very resistant to proprietary code, at least the big ones like Facebook, Yahoo, Rackspace, and Google.

A bit about future plans:

Meanwhile I expect we will take a page from Schooner and start patching the MySQL server over time to make our software run more effectively and provide better solutions to customers.  Large web properties in particular are very comfortable with this approach.

And finally some mercifully short rah-rah, still on the theme “We only acknowledge one competitor and we can clobber them.” Actually, I moved this from further up, where it seemed a bit jarring.

I anticipate that over the course of 2011 Tungsten will be recognized as the best replication engine for MySQL.  This is a big statement considering the entrenched position of MySQL built-in replication but our feature set is very broad and we will also have most of it available in open source by mid-year, which means that a lot more people will start using it.  The list of stable improvements over MySQL is so long I cannot fit them on a single slide any more.

• Teradata is discontinuing Xkoto’s existing product Gridscale, which Scott characterized as being too OLTP-focused to be a good fit for Teradata. Teradata hopes and expects that existing Xkoto Gridscale customers won’t renew maintenance. (I’m not sure that they’ll even get the option to do so.)
• The point of Teradata’s technology + engineers acquisition of Xkoto is to enhance Teradata’s active-active or multi-active data warehousing capabilities, which it has had in some form for several years.
• In particular, Teradata wants to tie together different products in the Teradata product line. (Note: Those typically all run pretty much the same Teradata database management software, except insofar as they might be on different releases.)
• Scott rattled off all the plausible areas of enhancement, with multiple phrasings – performance, manageability, ease of use, tools, features, etc.
• Teradata plans to have one or two releases based on Xkoto technology in 2011.

Frankly, I’m disappointed at the struggles of clustering efforts such as Xkoto Gridscale or Continuent’s pre-Tungsten products, but if the DBMS vendors meet the same needs themselves, that’s OK too.

The logic behind active-active database implementations actually seems pretty compelling: 

• You may well be keeping a second copy of your database for high availability/hot standby.
• You might even be keeping a third copy for off-site disaster recovery.
• In some cases, you might have reasons beyond disaster recovery to distribute a database around the world.
• So why not allow queries to be run against all the copies?
• And by the way, splitting the workload up a bit by kinds (e.g., long-running vs. short query) might let you optimize the implementation of each copy of the database. (This last point becomes even more important with the rise of solid-state memory.)

Analytic DBMS vendors pretty much all need to offer this. (Possible exception: If they have a data-mart-only positioning so extreme that customers will never care about any form of failover.) That said, I must confess to not having done a good job of tracking who does or doesn’t have which features in this area to date; informative comments to this post in that regard would be much appreciated!

• A little over a year ago, Julian Browne put up a great post on Eric Brewer’s CAP conjecture/theorem, which provides much of the impetus to relax the traditional requirement for atomicity/consistency.
• Even more directly inspirational to NoSQL technology development were two seminal papers: Google’s on BigTable and Amazon’s on Dynamo. (That said, I’m having trouble getting myself to actually read them from start to finish, especially since they’ve been superseded by subsequent technology development.)
• 10gen (the MongoDB guys) hosted a NoSQL conference yesterday. Much blogging has ensued. The best post I’ve seen so far was by Adam Marcus. I find the graph database notes near the bottom particularly interesting.
• Mark Callaghan hit back against the NoSQL movement hype, and in particular against the MySQL/memcached is passe‘ meme. On the other hand, he also bemoaned many failings of MySQL. On the third hand, he praised or at least expressed hope for a variety of MySQL-related technologies, including Tokutek’s TokuDB and Continuent’s Tungsten.
• In connection with that debate, Mark Rendle offered a funny rant, mainly pro-NoSQL, in the style of a Socratic dialogue.
• John Quinn of Digg recently described Digg’s move from MySQL to Cassandra, and outlined a lot of features Digg was adding to Cassandra, all of which it is open-sourcing.
• The NoSQL guys maintain their own long list of NoSQL-related links.

Robert Hodges of Continuent offers a great outline of Continuent’s clustering story, with a lot of “Now we got right what we previously didn’t know/admit we got wrong.” Continuent now claims to have a strong clustering offering, both paid and free/open-source, for both MySQL and PostgreSQL, with Oracle support perhaps coming really soon.

Merv Adrian, who has overrated the importance of TPC benchmarks in the past, seems to have become more skeptical.

Interim CEO Mark Burton laid out Infobright’s focus pretty clearly when he took over:

… the focus must be in building products that fit market segments where ease-of-use and easily attainable performance are valued.  This doesn’t sound like the high end of Data Warehousing to me where highly complex MPP architectures and teams of DBAs spend their time.  It sounds like the realm of Departmental IT and SMB where business leaders are in a hurry to gain access to data and answers without the lead time and pain of complex architectures and high costs.

I’m hearing about a SaaS focus from a lot of companies. The Continuent link above mentions one. So does RainStor’s latest blog post. Gooddata, a SaaS vendor itself, seems focused on analyzing data that was originally created via SaaS. I haven’t talked with Cast Iron or Pervasive for a while, but when I did, their ETL market targeting was all about SaaS. And of course, I hear dumber SaaS-focus ideas as well. I think the biggest substantive reason for this trend is — if you don’t have the broadest feature set, and fear large enterprises therefore won’t want your stuff, going after SMBs makes sense. And SMBs are presumed to be going SaaS. Also in the mix, of course, are a single platform to support, a small number of large SaaS vendors to sell to or partner with, and/or general trendiness.

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 …