Back in August I talked with John Busch of Schooner Information Technology, which has a non-obvious URL. Schooner Information Technology sells Flash-based appliances that are mainly intended to run MySQL with blazing write performance.
This is one of those cases in which I warned that due to my September wave of family health issues I would cut a few blogging corners, so:
- I’m only going to write about the MySQL aspect, even though Schooner has a memcached product and claims to be able to run other NoSQL stuff as well.
- I’m not going to dig for company information beyond recalling:
- Schooner said that it has invested $20 million in R&D.
- Schooner’s appliances are resold by IBM.
- Schooner also has a direct sales force.
- One flagship customer had 30 TB of data on 17 Schooner nodes.
If Schooner wants to add some of what I’ve left out into the comments to this post, that would be great.
Schooner appliances are meant to be clustered, and “linear” scalability is claimed. Updates go to RAM cache, and are immediately sent to other RAM caches in the cluster as well. Relying on the safety provided by synchronous replication, Schooner appliances gain performance by writing to Flash only in a lazy, block-at-a-time manner. Beyond that, everything I picked up about the Schooner architecture was specific to individual nodes, including:
- John cited two of the tough points of Schooner’s design as being:
- Enough parallelism to drive the Flash IOPS (Input/Output Per Second)
- Concurrency/non-blocking threads/affinity management
- As you’ve probably already picked up above, Schooner batches all interrupts.
- In particular, Schooner batches writes into 4Kb-64Kb blocks, even if the application thinks they’re only 64 bytes or whatever. This mapping is done in DRAM.
- Schooner neither clusters nor sorts anything by key value. (That leaves a huge open question as to how anything ever gets retrieved with any efficiency.)
- Schooner’s block-writing strategies include:
- Obviously, batch-at-a-time writes are ideal for wear-leveling.
- Since it takes half a second or so to erase a Flash block, this is done before the block is needed. Of course, when Schooner erases a block it rewrites its contents elsewhere.
- Eventually, Schooner will erase and rewrite all blocks, even relatively clean ones. This is its compaction process.
- Transaction logs are written to disk.
- All of the above (especially the block placement and concurrency) required a lot of InnoDB hacking.