数据库和编程语言一样,同样是软件工程师们的必争之地。今天我就和大家聊一些数据库相关的知识。
去年 Uber 发表了一篇文章,宣布他们从 PostgreSQL 转到 MySQL 了。文章的内容很好,同时还科普了一些数据库索引和复制的基本常识。当时,我转给了一个朋友,朋友看了之后说:“哦,他们 2013 年才发了一篇文章说他们从 MySQL 转到 PostgreSQL 。”
我找来朋友提到的那篇旧文,读过之后,大概理解了两篇转型文章背后的原因。
作为两大主流开源数据库,MySQL 和 PostgreSQL 的 “战争” 从未停止,虽然硝烟不如编程语言那么浓烈,但也是你来我往,剑影刀光。
如果去 Quora 或者 Stack Overflow 上搜索 MySQL V.S. PostgreSQL 这样的关键字,会出现一大堆帖子,大家各执一词众说纷纭,我的感觉则是:两者各有各的优势和使用场景,并不存在一种数据库对另一种压倒性优势。
对于大部分程序员来说,公司用哪个数据库,基本无需你去决定。加入一个公司的时候,除非是创业公司,或者你是 CTO、VP、总监级别的,否则大部分的技术选型早已应该尘埃落定。
尤其是数据库,一旦选择,再迁移的代价非常大。因此,除非有颠覆性的优势或者难以克服的问题,很少有公司会去费时费力做这种大的迁移。
不论是技术选型还是技术转型,其中不可忽略的因素是:你的工程师更容易驾驭哪一种技术,或者有话语权的决策者们倾向于哪一种技术。这一点其实和程序语言的选型有异曲同工之处。
类似 Uber 两次高调转型的事情,在我曾经工作过的 Square 公司也发生过。
Square 最早使用的是 MySQL,到了 2012 年,由于 PostgreSQL 的各种优势越来越突出 —— 比如对地理空间(Geospatial)数据和搜索的支持,当时几位资深工程师也开始大力倡导,很多新的服务就尝试性地使用 PostgreSQL。
那时候,公司的架构是 MySQL 和 PostgreSQL 并存的。对于我而言,这就有机会学习、掌握和比较两种不同的技术。
在我来看,两者各有特点,有些技术实现在 MySQL 里更方便一点,另一些则反之。无论哪种数据存储方式,总有方案可以解决问题,并没有觉得非要哪一种才行。
一个公司如果数据库从来不出问题,那一定是因为没有业务量或者流量。所有技术的选型和设计,都有它的应用场景,除去那些让人开心的案例,剩下的毫无疑问就是坑。
如何尽可能地避开这些坑,如何在出现问题的时候可以用最快的速度去修复,这些都是至关重要的因素。
大部分工程师并不是数据库专家,在 Square 公司两种数据库并存的期间,PostgreSQL 的牛人寥寥无几,但是 MySQL 却有几个专家是极为靠谱的。对我们而言 ,PostgreSQL 和 MySQL 的相对优势,都比不过出问题的时候有人救火和解惑来的重要。
另外,一个公司维系两套同类的数据库系统本身就是个负担,因为这些原因,那些使用 PostgreSQL 的服务慢慢就转成了 MySQL 。
我们支付类的技术工作需要强事务和一致性的支持,所以 NoSQL 类型的数据库用得比较少,主要使用的是 MySQL 或者 PostgreSQL。由于在工作中常常与数据库打交道,我也逐渐了解到不少相关的知识和技术,但是线上真的出了问题,我还是没有把握自己去搞定。
好在,每个公司都会有一些专攻数据库的大牛,这种专门的职位便是 DBA,有的中小创业公司没有专职 DBA,数据库便由做运维的人维护。我和几位这样的牛人私交甚好,加之平时自己处理起系统中出现的相关问题,也会常常请教他们,一来二去就知道了很多有趣的数据库知识。
对数据库专家我一向是敬佩的态度,他们的价值不可小觑。公司只要稍具规模,如果数据库这块做不好,基本也就没什么可玩的了。数据库可以说是互联网公司最宝贵的资产,这块不出问题也罢,一出问题,即是见血封喉,服务直接宕机。
关于数据库,最常见的问题都有哪些呢?