SQL如何快速处理海量数据?

Posted 2023-05-16

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了SQL如何快速处理海量数据?相关的知识，希望对你有一定的参考价值。

在以下的文章中，我将以“办公自动化”系统为例，探讨如何在有着1000万条数据的MS SQL SERVER数据库中实现快速的数据提取和数据分页。以下代码说明了我们实例中数据库的“红头文件”一表的部分数据结构：

CREATE TABLE [dbo].[TGongwen] ( --TGongwen是红头文件表名

[Gid] [int] IDENTITY (1, 1) NOT NULL ,
--本表的id号，也是主键

[title] [varchar] (80) COLLATE Chinese_PRC_CI_AS NULL ,
--红头文件的标题

[fariqi] [datetime] NULL ,
--发布日期

[neibuYonghu] [varchar] (70) COLLATE Chinese_PRC_CI_AS NULL ,
--发布用户

[reader] [varchar] (900) COLLATE Chinese_PRC_CI_AS NULL ,

--需要浏览的用户。每个用户中间用分隔符“,”分开

) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

下面，我们来往数据库中添加1000万条数据：

declare @i int

set @i=1

while @i<=250000

begin

insert into Tgongwen(fariqi,neibuyonghu,reader,title) values('2004-2-5','通信科','通信科,办公室,王局长,刘局长,张局长,admin,刑侦支队,特勤支队,交巡警支队,经侦支队,户政科,治安支队,外事科','这是最先的25万条记录')

set @i=@i+1

end

GO

declare @i int

set @i=1

while @i<=250000

begin

insert into Tgongwen(fariqi,neibuyonghu,reader,title) values('2004-9-16','办公室','办公室,通信科,王局长,刘局长,张局长,admin,刑侦支队,特勤支队,交巡警支队,经侦支队,户政科,外事科','这是中间的25万条记录')

set @i=@i+1

end

GO

declare @h int

set @h=1

while @h<=100

begin

declare @i int

set @i=2002

while @i<=2003

begin

declare @j int

set @j=0

while @j<50

begin

declare @k int

set @k=0

while @k<50

begin

insert into Tgongwen(fariqi,neibuyonghu,reader,title) values(cast(@i as varchar(4))+'-8-15 3:'+cast(@j as varchar(2))+':'+cast(@j as varchar(2)),'通信科','办公室,通信科,王局长,刘局长,张局长,admin,刑侦支队,特勤支队,交巡警支队,经侦支队,户政科,外事科','这是最后的50万条记录')

set @k=@k+1

end

set @j=@j+1

end

set @i=@i+1

end

set @h=@h+1

end

GO

declare @i int

set @i=1

while @i<=9000000

begin

insert into Tgongwen(fariqi,neibuyonghu,reader,title) values('2004-5-5','通信科','通信科,办公室,王局长,刘局长,张局长,admin,刑侦支队,特勤支队,交巡警支队,经侦支队,户政科,治安支队,外事科','这是最后添加的900万条记录')

set @i=@i+1000000

end

GO

通过以上语句，我们创建了25万条由通信科于2004年2月5日发布的记录，25万条由办公室于2004年9月6日发布的记录，2002年和2003年各100个2500条相同日期、不同分秒的由通信科发布的记录（共50万条），还有由通信科于2004年5月5日发布的900万条记录，合计1000万条。

一、因情制宜，建立“适当”的索引

建立“适当”的索引是实现查询优化的首要前提。

索引（index）是除表之外另一重要的、用户定义的存储在物理介质上的数据结构。当根据索引码的值搜索数据时，索引提供了对数据的快速访问。事实上，没有索引,数据库也能根据SELECT语句成功地检索到结果，但随着表变得越来越大，使用“适当”的索引的效果就越来越明显。注意，在这句话中，我们用了“适当”这个词，这是因为，如果使用索引时不认真考虑其实现过程，索引既可以提高也会破坏数据库的工作性能。

（一）深入浅出理解索引结构

实际上，您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引（clustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）。下面，我们举例来说明一下聚集索引和非聚集索引的区别：

其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。

我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。

如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。

