如何评判基于中间件的分布式mysql与 云数据库？

利益相关，本尊是做DRDS的，当然也了解tidb，蟑螂数据库, oceanbase，否则没法做商业产品。

如果这个问题纯粹从当前时间、单纯技术层面去看，对比技术先进性，那就说不清楚，每个产品都能说出一堆的优点，比如pg非常优秀，有搞定全世界所有数据库需求的架势，但是实际上也有很多问题，就像

@郭宽

同学说的，业务想要银弹，可惜没有完美的银弹：），所以必须加上业务场景来聊。

从业务领域来说：前台在线业务，后台adhoc+分页+打标，后台adhoc+聚合，数据报表和分析。大概这4类业务。确实很多业务方将这4类需求混在了一块，然后丢给一个NB数据库处理，然后出来各种问题，可能一个单条数据主键查询要个2秒钟--(我们真碰到过这种情况)，因为这4类需求对数据库资源要求是不一样的，混用在一块，导致workload分配非常难。所以目前看上去比较合理的做法是链路隔离，然后选用合适的产品。

DRDS选择解决前台在线业务和后台adhoc+分页+打标处理这样的业务，其中前台业务最大的特点在于围绕某一个或者某几个数据主体进行操作，并且如果要达到超高性能，必须关注数据聚簇或者说data locality，所以拆分方式贴合数据特点是DRDS最大的优势,当然也带来架构设计上的问题,但是实际上所有的数据库在使用的时候都有做表结构设计和数据分布设计，只是分布式突破了大家原来的认知而已。

那接下来有一个问题，我就一个屌丝用户，能否不关注拆分？答案肯定是可以的，但是意味着你会碰到分布式事务或者分布式数据库中所说的全局二级索引，而这个是目前上述我所列产品的重要区别。

先不评论其他产品，DRDS目前无法实现严格一致分布式事务的原因实际上就是在于MySQL, 分布式事务目前最好的方式要么锁，要么MVCC，锁我们评估下来坑比较多，涉及到状态维持，所以基本上目前来看分布式mvcc是相对比较好的分布式强一致事务的实现(不过也有很多坑，各家实现上有些许区别，表现出来的能力也有差异)。

实际上DRDS对于分布式SQL引擎积累了很多优化经验(我们积累了很多用户SQL经验)，我们的SQL引擎将在不久更新，将会有非常好的SQL兼容性和产品格局。另外实现强一致分布式事务+全局二级索引实际上并没有想象的那么困难，我们已经有这个版本，但是目前我不敢给各位用，原因看总结。

最后总结下：用最新的分布式数据库，可能不需要关心拆分，那么你的业务量一大，按照二级索引查询，最起码2次跨网络数据操作(要么覆盖索引)，然后索引一致性黑盒(分布式索引维持比单机难很多)，另外你的数据会放在一个发展小于5年的数据库上，而且是最后一份数据(所以采用paxos,raft等加持)，如果你用DRDS，你可能会稍微痛苦点，需要选择拆分字段(实际上原则非常简单，前台类业务肯定能找到一个数据主体，然后按这个拆就可以)，然后需要同步几份数据做二级索引(开发中，18.4提供)，碰到分布式事务，需要用最终一致方式解决，但是你的数据是放在mysql上，当然还有三节点版本加持。

未来美好，现实残酷，各取所需。