大咖说 | 信创数据库选型推荐与指导

KunlunBase 昆仑数据库 2024-09-29

1106

点击上方蓝字关注我们

导读
一个开源产品有一个主导公司来推动的好处，是它的发展路径和质量更加可控可预期，这对于所有用户都是好消息。MySQL和MariaDB以及基于它们的数据库产品，都可以较好地满足国内信创需求，这里面泽拓昆仑Klustron和昆仑参天功能完善全面，技术可靠、性能优越，在各方面具有完备的优势，可以很好地满足数据库用户的信创需求。

关键词：信创数据库、MySQL、MariaDB、Oracle、昆仑参天、Klustron、泽拓昆仑

信创的现状

国家提出信创政策要求的最主要目标，是自主可控，也就是确保芯片、操作系统、数据库系统等关键信息基础设施，有长期稳定可靠的产品和技术服务供应商，避免关键行业受制于他国造成信息基础设施的技术供应风险。自主可控本质上是要求可以长期持续迭代升级产品，并且提供可靠的技术服务。对企业来说，信创意味着商机，目前这已经是一个规模可观的市场。

目前信创数据库主要是为了替换Oracle数据库，有些公司还有少量DB2，SQL Server以及其他更老旧和古早的数据库系统，比如sybase，informix等。在信创政策出台后，国内出现了不少大中小公司，提供信创数据库替代产品，这些产品大多基于MySQL或者PostgreSQL做一些内核或者外围的优化、增强，或者使用MySQL或者PostgreSQL作为其组件。笔者创立的泽拓科技，拥有一个技术实力强劲的MySQL原厂开发团队，我们的系列核心产品泽拓昆仑数据库系统，也是用增强和优化后的MySQL或者MariaDB作为核心组件。

MySQL目前属于美国的Oracle公司，这让一些人担心，基于MySQL研发的各种信创数据库，有可能会受制于美国的技术出口政策，也就是有一天美国政府可能要求Oracle公司停止出口Oracle任何产品给中国的任何用户。这个限制对于Oracle Server数据库这样的闭源产品来说，确实是有效的，因此才有信创的政策要求，关键行业才需要替换Oracle数据库；但是对于完全开源的MySQL来说，这个限制毫无意义；还有些用户担心MySQL的许可证条款；另外一些用户担心MySQL的性能和语法兼容性。针对用户的这些担忧和潜在风险，笔者在本文中给出我的看法和建议。总的来说，笔者认为基于MySQL（包括MariaDB）的数据库产品非常适合信创要求。

MySQL和MariaDB是自主可控的

MySQL是开源的，其代码及其变更历史可以从github下载到；其用户技术文档，甚至近10年内的功能设计文档都可以从Oracle官网线上获得（后文有链接）；同时，国内有一个分布于各个大厂以及包括泽拓科技这样的高科技中小企业的MySQL/MariaDB内核研发人才群体。因此即使Oracle将来因为任何原因不再开发、维护MySQL，或者MySQL未来新版本专门针对中国用户不再可用（笔者认为这几乎不可能，这样的排除限制也无法落地执行），国内的这个MySQL内核开发群体仍然可以继续开发迭代MySQL的中国分支。

那么国内这个MySQL开发者的群体规模有多大呢？曾经在Oracle MySQL团队工作过的研发人员，包括笔者在内，总数大约10人。这些人在过去10年陆续去了华为、阿里、腾讯等公司。我们泽拓科技是国内拥有MySQL原厂开发者最多的中小企业，多位核心技术专家曾在Oracle MySQL 团队作为核心开发者工作多年。我们在泽拓昆仑数据库中，在我们的MySQL分支中研发了很多新功能和性能增强，这体现了我们的技术实力。这些MySQL原厂开发者在过去这10年中在各个大厂工作期间，带出了总数可能有数十人的MySQL内核开发人员，再加上从大厂研发实践中成长起来的MySQL内核开发者，总数可能有一百多人，这个规模已经超越MySQL原厂开发团队了。他们都是这些公司目前的主力数据库开发者。

