数据库管理-第170期 那些被错误需求带偏的数据库理念（20240410）

数据库管理-第170期 那些被错误需求带偏的数据库理念（20240410）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Associate: Database（Oracle与MySQL）
国内某科技公司 DBA总监
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家、年度墨力之星，ITPUB认证专家，OCM讲师
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭。

首先，没想到昨天那篇《震惊，ACE装国产数据库花了两周》火了（果然还是“震惊体”好用啊），今天在换个角度在看看其他的东西。
在之前的文章，我提到过，很多国产数据库在卷那些莫名其妙的设计或者说叫理念抑或是观念，其实这些都是来自于错误的需求或者场景。本期将以我个人的观点，来理一理我认为的数据库圈内的错误需求。
手动保命+1：本期内容不涉及任何具体厂商和具体产品，请不要对号入座，如有巧合，纯属不幸。

1 延迟vs并发

之前在首席群里看到了一个观点：“分布式数据库就是用降低单个事务的处理能力来提升全局扛并发能力”。我就举一个栗子：早高峰鸭梨巨大的地铁站，原来是秒过闸机，在换上“上面这个理念的数据库”后，过闸效率从1s以下变成1s以上，就会造成过闸效率太慢，那么这种情况下即使有很多闸机也会出现大面积排队，要不排队就需要巨量的闸机数量，那么地铁站有那么大么？
回到这个观点本身，相信很多做分布式数据库的大佬也会反驳，虽然分布式数据库势必带来一些操作的时间增加，但是可以通过合理的分片关联设计、网络配置调整、关键业务拆封等方式来尽可能减少甚至消除这种操作延迟。那么从一开始对分布式数据库错误的理解就造成了对分布式数据库错误的观念进而可能影响数据库的设计与使用。

2 TPvsAP

其实现在很多场景OL到底是Online还是Offline的界限越来越模糊了，也听到过一些人说，现在数据库的TP能力已经到了极限，往后数据库应该轻TP重AP。这种理念在有些少写多读的场景下确实是一种不错的选择，但是数据库作为一个通用产品还是应该去考虑那种多写少读、甚至是多读多写偏向于HTAP的场景。我认为对于一个数据库来说，TP和AP性能都是需要考量的内容，而且结合内核算法、存储设备、网络环境等的进步，配合合理的业务设计TP性能还是可以有很大的上升空间的。当然，让一个或者多个数据库专门跑TP，同步到另一个或者多个数据库跑AP，也不是不可以，这个就看团队和资金能力了。

3 实时vs批量

这是一个在运营商计费场景关于数据库使用的理念，也就是业务怎么去设计，众所周知现在的运营商计费系统是实时的，客户查询套餐用量和余额的结果机会就是查询时间点的实际情况。之前听说有人质疑这种业务设计，认为运营商计费不需要实时落库，可以通过定时分批记录的方式来降低数据库的TP能力需求（这里和上一节有一丢丢交叉）。
还是回到业务需求本身，举个例子：如果按照10分钟粒度刷新数据，在这个时间点我话费只有1元，流量刚好用完，业务记录到数据库我的话费1元，流量为0；然后我开始刷抖音（流量包外的流量费用大家DDDD），没有实时提醒我充值；在10分钟后，我有一个特别重要的业务电话需要打，结果发现欠费了充值又得等到下个10分钟（当然也业务可以设置充值后触发刷新），总之花了几分钟时间，成功错失重大商务机会，这种情况下该去找运营商追责么？换到运营商角度，会给客户有白嫖10分钟的机会么。运营商的场景其实还算相对宽松的，有些制造业的数据录入是不允许有一丝丝延迟的，机器停工带来的损失是不可估量的。

总结

隔行如隔山，很多时候错误的需求就来自于对对应行业的不了解，这种错误的需求评估就会给数据库带去错误的设计、理念或观念。
老规矩，不知道写了些啥。
最后的最后，再宣传一下，4月12-13日，我在DTC现场等你：