在过去的两三年里，国产数据库成了热点。各家厂商如雨后春笋一般破土而出，向阳而生。这种局面放在10年前是难以想象的。身边也有朋友的公司开始引入各类国产数据库。然而我们都很清楚，开发一个稳定成熟的数据库，是一件门槛极高风险极大的工作。即便是有MySQL或者PG这种稳定的开源产品，在它们基础上进行开发，仍然是一个以年为单位的事情。
这期间，也有一些做数据库国产化的厂商和朋友问我，你觉得什么样的数据库是一个“好数据库“。而每逢此时，我都会问他们，是让我以一个专职DBA的视角回答，还是以一个旁观者的视角回答。事实上，每个角色对于“好”的标准差异很大。最后得到的答案几乎是一边倒的DBA视角，最终也促使我去写了整个系列的文章。铺垫了前两篇之后，终于该去回答一下我的答案了。
必备要素1：稳定性
既然是做数据库，当然要在生产环境跑。而生产环境，对DBA来说，稳定性永远是第一要务。性能再好功能再多，稳定性有问题，不但DBA不会喜欢，业务部门也不会去用。
这里说的稳定，既包含了服务状态的稳定，又包含了性能稳定，同时还有一个隐性的指标，成本的稳定。前两者我相信很多人都理解，成本的稳定指的是什么？
通常来说，一个企业，尤其是传统企业，每年的IT预算不会出现太大幅度的增长，除非有特殊的原因，能够说服相关负责人。如果数据库软件，随着业务规模和数据量的增长，成本的增长是可以预期可控的，这才能在每年预算中游刃有余。但是如果我规模是10的时候成本是10，规模是20的时候，成本变成了30甚至50，这在成本的稳定性上就会出现大问题。这里面的成本既包含了软硬件成本，又包含了人员成本。而比较糟糕的是，成本的稳定性往往都是在跑了一定时间之后才发现，这时候要么就接受更高的成本，要么就是选择更换数据库软件，是一件很痛苦的事。
在这一点上，我觉得目前主流的商业数据库都能做到成本的稳定性。而对于国产数据库来说，需要通过时间来验证。到了大规模使用，长时间使用之后，来检验这个事情。
必备要素2：易用性
一个数据库如果从安装配置到后期运维，全程都都很难用的话，注定不会成为一个好数据库。
早期的Oracle安装配置真的不友好，尤其是RAC的安装，通常一个熟练的DBA照着文档都得按天计算来折腾。尽管现在Oracle提供了RPM包安装的方式，但是在安装时也很难一帆风顺。好在安装完成之后，需要二次折腾的频率就大幅下降了。加上现在Oracle自带的OEM不断完善，很多时候我干脆用图形界面去完成很多日常工作，整个的效率提升了很多。而SQL Server的安装和运维可能是我个人感觉易用性做的最好的，小到一次备份恢复，大到一次服务器迁移。
MySQL和PG安装配置确实是简单了很多，可是后期运维的时候，在功能和性能面前，都需要DBA和开发人员做各种取舍。在出了问题之后，各种诊断和排查工作，缺少足够的信息支撑，很多的时候要靠猜和反复比对。这一点上，一些基于MySQL与PG开发的国产数据库，也没有做到实质性的改善。
倘若一个公司只用了一两种数据库，易用性不强的问题可以通过深入学习来慢慢抵消，可是很多的时候，一个DBA要运维五六种数据库的时候，易用性的好坏可能直接影响了DBA的工作难度，而这种难度的提升，是否存在真正的意义，有时候是要打一个问号的。
必备要素3：辅助工具
一个好汉三个帮，数据库想完成自己的工作，有时候也不是一个引擎就能搞定一切的，需要很多内置的外置的工具来共同完成。
商业数据库往往选择了把这些必备工具打包到自己的数据库产品里，比如AWR、RMAN、ADG，都已经成为了Oracle数据库的组件之一，伴随着数据库软件的安装一次搞定。而像OGG这类根据需要来选择的则可以单独配置安装。SQL Server更是夸张到希望把所有辅助组件都集成到一个官方运维工具里。
主流的开源数据库在这里则是选择了另一个路径，只提供了尽量少的辅助，而把更多必需的工具，交给开源社区来完成。好处是同一个需求可能找到很多不同的选择，缺点是有的时候，想要精准找到匹配自己需求的工具或者插件，不仅仅需要时间，有时候也需要一些运气。
如果未来有更多的新型数据库出现，从DBA的角度，我理想中的状态是两者皆有，既能有足够强大的官方工具提供支持，又能有比较丰富的开源社区工具提供补充。小孩子才做选择，我有点贪心，什么都想要。
必备要素4：安全审计
在金融行业或者上市公司做DBA，日常永远绕不开的就是安全和审计。即便不在上述这两种企业，对于数据库的安全，也是一个非常敏感的话题。现在数据库行业，很多产品都标榜自己符合金融级别的安全。也侧面说明了，数据库安全是一个强需求。
如果一个数据库软件，做不到足够的安全，是不会有企业客户和DBA敢把它放到生产环境跑关键业务数据的。不安全的数据库，无疑给自己挖了一个坑。权限和角色管理完备，安全机制足够好，是DBA对一个数据库最基础的要求。甚至有的时候，一些资深的DBA希望把自己的权限都能尽量收缩，以便减少误操作所带来的的损失。
审计的意义在于，让小到一条查询，大到一次停库，都能有迹可循。当然，实际生产环境，我们很少会让每一次查询都记录在日志中，但是我不用不代表你可以没有。真正到需要的时候不能提供，才是尴尬的时刻。
必备要素5：备份恢复与高可用
这里的备份恢复，既包含了冷备份与恢复也包含了热备份与恢复，而且是可以异机恢复的。
可能有读者看了这条会说，会有数据库厂商或者团队不提供这个吗？你可别说，真的有。以前接触过一个初创的数据库团队，我问他们，数据库连热备都不提供，你让我每次备份数据都是停库复制文件吗？对方振振有词地说，我们这是分布式多副本的架构，你有了这一套东西，就等于有了多个冗余。说出这话，让我意识到，对方根本不了解一线数据库运维的需求，都是在脑补。即便是分布式多副本，在一些行业中，仍然要求数据库要有单独的备份介质，可以单独恢复数据，并且有硬性的保存的年限。即便行业和公司没有要求，对于DBA来说，备份的数据都是自己最后一道防线。
而高可用也是同理，银行业的两地三中心是监管的强制要求。即便没有强制要求的行业，高可用冗余所带来的停机损失，也是远远小于从备份里恢复的。而且这个高可用的冗余，最好也是可以做switchover的。有时候我们看到某个系统因为故障导致长时间停机的时候，我总会下意识地去问，没有冗余吗？生产环境挂了，怎么不切换到备用环境？
极端情况，是一个合格的DBA永远需要考虑的。
必备要素6：版本管理
一个数据库软件的生命周期可能长达10年，这期间无论是内部还是外部的变化，有时候都会比我们想象的还要大。这期间做版本升级或者打补丁，都是不可避免的。
好的数据库，能够做到补丁的升级，同时对业务数据不会有影响。倘若我打一个补丁，数据读不出来或者不准确了，那就成了灾难。同时还得有回退机制，不能我这一个补丁打上去，发现有问题还不能回退，只让前进不让后退。而到了大的版本升级的时候，升级的步骤和结果必须是确定的。1.0到1.1升级，要是不同机器的结果千差万别，那干脆直接安装一套新的好了。
这里面还有一个隐性的要素，相邻版本之间的操作思路以及方式，不要有太大差异，给DBA一个过渡的时间。倘若升级了，哪哪都得重新学，这也是一个很要命的点。
写完这6个，我还反复斟酌了几个点，例如新特性是否及时、不同数据库之间的数据导入导出是否方便，这些固然都是成为“好数据库“的要素，但不能算必备要素。取一个“好数据库“的最大公约数，大概就是这6点。