过去这些年这些国内的MySQL开发团队也极大地促进了MySQL和MariaDB的持续进步，包括贡献新功能，以及修复bug，报告bug等，这正是开源的强大威力。笔者就曾经修复了MySQL的数十个个核心功能并贡献给了MySQL团队，并且修复的bug中有几个是被MySQL团队列为保密的bug，也就是非Oracle员工和笔者自己之外，其他人无法从MySQL 的bug系统中查到这几个bug的信息（此处容笔者小小地嘚瑟一下）。而且MariaDB的创始人Monty先生还当面邀请我把这些bug报告提交给MariaDB社区，我也欣然同意并且在MariaDB-10.11上面验证了这些bug是否存在，把存在的bug报告该了MariaDB社区，例如MDEV-31998[1]和MDEV-31999[2]。

国内的各MySQL开发团队也开源了一部分他们的产品：例如我们泽拓科技就开源了我们对MariaDB的增强版本Kunlun-MariaDB[3]；阿里、腾讯等也开源了他们的部分MySQL分支；华为开源了他们为MySQL 完全自研的存储引擎（数据库系统最重要的核心子系统或者组件） --- 参天引擎。我们泽拓科技正在把华为参天引擎接入我们的Kunlun-MariaDB[4]，其巨大的技术潜力我会在下文详述。

同时，MariaDB也在持续发展中。虽然近年其股价一直跌的很惨后来还私有化了，但是其产品和技术团队一直比较稳定，也有数十人的规模，而且一直在稳步推进包括Oracle兼容能力在内的功能开发，所以MariaDB也是国内信创需求的可靠保障之一。

总的来说，国内目前有大约一两百人具备不同程度的MySQL内核开发能力和经验，分布在包括华为、阿里、腾讯等大公司以及泽拓科技等高科技中小企业。这些人正在积极围绕、基于、使用MySQL做信创数据库产品研发。这样的人员规模完全可以确保这些数据库产品的自主可控。未来如果有足够的市场需求和资源输入，国内的这些MySQL团队完全可以继续扩大规模。再加上MariaDB的开发团队，足以满足国内信创市场的需求。

MySQL和MariaDB的GPL许可证

采用MySQL和MariaDB的另一个担忧，是GPL许可证协议对开源的要求。不过似乎很多人并没有深入研究GPL许可证的要求，笔者对此有所了解。GPL协议要求的是---以MySQL为例 --- 如果一个公司把MySQL的使用许可卖给其客户，那么其客户有权要求获得MySQL的源代码。这个公司对MySQL的任何修改也自动属于Oracle。这意味着以下几个事实：

公有云服务不包含在内。AWS、阿里云等国内外公有云厂商对MySQL的修改并没有开源，但是完全不违反GPL协议，因为他们销售的是云数据库服务。
有权利提出获得源码要求的是这个公司的商业客户，而不是Oracle。Oracle无权要求这个公司开源其MySQL分支。当然，在实践中假如Oracle希望某个公司开源，只要说服某个公司提出开源要求即可，尽管实际上这样事情绝不可能发生。
如果这个公司开源了他们的MySQL分支，那么Oracle完全可以合法地使用其中的任何代码，把这些代码合并到MySQL代码中。

同时，GPL的许可条款其实还包括了链接使用MySQL的二进制客户端库和包含这些库的头文件（一种C/C++代码文件）的情况。按照GPL的条款，这种使用MySQL的方法，用户的终端客户也有权要求用户开源其应用软件代码。不过Oracle放弃了GPL协议规定的对用户使用这些头文件和二进制库文件的开源要求 --- 在MySQL的代码中你可以看到，所有需要应用软件包含的头文件，都有额外的许可说明 --- 用户使用MySQL的客户端连接库以及包含这些库的头文件，用户的软件无需因此而开源。

替换Oracle数据库的技术要求

要替换Oracle数据库，新数据库产品首先必须要做到Oracle语法兼容性。虽然其他关系型数据库和Oracle数据库都支持SQL语言作为标准的数据访问方式，但是每一种成熟的关系型数据库产品都在实现了绝大多数标准SQL语法之外，还或多或少的增加了一些本产品特有的SQL语法。Oracle增加了大量独有的SQL语法，架构于Oracle数据库之上的应用系统，通常都会使用这些SQL语法。用户替换Oracle数据库时，通常希望不修改或者少修改应用系统的SQL代码，否则其应用系统维护成本会非常高；甚至有些应用系统由于时间长久可能已经没有源代码或者没有供应商了，这些情况下要修改源码就完全不可能了。

