写点什么

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

2019 年 10 月 24 日

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

引子

在一次 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 团队,小一点的就只能一个人扛,所以一项技术或产品有足够活跃的社区绝对是选型中的必要因素。


做个总结

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


作者介绍


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


本文转载自 AskTUG


原文链接


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


2019 年 10 月 24 日 08:001123

评论

发布
暂无评论
发现更多内容

实用!8个 chrome插件玩转GitHub,单个文件下载小意思

程序员内点事

GitHub

.NET可视化权限功能界面设计

力软.net/java开发平台

.net 可视化 权限

基于阿里云容器的CI/CD落地实践

LorraineLiu

阿里云 k8s Helm jenkins CI/CD

分布式文件存储QoS硬核黑科技,真香

焱融科技

高性能 存储 HPC 分布式文件存储 QoS

爬虫“学前班”,记住这些不踩坑!

华为云开发者社区

爬虫 数据 搜索

MySql从青铜到王者晋级之路,阿里大牛经验总结让牛少走弯路!

Java架构之路

Java 程序员 架构 面试 编程语言

大企程序员亲身经历告诉你,CRM系统,自己的才是最好的

Learun

敏捷开发

即构SDK10月迭代:新增多款语音音效、外部采集码流控制及Android SDK 最低支持操作系统版本调整

ZEGO即构

android RTC

阿里巴巴专属著作超赞,就是名字起得有点狂“成神之路”???

Java架构师迁哥

「深度解析」告诉你如何选择容器存储

焱融科技

Kubernetes 云原生 焱融科技 容器存储 分布式文件存储

一文读懂GaussDB(openGauss) 的六大关键技术特性

华为云开发者社区

数据库 数据 存储

Vidyo的技术特点都有哪些?

dwqcmo

音视频 集成架构 解决方案 智能硬件

什么是动态代理

Rayjun

Java 动态代理

我服了,难倒无数程序员的源码面试,就这样被轻轻松松讲透彻

小Q

Java 学习 源码 架构 面试

uni-app支持PC宽屏适配

崔红保

uni-app 前端

接口测试工具

测试人生路

接口文档 接口测试

最近程序员频繁被抓,如何避免面向监狱编程!?

Java架构师迁哥

如何生成 Flink 作业的交互式火焰图?

Apache Flink

flink

来自阿里面试官的Java面试连珠炮,让你自由发挥你能撑到哪一步?

Java架构之路

Java 程序员 架构 面试 编程语言

搜狗搜索或成为企鹅号流量入口:腾讯欲实现自己的流量闭环

石头IT视角

程序员不愿意说的秘密!Java进阶架构师必看:架构完美设计+程序员三门课+架构修炼之道

Java架构追梦

求职时这样回答问题你就输了!来自IT类面试官视角的深度解读

华为云开发者社区

面试 软件开发

【JSRC小课堂】Web安全专题(一)认证缺失和认证缺陷漏洞

京东科技开发者

WEB安全

WebSocket-技术专题-服务器端消息推送

李浩宇/Alex

小程序云开发实战:从0搭建科技爱好者周刊小程序

薛定喵君

微信小程序 小程序云开发 云开发

API生态的发展与机遇:从5000组数据看中国API生态与开发者现状

华为云开发者社区

华为 API

30 岁的码农人生 ——人生至暗时,你依然能窥见光明

cxuan

程序员 程序人生 感悟

以A.I.之力打破方言沟通障碍 科大讯飞重磅发布智慧翻译系统

Talk A.I.

个人计算机、工作站、服务器的主要区别

德胜网络-阳

10 张图打开 CPU 缓存一致性的大门

小林coding

缓存 cpu 操作系统 计算机

你有时间吗?

池建强

时间

开源中间件技术学习路线

开源中间件技术学习路线

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