暂无图片
暂无图片
1
暂无图片
暂无图片
暂无图片

开源去o的第二步-数据库规划设计

原创 周琦放 2022-01-26
955

在数据库设计过程中一般都会有常用的方法:需求调研,概念设计,逻辑设计,物理设计,实施部署等几个阶段。因此在具体的设计过程中,需要各个开发人员,需求设计人员,技术人员等多方面的配合才能完成。在具体的数据库设计过程中和行业关系非常大,在这里我更多的是提供一种思路和过程。

1:数据分布设计

在数据库设计之前需要对业务数据进行一个梳理,该方面得工作需要开发人员和需求设计人员参与,比如数据架构设计中的业务模型设计的主要目的是对数据的逻辑概念进行一次说明。从业务应用的角度对数据进行一次划分。区分的维度可以是应用或者微服务。对后面的分库,分schema有重要的指导意义。在此基础上划分出数据分布。弄清楚数据的分布也对微服务中的数据访问隔离有重要的指导意义。

可以参考下面的表格对业务数据进行梳理。数据分类:从应用角度分类。 数据主题可以是功能划分或者微服务的角度划分。

数据分类

数据主题/子类

数据内容

平台数据

运营管理

运营记录数据。

运维监控

配置信息,开发者信息。

配置管理

告警日志,错误日志,慢日志等


2:数据库分类设计

根据不同的数据主题选择合适的数据库类型,以满足业务的需要

关系型数据

关系型数据库的选取路线为mysql和postgresql两种数据库,根据业务数据领域进行多个物理库及逻辑库划分,对常规结构化数据进行存储,同时根据数据量和使用频率进行分表分库及读写分离。

缓存类数据

数据缓存采用Redis作为缓存库,实现多个服务间内存数据共享,将网关集中会话数据、计数器统计数据、进度条数据、配置参数数据、分布式锁数据和应用热点数据缓存到redis缓存库中,增加数据并发查询响应能力及分布式数据共享。

非结构化类数据

非结构化类数据包括文档、图片、视频、图形等归档资料,比如oss存储。

半结构化数据

半结构化数据采用ElasticSearch组件,通过建立索引实现文档类数据的查询。

海量分析数据

如果业务需要存储大量的归档数据,历史数据供后续的数据分析,需要创建大数据平台,比如采用hbase进行存储。


3:逻辑库设计

在此项目中由于大部分的业务实现都是通过微服务的方式实现的,而微服务的要求每个微服务组对应一个数据库,如果采用此方式可能会导致大量的数据碎片,表不共享,数据冗余等问题。因此在实际的数据库设计中会根据某些规则进行数据整合。我们的数据整合思路如下:通过设计业务逻辑库,该业务逻辑库之间的数据只能通过微服务进行调用访问,不能直连数据库。

该逻辑库并不是mysql、postgresql数据库中的database的概念,而是从业务的逻辑库,同样遵守微服务的一些设计原则:依据高内聚低耦合原则组织数据逻辑存储,数据通过服务调用进行交互。

 

把服务中心按照业务数据主题进行聚合,根据聚合的结果拆分到不同的业务逻辑的库中,不同的逻辑数据库之间只能采用服务调用的方式,该设计思路,在数据层面能够划清不同的数据访问关系,还能对数据进行良好的拆分聚合,较少数据碎片和冗余

服务---》数据主题--》业务逻辑库 


按照上面三个层级划分为具体的逻辑库

3:物理库设计

按以下原则进行数据库实例(INSTANCE)、库(DB)、模式(SCHEMA)的规划设计。

继承沿用原则

物理库建设过程中如无业务或者强技术政策要求,尽量减少物理组件、代码级别的变更,比如:更改存储组件、数据表命名、字段命名。

应用隔离原则

结合项目特点,比如项目中的微服务是用来做中台建设的,因此需要考虑中台和应用的隔离。在业务领域逻辑库的基础上,把中台相关的库和应用库物理上隔离。

遵守微服务的设计原则,不同业务领域的数据只能通过微服务访问。

 数据处理耦合原则

为保证数据处理完整一致、高效,数据存储分布遵循一下原则:

领域聚合根耦合:业务处理过程中,同一业务聚合根数据不能拆分到不同的物理存储SCHEMA;

批量处理耦合:业务处理需要批量加载某数据实体的批量数据实例时,建议尽量将该业务的数据表与被批量加载的数据表放置于同一DB;

其他业务数据耦合:如果两个数据主题有紧密的耦合关系,建议把数据拆成不同的schema但是放到同一个db中,保证分析性能高效、便捷。

数据分类存储原则

根据数据形态特点选择不同的数据库存储组件。根据业务领域数据形态可分为:结构化数据、非结构化数据、半结构化数据、缓存类数据。

高可用数据保障原则

对于核心业务保证高可用、可靠数据,建议在物理上独立分配资源、配置主备进行保障。云资源也采用独享型

管理扩展方便、运维可控原则

按照业务领域,各个业务领域的数据需要独立存储,考虑后续各业务领域数据库表在扩展升级方面互相不受影响,运维开发人员便于定位管理,

在业务领域隔离的基础上,评估数据容量大小,同专业的业务领域数据DBSCHEMA也可进行合并。

 总体来说该物理库的原则更主要的是从业务的角度,考虑数据的访问和管理更加方便,不能单纯的从技术角度去划分。

4. 物理库数据分布


下图中,行列交汇处的单元格英文为PG的SCHEMA名称,如:业务逻辑库1中的公共部分对应的schema为sys

物理库实例 物理库A
应用领域 公共 DB1 DB2 DB3 DB4
业务
领域
业务逻辑库1
业务逻辑库2
业务逻辑库3
业务逻辑库4
物理库说明



5:新增业务schema构建


6:各个物理库具体说明


最后修改时间:2022-01-26 17:08:19
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论