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

1  引言

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

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

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

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

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

2  大数据量下的数据特点

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

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

 

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

识别项	核心数据	过程数据
数据流向	几乎不流动	按工作流的方式运动
数据的访问特点	主要读，多半是关联查询	主要写，更新和删除涉及到查询
数据量	大	非常大
数据的增长量	增长缓慢或者完全不增长	增长迅速，甚至是爆发性的
数据生命周期	长，甚至永久的保留	短，几天到几个月不等

 

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

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

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

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

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

3  数据表的分类

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

  

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

表类型	表说明
核心表	数据生命周期长，读比写的访问频率高，数据增长慢
恒数表	数据量小，总是读，很少写
递增表	数据量大，经常读，很少写。某些情况会频繁写。

 

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

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

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

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

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

 

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

表类型	表说明
过程表	数据生命周期短，写比读的访问频率高，数据增长快
流水表	数据量大，经常写，很少读。只插不改，定期删。
状态表	数据量大，经常写，经常读。边插边改边删。

 

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

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

 

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

 

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

 

识别项	恒数表	递增表	流水表	状态表
数据流向	几乎不流动	数据很少流动	数据不流动	数据在不同的表之间流动
数据的访问特点	读很频繁，很少写	读很频繁，很少写，每次仅访问表中的极少量数据	只插不改不删，数据生成后只用来备查	读和写都很频繁，不光是插还要改和删
数据量	数据量小，一般在万条以内	数据量大，一般在几万条到上亿条以内	数据量很大，一般在几十万条到上亿条以内	数据量很大，一般在几千条到上千万条以间
数据的增长量	几乎不增长	增长缓慢	增长快	增长快
数据生命周期	长	长	短	很短

4  存储参数设计(略) 

5  数据存储模式的设计(略)

6  成功应用数据存储模式的步骤(略)

原文链接 :http://labs.chinamobile.com/mblog/100128_48277

 

大数据量的系统的数据库结构如何设计

1、把你表中经常查询的和不常用的分开几个表，也就是横向切分
2、把不同类型的分成几个表，纵向切分
3、常用联接的建索引
4、服务器放几个硬盘，把数据、日志、索引分盘存放，这样可以提高IO吞吐率
5、用优化器，优化你的查询
6、考虑冗余，这样可以减少连接
7、可以考虑建立统计表，就是实时生成总计表，这样可以避免每次查询都统计一次
8、用极量数据测试一下

数据仓库解决的是数据挖掘，共享，和大数据量存储有什么根本关系？
mrzxc 等说的好，考虑你的系统，注意负载平衡，查询优化，25 万并不大，可以建一个表，然后按mrzxc 的3 4 5 7 优化。


速度，影响它的因数太多了，且数据量越大越明显。
1、存储
将硬盘分成NTFS格式，NTFS比FAT32快，并看你的数据文件大小，1G以上你可以采用多数据库文件，这样可以将存取负载分散到多个物理硬盘或磁盘阵列上。

2、tempdb
tempdb也应该被单独的物理硬盘或磁盘阵列上,建议放在RAID 0上，这样它的性能最高,不要对它设置最大值让它自动增长

3、日志文件
日志文件也应该和数据文件分开在不同的理硬盘或磁盘阵列上，这样也可以提高硬盘I/O性能。

4、分区视图
就是将你的数据水平分割在集群服务器上，它适合大规模OLTP,SQL群集上，如果你数据库不是访问特别大不建议使用。

5、簇索引
你的表一定有个簇索引，在使用簇索引查询的时候，区块查询是最快的，如用between，应为他是物理连续的，你应该尽量减少对它的updaet,应为这可以使它物理不连续。

6、非簇索引
非簇索引与物理顺序无关，设计它时必须有高度的可选择性，可以提高查询速度，但对表update的时候这些非簇索引会影响速度，且占用空间大，如果你愿意用空间和修改时间换取速度可以考虑。

7、索引视图
如果在视图上建立索引,那视图的结果集就会被存储起来，对与特定的查询性能可以提高很多，但同样对update语句时它也会严重减低性能，一般用在数据相对稳定的数据仓库中。

8、维护索引
你在将索引建好后，定期维护是很重要的，用dbcc showcontig来观察页密度、扫描密度等等，及时用dbcc indexdefrag来整理表或视图的索引,在必要的时候用dbcc dbreindex来重建索引可以受到良好的效果。

不论你是用几个表1、2、3点都可以提高一定的性能，5、6、8点你是必须做的，至于4、7点看你的需求，我个人是不建议的。

  

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



原文链接 ：http://www.cnblogs.com/ronli/archive/2009/05/14/1456582.html