从两个更换数据库的案例谈起

给我印象最深的一句话是一篇关于英国卫报从MONGODB向PostgreSQL迁移的案例，虽然这次NOSQL向SQL迁移十分具有戏剧性，但是最终卫报的IT负责人谈起这次迁移的最初动力的时候说的一句话让人印象深刻。

很显然的，一小时的数据库故障是更换数据库的十分强大的动力。卫报更换数据库的主要原因是2015年7月的一个偶然事件，在此之前，卫报一直是Mongodb的一个典型的成功案例。当时伦敦发生的极端炎热天气让相关新闻大爆发，而正是这个时候，大量的作者发现他们无法上传和发布他们的文章了。卫报的IT部门发现CMS系统和Mongodb数据库都出现了严重的问题。为了更好的运行Mongodb，卫报花大价钱购买了OpsManager软件，并从Mongodb购买了昂贵的原厂服务，不过这一切在故障发生时，并未起到任何作用。在Mongodb故障的两个多小时里，来自原厂的服务支持的效果几乎为0。这一切都让卫报的IT管理者坚定了从自己的私有云向亚马逊公有云迁移的决心。

不过将如此大的IT系统从Mongodb迁移到AWS的云平台上并不容易，因为经过此次故障，卫报希望亚马逊能够提供一个全面的解决方案。DynamoDB似乎是个好方案，不过由于当时DynamoDB不支持端到端加密,客户端无法以加密的方式与服务器通讯，因此无法满足卫报的安全要求。于是PostgreSQL进入了视野。因为Postgresql支持的JSON类型可以较为简单的实现从MONGODB 数据向PG的迁移，因此卫报很快就选择了Postgresql on AWS RDS。最终在2018年初，卫报把230万篇文档从Mongodb迁移到了PostgreSQL,并实现了这一0停机时间的系统迁移。至今为止，这套系统运行稳定，达到了卫报IT部门的最终期望。

另外一个Mongodb到PostgreSQL迁移的案例来自于科技公司Shippable，这是一家从事devops解决方案的公司。他们的代码库最早是使用关系型数据库的，后来发现Mongodb对于非结构化半结构化数据处理以及灵活的数据模型的特点特别适合他们快速发展的业务，因此就把数据库迁移到了Mongodb。随着Shippable公司的快速发展，Mongodb的灵活性给他们带来了巨大的福利，最初的几年是蜜月期，一切都十分完美。直到Shippable的代码库系统的故障发生率越来越高的时候，人们才发现，几乎90%以上的故障似乎都和数据库有关，虽然以前大家都认为这些故障都是因为代码中存在BUG导致的。故障中大约有30%-40%的问题是性能问题，这些性能问题有时候经过一顿漫无目的的尝试，有可能就消失了，很多问题解决后并未真正的定位到了问题。还有一些问题最终发现是代码的问题，由于业务发展很快，微服务数量爆炸性的增长，而数据模型也在不断地更新，代码与数据模型不一致的问题十分常见，开始大家都把这一切归咎于开发人员的疏忽。后来终于有一个明白人说了一句话：“我们花了极大代价去做测试的工作，不都应该是数据库的基本功能吗？为什么还要我们开发人员来做呢？”。

于是在一次4小时的数据库故障之后，更换数据库就被作为一个正式的工作提了出来。一年后，Shappable将数据库迁移到了PostgreSQL,事后他们发现，数据库小了很多，管理也更方便了，业务变更的速度也提升很大，后来当有记者问他们的IT主管的时候，他回答说，及时把数据库从NOSQL迁移回SQL是他这些年做的最为正确的决定之一。

实际上虽然这两个案例都是由NOSQL的MONGODB迁移到PG的案例，但是并不是说MONGODB不如PG，而是说数据库选型不仅仅是选择一个数据库的问题。一个企业选择数据库一定要充分考虑企业自身的业务特点、开发人员的素质水平、运维能力等多方面的因素。5年前我和一个企业的IT部门交流的时候，听他们说起他们向阿里云DRDS迁移的经历，几乎原有的开发团队都没有能力写出好的DRDS应用，于是接近200人的研发队伍进行了重建，每年多花的研发费用就超过4000万。上个月我参加一个架构优化的会议，其中一个研发企业的负责人就说，领域建模是个好东西，可惜我们的研发人员玩不转这东西，所以最初的数据库设计完全就落空了。这些问题都是我们所面对的，而正好又是很多企业的IT部门的高层领导们所不知道的事情。

无论是Shappable的为什么让数据库该做的事情都让研发人员来做，还是卫报的一小时停机的故障足以让你下决心换数据库，这些都是在为错误的选择付出代价后的感悟。幸运的是，他们最终明白了这一点，并且做出了正确的选择。