「数据库」再聊聊数据库国产化代替

　　实践上，假如真的去做这件事，计划选型也并不是很难的作业，也并非有必要经过严厉的考虑才不会犯错的，有时分你考虑了好久，反而终究的挑选不见得最好。而我的观念是，或许会选错数据库可是你的数据库国产化路途不会走错，你会在不断的纠偏进程中不断的完善计划。

　　本文首要评论数据库国产化数据库中的战略，选型等方面的问题。今日的文章比较长，有5000多字，主张咱们先保藏再渐渐阅览。

　　从2019年华为作业产生开端，就不断有企业和我评论数据库国产化代替的作业。我也参加了一些数据库国产化计划的编写作业。不过这些年来，我看到的数据库国产化代替好像有点雷声大雨点小。咱们都挺注重，领导也够注重，计划做了一遍又一遍，可是动作实践上并不大。这和前些年的去IOE浪潮构成了显着的比照，那一次咱们也是从疑问到开端打听，到大规划运用，不过相似的犹疑期短了许多，一旦小规划打听完毕，大规划运用随之而来。这回的数据库国产化作业好像推动的没有这么快。细想起来，这也很正常。去IOE给企业带来的对错常显着的省钱效益，用相对现已非常安稳的,价格非常廉价的，商场上收购周期极短的X86代替贵重，收购周期很长的小型机，以及用免费的开源数据库代替Oracle，可以大大下降企业IT的本钱。而数据库国产化代替就没那么简略了，这项作业尽管说触及到信息化的底子安全，可是当某种特别的要挟没有当即产生到自己头上的时分，总是觉得数据库国产化代替的效费比不太合算，所以领导总说这是大事，可是到了行动上就只是走马观花，也便是很正常的作业了。

　　不过局势比人强，跟着国际局势的改变，信息体系国产化代替的气势来的越来越猛。现在还按兵不动的企业遭到的压力也越来越大。许多企业把方针定为在2027年末前完结应替尽替，因而最晚从下一年开端也要开端大规划的替换作业了。数据库国产化代替的计划，也不能总是处于证明阶段，而是真的要开端着手施行了。

　　实践上，假如真的去做这件事，计划选型也并不是很难的作业，也并非有必要经过严厉的考虑才不会犯错的，有时分你考虑了好久，反而终究的挑选不见得最好。而我的观念是，或许会选错数据库可是你的数据库国产化路途不会走错，你会在不断的纠偏进程中不断的完善计划。

　　当年Oracle数据库一统江湖，替掉90年代形形色色的数据库产品，绝大多数企业也并不是做了很具体的规划，才一点点施行起来的。并且那时分Oracle数据库也没有那么好的口碑，在人们的眼中也并不是怎样选都不会错的产品。许多企业是不甘愿的用了Oracle，发现Oracle很不错，往后信息体系上线就悉数运用Oracle了。终究，企业里其他数据库产品也逐步在体系升级时换成Oracle了。

　　我有一个客户，20年开端预备数据库国产化代替的作业。首要选了一款国产分布式数据库，搬迁了一套小体系。搬迁进程中发现研制投入，上线运维方面，都存在不小的问题。21年依据上级单位要求，对OA体系进行国产化搬迁，挑选了一套OA体系支撑的会集式数据库，发现整个搬迁作业顺利了许多，搬迁费用也比第一个项目更低。所以他们决议试着在几个新的项目里运用这个会集式数据库产品，进一步堆集经历。我想关于大多数企业来说，这种小步快跑，不断批改的办法是本钱最低，比较简略成功的。比及堆集了满意的搬迁经历的时分，再进行大规划搬迁作业，那应该不会太难。

　　有些企业的IT规划较大，特别怕试错，因而他们总是期望谋然后动，先把计划做厚实了，然后再全面推动。不过我总觉得做此类计划的靠谱指数往往偏低，“专家”提出来的计划也不见得是正确的、合适企业现状的。就像见过猪跑，也很难幻想得出红烧肉是啥滋味相同，只做计划，不去测验，是不行的。

