Speedb, a startup only 18 months old, has reinvented the RocksDB storage engine code and offers an API-compatible plug-in replacement speeding RocksDB-using applications.
A storage engine is the low-level code used to write data to and read data from storage drives. Facebook created key:value based RocksDB for its internal use and contributed it to the wider community. It is in very wide use – Redis for Flash uses RocksDB to interface to SSDs, and MongoDB is another database using it. There are other storage engines such as InnoDB which is used by Oracle.
Speedb CEO and co-founder Adi Gelvan told an IT Press Tour in Tel Aviv that “Key:value storage engines have become the key bottleneck of modern databases.”
RocksDB doesn’t scale well. Gelvan says it needs to be sharded to run on separate nodes when its data set size is over 100GB. Many users restrict themselves to 30GB shards, which sends running costs skywards as each node is a server. Since RocksDB is in wide use this is, Gelvan said, a huge problem.
His co-founders – chief science officer Hilak Yochai and CTO Mike Dorfman – recognized that there was a problem and looked deep into the RocksDB code to see if it could be improved. They both have technical backgrounds, including EMC and Infinidat, and hold many IT technology patents – Dorfman 10 and Yochai 100. Gelvan’s metaphor of what they did is this: “We looked at the storage engine not as an atom but as a molecule, and looked inside” – re-arranging and improving the components, such as code paths and algorithms.
Dorfman and Yachai spent about a year on this, rewriting about 70 per cent of the RocksDB code with a new log-structured merge tree, but not altering its API so that their replacement – a key:value store – could be switched in with no upper level stack changes at all. Then they contacted Gelvan, an ex-Infinidat sales head, and the three set up Speedb in 2020 with $4 million in seed funding from investors.
One of their first customers was Redis for Flash, the Redis in-memory database variant using SSDs. The performance improvements were radical – Speedb’s code provided support for a 100x larger dataset, ten times more operations per second and 80 per cent less compute resources, meaning saved cost. The code reduces write amplification from roughly 24x to around 4x, extending the endurance of SSDs.
It can even improve RocksDB performance six to seven times with Optane SSDs.
The first business model was to charge for their code, but this changed to become a 3-modal model. First, they would sell the code to OEMs to embed in their software and sell on, with Redis for Flash as the first one. Second, they would supply an open source version of their code so that the developer community could use it freely and also contribute to its development.
This could, and should, spread Speedb’s use widely throughout the community, because the code is simply far better than RocksDB. Longer term, and third, they could provide a charge-for enterprise version – with support for larger customers who wanted to use Speedb in production applications.
None of the three founders are natively open source people. Consequently Gelvan is putting people in place to support open source community members. He’s hired an open source project manager and open source advocates. The company has 19 employees currently, with the headcount expected to reach 40 by the end of the year. Speedb is considering whether to use Apache or some other open source licensing scheme.
Asked about Pliops and its hardware route to improving storage engine speed, Gelvan said: “We believe in software. The future will be in the cloud.”
The product’s roadmap includes improving the compaction code and algorithm, adding memory management – which Gelvan described as “a potential game-changer” – and auto-tuning features. The product would monitor its own performance and reset parameters if it detected inefficiencies.
Speedb has clearly better key:value store code than RocksDB. Using the open source route to market seems appropriate, especially as Speedb is a drop-in RocksDB replacement. We’ll watch its progress with interest.
