写点什么

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

  • 2019-10-24
  • 本文字数:2174 字

    阅读完需:约 7 分钟

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

引子

在一次 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:002046

评论

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

【PHP】thinkPHP6中的MVC思想的小案例

Geek_Angel

php mvc thinkphp6

文心一言 VS 讯飞星火 VS chatgpt (157)-- 算法导论12.3 4题

福大大架构师每日一题

福大大架构师每日一题

IoTDB 企业版 v1.3.0 发布 | 新增内生机器学习框架 AINode、权限模块全面升级等内容

Apache IoTDB

建立海外SD-WAN专线网络的成本分析

Ogcloud

网络 SD-WAN 组网

开源大侠请留步!您有一份开源集市攻略!

开放原子开源基金会

Java 开源 程序员 开发者 算法

3D渲染买显卡还是用云渲染?3D渲染卡慢

3DCAT实时渲染

云渲染 实时云渲染

有OpenHarmony技术问题,上Laval社区

极客天地

软件开发

Geek_8da502

SD-WAN实现MPLS成本降低

Ogcloud

网络 SD-WAN MPLS 专线网络

诚邀报名 | AI 向量、云原生、开源,今年的数据库热点技术都在这里

开放原子开源基金会

Java 开源 程序员 开发者 算法

TikTok跨境直播:SD-WAN解决方案的优势解析

Ogcloud

网络 SD-WAN 组网 TikTok

软件对于企业的关键价值点在哪里?

天津汇柏科技有限公司

软件

图说技术:我的技术文章配图实践经验

Java 工程师蔡姬

技术人 21 天技术人写作行动营

MacCleaner 3 Pro中文激活:Mac电脑强大的清理优化软件

胖墩儿不胖y

优化软件 Mac软件推荐 系统优化工具

Flink Forward Asia 2023 主会场精彩回顾

Apache Flink

大数据 flink 实时计算

流计算迎来代际变革:流式湖仓 Flink + Paimon 加速落地、Flink CDC 重磅升级

Apache Flink

大数据 flink 实时计算

2023年中国游戏产业年会:鸿蒙全链路赋能游戏产业可持续发展

新消费日报

诚邀报名 | 技术创新,照见未来——共建OpenHarmony,共赴开源世界

开放原子开源基金会

Java 开源 程序员 开发者 算法

多家高校设立“鸿蒙班”;ChatGPT 成为 Nature 年度十大人物丨 RTE 开发者日报 Vol.107

声网

单口千兆以太网物理层芯片

芯动大师

一文详解 BRC20 衍生品协议 Bitcat,铭文市场长期发展的助推器

鳄鱼视界

OpenHarmony创新赛圆满收官:引领开源趋势,开启创新技术新纪元

新消费日报

福利「Flink Forward Asia 2023 」PPT 阅读合集!

Apache Flink

大数据 flink 实时计算

如何使用 NFTScan NFT API 在 Viction 网络上开发 Web3 应用

NFT Research

NFT NFT\ NFTScan

Vue 2 即将停止更新

南城FE

JavaScript Vue 前端开发

Cilium CNI深度指南

俞凡

Kubernetes 云原生 网络 通信

技术选型中的非技术因素:以数据库为例_数据库_贾世闻_InfoQ精选文章