大数据量下的存储设计模式探索

引言

现实世界商务竞争越演越烈，出现更多的细分市场、深度营销和定制功能，这导致各种商务应用的用户数和业务复杂度同步增加。反映到数据库里，就是表的数量和数据量日益增长，数据库响应速度日益缓慢。

为什么一个功能好的产品，往往上线后就出现性能问题，不得不反复回炉修改？为什么一到业务高峰期，系统就慢的动弹不得，只能关闭部分业务保障关键业务？数据量从十万到百万，从百万到千万，从千万到上亿，从亿再向兆跨越，如何保障程序能够经受住大数据量的考验？这都是我们面临的真实现状，也是大家反复在思考的问题。

《道德经》上说：“有道无术,术尚可求,有术无道,止于术。”众人把目光集中在系统架构、查询算法、数据库软件的底层原理等等“术”上，却忽视了深刻理解数据这条光明大“道”。数据从哪里来？要到哪里去？数据用来读还是写？数据与数据之间有什么样的关系？数据的增长速度如何控制？最有价值的数据是什么？数据什么时候可以丢弃？假如不能回答这一长串问题，如果不是以这一长串问题的答案为程序设计的出发点，代码如何能经受大数据量的考验？

在数据的采集、计算、展现和存储这一设计链条中，开发者通常负责设计关系型数据模型，编写程序计算和展现数据，数据库管理员负责数据文件存放位置、表空间存储参数等的架构设计。但是，数据库管理员往往不了解业务，不了解数据的特点，数据存储设计表现为千“表”一律。

数据存储设计模式是根据数据的真正特点，仔细分析数据流向、数据访问特点、数据量、数据增长量和数据生命周期，对数据进行分类，然后根据不同类型的数据设计不同的存储策略。正确的应用数据存储设计模式，可以几倍，甚至几十倍的提高数据访问效率。

大数据量下的数据特点

全球最大数据库的数据量已经先后越过了MB量级、GB量级和TB量级，站到了PB量级的门口。在庞大的数据量面前，对数据进行分类显得尤为重要。人们对数据感兴趣的时间是不一样的，大量的数据进入数据库后，经过计算、聚集和转换，仅有少量的活跃数据需要长期保留在数据库中，剩下的数据只有备查的价值，可以暂时存储在数据库中或者离线备份，等到休眠数据完全没有价值后直接删除。

需要长期保留在数据库的活跃数据可以称之为核心数据，它是整个商业活动中最有价值的数据，需要长期甚至永久的保留。程序完成处理后只需要备查的休眠数据可以称之为过程数据，是伴随核心数据流动所产生的数据，它的存在周期视商业活动的重要性而定。

数据的分类有利于把资源聚焦于有价值的数据，我们可以通过以下几个方面识别核心数据和过程数据：

识别项

核心数据

过程数据

数据流向

几乎不流动

按工作流的方式运动

数据的访问特点

主要读，多半是关联查询

主要写，更新和删除涉及到查询

数据量

大

非常大

数据的增长量

增长缓慢或者完全不增长

增长迅速，甚至是爆发性的

数据生命周期

长，甚至永久的保留

短，几天到几个月不等

表类型

表说明

核心表

数据生命周期长，读比写的访问频率高，数据增长慢

恒数表

数据量小，总是读，很少写

递增表

数据量大，经常读，很少写。某些情况会频繁写。

在大数据量环境下，数据库服务器的资源是昂贵的，混合核心数据和过程数据的后果就是资源被不重要的数据占用，被不必要的进程占用，导致性能缓慢和堵塞。常见的误解数据特点的现象包括：

核心数据和过程数据以不同字段的形式在同一条记录里存放

核心数据和过程数据以不同记录的形式在同一张表里存放

把不同队列的过程数据在同一张表里存放

过程数据没有合适的退出机制，长期保留在数据库中

数据表的分类

在一个大数据量环境中，表的数量往往达到数千张。根据核心数据和过程数据的不同特点，可以将表大致分为2个大类，4个子类。

核心表及子类的明细定义如下：

表类型

表说明

核心表

数据生命周期长，读比写的访问频率高，数据增长慢

恒数表

数据量小，总是读，很少写

递增表

数据量大，经常读，很少写。某些情况会频繁写。

在核心表的关系型数据模型设计阶段，有以下原则需要遵守：

务必要尊重范式，即确保原子性，检查对键的依赖性，检查属性独立性等三个原则。

严格控制关键递增表的字段个数和字段长度。

重要的递增表的属性一旦定义，不允许随意添加字段。后续业务升级最好是增加新的递增表。

如果递增表总是需要做范围查询，应重新审视关系型模型。

过程表及子类的明细定义如下：

表类型

表说明

过程表

数据生命周期短，写比读的访问频率高，数据增长快

流水表

