2024最后吐个槽
数据库管理-第276期 2024最后吐个槽(20241227)
作者:胖头鱼的鱼缸(尹海文)
Oracle ACE Pro: Database
PostgreSQL ACE Partner10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP,ITPUB认证专家,数盟会长老会成员,OCM讲师
PolarDB开源社区、青学会MOP社区技术顾问
HaloDB外聘技术顾问
OceanBase观察团成员
IF社区联合发起人
圈内拥有“总监”称号,非著名社恐(社交恐怖分子)公众号:胖头鱼的鱼缸
CSDN:胖头鱼的鱼缸(尹海文)
墨天轮:胖头鱼的鱼缸
ITPUB:yhw1809。
除授权转载并标明出处外,均为“非法”抄袭
最近又接触到了一些和数据库相关的一些事情,感触良多,忍不住吐槽,默认都和本人实际工作没有关系,请身边人仔细鉴别。
1 换数据库简单
一个朋友跟我说,他的客户是如是说的(经过加工和总结):
数据库都一样的嘛,买来安装上数据弄过去就可以换了,很简单嘛
今天恰巧我的一个客户跟我聊天时候说到“当年从HP小机11g迁移升级到Exadata X8的19c上我们都搞了大半年才弄顺畅,相同产品的不同版本尚且如此,换数据库的难度可想而知”(如果大家有兴趣可以去翻翻我古早的文章)。当初我这里算是最早吃螃蟹的(上19c),众所周知,Oracle 19c初期版本BUG多的出奇,而我又踩了很多BUG,其实如果我缓缓上19c可能真还没那么多问题。
其实我还想补充一点,那次迁移并没有遇到换数据库最大的问题:应用改造,这里我重新总结(科普)一下,为什么即便是兼容性高的发指的数据库,都需要耗费较多的成本进行应用改造:
数据类型支持的区别:不同的存储引擎、数据库设计、数据库限制等能支撑的数据类型、数据类型的长度、表宽度等都是可能存在不同的 底层存储不同:比如常见的B-Tree、Heap、LSM Tree等,不同的底层存储的注意事项、性能表现、硬件需求、硬件利用效率都是不相同的 优化器的区别:很多时候,不同的数据库即便是支持在相同数据下可以运行一样的SQL,也会因优化器的能力表现出不同的性能,这些都是需要进行调整的 数据库架构的不同:集中式向分布式(分片)数据库转换;存算分离和存算一体的区别(这些都是老生常谈了) 语句方言:不同的数据库是带着很多独特的语句的,有些语句的实现不是那么简单的 等等
2 加节点就好
这也是一个朋友跟我说的(经过加工和总结):
多整点服务器,扩充集群节点数量性能就一定好
还是总结(科普)一下:
任何集群节点越多需要管理维护服务器和组件就会相应增加 内存本身的延迟是100ns左右,网络都是ms往上,节点多了网络带来的传输性能开销是非常可观的 如果节点多到一定程度或者规划原因需要跨网段、跨交换机,那么网络可能带来的波动和延迟会更大
当然还有一个和节点相关的论调:
集群就该奇数节点,偶数节点都是有问题的
集群偶数节点最容易出现的问题就是脑裂,比如四个节点1、2节点和3、4节点相互中断但1、2节点间和3、4节点间又能通信,全局投票就会出现2:2的现象,谁也不服谁,都觉得自己该存活,因此会造成全局不一致。这也是一些数据库的建议中使用奇数节点的原因之一。
当然数据库集群架构已经发展了这么多年了,可在偶数节点上解决这一问题当方案简直多了去了:
节点权重:不同节点权重不同,全局不可能出现投票同分现象 多网络:在生产、传输网络之外,增加用于管理的网络 仲裁节点:在数据库节点外增加独立的仲裁节点 存储仲裁:在存算分离架构中,使用存储替代网络进行投票和探活 等等
当然上面几种方案组合使用效果更加,但是对于集群自身管理而言也是一种挑战。
3 慢就一定有问题
还是朋友跟我说的(经过加工和总结):
SQL运行时间长的就一定有问题
等等,这是不考虑数据量、SQL复杂度、业务场景要求等一系列因素啦。数据量越大需要的数据IO越多,耗时自然会更多;SQL越复杂需要关联处理的数据越多,时间越长也是情理之中;如果是OLAP的业务,那么大多数时效性要求也没那么高…
但是不得不说,如果本着精益求精的态度去优化这些语句,节省的可不只是时间,还有相应的各类资源损耗。
总结
2024年最后一次集中吐槽了,希望大家喜欢。
老规矩,不知道写了些啥。