本文主要讨论数据库本地化数据库的策略和选择。今天的文章比较长，有5000多字。建议大家先收藏起来，再慢慢看。自从2019年华为事件后，就有公司跟我讨论数据库替换的国产化问题。我也参与了一些数据库本地化程序的编写。然而这些年，我所见的数据库本地化，似乎有些雷雨交加。大家都很关注，领导也足够重视。计划做了一遍又一遍，但动作其实不大。这与前几年的去IOE浪潮形成鲜明对比。当时大家从疑惑到试用和大规模应用。不过，同样的犹豫期要短得多。小规模试验结束后，大规模应用随之而来。来。这一次，数据库本地化的进展似乎没有那么快了。想想，这也很正常。去IOE给企业带来明显的省钱效益。它用市场上采购周期非常短的相对稳定和便宜的X86替代价格昂贵、采购周期长的小型机，并且使用免费的开源数据库可以替代Oracle，可以大大降低企业IT的成本。数据库本地化的更换并不是那么简单。虽然这项工作涉及到信息化的基础安全，但当特殊的威胁没有立即发生在我身上时，我总能感受到数据库替换本地化的效果。性价比不是很划算，所以领导总说这是大事，但到了行动上却只是表面现象，这是很正常的事情。然而，形势比人强。随着国际形势的变化，信息系统国产化的势头越来越强。目前退缩的企业也承受着越来越大的压力。很多企业都设定了2027年底实现置换的目标，那么大规模的置换工作最迟要在明年开始。数据库本地化的替代解决方案不可能总是处于示范阶段，而是真正即将实施。其实，如果真的要做这个，选择方案并不难，也不必经过严格的考虑，避免出错。有时候你想了很久，但最后的选择未必是最好的。好的。而我的观点是，你可能选错了数据库，但你的数据库本地化路径不会出错，你会在不断修正的过程中不断完善方案。当90年代甲骨文数据库一统天下，取代了各种数据库产品的时候，大多数公司并没有制定非常详细的计划，而是一点一点地实施。而且当时的Oracle数据库还没有这么好的口碑，在人们眼里也不是一个不能错的产品。很多公司不愿意用Oracle，发现Oracle很好。未来所有的信息系统都将使用Oracle。最后，企业中的其他数据库产品在系统升级过程中逐渐被Oracle取代。我有一个客户在20年开始准备数据库本地化替换。首先选择了国内的分布式数据库，迁移了一个小系统。在迁移过程中，发现研发投入、线上运维等方面存在诸多问题。21年根据上级单位要求，进行了OA系统的本地化迁移，选择了OA系统支持的集中式数据库。发现整个迁移工作顺畅了许多，迁移成本也比第一个项目低。于是他们决定在几个新的项目中尝试使用这个集中式数据库产品，进一步积累经验。我觉得对于大多数公司来说，这种小步走，不断修正的方法成本最低，也比较容易成功。在积累了足够的迁移经验后，进行大规模迁移应该不会太困难。有些企业IT规模大，特别怕试错，所以总是希望在行动之前做好规划，先做好规划，然后全力推进。但是，我总觉得这类方案的可靠性指标往往较低，“专家”提出的方案未必是正确的，不适合企业的现状。就像看到猪在奔跑一样，很难想象红烧肉的味道。仅仅制定计划而不去尝试是不够的。可能有的朋友会觉得，不谈技术，只谈决心，只谈数据库本地化的技术问题，未免太理想化了。数据库更换这个难题，下定决心就能解决吗？其实，要说数据库本地化工作的成败，首先不是技术问题，而是决心。只要下定决心，就可以做到。当然，光有决心是不够的，还需要充分考虑技术问题。今天的下半部分，我们将讨论技术问题，其中核心是数据库选型的问题。现在国内和开源的数据库数量庞大，种类繁多。怎么选择真的很头疼。很多朋友都很关心数据库选型的技术问题，但是我觉得数据库选型的技术问题以后可以放一边。因为数据库对应用系统的开发影响很大，所以数据库最忌讳的就是频繁更换。一旦选择完成，最好在五到十年内不要更换。所以在选择数据库的时候，要么选择比较活跃的开源社区，要么选择大厂产品。对于IT规模较大的企业，一些非常有特色的小厂产品可能在某些方面具有吸引力，但应谨慎对待。此时选择大型使用的关系型数据库一定要考虑长远，而对于一些特殊功能、使用范围小的数据库，可以选择一些中小企业的产品。对于数据库的选择，商业路线有两大选择：开源和商业。开源和商业数据库产品的选择一直争论不休。任何企业都无法拒绝开源数据库的诱惑。大量用户积累的免费授权、社区支持、应用运维经验，都是数据库换代非常稀缺的资源。因为开源数据库的代码是公开的，从开源代码中，你终于可以找到解决一些疑难问题的方法。因此，与代码封闭的商业数据库相比，开源数据库更容易形成良好的第三方服务生态。但是，一个开源数据库到底算国产数据库还是信创数据库的问题也困扰着很多企业。此外，开源数据库无法获得原厂的支持，因此缺乏底线支撑单位，这也让不少企业面临选择的困境。商用数据库正好相反，license是收费的，目前国内商用数据库的license是需要购买的，不像oracle那样可以并排玩。国内商业数据库的用户基数还不够大，第三方服务能力也很弱，远不及一些著名的开源数据库产品。但是，商业数据库背后有一个“原厂”，可以帮你一探究竟。只是“原厂”的底线覆盖能力因原厂规模和实力的不同而大相径庭。有人认为，数据库本地化永远不能简单地被开源数据库取代。我不太同意这一点。开源数据库已经被许多不同规模的公司证明，是甲骨文等数据库的良好替代品之一。由于开源社区的特点，大部分开源协议都保证这些数据库不会因为美国的进出口管制措施而影响您的使用。在使用最广泛的开源数据库——MySQL和Postgresql数据库方面，很多企业都获得了巨大的收益。如果企业研发能力强，应用系统已经微服务化，那么数据库可以拆分成更小的部分，MySQL是非常好的选择。MySQL的运维非常简单。在应用中对业务逻辑进行全面优化后，只要在MySQL的高可用架构上进行设计，平时的运维就非常简单了。偶尔，某个图书馆有问题。只需重启数据库实例或切换备库即可解决问题。如果企业的应用比较复杂，SQL经常有几个大表的关联查询，研发部门优化能力有限，那么Postgresql可能是你更好的选择。PG的优化器非常强大，可以解决大部分复杂查询的性能问题。PG的插件化结构也让你可以使用一些特殊的方法，甚至可以针对特殊的应用场景开发特殊的索引来解决一些开源版本无法解决的问题。目前国内很多数据库也都走上了开源之路，这些数据库也是本地化替代的不错选择。与美国主导社区的开源数据库产品相比，中国企业主导的开源数据库产品在极端情况下会更加安全。目前，PingCap的TiDB、蚂蚁的Oceanbase、华为的openGauss、阿里的PolarDB都形成了一定规模的开源生态。另外，其实国内很多数据库产品也是基于开源项目的。比如人大金仓KingBaseES、汉高HighoDB、优轩数据库等都是基于Postgresql开源项目。开源项目openGauss的源也是Postgresql9.2。MassiveG100、MogDB、神州通用数据库都是基于openGauss开源项目的闭源商业数据库。我和很多朋友讨论过这些基于开源项目的闭源商业国产数据库产品，认为这种shell本地化的产品不能算是真正的国产数据库。大家可能很难就这个问题达成一致。我还是比较赞成基于开源项目构建商业产品，因为这样可以大大降低研发成本，也可以利用开源社区的扩大，充分整合开源的资源社区。只要产品遵循开源协议，在不违反开源协议的情况下做闭源是没有问题的。当然，如果能像openGauss等国内开源项目一样，一方面脱离国外开源社区，一方面发布开源版本就更好了。如果一个数据库既有商业版又有开源版，既能解决企业大规模使用的成本问题，又能支撑企业的核心应用。这解决了更换许多大型企业数据库的一个大问题。除了商业路线，还有一个很重要的选择就是集中式数据库和分布式数据库。集中式数据库易于使用和操作，但不如分布式数据库具有可扩展性和高可用性。分布式数据库扩展性强，容错能力强，但结构复杂，运维复杂，一旦出现问题难以定位。两者的优缺点都很明显，真的很难取舍。其实还有第三条路线，就是亚马逊发明的Aurora。这种日志是数据库概念的产物，可以实现读写分离的强一致性。因此，在很多情况下，它被看作是一个非对称架构的分布式数据库。其实这是介于集中式数据库和分布式数据库之间的一种架构（其实OracleRAC也可以大致归为这种类型），今天我们把它作为第三种技术路线。集中式和分布式数据库的选择还是要看应用场景、应用目标和企业IT能力的积累。集中式数据库相对简单。对于应用的开发和运维，只要把高可用架构和主备数据库做好，可用性也是有保障的。在最坏的情况下，保证在30分钟内恢复应用程序。但是，还有一些对可靠性要求比较高的应用场景，比如股票交易、实时系统等，虽然这类系统在企业中的数量不是很多，但往往是最核心的。如果应用需要在分钟级恢复，那么分布式数据库在架构上更有优势。对于互联网交易、物联网应用等业务逻辑相对简单、数据写入高并发、数据输出规模大的场景，分布式数据库因其极高的可扩展性而更加适合。我觉得在一个企业中，很可能集中式数据库被广泛使用，中小型或者比较稳定的系统使用比较简单的集中式数据库，小部分需要极高可用性和高并发的系统使用分布式数据库。数据库可能是一种非常常见的形式因素。第三类数据库目前在国内数据库中比较少见。最典型的就是阿里的PolarDB-PG和PolarDB-O，都是基于Postgresql开源项目的非对称分布式架构数据库产品。通过底层多副本实现IO能力的扩展，通过读写分离集群实现有限水平扩展。事实上，目前国内大部分中心化时间数据库产品都可以开发出类似的衍生产品。了解到国内很多集中式数据库厂商都在开发类似OracleRAC的产品，而大梦的类RAC功能的数据库产品已经开始商用。不过，我还是觉得像PolarDB这样的非对称读写分离架构，对于大部分企业来说已经足够了。不仅可以通过读写分离分离最昂贵的读取负载，还可以实现亚分钟级的高可用故障转移，完全可以满足核心系统对高可用的需求。如果一款中心化数据库产品能够具备这种能力，在前端通过代理实现读取负载的自动卸载，那么对于大部分读取负载超过80%的管理信息系统来说，将彻底解决单机无法卸载的问题。被扩大。问题。集中式数据库供应商可以依靠这种能力与分布式数据库竞争核心业务市场。分布式数据库供应商也可以伸手到集中式数据库供应商的碗里。今年的OceanBase4.0大会给了数据库行业一个新的启示，分布式数据库也可以有新的玩法。OB4.0发布了单机数据库模式。对于一些企业来说，数据和业务的规模还没有达到需要分布式数据库的地步。可以先用一个单机版的OB，以后需要的时候可以方便的扩展。对于分布式数据库。这样，企业的大小数据库就可以使用同一个数据库产品，根据需要选择集中式或分布式。OB4.0发布的时候，一个数据库厂商的朋友看到??新闻跟我说：“这已经不好玩了，如果OB单机模式能达到标榜的性能，那这对降维来说是一个打击。”“up”。能不能降维不好说，因为要将一个分布式数据库架构的数据库产品，改造成一个单机的中心化数据库，性能媲美普通中心化数据库，不是一件容易的事。真实情况需要通过实际应用来证明，选库是一个非常复杂的过程，很难通过一些规则来量化，通过量化打分来完成选库看似科学，但实际上未必能使一个不错的选择。数据库的选择要根据企业的特点，不仅要看数据库本身的技术先进性，还要看企业本身的技术特点、技术能力，以及企业在数据库、科研上的投资比例。和开发等都会影响到数据库的选择。最终结果。今天时间有限，就不展开讨论了.如果您有兴趣，我将在以后讨论这个问题。最后说说数据库的对比测试和评估，这也是困扰企业数据库选型的一个问题。任何测试都不可能做到完全公平，因此通过测试来实现模型选择的公平性并不一定可能也没有必要。我们要做的就是选择的数据库能够真正满足我们日常的应用需求。以我的经验来看，BENCHMARK测试、TPCC之类的对于大部分企业的数据库选型意义不大。从简单的TPCC来看，20万个TPMC基本可以满足绝大部分企业的并发事务需求，但是像BENCHMARK这样简单的测试，无法衡量企业对复杂SQL的支持能力，大的意义不大。企业数据库替换测试中比较重要的测试项目有数据库兼容性测试、复杂SQL支持能力和性能测试、高可用性测试等，数据库兼容性测试主要是和Oracle对比，大部分企业都会进行大量的系统迁移从Oracle到国产数据库。兼容性意味着高或低的迁移成本。如果不修改少量代码，甚至不修改一行代码就可以实现应用的迁移，对于有数百个甚至上千个系统需要迁移的企业来说，可以节省大量的成本。在这方面，大梦才是真正的王者。从我们这些年做的迁移来看，大梦数据库和Oracle的语法兼容性是最好的。在这方面，国内商业数据库普遍优于开源数据库。海量G100、仁达金仓、OCEANBSE（Oracle兼容租户模式）等在SQL和PL/SQL与Oracle的兼容方面都做得很好。对于复杂的SQL测试，最好选择一些比较复杂的系统，比如ERP系统、SCM供应链管理系统等，这些系统的业务逻辑非常复杂，大量多张大表关联，并且存在输出大量数据的场景有很多。可以测试数据库产品对复杂SQL的处理能力和运行性能。如果一个数据库能够更好地支持这些应用，那么它的SQL能力完全可以满足你其他系统的需求。有朋友会说，如果用数据仓库的应用来测试，不是更能体现复杂SQL的能力吗？事实上，太多是不够的。OLAP不仅仅是SQL的问题，还需要宽表优化、列存储、索引优化等，这与OLTP系统中的复杂SQL不同。数据库本地化更换涉及的问题太多了，五六千字的文章我也赶不上。今天就说这么多吧。早上六点以后我开始写这篇文章。我边想边写的。需求相同，但观点不同，希望多多交流。以后我会抽空认真整理这篇文章，抽空发一个更好的版本。希望今天的文字能够对正在做这项工作或者正在思考这个问题的朋友有所帮助。