我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。

通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。

进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。

（二）何时使用聚集索引或非聚集索引

下面的表总结了何时使用聚集索引或非聚集索引（很重要）。

动作描述

使用聚集索引

使用非聚集索引

列经常被分组排序

应

应

返回某范围内的数据

应

不应

一个或极少不同值

不应

不应

小数目的不同值

应

不应

大数目的不同值

不应

应

频繁更新的列

不应

应

外键列

应

应

主键列

应

应

频繁修改索引列

不应

应

事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可；而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。

（三）结合实际，谈索引使用的误区

理论的目的是应用。虽然我们刚才列出了何时应使用聚集索引或非聚集索引，但在实践中以上规则却很容易被忽视或不能根据实际情况进行综合分析。下面我们将根据在实践中遇到的实际问题来谈一下索引使用的误区，以便于大家掌握索引建立的方法。

1、主键就是聚集索引

这种想法笔者认为是极端错误的，是对聚集索引的一种浪费。虽然SQL SERVER默认是在主键上建立聚集索引的。

通常，我们会在每个表中都建立一个ID列，以区分每条数据，并且这个ID列是自动增大的，步长一般为1。我们的这个办公自动化的实例中的列Gid就是如此。此时，如果我们将这个列设为主键，SQL SERVER会将此列默认为聚集索引。这样做有好处，就是可以让您的数据在数据库中按照ID进行物理排序，但笔者认为这样做意义不大。

显而易见，聚集索引的优势是很明显的，而每个表中只能有一个聚集索引的规则，这使得聚集索引变得更加珍贵。

从我们前面谈到的聚集索引的定义我们可以看出，使用聚集索引的最大好处就是能够根据查询要求，迅速缩小查询范围，避免全表扫描。在实际应用中，因为ID号是自动生成的，我们并不知道每条记录的ID号，所以我们很难在实践中用ID号来进行查询。这就使让ID号这个主键作为聚集索引成为一种资源浪费。其次，让每个ID号都不同的字段作为聚集索引也不符合“大数目的不同值情况下不应建立聚合索引”规则；当然，这种情况只是针对用户经常修改记录内容，特别是索引项的时候会负作用，但对于查询速度并没有影响。

在办公自动化系统中，无论是系统首页显示的需要用户签收的文件、会议还是用户进行文件查询等任何情况下进行数据查询都离不开字段的是“日期”还有用户本身的“用户名”。

通常，办公自动化的首页会显示每个用户尚未签收的文件或会议。虽然我们的where语句可以仅仅限制当前用户尚未签收的情况，但如果您的系统已建立了很长时间，并且数据量很大，那么，每次每个用户打开首页的时候都进行一次全表扫描，这样做意义是不大的，绝大多数的用户1个月前的文件都已经浏览过了，这样做只能徒增数据库的开销而已。事实上，我们完全可以让用户打开系统首页时，数据库仅仅查询这个用户近3个月来未阅览的文件，通过“日期”这个字段来限制表扫描，提高查询速度。如果您的办公自动化系统已经建立的2年，那么您的首页显示速度理论上将是原来速度8倍，甚至更快。

在这里之所以提到“理论上”三字，是因为如果您的聚集索引还是盲目地建在ID这个主键上时，您的查询速度是没有这么高的，即使您在“日期”这个字段上建立的索引（非聚合索引）。下面我们就来看一下在1000万条数据量的情况下各种查询的速度表现（3个月内的数据为25万条）：

（1）仅在主键上建立聚集索引，并且不划分时间段：

Select gid,fariqi,neibuyonghu,title from tgongwen

用时：128470毫秒（即：128秒）

（2）在主键上建立聚集索引，在fariq上建立非聚集索引：

select gid,fariqi,neibuyonghu,title from Tgongwen

where fariqi> dateadd(day,-90,getdate())

用时：53763毫秒（54秒）

（3）将聚合索引建立在日期列（fariqi）上：

select gid,fariqi,neibuyonghu,title from Tgongwen

where fariqi> dateadd(day,-90,getdate())

用时：2423毫秒（2秒）

