#dbshards

First:

Schooner Information Technology started out as a complete-system MySQL appliance vendor. Then Schooner went software-only, but continued to brag about great performance in configurations with solid-state drives. Now Schooner has pivoted further, and is emphasizing high availability, clustered performance, and other hardware-agnostic OLTP (OnLine Transaction Processing) features.

Second:

Schooner is my client. Code Futures is my client. I introduced them and suggested their partnership.

And third:

There’s a perception that, if you want (relatively) worry-free database scale-out, you need a non-relational/NoSQL strategy. That perception is false. In the analytic case it’s completely ridiculous, […] And now it’s false for short-request/OLTP (OnLine Transaction Processing) use cases as well.

My favorite relational OLTP scale-out choice these days is the SchoonerSQL/dbShards partnership.

So the recipe is: fail twice, get into a partnership[1] and that will make your product the most promising scale-out relational OLTP system in the eyes of an analyst.

Indeed dbShards’ list of customers includes some interesting names  ↩

Curt Monash:

We’ll know they’re even more serious if they buy MySQL enhancements such as Infobright, dbShards, or Schooner MySQL

Why?

Three articles about dbShards:

highscalability.com: Product: DbShards - Share Nothing. Shard Everything

What Kind Of Customer Are You Targeting With DbShards? Who Ends Up Using Your Product And Why?

The primary customers for dbShards fit into two categories:

fast-growing Web or online applications (e.g., Gaming, Facebook apps, social network sites, analytics)

any application involved in high volume data collection and analysis (e.g., Device Measurement). Any application that requires high rates of read/write transaction volumes with a growing data set is a good candidate for the technology.

I’ve checked the customers page and I don’t see any company listed there that corresponds to the first point above. As regards the second category, read on.

dbms2.com: dbShards — a lot like an MPP OLTP DBMS based on MySQL or PostgreSQL

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.

I assume you are aware of some numbers for NoSQL databases. Not to mention the 750k qps NoSQLized MySQL.

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.

While there’s no surprise in the above quote, I’m not sure how to correlate it with the fact that dbShards targets data analysis clients.

dbms2.com: dbShards update

dbShards’ replication scheme works like this:

A write initially goes to two places at once — to the DBMS and a dbShards agent, both running on the same server.

The dbShards agent streams to the dbShards agent on the replica server, and receipt of the streamed write is acknowledged.

At that point the commits start. (Cory seemed to say that the commit on the primary server happens first, but I’m not sure why.)

In essence, two-phase database commit is replaced by two-phase log synchronization.

Anyone could explain how are these different?

I know all this may come out as too negative. But while I think dbShards has a decent set of features, some of the statements out there are not doing it any favors.