　　或许有些朋友觉得对数据库国产化代替这样一个技能问题，不谈技能，只是谈决计，是不是有点太唯心了。数据库代替这个难题，莫非光靠下决计就可以完结的吗？事实上，假如说数据库国产化作业的胜败，放在第一位的还就不是技能问题，而是决计。只需下了决计，就必定精干成。当然光有决计仍是不行的，技能问题也是需求充沛考虑的。今日咱们的下半部分，就来评论一下技能方面的问题，其间的中心仍是数据库选型的问题。

　　现在国产、开源数据库数量巨大，品种繁复，怎么挑选的确令人头疼。许多朋友都很关怀数据库选型的技能问题，不过我觉得数据库选型，技能问题还可以往后放一放。由于数据库对运用体系研制的影响很大，因而数据库最忌讳的是常常替换。一旦完结选型，最好是可以五到十年内不要替换。因而在数据库选型的时分，要么挑选相对活泼的开源社区，要么挑选规划较大的大厂产品。关于IT规划较大的企业，一些很有特征的小厂产品，尽管或许在某些方面很有吸引力，不过也要慎重对待。在这一点上，大规划运用的联系型数据库选型必定要考虑久远，而关于一些特征功用的，运用范围较小的数据库，则可以挑选一些中小企业的产品。

　　数据库选型，在商业路途上有开源、商用两个大的路途可选。开源和商用数据库产品的挑选，一向争论不休。开源数据库的引诱是任何一个企业都无法回绝的，许可证免费，社区的支撑力气，许多的用户堆集下来的运用运维经历，这些关于数据库代替来说都对错常稀缺的资源。由于开源数据库的代码是敞开的，从开源代码中，终究可以找到处理某些疑难问题的办法，因而相关于代码关闭的商用数据库而言，开源数据库更简略构成杰出的第三方服务生态。不过开源数据库是不是国产数据库，是不是信创数据库的问题，也困扰了许多企业。别的开源数据库无法取得原厂的支撑，也就缺少了一个兜底的支撑单位，这也让许多企业面对挑选窘境。

　　商用数据库则正好相反，许可证是要收费的，并且现在国产商用数据库的许可证是需求花钱购买的，并且也不像Oracle相同可以打打插边球。国产商用数据库的用户集表现在也还不行大，第三方服务才能也非常单薄，远远比不上一些闻名的开源数据库产品。不过商用数据库后边有一个“原厂”存在，可以帮你兜底。只不过这个“原厂”的兜底才能因原厂的规划与实力不同，有较大的不同。

　　有些人觉得数据库国产化代替绝对不能用开源数据库简略的代替了，这一点我不是太认同。开源数据库现已被许多规划不同而企业证明了，是Oracle等数据库的很好的代替者之一。由于开源社区的特色，大部分开源协议保证了这些数据库并不会由于美国的进出口控制办法而影响你的运用。在运用最为广泛的开源数据库-MySQL和Postgresql数据库方面，许多企业现已取得了巨大的收益。

　　假如企业的研制才能较强，运用体系都现已微服务化了，那么可以把数据库拆分的比较细微，运用MySQL对错常好的挑选。MySQL的运维非常简略，事务逻辑都在运用里做了充沛优化后，只需在MySQL的高可用架构上做好规划，那么平常的运维是很简略的，偶尔产生某个库出问题了，只需重启数据库实例或许切换备库就可以处理问题了。

　　假如企业的运用相对杂乱，SQL常常会呈现数张大表的相关查询，而研制部门的优化才能也有限，那么Postgresql或许是你比较好的挑选。PG的优化器才能非常强壮，可以处理大多数杂乱查询的功用问题。而PG的插件结构也可以让你经过一些特别的办法，乃至为某个特别运用场景开发特别的索引来处理一些开源版别无法处理的问题。

　　现在现已有不少国产数据库也走上了开源的路途，这些数据库也是国产化代替中的不错的选项。与美国主导的社区的开源数据库产品比较，我国企业主导的开源数据库产品在极点情况下会更安全。现在PingCap的TiDB、蚂蚁的Oceanbase、华为的openGauss、阿里的PolarDB都现已构成了必定规划的开源生态。

