也许MySQL适合Uber,但它不一定适合你
作者:LW 发布时间:[ 2017/5/5 10:24:41 ] 推荐标签:数据库 MySQL
关于物理复制
我的下一个关注点是原文有关于 PostgreSQL 的物理复制(Physical Replication)。原文谈到「索引再平衡」话题的原因是 Uber 曾经遇到了 PostgreSQL 的复制错误,这导致了下游服务器的数据毁损。(这个错误值“影响了 Postgres 9.2 的一些特定版本并且已经修复了一段很长时间”)。
因为 PostgreSQL 9.2 只在 core 提供物理复制,复制错误“只造成了树的很大一部分变得彻底无效。”具体解释为:如果一个结点分裂进行错误的重复,那么它不能指向正确的子结点,这些子树将会变得无效。这是正确的,正如其他警言“如果存在一个 Bug,那么不好的事情会发生”。你不需要改变大量的数据,可以打破树的结构。一个单独的坏指针足够了。
Uber 的文章提到了其他关于物理复制的情况:大量的复制流量—一部分由于更新带来的编写增幅—并且故障时间需要更新到新的 PostgreSQL 版本。如果第一个对于我而言是由意义的,那么我是不能评论第二个的(但是这里仍有 statements on the PostgreSQL-hackers mailing list )。
后,原文也声明了 Postgres 并没有真正的 MVCC 支持副本。幸运的是,原文链接到了 PostgerSQL 的文档,里面这个问题得到了解释。这个问题基本上是主机并不需要知道副本做了什么,并且因此会删除数据,而这些数据仍然需要副本来完成查询。
根据 PostgreSQL 官方文档,有两个办法可以处理这个问题:
1.为可配置的超时延迟复制流的应用,以便读取事务有机会完成。如果查询没有按时完成,杀死这个查询,并且继续应用这个复制流。
2.配置副本,把所有正在运行的查询,反馈送回到主机(master),这样一来主机并不需要清空行版本(row versions),恰好这些行版本在一些从属(slave)中仍然需要。Uber 的文章对第一个版本制定了规则,但根本没提第二个版本。相反,原文指责了 Uber 的开发人员。
关于开发者
以荣誉之名引用这段话:“举例来说,开发者有一些数据需要将发送给用户。取决于代码是如何写的,这些代码可能隐含有一个数据库事务,同时执行不相关的 I/O 阻塞,事实上是许多工程师都不是数据库方面的专家,因此不能总是理解这些问题,尤其是当使用 ORM 时,ORM 隐藏了许多底层细节,比如 open transactions 。”
不幸的是,我理解甚至同意这个评论。但是我不认同“许多工程师不是数据库,是因为每一个开发人员接触 SQL 是需要了解 transaction 的 ,不只数据库专家。”
鉴于对开发人员进行 SQL 培训是我的主要工作。我在各种规模的公司做过这件事。如果说我能确定一件事,那是和数据库相关的知识低的离谱。比如在刚刚提到的“open transaction”,我能确定的是,很少有开发人员知道只读事务是真事。大多数的开发人员只知道 事务可以用于回写。我遇到太多这种误解了,所以我准备了幻灯片来解释。
关于成功
这是我想写的后一个问题。一个公司雇佣的员工越多,他们的资质越趋于平均。夸张一点说,如果你雇佣了整个星球上的人员,你将会拥有的平均水平。雇佣再多的人,只是增加了公司的规模。
这里有两种方法来击败这种比率:
1、只雇佣好的员工。这个方法难的部分是,当没有高于平均资质的候选者时,需要等待。
2、雇佣一般的员工,然后在工作上培训。这对于新员工来说,需要一段很长的热身时间,并且可以结合现有员工进行培训。这两个方法的共同问题是需要时间。如果你没有时间——因为你的公司在快速增长——你不得不接受平庸,接受一些不是很了解数据库的人( empirical data from 2014 )。换句话来说:对于一个快速增长的公司来说,技术比人更容易改变。
正如随时间改变着的需求,成功的因素也会影响技术栈。在初期阶段,创业公司需要创造性的技术,即可以立即获得并且足够灵活来用于业务中。 SQL 一个比较好的选择,因为它确实灵活(你可以用任何方法来查询你的数据)并且很容易找到理解 SQL 的人,哪怕只对 SQL 有一点点了解。好了,那么开始吧!然而对许多—或许大多数公司来说,故事在这里结束了。即使他们比较成功并且他们的公司成长了,他们也可能在 SQL 的局限中永远处于原地踏步。Uber 不这样。
一些幸运的创业公司终从 SQL 蜕变。随着这种情况的发生,他们会有更多的机会访问资源并且然后…一些奇妙的事情发生了:他们意识到,如果他们开发一个只为自己使用的专用系统来取代通用数据库,他们可以解决许多问题。这是一个全新 NoSQL 数据库诞生的时刻。在 Uber ,他们将之称为 Schemaless 。
关于Uber 的数据库选择
直到现在,我相信 Uber 没有像他们的文章所建议的使用 MySQL 取代 PostgreSQL 。看来他们确实在一些特定的方法上替换了 PostgreSQL ,而这些方法恰好是 MySQL / InnoDB 所支持的(在当时)。看来原文只是解释了为什么 MySQL/InnoDB 比 PostgreSQL 更好地支持 Schemaless 。对于在用 Schemaless 的人来说,采纳他们的建议!不幸的是,原文并没有明确这一点,因为它并没有提及,和 2013 年从 MySQL 迁移到 PostgreSQL 相比,他们的需求是如何随着 Schemaless 的引进而改变的。
可悲的是,Uber 那文章留在读者脑海中的事情,是 PostgreSQL 很差劲。
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系SPASVO小编(021-61079698-8054),我们将立即处理,马上删除。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11热门文章
常见的移动App Bug??崩溃的测试用例设计如何用Jmeter做压力测试QC使用说明APP压力测试入门教程移动app测试中的主要问题jenkins+testng+ant+webdriver持续集成测试使用JMeter进行HTTP负载测试Selenium 2.0 WebDriver 使用指南