临时工访谈：腾讯“退休”的架构师怎么看数据库 和 DBA 在项目中的重要性

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2380人左右 1 + 2 + 3 + 4 +5 + 6） 新人奖直接分配到6群。现需要达梦的技术老师，群里最近经常有达梦的问题。另 starrokcs 的技术老师已经入群，有starRocks 的需求可以解决。

临时工这两个礼拜没有访谈的文章出现，主要是在忙工作最近事情很多，一个人写文章，管理群，回答问题，还有7月份的活动，一把年纪的人了，有人已经建议我差不多得了，身体重要，在每个打工人的心里，都有一个不变的期望，退休。

周六日，到北京继续干了点事情，期间又听到某国产数据库与大型企业的替换数据库的事情，这也属于国情下历史的必然，其中的摩擦和矛盾也是必然，静观其变吧。

今天我们就访谈一位，从腾讯退下来的架构师（业务），现在在某知名的大银行里面继续着自己的工作，我们也共事过一段时间，他给我的感觉是沉稳，干练，有自己的主意，最主要的是人非常的“荷花”，出淤泥而不染的一种性格，非常有人格的魅力。

之前我的一些架构的知识，也是从他哪里讨教的，最近大环境都不好，偶然聊起来，所以想访谈一下，从业务架构师的角度来看数据库和DBA这个职业是怎样的定义。

访谈开始：这里我们称他为架构师

临时工：Hello,最近怎么样，银行应该还算稳定，外面的工作环境是越来越差了，我这熬着呢！

架构师：还行，不过我这也感受到了一些大环境的压力，我们这里也开始 XXXXXXXXXXX ，可能也XXXXXX, 也熬着呢！（基于特殊原因，部分内容不能播放）

临时工：也想到了，都会传导的，只是早晚的问题，都逃不过去。最近我搞了一个访谈的节目，与数据库有关，想访谈一下关于架构师怎么看数据库和DBA的故事，想看看架构师的角度是怎么理解现在的数据库和DBA这个工种的。

架构师：我这边现在在银行里面工作比较的规范化，接触新的一些东西有限，可能见解不是很全面或有过时的情况，我看还是算了吧 ！

临时工: 是这样的，我个人对于架构师的理解是，在一个项目中架构师也是分类的，有的架构师是以技术为主导的架构师，有的架构师是业务为主技术为辅，成本核算附带的综合类的架构师，设计上后者这样的类型的架构师是，架构师，项目成本核算，项目经理的部分工作合并的一种综合类的架构师，我这样想有没有问题，如果是后者的话，其实我看没有什么过时不过时一说，数据库技术在新，DBA的能力再强，也在项目里，也在架构师的管控或挟制中，你说对吗？

架构师：话不能这么说，只是工种的不一样，工作的角度不一样，负担的责任不一样，汇报的领导不一样，其他都是一样，都是打工人。要说对于数据库的开发，我这可能是不完全，单纯的我个人的看法，也代表不了一个群体，哪里说的如果不对，可以给我纠正哈! 另外我也仅仅是在一些项目里面负责，主导，也是一个大头兵，千万别把我标榜成架构师，担当不起呀

临时工：你还是那么的沉稳和老练，谦虚。

架构师：从我的浅薄的工作经验和工作的项目中积累的经验，我认为数据库从本质上，提供了存储领域的专业性服务，让程序员可以，以很低的心智负担和学习成本完成大部分业务逻辑，开发无需考虑数据落盘的复杂问题，是广大CRUD程序员的保命神器。而DBA就是这个保命神器出问题时的救命稻草，DBA更像老中医，吃经验，必须一针救命，不能胡乱尝试。程序员的价值在于业务，而DBA的价值在于保持系统稳定，所以程序员躺不平，因为业务一直在变，但DBA应该可以。

临时工：之前有一库传三代了，现在也不行了库的种类多了，要求掌握的知识层次在不断的拔高，卷的厉害。

