近日，财政部联合工业和信息化部共同印发《数据库政府采购需求标准（2023）》。这为很多政府机构采购数据库提供了统一标准，也为其他行业采购起到了一定示范作用。对广大数据库厂商而言，无疑具备非常好的指导意义。下文将从政策本身及对应技术能力角度，谈谈个人对这一标准的解读。
一、采购需求标准：政策篇
关于此次下发的政府采购标准，可参考下面的详图。这里仅谈谈从文字上可得到的直观信息。
❖ 适用范围：政府部门
此次下发标准的适用范围为政府部门。采购人在采购数据库是都应遵循这一采购标准。
❖ 采购原则：分包采购
此次下发标准明确，无论是采购软硬件产品、集成服务项目亦或是达到采购限额，都应独立分包采购。
❖ 采购标准：采购指标
此次下发的标准中，部分指标标记为"*"，即作为强制采购标准；非标记指标，可根据需要选择纳入采购标准。标准也说明用户可增加新的指标或对已有指标提出更高要求，但不应超过实际需要。后面技术部分，将针对指标做更详细的分析说明。
❖ 回应形式：承诺函
在招投标环节中，供应商通过提供的承诺函来回应采购标准，并被视为产品符合要求。采购商不的对数据库进行检测、认证或要求厂商提供检测、认证报告。这一要求无疑对数据库厂商是利好的，减少大量重复的资源投入。
❖ 验收形式：用户或三方
在验收环节，用户需严格履行验收职责，自验或委托三方机构进行验收。
二、采购需求标准：技术篇（总览）
此次下发标准中，包含两种标准、分为五大类、二十四小类标准。下面针对整体技术指标进行一些说明
1、两类标准：集中式、分布式
此次下发两类标准，分别是面向集中式数据库和分布数据库。在具体的采购需求标准（简称指标）中，绝大部分都是相同的，只稍有差异。其中，集中式是108条指标、分布式113条指标，相同指标有107条，差异部分主要体现在集群管理部分。集中式有基于共享存储的管理标准，分布式则增加了对数据分布、数据重分布、分布式计算、集群扩展等指标，具体指标解读参见后文。
2、指标分析：5大类，24小类
下发标准中共制定了114项指标，分为五大类，分别是功能要求、可靠性要求、安全要求、服务要求和兼容要求；在每个大类中又进一步细分为若干小类，共计二十四小类。下图根据指标的大类小类分布情况做了个比例图。
3、关键属性：必选指标集中
在下发标准中，通过指标比较星号，区分是否为必选指标。即标记星号代表指标必须纳入采购需求指标；未标记星号则代表指标为非必含项，由采购人根据实际需要自行确定是否包含在采购需求中。从必选指标的范围来看，主要针对服务能力、兼容要求以及稳定运行等限定严格，更为强调其必要性。下图按照功能子类及子类内必选与必选指标的分布，加以图示说明。
4、关键属性：评分项少之又少
在下发标准中，还标注了那些指标是设置为评分项。标记为是，则代表该指标采购人可以根据实际需要在采购文件中设为评分项；否则则代表该指标不能设为评分项。从标准的114个指标中，能作为评分项的少之又少，目前仅有硬件兼容、供应链保障、容灾能力（同城和异地）以及安装升级中的兼容性（多CPU架构）做出评分项选择。可以看出官方尽量减少的评分范围，仅选择更为有利于国产化硬件、运行安全及服务保障范畴的指标作为评分项。
三、采购需求标准：技术篇（详解）
下面针对下发标准的114个指标项加以简单分析。
1、功能要求
❖ 安装与升级
数据库安装与升级属于常规要求，这部分指标应大体都无问题。需要注意的是升级能力，国产数据库不可避免会面临功能的修改，因此平滑兼容的升级能力很重要，此外也需要说明升级的功能变化。还有就是安装升级中的硬件兼容性，即可以支持多种架构CPU条件下的安装，这对于当前自主可控的大背景尤为重要。这点也作为的关键评分项；但比较奇怪的是未作为必选指标。
❖ 数据配置
这部分就是对数据库的各类参数进行配置，包括对常规参数以及针对存储、内存方面的特有配置。个人感觉，目前很多数据库（特别是分布式数据库），都支持不同角色（如存储节点、计算节点等），因此参数配置应区分并分列，这样便于用户理解和配置。
❖ SQL 功能
这部分包括数据类型、SQL 语句、字符集、操作符、执行计划等，就是数据库基础能力。这里面比较受关注的点一是针对扩展数据类型的定义、存储、检索的支持，随着用户场景的复杂，扩展数据类型成为一种必然；二是字符集支持，去年也有不少国内厂商通过了中国强制字符集标准GB 18030-2022；三是针对 SQL 执行计划干预能力，这样可以有效解决数据库优化器能力不足或Bug所导致的执行路径异常，可快速解决用户问题。
❖ 数据对象
数据对象部分，则包括从表、分区、视图、索引、序列、触发器、存储过程等。一方面是对这些对象的支持情况，一方面是对这些对象的变更、查看、完整性管理的能力。这其中有几个难点，一是分布式数据库对于部分对象的不支持（如索引、视图、库内计算），这也是很多从集中式数据库迁移到分布式数据库必须面临的问题；二是对于在线重定义的支持，特别在分布式架构、海量规模情况下尤为重要。
❖ 事务能力
标准的 ACID 能力，也是对数据库的基本要求。前两年在对国产数据库评测时，出现过部分问题，但随着各厂商产品的完善一般都没有太大问题。死锁则是另一个痛点，部分厂商产品还有明显缺陷。
❖ 运维
运维方面包含的内容很多，标准把运维方面的重点放在信息的获取、告警方面。强调了从主机、系统、实例、语句多维度获取数据以便于运维保障，比提供远程运维能力以及针对语句的运维能力。从现状来看，分布式架构产品存在一定短板，主要是因为其组件多、受基础环境影响大等原因，对信息输出进而诊断的能力显得尤为重要。很多产品是将信息做了输出，但如何快速识别、快速定位、快速诊断并进而解决问题，还是困扰着很多用户。这方面确实可以向如 Oracle 这些老牌数据库产品学习。
❖ 迁移
迁移部分分为两块，一是逻辑的迁移（如应用及SQL），一是数据的迁移。前者强调通过工具或其他手段降低迁移难度及工作量，加速迁移过程，保障迁移质量；后者则是针对数据对象结构迁移、数据本身迁移问题，需保证迁移前后的数据一致是问题关键。此外针对数据比对，标准还特意列出了两条，足见其重要性。很多国内产品都提供的生态工具来支持上述两种诉求。
❖ 备份恢复
备份恢复领域，标准提出了对数据备份、备份集管理、细粒度、多介质支持等能力要求。
❖ 集群管理
在集群管理方面，分布式与集中式数据差异明显，因此在标准上也提出不同要求。除了支持常规的集群创建、管理及扩展能力（读写分离）外，集中式重点强调了对共享存储架构的支持，这也是国内产品之前的短板，通过类似 RAC 的架构，可以满足大部分用户的场景需求。分布式则是强调了“弹性”。即通过数据分布下，通过针对存储、计算的扩展能力来满足用户需求，且这一过程中应做到用户“无感”。
❖ 工具
好的数据库产品，还需要上下游生态工具的配合，标准中针对用户常用的生态场景提供了工具化的要求。这里覆盖从数据库开发、运维、优化等多种面对不同人群、不同场景的工具。在这方面国内很多产品通过生态兼容方式做了支持，即通过兼容流行开源数据库产品或主流商业数据库产品的方式快速支持，这也是一条相对的捷径。
❖ 图形化管理
图形化管理能力，是有效降低产品使用难度，提升易用性的手段。标准中也将常用的图形化管理需求进行了整体，这里重点强调对运维和开发的支持。这方面国内厂商产品也大多提供了此能力，也有部分三方数据库管理厂商也提供了此能力。完善的图形化管理，将有效降低用户使用门槛。
2、可靠性要求
❖ 稳定运行
稳定运行是对数据库的基本要求，标准中也提到了。但这部分在落地时比较难解读，很难通过一个具体指标来反映数据库的稳定运行能力，更多是通过之前长期运行的实践案例加以说明。
❖ 故障切换
在故障切换角度，标准提出了对快速切换能力及切换时业务受损情况做出要求，但这里未明确具体的故障切换指标，如 RTO、RPO 的情况，下文在容灾部分进行了详细的说明。
❖ 容灾能力
在容灾方面，是标准提出较为严格的部分。针对分布式和集中式数据库提出了基于副本复制、日志复制的具体要求，来保证容灾能力。对于实例级的容灾要求，明确提出了RPO=0、RTO