虽然每条语句提取出来的都是25万条数据，各种情况的差异却是巨大的，特别是将聚集索引建立在日期列时的差异。事实上，如果您的数据库真的有1000万容量的话，把主键建立在ID列上，就像以上的第1、2种情况，在网页上的表现就是超时，根本就无法显示。这也是我摒弃ID列作为聚集索引的一个最重要的因素。

得出以上速度的方法是：在各个select语句前加：declare @d datetime

set @d=getdate()

并在select语句后加：

select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())

2、只要建立索引就能显著提高查询速度

事实上，我们可以发现上面的例子中，第2、3条语句完全相同，且建立索引的字段也相同；不同的仅是前者在fariqi字段上建立的是非聚合索引，后者在此字段上建立的是聚合索引，但查询速度却有着天壤之别。所以，并非是在任何字段上简单地建立索引就能提高查询速度。

从建表的语句中，我们可以看到这个有着1000万数据的表中fariqi字段有5003个不同记录。在此字段上建立聚合索引是再合适不过了。在现实中，我们每天都会发几个文件，这几个文件的发文日期就相同，这完全符合建立聚集索引要求的：“既不能绝大多数都相同，又不能只有极少数相同”的规则。由此看来，我们建立“适当”的聚合索引对于我们提高查询速度是非常重要的。

3、把所有需要提高查询速度的字段都加进聚集索引，以提高查询速度

上面已经谈到：在进行数据查询时都离不开字段的是“日期”还有用户本身的“用户名”。既然这两个字段都是如此的重要，我们可以把他们合并起来，建立一个复合索引（compound index）。

很多人认为只要把任何字段加进聚集索引，就能提高查询速度，也有人感到迷惑：如果把复合的聚集索引字段分开查询，那么查询速度会减慢吗？带着这个问题，我们来看一下以下的查询速度（结果集都是25万条数据）：（日期列fariqi首先排在复合聚集索引的起始列，用户名neibuyonghu排在后列）

（1）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>'2004-5-5'

查询速度：2513毫秒

（2）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>'2004-5-5' and neibuyonghu='办公室'

查询速度：2516毫秒

（3）select gid,fariqi,neibuyonghu,title from Tgongwen where neibuyonghu='办公室'

查询速度：60280毫秒

从以上试验中，我们可以看到如果仅用聚集索引的起始列作为查询条件和同时用到复合聚集索引的全部列的查询速度是几乎一样的，甚至比用上全部的复合索引列还要略快（在查询结果集数目一样的情况下）；而如果仅用复合聚集索引的非起始列作为查询条件的话，这个索引是不起任何作用的。当然，语句1、2的查询速度一样是因为查询的条目数一样，如果复合索引的所有列都用上，而且查询结果少的话，这样就会形成“索引覆盖”，因而性能可以达到最优。同时，请记住：无论您是否经常使用聚合索引的其他列，但其前导列一定要是使用最频繁的列。

（四）其他书上没有的索引使用经验总结

1、用聚合索引比用不是聚合索引的主键速度快

下面是实例语句：（都是提取25万条数据）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'

使用时间：3326毫秒

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid<=250000

使用时间：4470毫秒

这里，用聚合索引比用不是聚合索引的主键速度快了近1/4。

2、用聚合索引比用一般的主键作order by时速度快，特别是在小数据量情况下

select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by fariqi

用时：12936

select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by gid

用时：18843

这里，用聚合索引比用一般的主键作order by时，速度快了3/10。事实上，如果数据量很小的话，用聚集索引作为排序列要比使用非聚集索引速度快得明显的多；而数据量如果很大的话，如10万以上，则二者的速度差别不明显。

3、使用聚合索引内的时间段，搜索时间会按数据占整个数据表的百分比成比例减少，而无论聚合索引使用了多少个

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1'

用时：6343毫秒（提取100万条）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-6-6'

用时：3170毫秒（提取50万条）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'

用时：3326毫秒（和上句的结果一模一样。如果采集的数量一样，那么用大于号和等于号是一样的）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1' and fariqi<'2004-6-6'

用时：3280毫秒