做Oracle语法兼容就是一个需要长期投入的辛苦活儿，目前国内各大厂基本上都基于PostgreSQL数据库做了Oracle语法兼容能力，因为PostgreSQL的语法与Oracle更加接近。据笔者所知目前没有任何一个产品做到了100%兼容Oracle语法，倒不是因为这项工作的技术难度太大而无法实现，而是因为Oracle这么多年这么多版本，不同版本Oracle数据库的语法也在持续迭代和增减，确实要做到100%兼容有大量工作要做，需要长期持续投入。反过来说，其实Oracle语法兼容完全可以是项目驱动形式，避免做无用功。

对于任何一个做Oracle兼容的数据库系统来说，更难的是在性能层面兼容Oracle，也就是对于各种DML（增删改查）负载，包括含有多表连接、子查询、聚集查询、窗口函数等分析处理(OLAP) 类型的查询，其性能都可以接近或者超越Oracle数据库。

Oracle虽然是事务处理(OLTP)类的数据库系统，数据按行存储，天然不利于对OLAP类查询实现高性能，但是其OLAP性能并不差。Oracle用户经常把OLTP类负载和OLAP类负载都送入同一个Oracle数据库实例来执行，并且通常都能获得满意的性能。因此要做Oracle替换时，他们的应用系统架构通常就要求新数据库也要在OLTP和OLAP方面都有优异的性能。对于OLTP类型的数据库，比如MySQL以及国内各个围绕或者基于MySQL而研发的的信创数据库来说，在OLTP方面能够接近Oracle性能；但是能够在OLAP方面接近Oracle性能的非常少。

MySQL和MariaDB替代Oracle的技术能力

MySQL（包括MariaDB）是当今全世界范围内使用最广泛的数据库系统之一。由于这么多用户，MySQL的技术成熟度和可靠性非常之高，毫不逊色于Oracle数据库。特别是自MySQL-5.7开始，InnoDB 事务存储引擎和binlog replication已经足够可靠而且性能也足够好，这进一步让MySQL成为堪当大任的企业级数据库系统。当前在包括AWS等国外公有云平台，以及国内的阿里云，腾讯云，华为云等公有云平台上面，MySQL RDS都是使用最广泛而且能够大幅盈利的云数据库服务。AWS Aurora, Aliyun PolarDB也是基于MySQL开发的。

对于大部分用户的大部分业务系统来说，对于事务处理(OLTP)类型的负载，使用MySQL或者MariaDB在可靠性和性能方面完全可以替代Oracle。特别是近年版本的MariaDB还有一定程度的Oracle语法兼容能力，更加适合信创的需求，可以大幅降低数据库迁移成本，这也是为什么我们泽拓科技使用MariaDB研发昆仑参天数据库系统。MySQL和MariaDB的创始人Monty先生亲自告诉笔者：国外有若干知名大型金融机构使用MariaDB替代了数千个Oracle实例。在国外也有很多Oracle替换需求，主要是为了降低成本。

通过使用MariaDB，泽拓昆仑数据库获得了良好的Oracle兼容能力；同时我们把泽拓昆仑系列产品的核心功能和技术移植到MariaDB中形成我们自己的Oracle数据库替代产品Kunlun-MariaDB，可以同时实现Oracle语法兼容和性能兼容，从而完美滴替代Oracle数据库。

MySQL和MariaDB在事务处理性能方面可以接近Oracle数据库，显著优于PostgreSQL的事务处理性能。但是MySQL和MariaDB的弱项是分析类查询的性能，比如，MySQL的TPC-H性能数据就惨不忍睹，不仅大幅落后于Oracle，也大幅落后于PostgreSQL；令笔者自豪的是，我们泽拓昆仑数据库Klustron的OLAP性能已经大幅超越了Oracle数据库[5]，这让泽拓昆仑的系列数据库产品，有望成为在语法和性能层面都可以替代Oracle数据库的产品。

MySQL和MariaDB的生态影响力

MySQL（包括MariaDB）用户社区是全球最大的数据库用户社区之一，在规模上与之可以媲美的大概只有Oracle的用户社区了。当然，近年PostgreSQL用户社区也在快速发展。MySQL和MariaDB社区最重要的技术信息来源地就是MySQL work log[6]系统和MySQL bug系统[7]，以及MariaDB的jira系统[8]。在这些站点中你可以查到MySQL或者MariaDB的每一个功能的架构设计和详细设计文档；也可以找到每一个bug的症状、修复版本、规避方法等。用户遇到了bug首先在bug系统中搜索，可以使用报错信息直接在Google或者bing搜索即可。这样，技术人员就可以找到规避问题的方法。如果没有找到bug报告，用户可以在bug系统报告这个新的bug。同时用户还可以查阅MySQL或者MariaDB的技术文档，这里面的功能说明非常完备。

