Within the spectrum of so-called "NewSQL" databases, there are basically two kinds:
* ones built on top of a mature relational database (e.g. Vitess, CitusDB)
* ones built on top of some custom or unproven KV store (e.g. TiDB, CockroachDB, NuoDB)
Ultimately, despite claims of benchmarks/elegance/MySQL not being web scale enough, I'm unsure if (at least in the immediate future) it's a wise move to do the latter. Solutions that use a proven storage engine seem like an easier pill to swallow.
I'm actually a fan of TiDB and Cockroach. I've met engineers from both, and they're super-sharp.
I am biased towards something like Vitess that builds on top of existing tech. The main advantage is that we can push-down the work to the lowest level, and leverage efficiencies that are already built in MySQL.
But the newer architectures offer better consistency models. Some customers may care more about that.
In the long run, I think these trade-offs should converge.
Overall, any NewSQL is a better alternative than using traditional key-value stores, because it gives you better functionality while not giving up on scalability.
Hey! I really enjoyed the talk you gave at Square :p
I agree that we can't build on the same base forever, but I also think it's really hard to get companies to trust completely unproven solutions -- ground-up rearchitectures like TiDB and Cockroach -- with their data. I'm not sure that there's an easy way to get around that.
Re: consistency -- wouldn't it be possible to e.g. make Vitess work nicely with MySQL's Paxos-based group replication?
MySQL group replication has some issues: It can fail your commits if multiple masters have conflicting transactions, which is a problem for cross-shard distributed transactions. Additionally, group replication is too chatty and doesn't work well cross-dc.
My argument was mostly based on the actual technical differences, so I didn't really count DBaaS as a separate category. At the very least, I don't think I know enough about how DBaaSes work differently underneath the UI :P
TiDB and CockroachDB both use Facebook's rocksdb. I would not call it an unproved KV store. Both also use etcd's raft implementation which is also quite well proven.
Sure, but I wouldn't exactly call them mature yet. I think MySQL is still much easier to trust than RocksDB. (I don't actually know much about RocksDB, but I remember that LevelDB had a bunch of data corruption issues. Hopefully RocksDB doesn't.)
To quote the famous video[1]: "Relational databases have been around since the fucking 70s and are some of the most mature technology you can find."
RocksDB is widely used in many of projects for years, i think it's quite mature. Not just TiDB and CockroachDB, MyRocks and MongoRocks are using RocksDB as storage engine too. Also there are plenty of other projects are using RocksDB. If you are worry about the adding new feature of RocksDB, yes, you are right, but all of the storage engine are changing rapidly(even InnoDB which is used by MySQL as default engine), Anyway, happy hacking :)
* ones built on top of a mature relational database (e.g. Vitess, CitusDB)
* ones built on top of some custom or unproven KV store (e.g. TiDB, CockroachDB, NuoDB)
Ultimately, despite claims of benchmarks/elegance/MySQL not being web scale enough, I'm unsure if (at least in the immediate future) it's a wise move to do the latter. Solutions that use a proven storage engine seem like an easier pill to swallow.