4 、日期列不会因为有分秒的输入而减慢查询速度

下面的例子中，共有100万条数据，2004年1月1日以后的数据有50万条，但只有两个不同的日期，日期精确到日；之前有数据50万条，有5000个不同的日期，日期精确到秒。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1' order by fariqi

用时：6390毫秒

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi<'2004-1-1' order by fariqi

用时：6453毫秒

（五）其他注意事项

“水可载舟，亦可覆舟”，索引也一样。索引有助于提高检索性能，但过多或不当的索引也会导致系统低效。因为用户在表中每加进一个索引，数据库就要做更多的工作。过多的索引甚至会导致索引碎片。

所以说，我们要建立一个“适当”的索引体系，特别是对聚合索引的创建，更应精益求精，以使您的数据库能得到高性能的发挥。

当然，在实践中，作为一个尽职的数据库管理员，您还要多测试一些方案，找出哪种方案效率最高、最为有效。

二、改善SQL语句

很多人不知道SQL语句在SQL SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。比如：

select * from table1 where name='zhangsan' and tID > 10000

和执行:

select * from table1 where tID > 10000 and name='zhangsan'

一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的10000条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个name='zhangsan'的，而后再根据限制条件条件tID>10000来提出查询结果。

事实上，这样的担心是不必要的。SQL SERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。

虽然查询优化器可以根据where子句自动的进行查询优化，但大家仍然有必要了解一下“查询优化器”的工作原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。

在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，并且可以利用索引快速获得所需数据。

SARG的定义：用于限制搜索的一个操作，因为它通常是指一个特定的匹配，一个值得范围内的匹配或者两个以上条件的AND连接。形式如下：

列名操作符 <常数或变量>

或

<常数或变量> 操作符列名

列名可以出现在操作符的一边，而常数或变量出现在操作符的另一边。如：

Name=’张三’

价格>5000

5000<价格

Name=’张三’ and 价格>5000

如果一个表达式不能满足SARG的形式，那它就无法限制搜索的范围了，也就是SQL SERVER必须对每一行都判断它是否满足WHERE子句中的所有条件。所以一个索引对于不满足SARG形式的表达式来说是无用的。

介绍完SARG后，我们来总结一下使用SARG以及在实践中遇到的和某些资料上结论不同的经验：

1、Like语句是否属于SARG取决于所使用的通配符的类型

如：name like ‘张%’ ，这就属于SARG

而：name like ‘%张’ ,就不属于SARG。

原因是通配符%在字符串的开通使得索引无法使用。

2、or 会引起全表扫描

Name=’张三’ and 价格>5000 符号SARG，而：Name=’张三’ or 价格>5000 则不符合SARG。使用or会引起全表扫描。

3、非操作符、函数引起的不满足SARG形式的语句

不满足SARG形式的语句最典型的情况就是包括非操作符的语句，如：NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等，另外还有函数。下面就是几个不满足SARG形式的例子：

ABS(价格)<5000

Name like ‘%三’

有些表达式，如：

WHERE 价格*2>5000

SQL SERVER也会认为是SARG，SQL SERVER会将此式转化为：

WHERE 价格>2500/2

但我们不推荐这样使用，因为有时SQL SERVER不能保证这种转化与原始表达式是完全等价的。

4、IN 的作用相当与OR

语句：

Select * from table1 where tid in (2,3)

和

Select * from table1 where tid=2 or tid=3

是一样的，都会引起全表扫描，如果tid上有索引，其索引也会失效。

5、尽量少用NOT

6、exists 和 in 的执行效率是一样的

很多资料上都显示说，exists要比in的执行效率要高，同时应尽可能的用not exists来代替not in。但事实上，我试验了一下，发现二者无论是前面带不带not，二者之间的执行效率都是一样的。因为涉及子查询，我们试验这次用SQL SERVER自带的pubs数据库。运行前我们可以把SQL SERVER的statistics I/O状态打开。

（1）select title,price from titles where title_id in (select title_id from sales where qty>30)

该句的执行结果为：

表 'sales'。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。

表 'titles'。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。

