暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

从Bruce Momjian的什么时候不选择PG数据库谈起

白鳝的洞穴 2021-03-13
844
最近这两年总有朋友和我讨论我该如何选择数据库,以及某某数据库和ORACLE相比用那个更好,等等等等。实际上讨论这些问题挺累的,因为对使用什么数据库,仁者见仁,智者见智。每个人的立场与出发点不同,每个人面临的现状也不同,身后的压力也不同。因此每个人的观点都会有很大的差异。
昨天中午的时候,翻了翻PG社区创始人之一Bruce MomJian的BLOG,最近这老大也不怎么写技术方面的博客了,不过去年的一个博客的题目吸引了我。

为什么不选PG数据库。他列出了六种不选择PG数据库的场景。翻译下来是这样的:
  • 企业的主要技能都在其他数据库上,并没有强烈的愿望去学习PG;

  • 企业不想把在另一个数据库上编写的应用程序修改为支持PG的;

  • 开发人员使用了不支持Postgres的外部开发的应用程序、工具或框架

  • 在非交易型数据或者内存缓冲数据,可能导致PG无法负载的情况;

  • 在多个主机上并行运行的十分简单的查询,这种场景NoSQL数据库具有十分明显的优势;

  • 小型单用户系统,可以选择SQLite这样的轻量级数据库。

大家有没有发现,Bruce的这六条不选择PG的原则里并无太多技术相关的因素,绝大多数是从企业自身特点和应用场景去考虑问题的。实际上目前普通企业使用的数据库,超过90%的场景是使用通用数据库。而不同的通用数据库的主要差异是在部分语法、并发能力与性能上的,并不是存在技术鸿沟的。企业选择使用哪种数据库可以根据自己的应用场景与企业自身的情况去综合分析,做出决策。
前阵子有个朋友和我讨论他们的一个数据库想从ORACLE上迁移下来,是选择分布式数据库好还是普通的交易型数据库好。我问他数据量有多大,他说大概未来会有30T左右。30T的数据库确实需要有些这样的考虑了。于是我问他30T数据中有多少是热数据,多少是活跃数据,多少是冷数据。他搞不清楚这些数据之间的关系,于是我解释了一下这三种数据,他仔细考虑了一下,说大概最常用的数据是最近一个月的数据和一些配置数据、字典数据,这些数据大概不到1TB。最近三个月的数据有可能会有一些变更,三个月前的数据基本上没有变更了。最近一年的数据偶尔会有人查询,大概5TB左右,其他数据都是很少访问的日志数据和历史数据,主要是为了今后审计使用的,其中日志类的数据插入后基本上不变化,也很少使用,但是又不能删除,必须长期保存。
通过这么一分析,这个问题其实是十分简单了,以前在ORACLE数据库上,管理30TB的数据库不是啥很麻烦的事,只是备份恢复的时间长了一点,在使用中并无太大的困难。从ORACLE上迁移到其他数据库的时候就担心普通的单节点的数据库是否能够支撑,于是有了选择分布式数据库的想法。不过这个案例实际上也很简单,1年后的历史数据很少使用,那么建设一个只读的历史库是十分必要的,这个只读库哪怕出问题也不影响生产库的运行,因此备份频率和备份策略也比较灵活。瘦身后的生产库只有几个TB,基本上目前大多数的开源数据库与国产数据库都可以支撑,根本不需要上分布式数据库。
其实分布数据库也不是万用良药,其应用适配、性能优化、数据备份恢复以及日常运维都比普通的单机数据库要复杂的多。中小企业在选择的时候还是需要慎重考虑的。大多数应用场景采用单机数据库,再加上读写分离,高可用集群的方案都可以支撑。这些环境的运维难度肯定都远低于较为大型的分布式数据库集群。
老白并不是反对使用分布式数据库,而是和Bruce的数据库选择理念有一些同感,数据库的选择一定是根据企业的特点、运维能力以及应用场景的综合考虑的结果。有些情况需要使用分布式OLTP数据库,有些场景可能用HBASE就可以了,而有些场景可能需要分布式的OLAP数据库。一个数据库包打天下连ORACLE都做不到,我们怎么能保证某个数据库就一定能做到呢?现在国内做数据库研发的企业至少有300多家,大家好像提出的口号都是秒杀ORACLE,可以包打天下,对于这一点老白是不太相信的。我觉得,我们的国产数据库抓住兼容性,稳定性,再具有一定的特色,针对某些特殊场景的支持,就已经十分难能可贵了,没必要事事都追求高大上的完美。研发成本与数据库的功能与实力还是成正比的。
几年前一个客户让老白帮助选择一款分布式数据库,用于企业的一些物联网应用,同时作为一个多租户的云数据库提供给不同的小应用使用。我们帮他们对国内的分布式数据库做了一定的分析评估与测试,最后选择了一个他们认为最优的方案,开始迁移应用。一年后他们发现多租户的大型分布式数据库在管理上的特点与他们比较灵活的物联网应用之间并不融洽。他们的物联网应用往往是一些十分小型的,相对独立的小系统。在线数据也顶多只保留3个月,历史数据全部进入数据中台集中存放了。经过一年的实践他们发现使用K8S+mysql的方案更为适合他们的应用场景。这些小数据库规模类似,负载不高,十分适合在容器云上部署,通过测试,他们确定了容器云上的mysql小数据库才是他们真正需要的。
今天讨论的话题有点发散,不过还有一点发散的问题我还是想说一说。那就是国产或者开源数据库你能否替代ORACLE的问题。实际上,这也是一个伪命题,Oracle并没有100%的占有市场,这已经说明了,Oracle肯定是可以替代的。关键是你用什么代价去替代,你怎么替代的问题。前些年参与了一些企业的数据库国产化的策略研究,有一个十分典型的案例,最后制定的策略是。原有的Oracle数据库因为应用改造的问题,暂时不替代,但是必须通过数据库整合减少实例数量,从而减少Oracle RENEW的成本,腾退的部分许可证给一些必须使用Oracle的应用扩容使用,并暂停所有新购Oracle等国外商用数据库的计划;新建系统的数据库尽可能使用不用额外花钱购买的企业私有云上的开源数据库;对于有国密与安全等保要求的数据库使用符合标准的国产数据库。这是一条较为务实的数据库国产化演进路线,数据库国产化替代不是一场大跃进运动,也不是一场花钱的新盛宴,而是要从可行性、成本、企业整体IT技术策略等方面进行综合考虑,在厉行节约的前提下有计划的进行。
文章转载自白鳝的洞穴,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论