架构师：是的，说实话，由于所在行业限制，很久没有跟进数据库的动态了，不过感觉数据库正在为程序员提供更高层次的抽象，关系型数据库让程序员把数据抽象成一个个扁平的表，文档型数据库直接抽象成层层嵌套的对象，图数据库可以直接把一个图放进数据库，ES把倒排索引放进了数据库，当然还有Redis提供了各种通用数据结构。这些其实都是在抢夺应用的地盘，我们可以把数据库想象成一个微服务，随着这个微服务现在可以提供的功能越来越丰富，应用层的开发效率就可以越来越高。当然这种垂直化的趋势肯定会有个限度，至少需要那个垂直领域的细分市场需求可以养活这些产品，否则就会陷入拿着锤子找不到钉子的尴尬。所以最关键还是找到一个足够大且竞争小的垂直细分领域。去年我们公司调研实时金融市场数据的存储方案，调研了一系列时序数据库如timescaledb，Clickhouse等，最终胜出者竟然是小众的KDB，一个20多年前写的单机数据库，功能简单，但是非常符合金融行业的需求。

注解：KDB是一种高性能的时序数据库（Time-Series Database），最初由KX Systems开发。KDB具有极快的处理速度和高度优化的存储结构，特别适用于处理大规模实时数据流和时序数据。KDB数据库专注于高速读写操作，适合在金融领域和其他需要高性能数据处理的行业中使用。它使用一种基于列的存储结构，能够快速执行聚合、过滤、排序和分析等操作，因此在处理大量时间序列数据时非常高效。KDB数据库通常与一种名为q的查询语言一起使用，这种语言专门为处理时间序列数据而设计，对时间序列数据进行分组、聚合等操作非常方便。KDB的高性能和优化设计使其成为许多金融机构、量化交易公司和其他行业的首选数据库之一。

临时工：我想问一下，为什么最终的结果是 KDB。

架构师：KDB 实际上是一个无事务，内存应用化的数据库，可能他更像一个应用。

临时工：说到这里，那对于NOSQL数据库产品你怎么看呢？

架构师：如上面我对传统数据库的开发类似，NoSQL数据库，图等新型数据库提供了针对细分领域的标准化解决方案。但是他并不是传统数据库的替代者，他们抢的是应用的地盘，而不是传统数据库的地盘。新型数据库的另一个问题是刚需太少，很多情况下应用在内存里也可以实现类似的数据结构，只要在落盘时存到关系型数据库即可。还有就是大公司的评审流程，引入一个新的db需要设计者去证明为什么必须用到这个数据库，这点其实很容易被challenge。

临时工：明白，数据库的种类越多的情况下，一个项目维护的成本也就越高，从架构师的角度看也就是说，倘若这个项目里面必须要引入一个新的数据库产品，是要说清楚原因以及必要性的，更多的情况下，菲关系数据库是在和应用来抢夺份额，而不是和传统数据库来抢夺份额。不过从我一个数据库从业者的角度，NoSQL，图，以及时序数据库，是在分割更细维度的传统数据库运作空间，反正是卷的厉害。以前我只是站在自己的职业角度看这个事情，今天又得到了新的角度看这个问题。这里我还有一个问题，针对DBA怎么理解架构师的工作，架构师的工作职责，或者架构师是否是决定一个项目成败的关键？

架构师：架构师不能决定一个项目的成败，我们也只是这个项目里面的螺丝钉，但从架构师的角度，首先我要说一句废话，决定设计成败的最重要因素毫无疑问就是对业务需求的理解，哪怕是infrastructure项目也得先搞明白要做的是什么。这里经验就很重要，如果一个人参与过类似业务需求的开发或使用，能极大的提高对业务的理解。然后就是学习，读书，读文档。反正我属于抽象思维不太好的人，很多事情必须做过才能深刻理解，没做过的东西哪怕看10遍也记不住。

大家都说CRUD程序员就像是流水线工人，其实架构师又何尝不是呢，各种大而全的框架，各种功能的中间件和数据库，从技术上讲架构师就是拼搭积木而已。只要业务需求不过分变态，性能，可靠性，安全性都不会有太大问题。唯一需要做的就是tradeoff，在开发效率，维护成本间做权衡