除了官方团队的技术资源，还有大量围绕MySQL数据库的第三方产品、组件、技术、文档和遍布在大量技术网站的使用经验的积累，以及有大量经验丰富的DBA技术人员。这些技术资源对于数据库用户来说是非常宝贵的，也是其他数据库难以逾越的壁垒。对于计算机软件来说，最难以逾越的壁垒就是生态壁垒，而不是技术壁垒，更不是团队规模或者资金壁垒。

用户做数据库产品选型时，数据库产品的用户社区的规模和资源积累是首选考虑的因素之一。

这也是为什么我们泽拓科技使用MySQL和PostgreSQL作为组件来开发泽拓昆仑数据库，通过根植于MySQL和PostgreSQL社区，熟悉MySQL或者PostgreSQL的DBA都可以快速上手使用昆仑数据库。不仅如此，MySQL和PostgreSQL社区的第三方组件还可以挂载到昆仑数据库集群组件上面，这些组件极大增强和扩充了昆仑数据库的产品规模和功能集合；同时泽拓昆仑数据库也放大了这些组件本身的能力 ---它们原本只能运行在MySQL和PostgreSQL这样的集中式数据库中，可以使用的计算资源有限，而在泽拓昆仑分布式数据库集群中，用户可以按需增加所需的计算资源，上不封顶。

用户如何选择替代Oracle的数据库产品

兼容性和迁移成本是基础要求

在技术和产品方面，这个数据库需要再语法和性能方面兼容Oracle，可以顺利而简单地完成数据迁移和应用迁移。完全符合这一条要求的数据库产品基本上不存在。通常要在语法兼容性方面做一些牺牲，也就是需要多少修改一些应用软件系统的SQL代码甚至其他代码，来符合新数据库的语法。这意味着那些没法修改源码的老旧应用系统，如果未来绝不可以使用Oracle数据库的话，那么到时候用户只能把它们抛弃掉了，所以用户要早做准备。

性能兼容方面，如果某些SQL语句确实无法在新的数据库系统上跑出可以接受的性能，那么只能改造应用SQL甚至改造应用架构，这个工作量通常较大甚至非常巨大，因为这通常意味着拆分应用数据，拆分或者重构业务逻辑等等。这也是为什么笔者认为，性能兼容性对用户更重要更有价值，也是数据库厂商更难实现的。

如果有几个信创数据库可选，那么应该优选性能兼容性好的数据库，这意味着相比其他候选数据库，这个数据库或许在语法兼容性方面不是最全面的，但是用户只需要多改写一些SQL语句以便遵循新数据库的SQL语法即可，难度很低，项目时间可控；而改写出稳定地具备更高的性能的SQL，难度较高甚至受限于新数据库的能力而完全不可能，只能花费大量时间精力来重构应用架构。

技术生态和用户社区很重要

技术社区规模是另一个需要考察的重点。使用一个数据库的过程中，难免会遇到各种技术问题。这时候，使用这个数据库的用户越多，这些问题被解决的几率越大。MySQL、MariaDB的很多bug是用户修复的，并且每个版本公开发布后绝大多数bug 是用户报告的。用户报告bug给开发团队，提供足够的bug症状信息，开发团队就可以解决问题。还可以给开发团队提出技术需求，这些需求未来有可能成为产品功能。

同时，围绕数据库开发的第三方软件模块越多，各行各业的数据库用户面向各种各样的公司的纷繁复杂、包罗万象的需求，构建整体解决方案就越简单甚至才有可能。有一些数据库的第三方软件模块如此重要以至于其知名度极高而且推动了数据库软件本身的普及，比如PostGIS，PGVector就是典型，它们的使用范围极广，在其细分领域内非常知名，接受度极高，极大推动了PostgreSQL的普及。

如上文所述，MySQL和MariaDB的技术生态系统和用户社区在全球范围内以及中国国内都非常活跃，在这方面可以说无出其右者。

是否100%自研完全不重要