（2）select title,price from titles where exists (select * from sales where sales.title_id=titles.title_id and qty>30)

第二句的执行结果为：

表 'sales'。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。

表 'titles'。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。

我们从此可以看到用exists和用in的执行效率是一样的。

7、用函数charindex()和前面加通配符%的LIKE执行效率一样

前面，我们谈到，如果在LIKE前面加上通配符%，那么将会引起全表扫描，所以其执行效率是低下的。但有的资料介绍说，用函数charindex()来代替LIKE速度会有大的提升，经我试验，发现这种说明也是错误的：

select gid,title,fariqi,reader from tgongwen where charindex('刑侦支队',reader)>0 and fariqi>'2004-5-5'

用时：7秒，另外：扫描计数 4，逻辑读 7155 次，物理读 0 次，预读 0 次。

select gid,title,fariqi,reader from tgongwen where reader like '%' + '刑侦支队' + '%' and fariqi>'2004-5-5'

用时：7秒，另外：扫描计数 4，逻辑读 7155 次，物理读 0 次，预读 0 次。

8、union并不绝对比or的执行效率高

我们前面已经谈到了在where子句中使用or会引起全表扫描，一般的，我所见过的资料都是推荐这里用union来代替or。事实证明，这种说法对于大部分都是适用的。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' or gid>9990000

用时：68秒。扫描计数 1，逻辑读 404008 次，物理读 283 次，预读 392163 次。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'

union

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid>9990000

用时：9秒。扫描计数 8，逻辑读 67489 次，物理读 216 次，预读 7499 次。

看来，用union在通常情况下比用or的效率要高的多。

但经过试验，笔者发现如果or两边的查询列是一样的话，那么用union则反倒和用or的执行速度差很多，虽然这里union扫描的是索引，而or扫描的是全表。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' or fariqi='2004-2-5'

用时：6423毫秒。扫描计数 2，逻辑读 14726 次，物理读 1 次，预读 7176 次。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'

union

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-2-5'

用时：11640毫秒。扫描计数 8，逻辑读 14806 次，物理读 108 次，预读 1144 次。

9、字段提取要按照“需多少、提多少”的原则，避免“select *”

我们来做一个试验：

select top 10000 gid,fariqi,reader,title from tgongwen ord 参考技术A 楼上的，太长了吧。在word里有21页，要一万七千多个字符。贴不下的。二楼的答案挺好。我支持参考技术B 对于关键的字段添加主键或者索引。会有效的提高查询速度。参考技术C 可以用数据分页存储过程来操作，可以轻松应付百万数据：
CREATEPROCEDUREpageTest--用于翻页的测试
--需要把排序字段放在第一列(
@FirstIDnvarchar(20)=null,--当前页面里的第一条记录的排序字段的值
@LastIDnvarchar(20)=null,--当前页面里的最后一条记录的排序字段的值
@isNextbit=null,--true1:下一页；false0:上一页
@allCountintoutput,--返回总记录数
@pageSizeintoutput,--返回一页的记录数
@CurPageint--页号（第几页）0：第一页；-1最后一页。
)
AS
if@CurPage=0
begin
--统计总记录数
select@allCount=count(ProductId)fromProduct_test
set@pageSize=10
--返回第一页的数据
select top10 ProductId, ProductName, Introduction from Product_testorderbyProductId
end
elseif@CurPage=-1
select * from (selecttop10ProductId,ProductName,Introduction from Product_test order by ProductId desc) asaa order by ProductId
else
begin
if@isNext=1
--翻到下一页
selecttop10ProductId,ProductName,IntroductionfromProduct_testwhereProductId>@LastIDorderbyProductId
else
--翻到上一页
select*from
(selecttop10ProductId,
ProductName,
Introduction
fromProduct_testwhereProductId<@FirstIDorderbyProductIddesc)asbborderbyProductId
end

海量数据处理－－从分而治之到Mapreduce

海量数据处理常用技术概述

如今互联网产生的数据量已经达到PB级别，如何在数据量不断增大的情况下，依然保证快速的检索或者更新数据，是我们面临的问题。
所谓海量数据处理，是指基于海量数据的存储、处理和操作等。因为数据量太大无法在短时间迅速解决，或者不能一次性读入内存中。

