从MariaDB衰败思考国产数据库品牌力建设

前文

10年前我非常好奇这个长得和MySQL一模一样的东西的发展，直到今天有了答案，MariaDB股价大跌，陷入财务危机，没有营收，砍产品，裁员，更换管理层，借债等等。

MariaDB曾经有一个InnoDB加强版的说法，但是从开发者的视角，没有必要关心里面是什么。 即使page head加强、page tail优化，page directory综合做了完善的更改。开发者只关心它在应用业务性能上有没有体现，使用是不是与MySQL一模一样。

从WEB应用体验，MariaDB与MySQL做比较，MariaDB的使用与MySQL的外模式和内模式一样。外模式指MySQL常用的SQL语句【等值查询、范围查询、聚合查询、窗口查询、两表关联、多表关联】，内模式指MySQL内部的元数据信息【数据字典、动态视图、静态视图】。

几乎可以把MariaDB当成套壳的MySQL，以此为镜， 300多个国产数据库可以感受到自由市场的竞争残酷。截至2月份， dbegines排行13名的MariaDB处于分崩瓦解的边缘。它给国产数据库的启迪是什么？我们怎么去发展建设国产数据库品牌。

千年前，明太祖朱元璋征求学士朱升对他平定天下战略方针的意见，朱升说：高筑墙，广积粮，缓称王。国产数据库可以遵从此道 ，高筑墙建立自己的品牌壁垒，广积粮营造自己的商业生态 。

从数据库的本质为应用服务、目标人群是商业实体，使用者多是开发者、DBA，我想到的三点有助于数据库品牌的建设。

协助建设应用

从目标利用的角度，天下应用分为以下三种系统建设，数据库作为系统中的核心服务,始终是为应用服务，应用是最终的变现。

信息系统建设方案： 传统的应用建设，主要是将现象生活反映到电子流，往往是单条业务流程整合，包括企业流程制度、企业控制管理、员工权限授权访问，常说的烟囱系统建设以及企业信息系统以及ERP、CRM、OA、交易系统、分析系统都属于这个范畴。此处数据架构较简单。

大数据系统建设方案: 此不仅仅包括我们常说的大数据建设，该应用建设表现往往高并发、高吞吐、低延迟、快响应，有时候需要整合较多的数据源，将集成较多的数据集，主要与业务系统联通或者其它设备的数据汲取过来，通过清洗、整合、编排后，输出一个错落有致、规范得体的数据指标，再反哺业务系统。用户跟踪、业务监控管理、实时需求预测都属于大数据系统的建设方案范围，主要它是能整合不同的数据，此处数据架构较复杂。

智能系统建设方案: 该系统建设属于高端信息应用范畴，需要智能算法以及更有效率的计算框架，包括音、视频、 边缘计算 、AI、 大模型、 AIGC等等，同时也包括基本的信息系统建设方案和大数据系统建设方案，智能系统建设是应用优化的永无止境的追求。主要表现是提供更加友好验证手段，以及更加便利的识别方法提供相应的服务，一般智能系统会搭承其它技术手段完成客户端需求的闭环。

目前信创改造以及国家信息发展项目，大部分以信息系统建设方案和 大数据系统建设方案居多，所有的国内厂商创收盈利来自此处。因为有逐利的目的性，厂商有目标奔向这些项目。

但是对一些开源信息系统的适配，没有厂商愿意接入，因为没有任何利润可言。例如wordpress目前只支持MySQL，从技术上的改造，这个是简单的，但是没有人愿意做这样的事。大部分国内数据库厂商已经完成国内头部ERP厂商的适配兼容，数据库兼容wordpress是轻而易举的事情。

数据库厂商可以试着从基于利润创收的目的性适配应用，切换到主动适配发展应用创新的模式。

从信息系统建设方案来看，目前国内大多的开源系统底层使用MySQL，这个在侧面反映在中国MySQL为什么比postgreSQL火的原因，postgreSQL在世界很流行，但是在中国普及不如MySQL。

大数据系统建设方案较复杂，单一的数据库无法解决所有的问题，但是可以作为方案其中的一个实力支撑点，目前许多厂商都与上下游产品已经完成适配兼容， 但是没有脍炙人口的成熟的技术栈自成一套的解决方案。

例如某管理系统平台的技术栈如下， Hadoop +Hive +Kafka +Zookeeper + HBase +Sqoop +Flume + 国产厂商产品，国产厂商产品的位置也许随便用国际主流数据库产品就可以替代。为什么还用不熟悉的国产厂商产品？

