分布式数据库品牌多，如何选型？

在讨论如何做数据库选型之前，我们必须了解几个问题，否则选型这两个字就无从谈起。
第一个问题是你的需求是什么？你用数据库来干什么，用到了数据库的哪些特殊的功能？很多用户其实并不清楚自己选数据库的目的是什么，只是和我说，有没有和Oracle差不多的数据库可以替代它？我问他哪方面像Oracle，他说所有的，性能，稳定性，可扩展性等等。我告诉他一个不好的答案，就是没有，Oracle是独一无二的数据库界的老大，如果以Oracle为标杆来选数据库，最后只能选到Oracle身上了。不过我会问他第二个问题，你的业务需求是什么，是不是只有Oracle才能满足你的要求？别的数据库可能没有Oracle那么稳定，偶尔会出现一些问题，宕库的机率也比Oracle高，但是达到四个9或者五个9，对于目前的绝大多多数数据库借助一些技术手段，在绝大多数场景下还是可以实现的。别的数据库可能没有RAC，但是你的应用一定需要rac才能运行吗，读写分离高可用集群是不是也能满足你的需求呢？你真的需要分布式数据库来替代Oracle吗？你是否了解单机的处理能力有多高呢？只有真正的回答好了这些问题，真正的了解了你的应用，这样你才能有更准确的选择。了解了这一切后，你可能了解到你的数据库就是用来存放数据的，每天插入几百万条数据，删除几万条数据，修改十来万条数据，另外就是对一些千万级的表做一些统计查询。这样的系统恐怕一台虚拟机上的MYSQL或者PG数据库就完全胜任了。你为什么非要去选比Oracle还强大的数据库呢？
第二个问题是你需要了解硬件的真实能力，一台两路服务器的配置是什么样的，处理能力可以达到多少，一块SATA SSD盘的IO性能是一块普通HDD的多少倍？万兆网络上能跑多少流量，IO延时大概是多少？可能很多DBA干了一辈子都对这些数据不甚了解。只有了解了这些问题，才不会问出“我的数据库每天要新增上千万条记录，得多少个节点的分布式数据库才处理的过来？”这样的问题。在一台不到10万块钱的4路服务器上，我们曾经测试过，对于简单的高并发大批量数据插入，可以达到每秒钟500万条数据的写入，这还不是最快的水平。在数据库领域，能用硬件解决的问题，尽可能让硬件来解决，和能够提供的性能来对比，多花的这点钱简直不要太值了。现在很多企业的集采都特别注重价格，而不太关注相同价格下的配置问题，这一点也是不足取的。同样一台4路服务器，集采的采购者往往注重CPU的数量与频率，以及内存的大小，而不会去关注PCI-E插槽的数量与规格，RAID卡数量以及RAID卡的缓冲大小与吞吐量大小这些指标，我有一次和一个服务器厂商的工程师讨论这方面的问题，我问他如果RAID卡换成吞吐量大一些的，大概需要花多少钱。他说另外一款RAID卡还是挺贵的，比你现在配的这块贵100多块钱。在集采的招标中，正是这些100多块钱的便宜，让我们吃了更大的亏，很多时候是买了台很便宜的法拉利，却只能开出桑塔纳的性能来。说到能用硬件解决的问题就尽可能不要用其他手段，可能会有一些极端，不过在很多场合是适用的。大概十多年前，老白还是靠系统优化混饭吃的时候，有个朋友找到老白，说他有套ERP系统需要做个优化，让我报个价。他告诉我这套ERP跑在两台2路服务器上，做了一个RAC，大概有400G的数据量，存储是一台EMC的CX3-40。我分析了他的系统，然后给他报了个特别便宜的价格，大概是不到30万。他听了觉得有点贵，问有没有更便宜的方案。我说很简单，买台新服务器，插上一些SSD盘，然后把数据库迁移到SSD盘的单机上，原来的服务器、存储和这套新的数据库做一个ADG，再把ERP部署调整成支持ADG的模式，他当时的大部分问题就都解决了。这样的话，总共也就花不到10万块钱就可以搞定。他照着去做了，结果效果很好。
第三个问题是你的企业的IT基础架构与应用架构的发展策略是什么，今后企业是走云平台还是容器化为主的技术路线？集中式的大型数据库还是分散的小型数据库？业务规模的发展是什么样的？这些都会对你的数据库选型产生重要的影响。适合你的企业的IT发展是数据库选择前最重要的需要分析的问题之一，只有回答好了这个问题，后面的数据库选型才真正有意义。而IT发展必须是适应企业业务发展的，因此最终还是你的企业的主要业务的特点决定了你的数据库选型。如果你的企业的业务是灵活多变，的IT必须采用更为敏捷的方式进行交付，那么有可能你的企业会选择基于微服务的容器云，那么你选择Oracle这样大型数据库就不合适了。
第四个问题是了解你的备选数据库的基本特性，这些数据库的架构是什么样的，技术特征如何，技术指标与参数如何，与Oracle的兼容性如何等等。在回答第四个问题的时候，我们需要从下面的几个方面去考虑。这些选择数据库的选择分析并不一定十分科学，只是老白这些年工作经验的总结，算是一家之言，仅供大家参考。
•通用性与适用性：这款数据库是通用型数据库还是专用型数据库，中国人是十分会玩文字游戏的，非通用型数据库可能会被命名为金融级数据库，似乎十分高大上，金融都没问题，别说其他应用了，可能实际上是这款数据库因为MVCC上存在的一些缺陷，导致在某些场景下的支撑不足。如果某个数据库脱胎于一些场景比较简单的互联网应用，那么可能被称为“云原生”数据库，到今天为止老白也没弄明白“云原生”和天生的数据库到底有啥区别，在这里也就不做评价了。对于适用性也很重要，你的业务与应用系统的特点可能会影响你的数据库选型。实际上并不存在一个包打天下，万物通吃的数据库产品，所有的HTAP数据库的噱头大于实际效果。OLTP与OLAP的场景十分复杂，一套适合数据仓库应用的数据库可能无法支撑高并发高吞吐的十分简单的ODS场景，而让一套普通的行数据库去做数据仓库擅长的几十亿条记录表之间的复杂统计也会效果不佳；
•部署便捷性：随着DEVOPS的发展，IT交付的快捷性也是企业追求的重要目标。所以老白把部署便捷性放在了比较重要的位置上，能否快捷的实现自动化部署，自动化配置是今后选择数据库的一个十分重要的考量指标；
•使用与维护成本：数据库不是一次性消费品，数据库选型中使用与维护成本的考虑十分关键，这也决定了今后企业IT在这方面的投资规模；
•高可用/备份/容灾等方案的完整性以及实用性：再好的数据库也不可能永远不出事，虽然我们不希望发生这些事情，但是一旦发生数据库故障，宕库，主库无法使用的时候，必须不能丢失数据。很多数据库具有很高的可用性，采用了包括多副本、消除单点故障等的设计，不过对于关键性的IT基础设施来说，这些还是不够的，我们不能总说做了万无一失的准备，但是遇到了百年不遇的问题，每年都遇到的百年不遇就是一年一遇。这些方案不仅要存在，还要完整，而且可实施，被验证有效；
•接口完整性：我们常用的接口都需要支持，包括JDBC/ODBC/OLEDB/C语言/PYTHON、GO等运维自动化工具常用的语言。完备的接口可以保证今后数据库产品在深入应用时不会遇到坑，也不会让企业的IT被数据库牵着走；
•工具完整性：围绕着数据库的各种工具，包括开发、数据处理、数据管理、运维、部署、备份/恢复、安全审计、报表平台、ETL工具、数据复制工具等，这些工具都是今后数据库应用进入深水区的时候必然会用到的，可能我们刚刚使用数据库的时候并不会关注这些工具，但是一旦我们要用的时候发现这些都需要花大价钱去开发或者购买的时候，就麻烦了；
•生态完整性：和数据库相关的工具、应用软件、报表工具、管理工具、容器支持、云平台支持等方面的生态是否完备是考量一个数据库是否被业界广泛接受的一个重要的因素，数据库功能插件与第三方解决方案的多寡也可以看出某个数据库是否在生态链中处于强势地位，这些都是在数据库选型的时候不得不考虑的。对于开源数据库，开源生态的活跃度也是产品生态中的重要因素，选择开源产品的时候，如果你选择了一个两三年后不再活跃的开源项目，那么今后数据库的优化与发展就完全要依靠自己了，你首先要想清楚自己是不是做数据库产品的料；
•与主流商用数据库的兼容性：如果我们是从某个数据库迁移数据库到新的数据库产品上，那么我们就要考虑兼容性的问题了，兼容性可能决定了迁移的成本。当然并不是所有的用户都需要考虑兼容性的，如果应用架构本身就已经屏蔽了数据库的特性，那么这方面的考虑就可以比较少，如果应用正好要升级或者重构，那么对兼容性的考虑也可以降低；
•原厂服务能力与第三方服务能力：我们已经习惯了Oracle强大的原厂服务于第三方服务能力，这也是这些年Oracle能在中国这么流行的重要原因，在选择数据库产品的时候，我们必须知道一点，今后服务是依靠我们自己的力量还是依靠厂家和第三方，如果是后者，那么在选择数据库产品的时候，需要十分认证的去考虑这些问题。
•原厂的规模与企业稳定性：在IT行业，百年老厂能活下来的少之又少，因此选择数据库产品的时候，对厂家也要有一些考虑，可能某个数据库产品十分先进，但是原厂规模十分小，那么你可能会面临十分痛苦的选择。这种情况下，可能选择开源社区的类似版本会比选择一个小厂优化过的版本是更好的选择；
•市场与行业应用效果与销售规模：数据库产业是一个高投入，慢产出的行业，没有十年磨一剑的耐心是很难做出一款好的数据库产品的。你选择的数据库产品的时候，也需要考虑这一方面，现在的数据库产品数量太多，十年后，估计能活下来的产品并不多；
•DB ENGINE流行度排名：DB ENGINE目前还是最好的数据库排名网站，流行度是用户对某个数据库的认可程度，因此其参考价值还是很大的。不幸的是，好像天朝的数据库产品都不屑于参加排行，或者说老外还不太关注我们的数据库产品，因此上榜的国产数据库十分少。