Splice Machine bags $9m to fund RDBMS on Hadoop and Spark Splice Machine has secured $9m in C-round funding to carry on splicing Hadoop and relational database management system (RDBMS) technologies together. Total funding is now $31m and the extra cash will pay for accelerated product, sales and marketing efforts. So what is the problem that this start-up is trying to solve? Splice …
>>Splice Machine RDBMS, a hybrid in-memory technology that incorporates >>Hadoop, ANSI SQL, ACID transaction
Unless they're counting an SSD as "in-memory" (stupid) or redefining "in-memory" to mean "has read caching" (mendacious) the only way to make DRAM based data engine ACID is to disallow writes.
D=Durability. A session cannot be allowed to StartTransaction until the previous Commit has a confirmed clean write to non-volatile storage. Doesn't matter if you replicate the transaction log to other nodes (e.g. MongoDB) to reduce single point failure risk, it doesn't qualify as ACID. Proper ACID systems go to great lengths to disable or force flush OS and storage controller write buffering for exactly this reason. That doesn't mean all (or even most) systems need ACID of course.
I don't know what Splice do but most on the in-memory crowd use a transaction log on disc in a very similar way to a conventional DB. The benefits are from fast reads, seeks, scans and locks rather than commits (although all those speed up commits too).
There's a good Stonebraker video kicking around if you want the high level or most of the vendors have a white paper.
That's my point. If you do that then you're not an "in-memory" database. All C/S RDBMS engines have read ahead buffering, LRU page caches and RAM based lock managers. Some also have MVCC (e.g. FireBird) and cache complex structures like views and OLAP cubes. No-one calls them "in memory" databases just as no-one (sane) calls MongoDB ACID.
I'm familiar with some of Stonebraker's papers. I've been using his stuff since Ingres on DEC Ultrix. As far as I know none of his work refutes any of this. Neither does Jim Starkey's stuff, and he disagrees with Stonebraker on many issues.
They've rewritten Apache Derby to use HBASE as a storage layer, and added some MVCC. Nothing wrong with that, although that implies optimistic locking which sucks under pressure, but otherwise it is a big bag of open-source stuff, which they are then trying to sell. I find that offensive.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