这里需要宣传，需要推广，需要实践使用，需要生根发芽，了解国际的现状，认清与国际的差距，他们能做的，我们也能做。

这是文化使用习惯的问题，同样是碳酸水，可口可乐和百事可乐已经是有口皆碑，国内的炭酸水的味道和质量不比可乐差，为什么销量比不过这两家。其中一个原因，可乐不仅在饮料行业生根发展，而且在食谱行业也有建树。例 如可乐鸡翅，可乐不仅可以用于消暑解渴，而且可以用于烹饪食物。

严格科学上来说，可乐是越喝越渴的，根本不能够解渴，但是可乐的口感还不错，价格还可以，人们就建立喝可乐可以解渴的信仰。这信仰一时三刻撼动不了。国产可乐要摇动 可口可乐和百事可乐的位置，长期宣传推广是必不可少，多搞点可乐鸡翅、可乐鸭掌是根本，可乐应用于烹饪，可乐应用于清洁用途，可乐应用于除味。

智能系统建设方案这里比较特别，传统数据库与智能应用的依赖相对弱，一些数据库厂为了加强核心能力，已经推出向量型数据库。标准的现代化的数据库的基本能力，无论是结构化数据、半结构化数据、全结构化数据都可以在库中进行处理。

事实上智能系统建设方案更偏重应用端的处理能力，识别特征、应用模型、计算方式非常重要，这些都不是数据库能够兜底的，真正的智能系统建设方案可以不靠虑数据库产品选型，但是数据持久化落地，必定要选择其一款数据库。

智能系统建设方案应用场景比 信息系统建设方案、大数据系统建设方案更加变幻莫测。

信息系统建设方案建设重点，数据库作为数字基座提供能力如下，包括系统稳定、高并发访问性能、交易查询请求功能、各种业务函数、友好的使用方式 ， 满足项目级、部门级应用发展的需求。

大数据系统建设方案方面，数据库原有的基础能力新增，包括分布式处理能力、多模型构建能力、事务交易同体能力、内外数据集成能力 、动态伸缩能力 ，满足跨部门的集团级应用发展的需求。

信息系统建设方案和 大数据系统建设方案的对比区别，一个是简单，一个复杂，而智能系统建设方案则是强调应用端的建设，服务端获取特征参数，在后端联调大量的模型，连接不同的数据库、知识库、文件系统做特征识别匹配，返回给客户。

那么智能系统建设方案 普及的应该如何建设？数据库厂商大力投入，带头组织活动，鼓励应用创新，推动金融智能应用、电信智能应用、制造业智能应用的发展，有助于提高厂商的品牌力，暴光厂商在智能系统建设方案 方面的实践经验，增强厂商的威望值。

笔者看来，信创及国产化大多属于信息系统建设方案和大数据系统建设方案， 智能系统建设方案则是未来社会发展的应用硬性需求，厂商可以大力投入。

建设产品的长宽高壁垒

产品品牌力犹如一个盒子，由长宽高组成， 长度不够、宽度不及、高度不深都会造成品牌力的短板，无法把客户的信心牢牢装在里面。

下面列出产品长度、产品宽度、产品深度相关的指标来量化一个国产数据库的综合实力，努力往这三方面发展应该是没有错的。知己知彼，百战百胜，产品长宽高是知己，知道自己已经做的事和即将要做的事。

产品长度重点考察应用案例

• 
  
• 确定行业头部企业覆盖范围【金融行业、通信行业、制造业】
  
• 确定行业相关企业覆盖面积【企业个数】
  
• 确定行业主流应用场景【生产、经营、交易、办公】
  
• 确定应用场景影响范围【核心业务、辅助业务 、边缘业务】
  
• 确定产品基于生产环境运行的稳定性【精确到年】
  
• 确定产品具备满足未来业务几年的性能【数据量增长】
  
• 确定产品利于业务展开运行的功能【产品功能与业务需求匹配度】
  

产品宽度重点考察生态适配

• 
  
• 软件上游 CPU、芯片、操作系统、文件系统
  
• 软件下游 BI软件、数据集成软件、ORM框架、数据可视化
  
• 与Oracle、Postgresql、MySQL的适配兼容
  
• 基于产品基础上的二次github技术开源
  
• 同类软件的适配兼容调度集成
  
• 行业标准接口JDBC\ODBC的适配兼容
  
• 建立合作伙伴战略关系
  
• 打造用户的社区【成熟度评估】
  
