跳到主要内容

技术选型中的非技术因素:以数据库为例

作者:贾世闻,京东云架构师,TUG 顾问团成员

文章首发于 2019 年 10 月

一、引子

在一次 TUG 活动中,主持人让大家谈谈选择 TiDB 的原因。我分享了从业以来的救火经历,以及如何最终聚焦到 TiDB 的过程。回想起来,在这个过程中我们并没有进行严谨的技术论证,顶多是进行了大量的业务适配(根据已有业务写案例测试基础软件)。那么,哪些非技术因素影响了我们的选择呢?

二、痛苦驱动我们不断寻找好的解决方案

先回顾一下我在 TUG 分享的故事。200X 年我们为某全国性银行搭建信贷系统,数据库用 Oracle,彼时我在项目组担任 DBA 并承担了部分开发任务。至于为什么是 Oracle,原因很简单:行方要求。200X 年以前,金融行业还是 IBM 的天下,数据库选什么基本比较固定,大行 DB2+Informix,小行比较单纯,清一色 Informix。所以整个项目除流程部分个性化,业务需求开发以外的大部分工作量是来做 Oracle 数据库的适配。半年以后系统上线,我就去带运维团队了。

新系统由于初期业务压力小,性能问题并不突出,大概四个月以后,系统全国推广,业务量剧增,数据库开始顶不住了。有一个星期的时间,我每天例行的事情是每天八点半开始,看着数据库监控让应用主机轮休,6 台应用全开,数据库大概率被打挂。原因说起来是设计理念问题。早期数据库既是数据存储中心,也是运算中心。系统中大量使用存储过程,造成数据库压力比 AP 大得多,通常 AP 的 CPU 到 30%,数据库基本就 100% 了。优化方案思路清晰,部分计算迁移 AP,给数据库减负。当然关键列不建索引,复杂 SQL 不优化这种优良传统那时候就有了,同样是优化范围。折腾数个月系统稳定了,公司的程序员大叔们也学会了如何与 Oracle 打交道,从此后平稳了大概三四年的时间。

201X 年我们为某互联网公司建设信贷系统(互联网金融)。我们数年打造的基于 Oracle 的体系不再适用。原因很简单:该互联网公司没有适用商业数据库的传统,也不想花费大把的授权费。分库分表成为项目的关键词。好在互联网公司有天然的创造性基因,他们有自己的数据库中间件,这让项目组看到一丝曙光,但是当我们实际引用的时候问题不少。中间件是基于互联网业务开发,而互联网业务比起金融业务来说相对简单,拆分更容易。为了适应开源数据库,我们的系统基本是玩儿了一次重构,数据库中建立了不少映射表,源数据表系统复杂度翻倍。系统运行过程中也是提心吊胆,一堆的数据库实例,宕掉一个数据完整性就难以保障。分库分表使我们用一堆开源数据库替代了商业数据库+商业存储的方案,但运维成本却提高不少。这个成本不仅仅是人员成本,有些成本是隐性的。比如在商业软件时代,系统有问题可以寻求厂商支持。开源软件构建的系统只能由项目组自己抗。虽然代理层已经为我们实现了很多 SQL 转换及分布式事务的方案,但业务数据拆解的工作量依然繁重。

疼到一定程度就开始到处找药。2017 年当看到 TiDB 的方案时,直觉告诉我这玩意儿不用分库分表,应该能行。

三、除了痛点我们还应该考虑些什么

痛点引领我们找到多种方案,到底选哪个呢?技术论证周期比较长,因为既要了解多种技术,又要结合业务进行取舍。最好的方法是把现有业务在新技术方案上跑一遍试试,这个方法最直观。问题又来了,多种技术方案的情况下先试哪个?先把技术放一边,让我们来问几个问题:哪项技术我们能更快速地了解到技术细节?技术是否符合我们团队的技术栈?使用过程中遇到困难能从哪里得到支持?落地时会不会有其他阻碍?

先来看看最后一个问题,因为如果因为某些阻碍方案不能落地,前面做的工作都是竹篮打水。

企业和组织都存在不同程度的技术惯性和遗留资产。以金融企业为例,去 IOE 喊了很多年,去 I 易,去 E 也不难,但是 O 却一直没有很好的方案。除了 Oracle 在业界的地位和领先的技术水平以外,还有很多因素。大部分金融机构都买断了 Oracle 的授权,弃之不用等于资产流失。技术人员对 Oracle 极其熟悉,其他技术了解程度不够,承接运维需要付出学习成本。从人性的角度来说,面对未知总会有一定恐惧。解决这些问题没有什么更好的办法,只能通过长时间的不断教育,另外就是等待已有授权过期,或者现有技术瓶颈凸显。

文化因素不可忽视。在国内 NewSQL 领域了解 TiDB 的同学应该明显多于 CockroachDB。除了社区活跃度以外,文化因素不可忽视,首先 MySQL 的用户群比 PG 要大的多,这些用户对于兼容 MySQL 协议的产品上手容易。再有就是文档本地化,PG 虽然有中文文档,但是是由英文文档翻译而来,和原生比起来差了一些。

前面我们关心了实施前的学习曲线,以及落地时有可能遇到的阻碍,那么落地后呢?我们能从哪里得到支持?早年间的 DBA 都比较孤独,一个人安装,一个人调优,一个人做数据迁移,项目组里有大量的程序员,但是 DBA 每个项目也分不到一个。大一点的企业或机构还好,有专门的 DBA 团队,小一点的就只能一个人扛,所以一项技术或产品有足够活跃的社区绝对是选型中的必要因素。

四、做个总结

技术选型中的非技术因素主要包括四个方面:痛点、文化、社区、技术惯性及技术遗产,分别对应选型、技术融合、后续支持、技术落地四个阶段。痛点驱动我们寻找方案并有的放矢;文化决定技术融合的效率及学习曲线是否陡峭;社区让我们有能力应对不确定因素;通过对企业技术惯性及技术遗产了解,可以提前预知落地时将要面对的困难,早做准备。综合考虑这些因素可以在选型及落地时提高效率,少走弯路。