我现在公司的架构理念是杜绝过度设计，能自己写绝不用library，能用library绝不用中间件，能单体绝不弄微服务，能用java绝不用其他语言：） 我们的一切目的就是减少内/外部依赖，减少自身复杂度，用java这种繁琐但契约性强的语言保证代码的可维护性。因为我们的目标是代码写完后自己维护10年，不想过几年某个library没人维护后重新这个逻辑，也不想引入的spring有cve导致整个项目被flag。

临时工：我有点明白，又不明白，我理解是，不做屎上雕花的事情，首先既要避免堆屎。

架构师：差不多是这个意思。举一个例子，为什么时序性的数据库我们最终选择的是KDB，不是其他的数据库产品，这和我们的业务强相关，我们的需求主要是做intraday数据的查询，只有当天的数据在kdb中，所以纯内存是可以接受的，t-1的数据会进入历史库，查询性能就不是考虑的关键了。但KDB 简单在这个项目里面完全可以Hold住，所以没有必要炫技。

临时工：只选合适的，不选夺人眼球的，一个技术哪怕很老，据我所知KDB有20年了历史了，所以考虑的角度不同，就会得出一个不一样的架构，或者从架构的设计就能理解这个架构师或者这个公司的一些处事风格。

架构师：或许吧，反正简约但不简单，是我做事的风格。

临时工：感谢，感谢你的时间，让我有学习了一些新的考虑事情的方法，我一直觉得如果DBA光在自己的三分地，考虑的问题比较狭隘，终究数据库是要给业务使用的，更多的理解业务以及业务架构对于数据库应用的一些想法，看法可以从广角来看待问题和处理问题。感谢。我这边可以贴你的微信号，如果有架构方面的问题，有缘的人也可以加你微信讨教一二。

架构师：不了，我好静，感谢。

临时工说：炮轰阿里云MongoDB司令部 低质高价技术差 你是要疯！！！！

临时工说：DBA转售前，练习怎么写数据库客户案例

PolarDB VS PostgreSQL  "云上"性能与成本评测 -- PolarDB 比PostgreSQL 好？

PostgreSQL 版本升级到PG14后，pgbouncer 无法使用怎么回事？

临时工访谈：NoSQL 大有前景，MongoDB DBA 被裁员后谋求新职位

临时工访谈：问金融软件开发总监  哪些业务不用传统数据库

PolarDB for PostgreSQL  有意思吗？有意思呀

PolarDB  Serverless POC测试中有没有坑与发现的疑问

PolarDB 数据库架构 测试 serverless 后的 三字真言  稳定，灵活，省钱（的用对地方）

临时工说：如果DBA大龄被裁员了怎么办？

临时工访谈：DBA 考PMP 有用没有用，访谈专业的项目管理人士的意见

MySQL 的SQL引擎很差吗？由一个同学提出问题引出的实验

临时工访谈：从国产数据库 到 普罗大众的产品 ！与在美国创业软件公司老板对话

PostgreSQL 如何通过工具来分析PG 内存泄露

MySQL 的SQL引擎很差吗？由一个同学提出问题引出的实验

临时工访谈：我很普通，但我也有生存的权利，大龄程序员 求职贴

PolarDB  Serverless POC测试中有没有坑与发现的疑问

临时工访谈：PolarDB  Serverless  发现“大”问题了  之 灭妖记 续集

临时工访谈：庙小妖风大-PolarDB 组团镇妖 之 他们是第一

临时工说: 快速识别 “海洋贝壳类” 数据库方法速递

临时工说：国产 数据库 销售人员  图鉴

MongoDB 不是软柿子，想替换就替换

PostgreSQL PG_DUMP 工作失败了怎么回事及如何处理

MySQL 八怪（高老师）现场解决问题实录

PostgreSQL 为什么也不建议 RR隔离级别，MySQL别笑

临时工访谈：OceanBase上海开大会，我们四个开小会 OB 国产数据库破局者

MongoDB 2023纽约 MongoDB 大会 -- 我们怎么做的新一代引擎 SBE

Mongodb 7.0双擎力量（译）