　　除此之外，实践上现在有许多国产数据库产品也都是根据开源项目的。比方人大金仓KingBaseES、瀚高HighoDB、优璇数据库等都是根据Postgresql开源项目的。openGauss这个开源项目的源头也是Postgresql 9.2，海量G100、MogDB、神州通用数据库等则都是根据openGauss开源项目的闭源商用数据库。不少朋友和我评论过这些根据开源项目的闭源商用国产数据库产品，认为这种套壳国产化产品不能算是实在的国产数据库。关于这个问题，或许咱们的观念很难共同。我仍是比较拥护根据开源项目构建商用产品的，由于这样可以大大削减研制的开支，别的也可以运用强大开源社区，充沛整合开源社区的资源。只需产品关于开源协议是遵从的，不违背开源协议的前提下做闭源，是没有问题的。当然，假如可以像openGauss等国产开源项目相同，一方面脱离国外开源社区，别的一方面发布开源版别，那就更好了。假如一个数据库既有商用版别，又有开源版别，那么既可以处理企业大规划运用的本钱问题，又可认为企业的中心运用托底，这处理了许多大型企业数据库代替的一个大问题了。

　　除了商业路途以外，还有一个非常重要的选项是会集式数据库与分布式数据库。会集式数据库运用、运维起来很简略，不过可扩展性、高可用方不如分布式数据库。分布式数据库高可扩展，容错才能强，可是结构杂乱，运维杂乱，出了问题也欠好定位。这二者优缺点都非常显着，的确欠好挑选。实践上还存在第三种路途，便是亚马逊创造的Aurora，这种日志便是数据库理念的产品可以完结強共同性的读写别离，因而许多情况下被算成对错对称架构的分布式数据库，而实践上这是一种介于会集式数据库与分布式数据库之间的架构（实践上Oracle RAC也可以近似归类于这品种型），今日咱们把它看做第三种技能路途。

　　会集式与分布式数据库的挑选仍然取决于企业的运用场景、运用方针与企业IT的才能堆集。会集式数据库相对简略，关于运用开发与运维来说，只需做好高可用架构、主备库等，可用性也是有保证的。最严峻情况下，保证30分钟内康复运用也是有保证的。

　　不过仍然存在一些运用场景需求更高的可靠性，比方股票买卖、实时体系等，这种体系在企业中尽管数量不是很大，可是往往又是最为中心的。假如需求分钟级康复运用，那么分布式数据库在架构上更具优势。而关于互联网买卖、物联网运用等事务逻辑相对简略，高并发数据写入，大批量数据输出等场景，分布式数据库也由于其极高的可扩展性而更为合适。

　　我想在一个企业中，很或许是会集式数据库用于广泛的，中小型的或许规划相对安稳的体系运用相对简略的会集式数据库，而可用性要求极高、超高并发的少数体系运用分布式数据库很或许是一种非常常见的形状。

　　第三类数据库现在在国产数据库中还比较少，最为典型的是阿里的PolarDB-PG、PolarDB-O，这是根据Postgresql开源项目的非对称分布式架构数据库产品。经过底层多副本完结IO才能的扩展，经过读写别离集群完结有限的横向扩展。实践上现在的绝大多数国产会集时刻数据库产品都可以研制相似的衍生产品。我了解到许多国产会集式数据库厂商都在开发相似Oracle RAC的产品，而达梦的相似RAC功用的数据库产品现已开端商用了。不过我仍然觉得相似PolarDB的非对称读写别离架构关于绝大多数企业来说现已够用了。既可以经过读写别离别离开支最大的读负载，又可以完结亚分钟等级的高可用毛病切换，彻底可以满意高可用性要求的中心体系的需求了。一个会集式数据库产品假如可以具有此种才能，并且在前端经过署理完结读负载的主动卸载，那么关于80%以上是读负载的绝大多数办理信息体系来说，就彻底处理了单机无法扩展的问题。会集式数据库厂商可以凭借此才能与分布式数据库抢夺中心事务的商场。