在解决海量数据的问题的时候，我们需要什么样的策略和技术，是每一个人都会关心的问题。今天我们就梳理一下在解决大数据问题
的时候需要使用的技术，但是注意这里只是从技术角度进行分析，只是一种思想并不代表业界的技术策略。
常用到的算法策略

分治：多层划分、MapReduce
排序：快速排序、桶排序、堆排序
数据结构：堆、位图、布隆过滤器、倒排索引、二叉树、Trie树、B树，红黑树
Hash映射：hashMap、simhash、局部敏感哈希

海量数据处理－－从分而治之到Mapreduce

分治

分治是一种算法思想，主要目的是将一个大问题分成多个小问题进行求解，之后合并结果。我们常用到的有归并排序:先分成两部分进行排序，之后在合并，
当然还有其他的很多应用，就比如是我们上篇文章中提到的Top K问题，就是将大文件分成多个小文件进行统计，之后进行合并结果。这里我们对分治进行抽象，
依然从上述提到的Top K频率统计开始出发。定义如下：有M多个Query日志文件记录，要求得到Top K的Query。
我们可以抽象成几个步骤：

多个文件的输入，我们叫做input splits
多进程同时处理多个文档，我们叫做map。
partition 从上文中我们知道。因为我们要将相同的Query映射的一起
多进程处理划分或的文件，我们叫做reduce
合并过个文件的结果，我们叫做merge

上面的这四个步骤是我们从Top K问题抽象出来的，为什么我们对每一步进行一个取名字？因为这就是最简单的MapReduce的原理。我们现在就可以认为之前已经
用过Mapreduce的思想了，它就是这么简单，当然中的很多问题我都没有提出来，但是主要的思想就是这样，很成熟的MapReduce的实现，有Hadoop和CouchDB等。
我给出一张图片来表示这个过程。

MapReduce

MapReduce是一种编程模式、大数据框架的并行处理接口和分布式算法计算平台，主要用于大规模数据集合的并行计算。一个Mapreduce的程序主要有两部分组成: map和reduce. 它主要借鉴了函数式编程语言和矢量编程语言特性。
MapReduce最早是由Google公司研究提出的一种面向大规模数据处理的并行计算模型和方法。Google公司设计MapReduce的初衷主要是为了解决其搜索引擎中大规模网页数据的并行化处理。

MapReduce组成

Map:
用户根据需求设置的Map函数，每一个工作节点(主机)处理本地的数据，将结果写入临时文件，给调用Reduce函数的节点使用。

Shuffle:
在MapReduce的编程模式中，我们要时刻注意到数据结构是(key, value)对，Shuffle就是打乱数据，也是我们之前提到过的Partition处理，主要目的是将相同的key的数据映射到同一个Reduce工作的节点（这是主要的功能，当然还有其他的功能）。

Reduce:
Reduce函数，并行处理相同key的函数，返回结果。

Mapreduce模式这么流行，现在几乎所有的大公司都在使用Hadoop框架，当然可能会有一些优化，不过主要的思想依然是MapReduce模式。在公司中或者个人的使用的时候，我们一般会先搭建Hadoop环境，之后最简单的使用就是提供Map函数和Reduce函数即可，语言可以使用C++、Java、Python等。例如我们提到的Top k问题的伪代码的例子：
```
map(String key, String values):
    // key: 文档名字
    // values: 文档内容
    for each line in values:
        EmitIntemediate(line, "1")

..... // 这中间的省略号，表示还可以加一些代码，
..... // 不加也不影响结果，只是效率问题，后面会提到

reduce(String key, Iterator values):
    // key: a query
    // values: a lists of counts
    int result = 0;
    for each v in values:
        result += ParseInt(v)
    Emit(AsString(result))
```

代码抽象

map:　　　 (k1, v1) 　　 —>　　 list(k2, v2)
reduce: 　　(k2, list(v2)) —> 　　list(v３)

