昨天我发了一篇关于GaussDB应用开发方面的一些建议的文章，有朋友和我讨论说，用TiDB就不需要这么麻烦。今天一大早做高铁出差，我就在火车上简单写的吧。

确实如这位朋友所言，TiDB的完全存算分离的架构，可以让用户类似使用集中式数据库一样使用分布式数据库，这是TiDB一直坚持的设计理念。不同的数据库设计理念不同，其架构也有巨大差异，对应用开发的要求也会有较大的差异。但是这并不一定就说这种架构一定是更为优秀的，还是那句我以前常说的话，没有完美的分布式解决方案，对于不同的应用场景，不同分布式数据库架构的适应度是不同的。就像汽车一样，手波的车让司机更加自主地控制汽车，从而能够适应各种地形，但是对司机有较高的要求，而自动波的车让司机很容易上手，但是对于复杂地形的处置可能无法调整到最 佳模式。

分布式系统在本质上与集中式系统有较大的的差别，因此想让用户像使用集中式数据库一样使用分布式数据库，以当前的IT基础设施能力而言，并不一定总是最 佳的思路。就目前的硬件条件而言，没有完美的分布式数据库架构。在增加易用性的同时可能带来的就是无法更好地提供应用优化的灵活性，对于一些应用场景无法从应用角度进行细致的调优。

像使用集中式数据库一样使用分布式数据库，这个理念在大多数情况下是正确的，但是这要求数据库系统有强大的能力。如果能像ORACLE数据库一样强大，那么应用开发水平差一些，都能跑得不错。如果分布式数据库的能力还不够强大，那么使用分布式数据库的时候，应用最好还是针对分布式应用的特点做好优化。

分布式数据库，无论是存算分离还是存算一体，都会对就近计算这个优化理念产生背离。跨节点的操作，无论是扫描还是JOIN，都会因为网络开销而带来成本。分布式事务更是会让事务的延时有所增加。分布式数据库可能会让一条SQL跑得更快，这主要取决于并发执行会对这条SQL带来多大的好处，如果这些好处比分布式计算所需要的网络开销以及分布式事务开销带来的负面影响更大，那么就会成为现实。而一些十分简单的SQL操作，往往无法从中受益。

在分布式数据库上开发应用的时候，针对不同的数据库架构所采用的思路是差异很大的。TiDB为代表的的完全存算分离的分布式数据库对开发是十分友好的，应用开发人员不需要考虑复杂的数据存储的分片策略，对于传统的集中式数据库用户来说，学习成本极低。但是在某些情况下对于应用性能优化是不友好的，因为我们没有办法根据应用特性去优化相关的表的存储结构，并更好地支持MPP计算。

相对而言，OceanBase和GaussDB这类分布式数据库可以使用类似表组和表复制的方法来优化某些应用场景，如果应用设计充分利用这些特性，那么是可以更好的下推某些算子，甚至将分布式事务变为本地事务，从而极大地降低应用的延时。这种优化在TiDB上就无法实现，只能通过对集群软硬件环境的极致优化来降低总体延时了。

正是因为TIDB的完全存算分离的架构，早期的TiDB是不支持MPP的，这意味着TiDB Server会成为系统的瓶颈，出现某个TiDB Server忙死，其他的Server眼看着帮不上忙的情况。从TiDB 6.1开始，也开始支持MPP了。而MPP计算比较好的模式是数据分片，存算一体。在做MPP计算的时候，TiDB的计算路径明显要高于存算分离的分布式数据库。

最后还是回到我的标题，没有完美的分布式数据库架构。对于目前国产分布式数据库的三个佼佼者而言，其架构差异很大，使用起来在某些方面也是各有优劣势。不过我个人观点是，对于分布式数据库上开发应用而言，如果应用规模不大，复杂度不大，对应用延时要求不高的时候，你可以不用为分布式数据库做专门的设计。而如果你的应用比较复杂，也十分关键，对于SQL响应时间要求十分严格的话，那么你还是在做数据库物理设计的时候多考虑一些分布式数据库的特点来优化你的应用。

今天的讨论不是讨论几种分布式数据库谁优谁劣，而是针对分布式数据库的应用建设这个技术点谈一些我的个人观点。如果要PK这些数据库的性能或者综合使用成本，那是另外一个范畴了，并不在我今天的讨论范围之内。