现代信息技术的底层逻辑之一就是分工，分层，封装和模块化。事实上分治策略(divide and conquer)也是任何复杂系统设计的核心逻辑。数据库系统作为信息系统基础设施中的基础软件之一，运行在操作系统之上，应用软件系统之下。任何一款数据库系统，其功能逻辑都不是完全由一个软件公司的代码组成，即时Oracle也如此。也就是并不存在“100%自研”的数据库系统或者任何软件系统。因此即时只考察数据库系统自身的功能模块和代码，100%代码都由自己的人写并不重要，毕竟任何公司都有人员流动；100%理解其产品架构、功能设计和代码才是重要的，而这意味着良好的软件开发流程和完善的系统设计、研发文档和bug管理追踪机制才是非常重要的。

为了论证我们的上述观点，下面我们就分解一下数据库的功能逻辑的构成。

首先操作系统（国内各种信创操作系统都是使用Linux内核的）是所有数据库系统以及其他任何软件运行的基础和环境，其中有大量基础功能逻辑，来管理和分配调度计算资源和存储系统硬件，向包括数据库系统在内的用户态软件系统提供标准的通用的接口和基础的计算、存储、通信功能。

第二，第三方工具库代码，比如c/c++语言的标准库，boost库，以及其他语言自带的标准库，都包含了大量基础功能逻辑，比如常用数据结构和算法等。包括所有数据库系统在内的各种系统软件和应用软件都在广泛地使用这些标准库。

第三，诸如压缩、加密、正则表达式等应用层通用功能，已经有成熟的功能库。几乎所有的软件系统都在使用这些程序库。

与任何其他系统软件一样，数据库系统也是构建和运行在这些通用的系统、组件和功能逻辑之上的。同时，数据库系统的理论基础非常完善而且比较复杂，有较高的理论高度，能与之比拟的也就只有通信系统、人工智能、图形图像音视频处理等。包括Oracle数据库在内的各种数据库的理论基础都是公开、透明和熟知的。目前并没有任何一款数据库系统使用的理论是排他和专有的。因此，即时某个数据库系统自身的代码是100% “自研”的，也仅仅是把一些数据库理论和算法再次100%重新实现一遍而已。尽管如此，不同数据库产品在工程层面的技术路线的差异和创新点以及独特技术优势还是广泛存在的。但是在2024年而不是1994年对于数据库系统来说，这种技术层面的任何优势都不是永久的。

笔者这么说并不是因为泽拓昆仑数据库基于MySQL/MariaDB和PostgreSQL作为核心组件，毕竟我们在此基础上做了大量内核层面的新功能、新模块和原有功能的优化增强，我们泽拓昆仑系列产品也有很多发明专利。用户完全没必要有‘自研代码’情节，而如果数据库系统从业者以此来证明自己产品的能力会显得很不专业。

用户真正应该关心的，是产品团队能完全地，100%地理解和掌握其数据库产品的代码和架构，这归根结底意味着产品研发团队要遵循上述完善的软件研发流程，有完善的产品架构设计文档，详细设计文档，功能接口文档以及问题追踪机制和文档记录。用户实际上几乎无法准确判断这些内部机制和能力，用类似考试的方法来判断几乎完全无效，只能通过测试验证产品的功能、性能、可靠性间接判断。同时用户还要关注的是产品供应商可以和愿意提供优质的技术服务。有一个对于数据库产品的用户来说最简单有效也是最基本的鉴别方法，就是看一个数据库产品是否可以在其公司官网下载（软件包或者源码都行），并且是否有完善的用户文档（使用手册）。这个判断方法就可以把国内所谓近300个数据库产品的80%排除掉。

国内信创政策对Oracle公司的影响

