关于架构,大家都有了解和理解。通常一个业务或项目,在做架构设计时,可能会包含业务架构和技术架构。其中技术架构是我们作为开发角色,在做设计时重点的工作内容。但还有架构类型的划分方式,会包括业务架构、技术架构、数据架构和应用架构四种。
数据架构管理的内容包括管理对象、管理流程、管理组织,管理对象又包括数据标准、数据模型、数据库、数据质量。总之,数据架构就是由一定的管理组织,通过一系列管理流程,来实现对数据对象的管理。数据架构构成如下图所示:
“经验来源于实践”。经历过一个或多个中大型项目/产品生命周期的朋友,大多会有这样的经验。在项目早期时,为了快速验证,会以尽快上线运行为最主要的目标,架构设计会有数据结构部分,但不会过多设计。在项目快速发展之后,频繁的表结构变更、数据类型变化会带来一系列的问题,尤其是当可能发生拆库、分表等动作之后,带来几个典型的数据问题:
表结构规范;
索引合理性设计、创建检查;
SQL 质量;
数据安全管理(插入、删除、更新,以及批量查询动作)
数据架构的重点是数据的标准化处理,这会贯穿于系统/项目的整个生命周期。包括数据架构设计阶段、开发阶段、迁移阶段、测试阶段等等。
关于大数据量的存储方案,常用的有分库分表方案,可以选用多种分库分表技术和中间件来实现。但有一个问题,当单表数据量到达多少的时候执行分库分表?
一直有这样一种说法,MySQL 单表数据量大于 2000 万行,性能会明显下降。冷热分离之 OTS 表格存储实战这篇文章中给出了来源:这个传闻据说最早起源于百度。“具体情况大概是这样的,当年的 DBA 测试 MySQL 性能时发现,当单表的量在 2000 万行量级的时候,SQL 操作的性能急剧下降,因此,结论由此而来。然后又据说百度的工程师流动到业界的其它公司,随之也带去了这个信息,所以,就在业界流传开这么一个说法。再后来,阿里巴巴《Java 开发手册》提出单表行数超过 500 万行或者单表容量超过 2GB,才推荐进行分库分表。对此,有阿里的黄金铁律支撑,所以,很多人设计大数据存储时,多会以此为标准,进行分表操作。”
背后的原理,大家也可以仔细阅读这篇文章,简单来说,这个说法源于 Mysql 的 InnoDB 引擎的存储结构和索引结构。记录数过多时导致 B+树高度过高从而需要多次 IO,导致性能明显下降。
首先,绝大部分场景,数据都可以分为“冷数据”和“热数据”。数据划分的原则,可以根据时间远近、热点/非热点用户等等。例如在以往项目中的实例,用户通常只访问一段时间之内的数据,例如近一周或一个月。如果数据不做划分,必然会导致一定程度上的性能、成本损耗。
通过合理的冷热分离设计,可以达到的好处:
需要考虑的包括存储方案、数据迁移方案,另外需要做历史查询时也需要支持聚合查询和自动的冷热查询路由。
存储方案,包括本地方案和云方案。本地的存储介质,通常是硬盘,但通常机械硬盘会受限于磁盘空间和 IO 瓶颈,这也是单表限制的主要原因。所以一般处于性能提升的考虑,会使用固态硬盘(SSD)。但 SSD 成本较高(远高于机械硬盘),所以不适合海量数据存储,这时候就需要考虑磁盘阵列等等。另外,磁带也是一种方案,但仅适合历史数据的持久化保存,和必要时做数据恢复,本身并不适合查询。
如果能够接受云方案,那么可选的就有云硬盘作为 DB 的存储介质、或者是云服务上提供的冷热存储(blob、表格存储)。阿里云的 OTS 就是一种表格存储实现,其技术架构如下图所示:
数据有冷热划分,那么就会有边界、生命周期。新的数据写入时,其属性是“热”的;当到达某个时间节点或预设阈值时,就需要把数据迁移到“冷”数据存储。这里又涉及到几个问题:
另外,为了保证冷热数据迁移过程中业务系统的稳定性,在数据迁移的过程中还一定要做到:可灰度[降低影响,提前发现],可一键回滚[快速止血]。
本文介绍了数据架构的概念、意义,以及数据的冷热分离,并阐述了冷热分离方案和注意事项。本篇作为综述,在后续系列文章中会通过实际案例来进一步探究数据架构的内容。