• 高校教育培养使用人群
  

产品深度重点考察产品是否与时俱进

• 
  
• 行业主流技术【向量化计算、向量化数据类型、边缘计算】
  
• 社会趋势【区块链】
  
• serverless平台
  
• 云计算系列
  
• 内置支持人工智能、机器学习、数据分析、业务函数
  
• 高校实验室底层研究
  

构建购买者和使用者的体验闭环

知己知彼，百战百胜，构建体验是知彼，知道对方对产品的感受以及使用者的反馈。

数据库作为一个商品，处处展现着生产者、购买者、使用者的关系。 生产者【厂商 】根据市场上的需求，丈量自家的研发实力开发了这么一个商品，当务之急就是要找到客户【购买者】，客户选择商品的背后有1000个原因。成交之后，使用者进场。购买者与使用者之间是甲方与乙方的关系，乙方根据产品的使用说明，使用相关解决解业务中的一系列问题。

厂商做的事情，包括引起购买者的兴趣，千方百计使用各种营销方式或者推广手段使购买者甘心付费成单，并且使用使用者的产品使用，包括质量反馈和功能缺点。

购买者体验

商品列入购买者的采购清单范围 ，可能原因是是产品的【协助建设应用】和【长宽高壁垒】做了大量铺垫，举例某产品应用于人工手势智能系统中，XX商品充当核心服务存储，XX商品应用于同行业的用户画像分析业务场景，或者XX商品联同BI软件已经在驾驶舱系统运行中。

在商品已经得到购买者的侧目，下一步是实践得到客户的肯定。下面的POC以及持久的技术支持将证明产品具备满足客户业务需求的功能和性能。

厂商对客户的进一步输出，可以量化为以下三个指标。依次为服务响应时间、竞品对应亮点、应用迁移经验。

服务响应时间，包括解决具体问题花的时间，到达现场花的时间，响应客户问题花的时间，原则上客户提出的问题 和疑问都要第一时间解答， 为此企业会有相应的知识库储备 ，针对问题可以马上解答。

竞品对应亮点, 建立同类相关产品对标，并突出本产品优势、亮点，数据库产品大同小异，全部产品都有数据存储、管理、使用的功能，但是单机产品与分布式无法100%进行匹配度。可以参考**【协助建设应用】和【长宽高壁垒】。**

应用迁移经验，客户关心第数据底座搬迁后的稳定性，基于数据库的应用迁移工作包括 具体数据迁移、数据结构迁移、SQL相关迁移，保障迁移后是无缝迁移状态。

具体数据迁移主要包括数据一致性、数据数量是否同、数据内容是否同等、数据是否转换等等。

数据结构迁移主要包括表结构、数据类型、数据长度、存储过程、函数、同义词等等，基于新底座转换后运行逻辑流程是否与原来相同 。

SQL相关迁移主要指SQL语句以及SQL相关的SHELLl调用、ETL语句，ORM框架内置SQL，基于新底座转换后运行逻辑流程是否与原来相同。

使用者反馈

在客户正式成为购买者后，使用者成为高级产品反馈者，厂商收集使用者和项目的相关信息，同时也是在进行**【协助建设应用】和【产品长宽高壁垒】**。

厂商对客户的进一步输出，可以量化为以下三个指标，包括项目业务背景，技术套件、文件使用、产品使用状况。

业务背景，包括项目驱动因素，领导愿景、发展目标、立项初衷等等，根据这些已知信息，掌握项目的痛点和痒点，评估项目预期可以做到的效果。

技术套件，记录包括项目中原来的和准备用上的技术套件，包括前端、UI、ORM框架构、中间件、数据库等相关解决方案一切用上的技术工具。

文档使用，建立用户对文档使用过程中的体验，根据厂商的提供的资料，是否足够工程师独力完成任务，不需要与厂商 互动。

产品使用状况，构建用户与研发互动和反馈的平台系统和制度流程， 包括API使用、DEMO操作、无法解决的问题。

总结

总的来说，品牌力不可能一蹴而就。围绕三点协助建设应用、建设长宽高壁垒、构建购买者和使用者的体验闭环进行数据库品牌力建设，笔者也是泛泛而谈展开铺叙，细节方面可以有更多补充。

最后概括以协助建设应用、建设长宽高壁垒为基本点，以此为线，赋能项目成单，增进客户的信心，交付项目使用。同时从购买者体验、使用者反馈搜集信息和数据，促进产品良性发展以及项目拿下订单，周而复始，不断循环。