国内替换Oracle数据库对Oracle公司的影响很小，因为中国市场在Oracle的数据库业务的收入占比原本也只是个位数；而国外Oracle的用户主要是非常稳定的大中型客户。国外的中小公司大多上云(AWS等）了，使用的主要是MySQL系列云数据库服务。也就是说对Oracle数据库市场份额真正有威胁的是各个主流公有云平台的数据库服务。同时也可以推断，国内信创数据库市场空间在5年内看恐怕也就是Oracle在国内的那些收入的一部分。不得不承认的是，全球范围来看Oracle数据库的市场地位是真正的遥遥领先而且非常稳固，因为即便在公有云大规模普及的今天，Oracle数据库在关系型数据库市场的份额依然最大。

Oracle会持续投入资源开发MySQL吗？

回答这个问题我们要考虑一下Oracle当年为什么要持续投资MySQL。Oracle在2010年收购了Sun，而Sun在2008年收购了MySQL，Oracle因此在2010年获得了MySQL。Oracle获得了MySQL后，持续地投入了15年，MySQL在这15年的产品力有了巨大的飞跃，这是Oracle对全世界的MySQL用户的巨大贡献。

尽管Oracle做了如此巨大的投入，MySQL基本上没有为Oracle赚多少钱。Oracle管理团队的思路，我想就是用MySQL帮助Oracle拦住追赶者，打压竞争者，以便把Oracle Server卖给大中型客户来赚大钱。这个思路也直接导致Oracle错过了云计算这一巨大机遇，把云计算的发展大机会让给了亚马逊和阿里云等。Oracle投入MySQL的资源相当于给其他公有云平台做了贡献，我相信Oracle的管理团队会因此而承受压力。直到近年Oracle才开始急起直追云计算，MySQL的研发资源也大多投入到了Oracle Cloud的MySQL云服务（比如HeatWave），这部分已经不再开源了。

所以可以预期，未来Oracle会把最先进的MySQL新技术放到Oracle Cloud上面，与开源的MySQL形成较显著的差异化，来与其他公有云平台竞争。但是同时，Oracle也会投入部分研发资源持续的维护MySQL，毕竟Oracle MySQL才是‘MySQL’正宗这个认知，对Oracle Cloud的业务还是有巨大价值的。特别是考虑到各大公有云平台都有自己的MySQL分支和一定程度的MySQL研发能力，Oracle想必不敢松懈对MySQL的研发投入。

另一方面，Monty发起的MariaDB项目，也在持续给Oracle以压力和鞭策，这进一步形成了良性的竞争格局，有利于MySQL整体生态的健康发展，对MySQL&MariaDB用户来说，这是非常好的产品。最后顺带提一下，MySQL近年新版本发布出现的那两三个不大不小的问题，主要是其采用了新的产品发布流程导致的问题，现在已经重回过去的成熟发布流程，想必MySQL自身的产品质量不会再轻易出现大问题。

总的来说，笔者认为Oracle会持续投入MySQL，MySQL和MariaDB都会持续健康发展。一个开源产品有一个主导公司来推动的好处，是它的发展路径和质量更加可控可预期，这对于所有用户都是好消息。MySQL和MariaDB以及基于它们的数据库产品，都可以较好地满足国内信创需求，这里面泽拓昆仑Klustron和昆仑参天功能完善全面，技术可靠、性能优越，在各方面具有完备的优势，可以很好地满足数据库用户的信创需求。

链接来源参考：

[1]MDEV-31998：https://jira.mariadb.org/browse/MDEV-31998

[2]MDEV-31999：https://jira.mariadb.org/browse/MDEV-31999

[3]MariaDB的增强版本Kunlun-MariaDB：

https://gitee.com/zettadb/kunlun-storage-mariadb

[4]Kunlun-MariaDB：

https://gitee.com/zettadb/kunlun-storage-mariadb

[5]Klustron的OLAP性能已经大幅超越了Oracle数据库：

https://doc.kunlunbase.com/zh/Klustron_VS_Oracle_TPC-H_perf.html

[6]MySQL work log：https://dev.mysql.com/worklog/

[7]MySQL bug系统：https://bugs.mysql.com/

[8]MariaDB的jira系统：

https://jira.mariadb.org/secure/Dashboard.jspa

END

为促进团队内外的沟通联系，我们Klustron团队的bbs论坛开始上线，欢迎各位同学使用！（链接：https://forum.klustron.com/，或者点击文末“阅读原文”，即可跳转）

论坛目前是测试版，可能还存在不稳定的现象，欢迎各位老师、朋友共享信息，如果遇到问题还请谅解。

欢迎大家下载和安装Klustron数据库集群，并免费使用（无需注册码）。

Klustron 完整软件包下载：

http://downloads.klustron.com/

如需购买请邮箱联系sales_vip@klustron.com，有相关问题欢迎添加下方小助手微信联系🌹

产品文档

Klustron 快速入门：

https://doc.klustron.com/zh/Klustron_Instruction_Manual.html

Klustron 快速体验指南：

https://doc.klustron.com/zh/Klustron_Quickly_Guide.html

Klustron 功能体验范例：

https://doc.klustron.com/zh/Klustron-function-experience-example.html

Klustron 产品使用和测评指南：

https://doc.klustron.com/zh/product-usage-and-evaluation-guidelines.html

点击👆上方，关注获取源代码及技术信息~

文章转载自KunlunBase 昆仑数据库，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。