数据库管理-第四十五期 又一期杂谈（20221125）

第四十五期 又一期杂谈

上周不是被封在客户现场了么，在行军床上睡了几天，着实不舒服，还有一点腿麻，去找医生看了看，又腰突了，果断正骨弄回去了。愿疫情早日过去吧，别再折腾了。
这周感觉也没做啥事，到年底了，又是一大堆材料需要整，我这边的某客户一周还变动了N多次要求，搞得材料都改了快十版了。愿天下甲方都仁慈一些吧。
这周也没啥精力写一些技术相关的内容，其实还有不知道写啥，还有就是最近两周也没推进啥具体的东西，所以还是扯淡一起把。

1 到底需不需要DBA

其实不要DBA的说法由来已久，毕竟养一个合格的DBA并不便宜。DBA其实和大多数运维岗是一样的，DBA的工作往往是防患于未然，确保数据库稳定运行，至于高效不高效反而不是重要指标，不挂才是最重要的，这也导致了很多DBA的工作看起来没有啥效果。
而公有云时代的到来，数据库大多直接托管在云厂商那，对于数据库运行健康啊、高可用这些其实自己可以不用管，唱衰DBA的论调也甚嚣尘上。但事实确实如此么，首先不讨论公有云上的数据安全问题，其实数据库运行过程中出现的性能问题，还是需要DBA来排查问题的，毕竟执行计划并不是所有人都能看懂并分析出结果（有时候甚至还要因此和云厂商撕逼），业务场景带来的其他问题也不是云厂商能一站式解决的，无论云上云下都是如此。
随着公有云数据库价格不断上涨，采购云数据库的性价比也越来越低，甚至远不如买云主机自己建库划算了，现在坚持公有云的地方甚至出现在云厂商采购裸金属服务器跑数据库的方案来降本增效。而这又回到了DBA的工作中。

2 数据库跑分

其实跑分这个东西广泛存在于各行各业，比如手机性能的安兔兔跑分、相机的DXOMark、显卡的3DMark、CPU的CINEBENCH等等。就拿显卡为例做个对比，3DMark主要是对显卡基准光栅性能的测试跑分，对比上一代提升也许是100%，而在实际游戏表现中又因为使用了其他技术实际表现提升了200%有余。当然也有可能在对比友商产品的时候，跑分有一定提升，但是实际游戏表现又因为驱动、兼容性等问题出现造成性能低下。
现在越来越多的数据库在强调自己的跑分能力有多强，各种TPC-C、TPC-H、sysbench等测试分数，经常性刷新国际友商尘封近10年的记录。然而当使用的时候却又发现实际性能表现又没有达到跑分应有的水平且极其不稳定。造成这一现象的原因无外乎这几个：1.跑分软件模拟的应用场景往往都是十分“完美”的，而实际生产跑的东西实际都是乱糟糟且参差不齐的；2.因为第一点，乐于跑分的数据库往往会针对“完美”的应用场景进行一系列优化（当然这个是不可能承认的）；3.其实这些数据库在实际生产中也不是跑不出该有的成绩，和前面说的显卡一样，每一种数据库都有自己擅长的东西和使用方法，然而很多时候为了宣传营销，营造出无需改造即可使用的数据库“人设”限制了数据库性能的发挥（类似于显卡那说的驱动、兼容性问题），而为了适配新的数据库，应用侧的改造才是最大的投入。

3 一体机

最近看到国内也开始指定数据库一体机的标准，其实我觉得就硬件而言也没啥标准可言，全用最好的就行：最强的CPU、超大的内存、PCIe 5.0 NVMe SSD、100GE以上的RoCE网络等等。
但是我想说的是，就Oracle而言，其实国内也有不少厂商推出了自己的一体机产品，其硬件规格大多数都远高于Exadata，但是为啥跑不过Exadata差距还不小？我认为软硬件匹配与融合才是更重要的，这一点可以类比一下Android和iOS。

总结

老规矩，不知道写了些啥。