MapReduce支持的数据格式，从上述的代码中，我们可以看到MapReduce的输入和输出都是(k, v)对的格式。当然这只是转换之后的格式，一般来书我们的输入文件都是文件，MapReduce认为第一个分隔符之前的字段是key，后面的values，(values可以不存在，例如我们的Top k问题就没有values)。所有在使用的时候，我们只需要用分隔符空格将key和values分开，每一行代表一个数据，提供我们需要的Map和Reduce函数即可。

文章到此应该已经可以结束了，我们可以在任何MapReduce框架下，根据需求写出map函数和reduce函数。对于想用使用MapReduce的程序员来说，在写函数的时候只需要注意key和value怎么设置，如何编写map和reduce函数，因为中间的细节，运行的框架已经帮我们封装的很好的，这就是为什么Mapreduce在业界流行。这种编程模式很简单，只要提map和reduce函数，对于那些没有并行计算和分布式处理经验的程序员，MapReduce框架帮我们处理好了并行计算、错误容忍、本地读取优化和加载平衡的细节，我们只需要关注业务，不用关心细节，还有就是这么编程模式可以简单的解决很多常见的问题，例如: linux中的grep命令，Sort，Top K，倒排索引等问题。

知其然而知其所以然，不仅更能帮助我们写出更优的代码，更重要的是如何在改进现有的技术，使其更好的应用到我们的业务上，因为很多大公司都会重写这种代码，使其在公司内部更好的应用。

浅谈技术细节

MapReduce模式下我们需要关注的问题如下(参考论文)：

数据和代码如何存储?

设置一个Master，拷贝代码文件，分配给节点进行处理，指定Map或者Reduce已经输入和输出文件的路径。所有Master节点是一个管理节点负责调度。

如何Shuffle？

在MapReduce中都是(key, values)数据，输入的M个文件直接对应M的Map，产生的中间结果key2，通过哈希函数，
hash(key) % R(R是Reduce的个数)。当然我们需要设置一个好的hash函数，保证任务不平衡分到不同的Reduce节点上。

节点之间如何通信？

Master负责调度和通信，其他节点之和Master节点通信，master监控所有节点的信息，比如是map或者reduce任务，是否运行结束，占用的资源、文件读写速度等，master会重新分配那些已经完成的节点任务，对所有的错误的节点重新执行。

节点出现错误如何解决？

因为有master的存在，可以重新执行出现错误的运行节点，注意的是对于出错的map任务，其分配到的reduce任务也要重新执行。节点运行bug，我们可以修改代码，使其更鲁棒，但是有时候我们必须使用try-catch操作跳过一些错误的bad lines.

Map和Reduce个数如何设置？

这个设置和集群的个数和经验有很大关系，建议我们每一个map任务的输入数据16-64MB, 因此map的个数 = 总的文件大小 / 16-64MB. reduce的个数建议大于节点的个数，这样可以保证更好的并行计算。

怎么控制负载平衡？

master会监控所有节点的运行状态，并且要对所有的运行完成的节点重新分配任务，来保证负载均衡，需要注意的是这里的并行计算是map和reduce的分别并行计算，必须保证map执行之后才能执行reduce(因为你有shuffle操作)。

技巧

map任务运行时候尽可能的读取本地或者当前局域内的文件，减少文件传输的网络带宽
M和R的设置会对master的监督有一定的影响，因为要监督所有的状态
备份运行状态很重要，可以知道那台节点运行的缓慢，可能出现异常，可以让其他节点代替它运行任务
shuffle操作的hash函数真的很重要，可以有效的解决负载均衡
map生成的中间文件要根据key进行排序，也可以便于划分
map和reduce之间有时候需要加合并(combiner)操作,可以起到加速作用

参考

以上是关于SQL如何快速处理海量数据?的主要内容，如果未能解决你的问题，请参考以下文章

算法专题之bitmap与布隆过滤器 ----如何快速处理海量数据

海量数据处理技巧

海量数据处理-重新思考排序

海量数据处理－－从分而治之到Mapreduce

海量数据处理-重新思考排序2

MySQL处理海量数据使得一些优化查询速度的方法