数据量大，经常写，很少读。只插不改，定期删。

状态表

数据量大，经常写，经常读。边插边改边删。

在过程表的关系型数据模型设计阶段，有以下原则需要遵守：

设计明显的代表数据生命周期终止的字段

从增删改的代价来考虑，插入代价最小，修改需检索数据，删除最为昂贵，可考虑多设计流水表，少设计状态表。

数据表的分类有利于围绕不同类型的数据进行不同的存储模式设计。我们可以通过数据流向、数据访问特点、数据量、数据增长量和数据生命周期等识别四种表类型：

识别项

恒数表

递增表

流水表

状态表

数据流向

几乎不流动

数据很少流动

数据不流动

数据在不同的表之间流动

数据的访问特点

读很频繁，很少写

读很频繁，很少写，每次仅访问表中的极少量数据

只插不改不删，数据生成后只用来备查

读和写都很频繁，不光是插还要改和删

数据量

数据量小，一般在万条以内

数据量大，一般在几万条到上亿条以内

数据量很大，一般在几十万条到上亿条以内

数据量很大，一般在几千条到上千万条以间

数据的增长量

几乎不增长

增长缓慢

增长快

增长快

成功应用数据存储模式的步骤

建立数据存储模式管理小组

正如同大型程序的核心模块会成立专门的核心开发小组一样，大数据量也值得成立专门的管理团队进行数据存储模式管理。

开发团队往往是按照业务模块来划分的，核心表被各个业务模块使用，但没有专人管理核心表。几乎伴随每一次大的业务升级，核心表都会被添加字段，少则几个，多则十几个。表面上，添加的字段节省了某个业务的关联查询的时间，但其恶果是核心表的过度膨胀和关系型模型的模糊，最终会拖累整体业务性能。

数据存储模式管理小组能够站在业务的整体角度去审查核心表的变动是否合理，维护关系型模型和控制核心数据的整体规模。更重要的是，他们能够根据数据规模和业务特点制定统一的数据存储模式，并在各个开发小组中推广。在存储模式实施有困难的时候，小组能给开发者提出有益的设计建议。

架构中的存储设计模式

对重要的商业应用来说，数据库并非只有一个，而是1（生产库）+N（容灾库）的方式在运行。再加上数据增长到一定量级时，数据库的物理拆分将不可避免，从一个大数据库变成多个小的数据库。面对这么多的数据库，软件架构师需要从更高层面进行数据存储设计。

首先，架构师要考虑的是如何利用容灾库来减轻生产库的压力？容灾库和生产库是准实时同步，数据一般是相差一天或者更短时间，最新的技术已经能做到容灾库在只读打开的状态下与生产库保持同步。容灾库适合用于备份、抽取数据源、综合统计、报表和压力测试。要做到容灾库接管综合统计和报表功能，架构师需要解决查询的跨库问题和生成报表的写数据库问题。

另一个重要的问题是如何对数据库做拆分？传统的思路是按照行政区域划分数据库，这种方式的优点在于容易操作，程序的改造难度小，缺点在于核心数据同步的工作量大，容易出现数据不一致。另一种思路是核心库加卫星库的方式，即核心库存放活跃的核心数据，卫星库存放休眠的过程数据。这种类似分区数据库的工作模式有利于核心业务的资源保障，对架构师的设计能力提出了很高挑战。

了解存储技术的最新趋势

如同已经发生的每一次技术浪潮一样，存储技术的巨大进步会给存储模式设计带来颠覆式的影响。我们需要了解存储技术的最新趋势，并在数据存储模式设计中考虑这一变化。

这里就以存储介质的技术变革，来举例分析存储技术的进步对存储模式设计的影响。由于传统磁盘的机械式运动，造成物理读和逻辑读，以及顺序读和离散读的巨大性能差别。因此，以往的设计思路是将数据尽可能的缓存到内存中，避免磁盘I/O，尤其是避免磁盘离散读。随着固态硬盘的技术成熟，物理读和逻辑读，以及顺序读和离散读的性能差别会大幅缩小，取而代之的是读和写的巨大性能差别。新的设计思路需要把重点放在减少数据流动，减少事务提交等方面上来。

结束语

如今，全世界的数据库都面临数据量的爆炸式增长，多核CPU、内存数据库、固态硬盘，甚至超高性能的多机集群等硬件性能的提升逐渐追不上数据增长的速度，我们必须要开拓新的优化思路来建设一个高效稳定的信息系统。

我们需要深刻的理解数据——识别数据流向、数据访问特点、数据量、数据增长量和数据生命周期等数据特性，并据此展开核心数据和过程数据的存储设计、程序设计和架构设计，才能满足不仅要实现功能正确，还必须足够快的商业需要。

转载请注明出处：华为云博客 https://portal.hwclouds.com/blogs

存储 数据库 存储

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。