　　分布式数据库厂商也可以把手伸进会集式数据库厂商的碗里，本年OceanBase 4.0的发布会上给了数据库产业界一个新的启示，分布式数据库还可以有新的玩法。OB 4.0发布了一个单机数据库形式，关于一些企业，数据与事务规划还没有到有必要上分布式数据库的境地，你可以先上一个单机版的OB，等往后有需求的时分，可以很便利的扩展为分布式数据库。这样企业的巨细数据库都可以运用相同的数据库产品，依据需求挑选会集式仍是分布式。OB 4.0发布的时分，有个数据库厂商的朋友看到这个音讯后和我说：“这下子欠好玩了，假如OB单机形式的确如宣扬所讲，能到达这样的功用，那么这算是降维冲击了”。能不能降维冲击还欠好说，由于要想把一个分布式数据库架构的数据库产品改造为一个单机会集式数据库，并且功用可以与一般的会集式数据库相媲美，并不是一件简略事。实在的情况怎么，还需求实践运用来证明。

　　数据库选型是一个非常杂乱的进程，很难经过一些规矩进行量化，经过量化打分来完结数据库选型看似很科学，实践上并不必定可以做出很好的挑选来。数据库选型应该是从企业的特色动身的，不只是要看数据库本身的技能先进性，企业本身的技能特色，技能才能以及企业在数据库、研制等方面的出资配比等都会影响数据库选型的终究成果。今日时刻有限，我就不再展开评论了，假如咱们有爱好，我往后专门来评论这方面的问题。

　　终究聊聊数据库的比照测验与点评问题，这个也是困扰企业数据库选型的一个问题。任何的测验都无法做到彻底公平，因而经过测验完结选型的公平并不必定可以做到，也并不必定有必要。咱们要做到的是，被选中的数据库真的可以满意咱们的日常运用需求。从我的经历上看，BENCHMARK测验，TPCC之类的关于绝大多数企业的数据库选型来说没有太大的含义。只是从简略的TPCC来说，20万TPMC基本上可以满意绝大多数企业的并发买卖需求了，可是BENCHMARK这种简略的测验，无法测出企业对杂乱SQL的支撑才能的好坏，因而含义不大。关于企业数据库代替测验中比较重要的测验项目包括数据库兼容性测验、杂乱SQL支撑才能与功用测验、高可用测验等。

　　数据库兼容性测验首要是和Oracle比，大部分企业将从Oracle许多搬迁体系到国产数据库上。兼容性意味着搬迁本钱的凹凸。假如运用可以修正少数的代码，乃至不修正一行代码就可以完结搬迁，那么关于有数百套乃至上千套体系需求搬迁的企业来说，可以节省许多的本钱。在这方面，达梦是实在的王者，以咱们这些年做过的搬迁来看，达梦数据库与Oracle的语法兼容性是最好的。在这方面国产商用数据库遍及要好于开源数据库，海量G100、人大金仓、OCEANBSE（Oracle兼容租户形式）等在与Oracle的SQL、PL/SQL兼容性方面都做的不错。

　　杂乱SQL的测验最好挑选一些比较杂乱的体系进行，比方ERP体系、SCM供应链办理体系等，这些体系的事务逻辑非常杂乱，许多的多张大表相关，大数据量输出的场景比较多，因而可以查验一个数据库产品关于杂乱SQL的处理才能与运转功用。假如某个数据库可以比较好的支撑这些运用，那么其SQL才能就彻底可以满意你其他体系的需求了。有些朋友会说，假如用数据仓库的运用来测验不是更能表现杂乱SQL的才能吗？实践上过为己甚，OLAP不只是是SQL的问题，还有宽表优化、列存储、索引优化等方面的需求，与OLTP体系中的杂乱SQL是不同的。

　　数据库国产化代替触及的问题太多，我也无法经过一个五六千字的文章一扫而光。今日就聊这么多吧，早上六点多就开端写这篇文字，边想边写，或许比较乱，某些当地也或许会有些遗漏，并且只是是一家观念，未必正确，也未必与您的需求相共同，有不同的观念，期望多沟通。往后我会找个时刻，仔细整理下这篇文章，找时刻再发一个更好的版别把。期望今日的文字可以对正在做这项作业，或许正在考虑这个问题的朋友有所协助。