随着国产数据库在各行业应用规模不断增大，并开始进入深水区。国产数据库从之前的不能用、不敢用逐渐过渡到如何用好。特别是以分布式数据库为代表的新架构数据库产品的出现，颠覆了原有架构产品，之前很多的知识不能复用，如何用好这些成为很多用户所关注的问题。近期，笔者也观察到部分国产数据库厂商经过阶段性实践后，开始将使用心得形成行业解决方案，这无疑对用户会带来积极影响，加速行业推广使用。本文将结合近期发布的两家厂商的行业解决方案为基础，说明下数据库行业解决方案都应包括什么内容。
1. 场景：让用户判断是否适合自己
用户的场景千差万别，没有一款产品是可以通吃所有场景的，因此明确的场景描述尤为重要。通过这部分描述，用户可以快速判断是否适合自己。这其中场景分为两种：
1).技术场景
一种方式是描述技术场景，如常见的 OLTP、OLAP、HTAP 等，但这些还是比较宽泛的，需要更进一步的细化。如处理的数据规模大小、计算逻辑怎样、延迟要求如何等等。如下面这段描述：这是一款分布式数据库，可满足百TB以下的关系型数据存储，可提供数万的高并发支持，适用于数据计算逻辑简单，支持简单点查、范围查询及数据变更，在高并发下情况下可提供百毫秒级别的响应时间等。上述技术场景描述，会给用户一个较为直观的印象。如果用户也整理有自己的数据库场景地图(如下图)，就可以很容易的找到结合点。
2).业务场景
另一种方式是描述业务场景，这种方式对用户而言会更加简单直观，毕竟用户是最了解自有业务的。用户在第一时间就明确了这一产品是否适合自己。如在金融行业，可以通过类似下面的一段话进行描述：某分布式数据库产品适合于银行核心系统分布式改造，过去此业务多是通过集中式架构、通用硬件来支撑，无法满足日益增长的海量数据规模、业务连续性也较差。分布式数据库产品具备海量规模、高性能处理、强一致事务保证、数据高可靠及服务连续性保证等，并已通过多年实践在很多银行系统核心改造中落地。通过上述一段描述，用户可以很容易产生共鸣。用户对自身业务是有着明确认知的，例如银行业业务分类参考下图。
2. 架构：让用户了解产品是什么
数据库产品是由多组件构成，对于分布式架构产品来说尤为如此。如何让用户快速了解产品，可通过架构部分进行描述。这里可通过一张架构图进行说明，包括哪些组件、组件有何功能、如何与周边生态协作、高可用实现机理等等。通过这部分可以让用户快速了解产品构成、工作原理等内容，也为后面进一步展开功能说明做个铺垫。下面通过一个分布式数据库架构示意图说明下
注意这里不是技术架构、也不是部署架构。前者更强调技术原理及实现，后者则为实施规划设计阶段需考虑。这里就是简单的产品功能架构，让用户有个概括性了解即可。
3. 功能：让用户了解我能干什么
1).现状描述
第一部分，重点是让用户了解现在产品能做什么。这里不是产品的功能手册，因此无需对功能做很详细的说明，但需要将一些重点的能力及用户比较关注的部分都说到。这里可包含但不限于这些内容：
基本能力：ACID、SQL引擎等
存储结构：行存、列存、索引结构
高可用：单机、主备、双活、多活
容灾：单机房、同城多机房、异地等
扩展性：接入、计算、存储扩展等
数据集成：导入导出、迁移同步等
安全能力：用户、权限、加密、审计等
运维相关：管理、监控、优化、备份等
生态兼容：协议、语法、接口等
部署方式：物理机、虚拟化、容器、云
国产化：软硬件、上下游
2).历史与发展
第二部分，是描述产品功能的发展历史及未来路标。产品功能发展是有一定传承关系的，用户可从演进版本中找到发展脉络，更好地了解产品。同时，产品未来发展也有助于用户判断产品未来发展策略及方向。下图以 MySQL 为例，做个简单说明。
4. 规划：解决用户产品上线问题
当用户对产品有了初步了解后，并有意愿后，该如何上手就是急需解决的问题。首当其中就是上线，需做如下一些工作。
1).硬件评估
数据库，特别是分布式数据库，通常有多个组件组成，不同组件的资源消耗模型不同，有的是 CPU 密集、有的是 IO 密集不等。这里需根据不同组件，给出硬件推荐的配置，方便用户快速上手。如考虑国产化问题，还需列明对应的国产化软硬件产品列表，供用户参考。此外，还和部署方式有一定关系，如云、容器化部署也有着特殊要求。可参考下表
这里需要注意的是，资源配置不仅与角色有关，也与负载有关系。上面硬件配置通常只是最低配置，实际生产环境可根据用户负载进行精确评估，这部分会在资源评估中详述。
2).资源评估
在做资源评估时，会情况比较复杂，需要考虑多重因素。很多厂商都提供了一个评估模版，用户可如实填入后，给出相关评估结果。下表简单说明下需考虑的因素。
这其中会有一些阈值，是根据厂商产品长期实践后所得出的，是与产品自身架构、功能有关。以负载维度为例，较大负载是需要更高的资源配置，可以简单根据一些指标做下分列，这样方便用户选择或内置到资源评估小工具。当然，如果能根据业务指标做相应的资源评估，无疑是更好的。
3).容灾方式
很多行业都对业务连续性有一定的要求，因此需要确定具体应用的业务连续性目标、设计对应的高可用方案。很多数据库产品也都支持了如单数据中心高可用、同城双中心、两地三中心、多地多中心等容灾架构模式。技术上基于多副本冗余技术、一致性复制技术和灵活高可用策略实现多种容灾方案，单台服务器故障自动切换到本数据中心其他机器的副本上;双中心以上的机房故障时，可快速切换到其他机房或者城市灾难中心，最大程度保证业务连续性。
5. 开发：解决用户应用开发问题
产品上线后，下一步的问题就是如何开发对接，这里需要将开发所关心的问题一一说明。
1).快速入门
首先可以通过一个DEMO，让用户快速入门。选择最主流的开发语言，实现一个简单的 CRUD 即可。目的是使得用户能够快速上手。国内很多产品都提供了一定的兼容性，例如兼容 MySQL、PostgreSQL、Oracle 等，其目的正是降低用户使用门槛。
2).开发接入
开发者使用此产品，需要关注的一些问题。包括如：连接池配置、应用高可用、负载均衡、字符集选择、事务控制等。此外，还包括适配一些主流的开发框架、日志跟踪工具等，对于开发一开始关注的问题都可在此处说明。
3).数据建模
主流的数据建模方法，是否适用于本数据库产品，需要有哪些注意事项。
4).结构设计
数据库对象设计上，有哪些注意事项。对于分布式数据库而言，对象设计上需要做一些调整以适应分布式架构，包括如数据分片策略、索引设计、自增类型、库内计算(存储过程、触发器等)。特别是数据分片策略，尤为重要。分布式数据库的基础就是将数据“大而化小”，但不是所有数据对象都需要做分片。哪些做分片，哪些不做?选择怎样的分片算法?分片的粒度如何?如何规避热点?如何解决关联对象的分片问题等等。上述问题都是需要解决的，有些数据库产品结合在行业的经验，将常规的分片策略抽象出来给出一定的最 佳实践，这对于用户来讲无疑会大大降低使用难度。通常有如下一些建议：
数据分片应尽量均衡
尽量减少跨节点事务
集合业务特点，梳理主题场景
同一主题选择相同分片键
分片键字段保持稳定
5).语句开发
制定一套应用开发遵循的开发规范，有利于避免重复触及数据库使用常见问题，提高可阅读性和问题定位速度。包括但不限于：命名规范、事务控制、语句写法，问题常见于索引、排序、函数、分组、关联等。
6).性能优化
将常用的性能优化手段，加以说明。可能包括如：性能分析手段、参数优化、模型优化、SQL调优等。
6. 迁移：解决用户数据上线问题
如何将用户数据平稳迁移上线，很多产品都提供了独立工具实现对异构数据库的迁移。这里可分为三个步骤：
1).事前评估
完成迁移动作，涉及到数据对象结构迁移、数据自身的迁移以及负载评估。前者需要支持异构数据库对象的映射，这其中包括很多细节(如字符集、空值等)，很多厂商都内置于工具中来完成;数据迁移则涉及对迁移速度、断点续传、异常处理等问题;最后则是数据库负载能否在新产品中得以支撑。除此之外，还包括可能得回退步骤。
2).事中迁移
正式的数据迁移，一般都包括全量数据迁移、增量数据迁移及数据比对三个阶段。很多产品都内置于工具中，提供一整套迁移方案。
3).事后割接
当都完成后，需完成最后的割接动作，一般是通过流量重定向到新库来完成。此时，如果需要后备，可一并提供回流能力，保证可回切。
7. 运维：解决用户日常管理问题
运维部分，包括的比较庞杂，如备份恢复、监控报警、扩缩容、升降级、日志分析等。很多产品都提供了运维平台来辅助完成上面这些管理动作。
8. 安全：解决用户的后顾之忧
安全部分，范围也比较广，包括主机安全、账户安全、传输安全、存储安全、安全审计等。
9. 案例：实践出真知，效果案例见
很多用户非常关心同行业的案例情况，一方面这些案例都是经过实践，具备一定的可参考性;另一方面同行业案例，往往还能反映出很多共性的问题。这其中需重点描述出场景、架构、效果即可。让用户有直观印象即可，也勾起用户尝试使用的兴趣。
