我们需要什么样的数据库产品

现在大家都在搞新创，一想到数据库选型就会头痛，我们到底需要什么样的数据库呢?在五花八门的数据库面前我们到底选择哪一款才不会吃亏呢？

一想到数据库选型，首先出现在脑子里的恐怕就是TPCC/QPS之类的指标。而我觉得在现在的软硬件条件下，TPCC/QPS反而是最不需要担心的事情。我们来算一笔账，比如说有一家地方性银行，每天产生8000万笔交易，那么那么算下来日平均1秒钟的交易量是1000，折算成TPMC大约是6万，实际上银行核心交易的延时与开销远小于标准Benchmark测试的场景，实际需要的TPMC低于6万。如果忙时集中系数是0.1，那么就是14.4万，如果双十一高峰期的交易量是平时平均值的10倍，那么双十一高峰期的峰值处理能力需求是60万。看到这个指标大家心里应该踏实了，现在的国产数据库产品，哪怕在一台2路服务器上都轻松突破150万TPMC，甚至有的国产数据库厂商号称在国产芯片的8路服务器上可以跑出500万+的TPMC，我们闭着眼睛都能找到符合这个条件的数据库产品。

至于QPS那就更不在话下了，我们以前优化过的上千套系统中，真正每秒执行量超过10万的少之又少，现在的数据库系统100-200万QPS那只是起步价。

如果不比TPMC，那么我们应该关注什么呢？实际上作为数据库规划的人员，我们更需要看需要使用这个数据库的应用的真实表现，比如如果我们能够从应用中选取数类典型SQL语句，那么测试这些典型SQL在数据库上的表现才真正靠谱。每类SQL按照单次执行，5并发,10并发，一直到实际并发量的数倍，通过这些测试，可以了解这个数据库系统和你的应用系统的真实耦合度。在评估执行性能的时候，我们不能只执行一次，而是要多次执行，分析每次执行的稳定性，如果一个数据库在相同的并发下执行相同的SQL，忽快忽慢，那么要么是你的配置没配好，要么就是这个数据库内核存在一些问题。

当然如果能够做混合压力模拟测试，把多种典型负载按照实际生产类似的比例进行测试（不是极限压测），看这些SQL执行的延时指标，那么就更能够了解数据库产品对应用的耦合度了。

除此之外，我们还需要关注一些其他的因素，比如与应用的兼容性。SQL语法是否兼容，存储过程是否兼容，触发器，序列发生器，字符集等等。在这些兼容性的比对中，我们不仅仅要考虑存储过程是否可以方便的迁移过去，更要关注SQL中使用存储过程、函数的方法是否兼容，这决定了系统迁移时应用修改的成本。虽然目前大多数国产数据库都号称与Oracle保持强兼容，不过不同产品之间的兼容度差异还是很大的。

接口的丰富性也是应用兼容性的一个重要的方面，如果说数据库只支持JDBC接口，而我的应用有PYTHON的定时任务，有需要使用ODBC/OLEDB的报表工具，有嵌入式C语言写的后台模块的时候，就遇到大麻烦了。

另外我们还要考虑的一个重要因素是备份和高可用，数据库是否能够在单机故障时确保高可用，并且能够十分方便的快捷切换应用，对于一些和钱打交道的系统还会关注是否具有0数据丢失解决方案。而对于备份，是否支持热备，增量备份，逻辑备份等也是重要的考虑因素。

容错能力是需要考虑的另外一个要素，是否支持闪回查询，数据库闪回，表删除回收站等，对于一些管理比较薄弱，偶尔会出现误操作的企业来说十分有用。

实际上评价一个数据库是否好用，是否适合某个企业的实际情况，还有很多的方面，今天我们只是讨论了几个大家容易忽视或者以往被放在比较靠后位置的因素。而实际上这些因素对于我们今后长期使用某个数据库产品是十分关键的。