引子

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

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

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

新系统由于期初业务压力小性能问题并不突出，大概四个月以后，系统全国推广，业务量剧增，数据库开始顶不住了。有一个星期的时间，我每天例行的事情是每天八点半开始，看着数据库监控让应用主机轮休，６台应用全开数据库大概率被打挂。原因说起来是设计理念问题。早期数据库即是数据存储中心，也是运算中心。系统中大量使用存储过程，造成数据库压力比 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 团队，小一点的就只能一个人扛，所以一项技术或产品有足够活跃的社区绝对是选型中的必要因素。

做个总结

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

作者介绍：

贾世闻，京东云架构师，TiDB User Group (TUG) 大使。

本文转载自 AskTUG。

原文链接：

https://asktug.com/t/topic/1358

创作场景

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