Distributed SQL database (TiDB) source code explained
pingcap.github.io
pingcap.github.io
* 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.
The guy that invented the term "NewSQL" seems to disagree with you:
https://sigmodrecord.org/publications/sigmodRecord/1606/pdfs...
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
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.
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.
I actually have a counter-proposal that addresses the above concerns here: http://ssougou.blogspot.com/2016/09/distributed-durability-i....
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."
There's been plenty of explanation on how its built, their process, the architecture, etc. Some practical application would be helpful now to help contextualize those decisions.