数据库行业解决方案都写了啥

原创
数据库 其他数据库
近期,笔者也观察到部分国产数据库厂商经过阶段性实践后,开始将使用心得形成行业解决方案,这无疑对用户会带来积极影响,加速行业推广使用。本文将结合近期发布的两家厂商的行业解决方案为基础,说明下数据库行业解决方案都应包括什么内容。

随着国产数据库在各行业应用规模不断增大,并开始进入深水区。国产数据库从之前的不能用、不敢用逐渐过渡到如何用好。特别是以分布式数据库为代表的新架构数据库产品的出现,颠覆了原有架构产品,之前很多的知识不能复用,如何用好这些成为很多用户所关注的问题。近期,笔者也观察到部分国产数据库厂商经过阶段性实践后,开始将使用心得形成行业解决方案,这无疑对用户会带来积极影响,加速行业推广使用。本文将结合近期发布的两家厂商的行业解决方案为基础,说明下数据库行业解决方案都应包括什么内容。

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、案例:实践出真知,效果案例见

很多用户非常关心同行业的案例情况,一方面这些案例都是经过实践,具备一定的可参考性;另一方面同行业案例,往往还能反映出很多共性的问题。这其中需重点描述出场景、架构、效果即可。让用户有直观印象即可,也勾起用户尝试使用的兴趣。

责任编辑:姜华 来源: 韩锋频道
相关推荐

2011-01-21 10:10:27

2011-03-07 16:42:05

MySQL数据库安全

2009-11-18 16:10:00

2011-01-21 09:43:10

安恒数据库安全安全审计

2011-03-24 15:41:42

数据库

2011-01-21 10:05:28

安恒数据库系统安全安全审计

2018-03-26 12:58:52

数据库OracleMySQL

2011-07-12 16:42:41

2011-03-03 18:09:14

2011-03-28 13:11:18

MySQL数据库安全

2010-09-15 09:50:55

2010-05-27 18:24:09

MySQL数据库密码

2009-03-31 11:57:52

2011-08-03 14:02:02

数据库连接ACCESS

2009-07-19 17:12:54

UTMIDSIPS

2022-04-01 11:41:00

智能技术数据库数据安全

2010-05-28 11:22:07

2017-05-12 09:11:41

云计算数据库高可用

2011-01-21 09:50:31

2018-02-10 19:12:14

区块链数据库解决方案
点赞
收藏

51CTO技术栈公众号