译者注：Swat.io是欧洲一家提供社交媒体解决方案的公司，总部在维也纳以下为译文。 乍一看，这篇文章看起来像是标题党。但是我们不能否认一个事实，公司从MySQL到PostgreSQL迁移已经开始，因为MySQL越来越复杂了。 回想公司刚成立那会儿，我们团队只有三个人，没有太多的资源和精力投入到技术的基础架构上；如果你正处在一个小团队，那么迁移到PostgreSQL就是个不错的选择。 不可否认，MySQL有许多优点，没有它，我们公司就不会发展到今天这一步。但是随着时间的推移，它的缺点慢慢的掩盖了其优点。由于缺乏更深入的专业知识，我们始终依赖于Percona MySQL和Ubuntu LTS 14.04的机带版本，从未使用过外部工具，因为一旦使用这些，就必须有人学习，了解以及维护这些工作流程，这将是一个巨大的人力成本的投入。 我们对MySQL 5.6不满意的最主要原因
开启轻量级的Postgres？我们做到了！我们遵循了建议，开始更深入的考察Postgres。为了简单起见，我们打算通过更改驱动程序来达到迁移的目的。但是，同志们，我们错了，2014年11月，我们提出了第一个完全迁移到Postgres的愿景的方案，标题为“[数据库]勇敢的新世界”。然而，这个方案有太多的问题，最终在半年后被抛弃了。 但是我们一直没有放弃。经过一番讨论和规划，我们决定将在新的swat.io分析引擎项目中引入Postgres。事实证明，这是一个绝妙的机会：一切从零开始，与现在的系统无关。唯一的缺点就是我们主要的数据仍然在MySQL中。要迁移到Postgres，就需要同步数据。虽然不是很完美，但是从商业角度来讲可以接受，从而为我们迁移的道路迈出了第一步。 这个项目需要花费了几个月时间完成，除了开发新的后端和UI代码之外，还给了我们足够的时间来学习新的数据库系统： 镜像模式？我们失败了！公司的分析引擎项目取得了成功，我们非常喜欢Postgres，但仍然无法迁移整个应用程序，我们尝试了另一种方法： 继续小的尝试？我们做到了！2015年夏季时，我们决定把一些记录表迁移到Postgres；但是这些数据只是些无关紧要的临时数据，所以放弃了数据迁移工作，直接迁移到新的数据库，并停用删除了相关的老数据库。 紧接着的尝试在2015年8月左右，我们的团队再次对MySQL的使用表示无奈，并且尝试迁移应用程序代码库。这次尝试比第一次更加先进，一次真正“使用”几乎完整的应用程序。
不幸的是，这次尝试在几个月内都没啥进展，最后几乎被遗忘。 挑战一切，永不放弃！不过，随着时间的推移，新内部项目中就出现了一个问题：
使用InnoDB数据库引擎的外键功能来保持数据一致并不总是很容易，往往在不同数据库间同步数据时容易出错。但是感到庆幸的是，这些MySQL中的主要痛点都不复存在了： 迁移的黎明Postgres的流行趋势仍在继续，MySQL的问题越来越多，夜间的维护时间越来越长，因为我们想在大表中添加几个字段，开始时需要2个小时，到最后变动完全不可测了，导致超出了我们宣布的停机维护时长。 2016春夏以后，我们再次尝试将整个应用迁移到Postgres。基于前一年提出的目标和一些新尝试，管理层经过仔细考虑，一直给我们开绿灯。 我们在2016年的几次尝试为我们带来了大量的性能优化经验，并且帮助我们解锁了一些发现bug隐藏属性，这在之前我们团队闻所未闻的。经过几个月的努力奋斗以及大量测试之后，我们拟定在2017年2月份，准备迁移工作。 虽然数据本身的迁移是成功的，但我们的应用程序的关键部分存在性能问题。这导致我们不得不回滚，然而我们并没有放弃，一直渴望找到问题根本原因。 在我们通往Postgres的道路上，我们得到了Markus Winand的use-the-index-luke和modern-sql框架的完美支持，他们对多种数据库的全面深入了解令我们惊叹不已。在我们团队的共同努力下，我们攻克了性能问题，最终被证明是由于数据库的“冷却”对性能造成了影响。迁移的最后一步，我们增加pg_prewarm上选择的关系，因而提高了对面向用户的关键部件的首次体验。 2017年3月的第二次尝试终于成功了。虽然数据迁移时间比预期的长，但是当流量到Postgres时，所有的一切都运行正常。 我最终迁移数量
为了确保迁移成功，能够正常工作且应对一定的并发量，在准备期间可能执行了约20-30次，跨时间约为两个月。 不得不转换8个代码库（其中有三个很大的代码库） 所有pull requests中凡是超过250次comments，我们就要定位问题，跟踪状态 超过150次的代码提交，并花费了很长时间仔细审查所有代码更改 我们没有开辟很多的git分支，但是猜想下，应该有50左右 大约有400个文件被改动 添加了大约7000行代码，大约删除了4000行 做了3次主要的攻关尝试 需要进行两次迁移尝试; 在第一次失败和第二次成功迁移的过程中，我们只在代码库中发现了两个真正意义上的bug。我们假定我们在某些极端情况下仍然存在bug，但这些经验给了解决问题的信心，我们正变得越来越好。 经验教训和收获
切换到Laravel仓库是件令人快乐的事：
能够优化我们的“线程注释” - 将代码从“n * m”查询转换为单个查询（尽管非常大和复杂），即使在具有十万条注释的线程上也能获得很好的性能（使用CTE和窗体函数） 与MySQL相比，PostgreSQL中的EXPLAIN（ANALYZE，BUFFERS）的输出更加实用性 MySQL与Postgres的结果字母顺序是不同的。MySQL使用自己的机制排列，Postgres则取决于操作系统的特性。（提示：PostgreSQL 10中有变化） 在MySQL中，要使用UTC（为了在整个系统中使用没有异常），首先必须导入时区；而在Postgres，它是开箱即用的； 文本搜索主要由我们的ElasticSearch服务器驱动，但有时您不需要它的全部功能，Postgres全文搜索能力也是足够好的，这一切还得益于GIN索引的高可用性； 部分索引（使用WHERE -clauses）并且能够在索引中使用表达式，这种新方法使得我们的生活变得更容易； MySQL中也有触发器这个功能，但对我们来说，它在具有WHEN功能的Postgres中更有用，能够简化触发函数本身并将其与应用它的条件分离； 通过使用可用的新功能（部分索引，窗口函数），我们可以将系统平均负载减少一半（从8降低到4）。我们知道，这就像比较苹果和橘子，因为即使在应用程序中也需要调整许多部分; 但是衡量这种变化过程本身是非常有趣的； WAL归档可能会让你感到惊讶。我们有一些看似平常的更新语句突然产生100GB的WAL文件的情况。你最好需要一个可以在线扩展的文件系统； 重构是我们团队的灵魂，特别是命名。为了快速理解所命名字段的意思和加强系统命名的规范和一致性。Postgres使我们可以轻松重命名数百个索引和外键，而不用让服务器停机。 与世间万物一样 ，调试复杂的系统也是一门艺术。相比之下，我们发现Postgres的文档是非常通俗易懂的。根据我们的经验，正是由于Postgres充分解释每个复杂概念和技术细节才使得MySQL的一些技术信息变得更加容易理解。 结语令人精神错乱的两种数据库协调同步（因为最终都服务于同一个领域）和令人头痛的MySQL维护对我们团队产生了极大的负面影响，万幸的是Postgres终于结束了这一切。完成迁移的那一刻，大家的满足感难以言表。 过去的已成历史，展望2017年，提高性能，更好地处理扩展需求以及提高客户满意度将成为我们的奋斗目标。 Linux面授班即将开班 四重优惠，万元大礼等你拿 详情，请咨询学习顾问 红豆 Linux面授班，报名优惠400元，名额有限，抢完为止！ |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
