Schooner — flash-based, now software-only, and very fast
Last October I wrote about Schooner Information Technology, which made flash-based appliances, for MySQL, memcached, or persistent memcached. Schooner sold those appliances to close to 20 customers, but even so decided software-only was a better way to go.
Schooner’s core value proposition is that one Schooner box with flash does the job of a lot of MySQL or NoSQL boxes with hard drives. Highlights of the Schooner story — of which you can find more detail at the Schooner website — now include:
- Everything I said in the prior post still applies, except:
- I probably overrated the role Schooner software plays in low-level management of block placement on the SSDs (Solid-State Drives).
- While it has blazing single-box performance, Schooner software doesn’t scale out as smoothly as I assumed, pending the upcoming release of something called Schooner Active Cluster.
- The short name for the MySQL version is Schooner MySQL. (The long version, and I’m not making this up, seems to be “Schooner Appliance for MySQL® Enterprise™ with InnoDB.”) That represents a little over half of Schooner sales to date, but a much larger fraction of the pipeline.
- The name for the Schooner memcached option(s) is Schooner Membrain. Schooner Membrain is “certified” to be fully memcached/memcapable compatible.
- It’s a little hard to pin down details of Schooner’s performance. Schooner has a benchmark story, however, to wit:
- Schooner asserts that on a 95% read, 5% write benchmark workload, Schooner performance is >50% better than other MySQL/flash combos.
- That’s all with Fusion-io boards, which may be the fastest Schooner option but aren’t necessarily the most cost-effective.
- I can’t get a separate write performance figure, but 5% of the nearly 200,000 transactions/second shown in the benchmark is a big figure. That’s on a box with 64 GB of DRAM, however.
- Schooner CTO John Busch told me that a year ago, with correspondingly inferior silicon but still 64 GB of RAM, Schooner did 50,000 key-value Sets per second.
- Note that the benchmark is run on 1 TB/node, which is a lot more that you might have for optimal MySQL (or NoSQL) performance on disk-based systems. That supports Schooner’s core replaces-many-boxes claim.
- Benchmarks, especially vendor-supplied ones, should always be viewed with considerable suspicion. (And to Schooner’s credit, it sort of acknowledges same — bottom of the linked page.) That said …
- … not all of my objections to the TPC-H carry over to this case. The hardware is reasonably representative of real life (very untrue for TPC-Hs) and there’s somewhat less scope for differences in workloads (because Schooner is used in situations where the workload is essentially simple).
- Schooner’s replication and clustering story goes like this:
- Schooner replication is fully synchronous. Schooner’s core replication performance hack is to batch updates together, and only replicate every half-millisecond or so. (Note: Schooner batches updates anyway as part of its flash-friendliness.) Come to think of it, that discussion is another piece of evidence that Schooner does a lot more than 2000 writes/second. 🙂
- When Schooner Active Cluster comes out (soon), it will offer single-master clustering. That’s great for read performance, but doesn’t do much to help writes. However, I see no reason why something like dbShards/Schooner integration couldn’t happen. Indeed, I hope it does. That combination would offer truly enormous throughput, including for writes. I doubt many users would actually need that much throughput, but it would just be cool.
- Since Schooner only provides or plans to provide synchronous replication, if you want to go geographically dispersed, Schooner encourages you to use somebody else’s asynchronous replication tool.
- Schooner has something in beta for Schooner MySQL called “dynamic schemas” that sounds pretty interesting.
- The basic idea is that you can add/delete columns and their associated indices on the fly.
- Schooner dynamic schemas is done with versioning and timestamps. I don’t have details. In particular, I had the impression Schooner MySQL eventually deletes erased/changed data, but it’s not obvious how that would be consistent with a heavy reliance on timestamps.
- Since this reduces planned downtime, Schooner is billing dynamic schemas as providing a high-availability benefit.
- In general, Schooner’s high availability story includes:
- Synchronous replication.
- Active cluster (near future).
- Dynamic schemas (ditto).
- Flash may well be more reliable than disk.
Last October I wrote about Schooner Information Technology, which made flash-based appliances, for MySQL, memcached, or persistent memcached. Schooner sold those appliances to close to 20 customers, but even so decided software-only was a better way to go. Now Schooner calls it a “Software Appliance,” which I might have discouraged on grounds of being a bit confusing if they’d become my clients somewhat sooner than they did — what Schooner sells is just software, and they don’t even seem to be particularly rigid about recommended hardware configurations.
Schooner’s core claim boils down to one Schooner box with flash does the job of a lot of MySQL or NoSQL boxes with hard drives.. Highlights of the Schooner story — of which you can find more detail at the Schooner website — now include:
· Everything I said in the prior post still applies, except:
o I probably overrated the role Schooner software plays in low-level management of block placement on the SSDs (Solid-State Drives).
o While it has blazing single-box performance, Schooner software doesn’t scale out as smoothly as I assumed, pending the upcoming release of something called Schooner Active Cluster.
· The short name for the MySQL version is Schooner MySQL. (The long version, and I’m not making this up, seems to be Schooner Appliance for MySQL® Enterprise™ with InnoDB.) That represents a little over half of Schooner sales to date, but a much larger fraction of the pipeline.
· The name for the Schooner memcached option(s) is Schooner Membrain. Schooner Membrain is “certified” to be fully memcached/memcapable compatible.
· It’s a little hard to pin down details of Schooner’s performance. Schooner has a benchmark story, however, to wit:
o Schooner asserts that on a 95% read, 5% write benchmark workload, Schooner performance is >50% better than other MySQL/flash combos.
o That’s all with Fusion I/O boards, which may be the fastest Schooner option but aren’t necessarily the most cost-effective.
o I can’t get a separate write performance figure, but 5% of the nearly 200,000 transactions/second shown in the benchmark is a big figure. That’s on a box with 64 GB of DRAM, however.
o Schooner CTO John Busch told me that a year ago, with correspondingly inferior silicon but still 64 GB of RAM, Schooner did 50,000 key-value Sets per second.
o Note that the benchmark is run on 1 TB/node, which is a lot more that you might have for optimal MySQL (or NoSQL) performance on disk-based systems. That supports Schooner’s core replaces-many-boxes claim.
o Benchmarks, especially vendor-supplied ones, should always be viewed with considerable suspicion. (And to Schooner’s credit, it sort of acknowledges same — bottom of the linked page.) That said …
o … not all of my objections to the TPC-H carry over to this case. The hardware is reasonably representative of real life (very untrue for TPC-Hs) and there’s somewhat less scope for differences in workloads (because Schooner is used in situations where the workload is essentially simple).
· Schooner’s replication and clustering story goes like this:
o Schooner replication is fully synchronous. Schooner’s core replication performance hack is to batch updates together, and only replicate every half-millisecond or so. (Note: Schooner batches updates anyway as part of its flash-friendliness.) Come to think of it, that discussion is another piece of evidence that Schooner does a lot more than 2000 writes/second. 🙂
o When Schooner Active Cluster comes out (soon), it will offer single-master clustering. That’s great for read performance, but doesn’t do much to help writes. However, I see no reason why something like dbShards/Schooner integration couldn’t happen. Indeed, I hope it does. That combination would offer truly enormous throughput, including for writes. I doubt many users would actually need that much throughput, but it would just be cool.
o Since Schooner only provides or plans to provide synchronous replication, if you want to go geographically dispersed, Schooner encourages you to use somebody else’s asynchronous replication tool.
· Schooner has something in beta for Schooner MySQL called “dynamic schemas” that sounds pretty interesting.
o The basic idea is that you can add/delete columns and their associated indices on the fly.
o It’s done with versioning and timestamps. I don’t have details. In particular, I had the impression Schooner MySQL eventually deletes erased/changed data, but it’s not obvious how that would be consistent with a heavy reliance on timestamps.
o Since this reduces planned downtime, Schooner is billing dynamic schemas as providing a high-availability benefit.
· In general, Schooner’s high availability story includes:
o Synchronous replication.
o Active cluster (near future).
o Dynamic schemas (ditto).
o Flash may well be more reliable than disk.
Comments
4 Responses to “Schooner — flash-based, now software-only, and very fast”
Leave a Reply
[…] of its then-CEO, I wrote very little about my then-client Continuent. However, when I knew Schooner’s recent announcement was coming, I reached out to other MySQL scale-out vendors too. I’ve already posted […]
[…] all over again, I’d suggest they use one of the high-performance MySQL options like dbShards, Schooner, or both together. I actually don’t know what they finally decided on in that area. (I do […]
[…] with CouchDB/Couchbase, MongoDB was one of the top examples I had in mind when I wrote about document-oriented NoSQL. […]
[…] Then Schooner pivoted to be a database software company with strong flash expertise. […]