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. Fortunately, Schooner has some interesting stuff in those areas to talk about.
The short form of the SchoonerSQL (as Schooner’s product is now called) story goes roughly like this:
- SchoonerSQL replicates data — synchronously if the replication target is local, asynchronously if it is remote.
- Local synchronous replication provides high availability; remote asynchronous replication provides disaster recovery.
- SchoonerSQL’s local synchronous replication also provides read scale-out.
- Schooner has a partnership with Code Futures/dbShards to provide write scale-out via transparent sharding.
- SchoonerSQL has some secret sauce in replication performance. This has the effect of significantly increasing write performance (assuming you were going to replicate anyway), because otherwise you might have to slow down the master server’s write performance so that the slaves can keep up with it.
- Schooner believes it still has some single-server performance advantages as well.
Just to be clear here: Schooner is my client. Code Futures is my client. I introduced them and suggested their partnership. I then introduced them both to a user client, who was sufficiently impressed to seriously evaluate both of them. Even so, some of the Schooner replication story only became clear to me when I visited last Friday.
To flesh that out a bit more:
- Schooner has been making performance tweaks to the MySQL/InnoDB stack for several years. Some of them are still relevant, and can offer 50-100% performance improvements, especially but not only if you use solid-state storage.
- Schooner has found a way to scale up the slave side of master-slave replication, both in the synchronous and asynchronous cases.
- The core idea of SchoonerSQL parallel (i.e. scale-up) replication is straightforward. The replication log streams in. A chunk is sent off to a CPU core. The next chunk is examined for conflicts with the first chunk. If there are none, it is sent off to a different core to be processed
- Thus, you can have both local replication/high availability and remote replication/disaster recovery without slowing down writes on the master the way you may have to with other alternatives.
- Schooner believes this feature alone can make SchoonerSQL 3X faster than MySQL alternatives, at least for writes.
At least in casual conversation, Schooner synthesizes its 1.5-2X single-server figure and up-to-3X clustering figure into a single claim of frequent 2-5X speedup over generic MySQL/InnoDB. But the usual caveats about vendor-supplied performance numbers of course apply.
Finally, some housekeeping:
- At Oracle’s polite request,* Schooner changed its product name to not mention MySQL; hence the moniker SchoonerSQL.
- SchoonerSQL is being launched Monday.
- Schooner has determined that if its version numbers are different from MySQL’s, confusion ensues. So the first ever version under the name SchoonerSQL is SchoonerSQL 5.1, a factoid that Schooner is wisely omitting from the official product launch press release.
- The synchronous part of SchoonerSQL’s replication story dates back to last January’s product release.
- Most of the asynchronous part of SchoonerSQL story is new for Monday.
- dbShards/SchoonerSQL partnership engineering is still underway.
*I mean that non-facetiously. Schooner’s MySQL OEM contract was such that Oracle didn’t have a legal hammer to force the change. Edit: Whoops! There turn out to have been inaccuracies in the original version of this footnote, which I now regret writing. The contract isn’t exactly OEM, and there actually were some trademark-based legal hammers.