这些年分布式数据库的热度很高，大家都在谈分布式数据库，很多人认为未来的数据库必须是分布式的，甚至金融行业在一个行业标准里把数据库类型规定为核心系统必须用分布式数据库。

不过在实际的应用场景上看，实际应用环境中，集中式数据库还是用得比较多，哪怕在现在的去O浪潮中，用于替换Oracle数据库的大多数还是集中式数据库。分布式数据库似乎有些叫好但是不卖座，为什么会出现这种情况呢?

国内的分布式数据库产业其实起步是比较晚的，大多数都是最近10年甚至最近5、6年才开始发展的，其成熟度当然没有集中式数据库高。甚至刚刚开始的时候，分布式数据库在功能上远远不如集中式数据库。早期的一些以SQL代理+MYSQL实例的分布式数据库实际上并不是一个特别完整的数据库产品，而只是一个工程化的东西。多表关联，复杂的统计函数，窗口函数等都不支持，特别是不支持存储过程，这让数据库的通用性大打折扣。应用开发商在使用这种分布式数据库的时候感到十分难受。

既然分布式数据库的功能还不如集中式数据库，那么近些年分布式数据库为什么还发展得这么快呢?实际上分布式数据库的发展是受到互联网和物联网应用发展的影响而发展起来的。这些业务的特点是数据量大，高并发，小交易，简单业务。这种业务实际上是天生比较适合分布式数据库的场景的。功能上简单点没关系，但是架不住我可以横向扩展，能够高并发写入数据。

不过这种场景终归是有限的，数据库市场占主流的还是管理系统类的业务，比如OA,财务，营销，ERP等。这些场景并发量虽然比较高，但是还高不到不用分布式数据库就搞不定的地步。另外一方面，这些业务系统的业务逻辑比较复杂，并且大部分业务逻辑都是通过SQL实现的，因此对复杂SQL的性能要求比较高。再加上开发团队的水平也无法和互联网企业相比，你给仅仅会用JAVA框架，写一些SQL语句的码农们制定一套编码的清规戒律，就十分困难了。可能有些朋友不太认可这个观点，认为应用开发不应该过度依赖于数据库，而是应该与数据库无关。既然这样，那么我们还费什么劲来做数据库选型呢?把钱投在研发上不就行了。事实上，不同的企业有着不同的特点，要求企业的信息系统建设适应数据库产品，是完全没有道理的。

再加上分布式数据库部署的门槛过高，动辄三五个节点甚至十多个节点，也会让一些企业望而生畏。部署环境复杂必然带来运维的复杂性，如果文档做的再差点，原厂服务我想肯定是指望不上的，第三方服务生态更是一塌糊涂，那么用户肯定宁可使用相对简单的集中式数据库也不会选择分布式数据库了。

分布式数据库想要在这样的场景中获得较好的应用，不能总是吹嘘自己的TPCC有多高，支持的数据量有多大，更重要的是把自己的产品做好。首先把集中式数据库有的功能都实现了，在功能上没有短板，然后再谈分布式数据库的可扩展性和高可用能力吧。如果分布式数据库的功能与集中式数据库相当，运维便捷性也并不差，可扩展性与性能还优于集中式数据库，价格方面也不会太贵，那么分布式数据库叫好又叫座也就不难了。

总结一下，让分布式数据库叫好又叫座的根本因素还是在我们的数据库厂商，他们是否真正倾听客户的心声，根据客户的需求与应用场景的需求来设计与研发产品。在功能上能够满足客户的全方位需要，而不是附赠给客户一堆开发规范;在易用性上可以让客户低门槛上手，便捷运维;在文档上丰富全面，让用户能够看着文档用好数据库产品;在生态建设上构建完善的服务体系，包括知识库、售后服务网站、第三方服务能力等。

我想，不管哪个数据库企业，能把这些做好了，就不怕客户不买账了，这比花多少钱在营销上都要有效得多。