浅谈数据库的分割技术

　　随着社会的日益进步，各行业的运营支撑系统都面临着越来越大的压力，承受着业务数据量、访问并发数的飞速增长的双重巨大压力，在我们电信行业，同样面临着这样的难题，是否有一套适合可行的方案来应对呢？

　　本文重点描述数据库的分割技术，如果能适当的应用在生产中，必然能极大减缓来自与日俱增的业务量带来的巨大压力。

　　如何分割？我们可以从如下六个方面来考虑：

　　一、读写分离分布技术

　　由于数据库存在这样的特性，索引可以提升查询的性能，但却极大地影响了DML操作的性能。面对此类矛盾很多人都很困惑，其实我们可以对其进行分割，将实时更新的数据库同步复制到另外一个库中，该库以读操作为主，而索引则建立在只读库中，实现了最简单的读写分离．当前计费应用中已经使用了该技术，采用的是DSG同步复制软件工具，取得了不错的效果。Myspace公司早期（2004年前后）只有50万用户时，数据库服务器无法满足当时的要求．后来采用了三台SQLSERVER服务器，一个为主，所有数据向它提交，再由它复制到另外两个库上，这样减少了压力，成功的度过了难关。

　　二、垂直分割技术

　　随着业务的发展，Myspace公司在2005年用户达到了200万，存储成了最大的瓶颈．此时该公司进行了第二次切割，对数据库采用垂直分割，分出多个数据库，不同数据库运行不同业务，这样极大的缓解了IO，再次度过了难关。在计费系统中，也采用了这样的技术，成功的将原有的数据库分离成账务Cal、统计Stat、计费Bill等多个数据库，也极大的缓解了IO的瓶颈，这也是成功的垂直切分技术的运用。

　　三、水平分割技术

　　Myspace公司随着业务的飞速发展，很快在2006年实现了千万用户的飞速增长．这个时候，由于业务量过于庞大，被切割出的每一个单独的业务难以避免产生了IO瓶颈，这个时侯水平分割技术得以应用。Myspace公司对所有的用户进行了水平分割，平均一个数据库保存了多个用户及对应信息，多的数据库用户数达到近200万个。这样数据库无形中又被进行了进一步的切割了，变的更细小了，无论是访问响应还是数据迁移，都得到了极大的提升，Myspace公司再次度过了难关！当前电信诸多项目并未在水平切割上做太多的规划，实际上我们可以借鉴Myspace公司的成功案例，尝试将水平切割技术可以应用到我们电信项目中，成为应对缓解数据库压力的利器之一。

　　四、虚拟化存储技术

　　水平分割可以解决数据库主机的性能问题，但是还可能存在这样的一种情况，就是被切割的数据库及用户可能存在有的访问量大，有的访问量小的不均匀情况。这个时侯我们可以考虑引进现在新的存储技术，比如虚拟化存储技术，比较著名的有3PARdata的虚拟存储技术，让存储统一管理负载均衡。

　　五、web缓存分割技术

　　Myspace公司在2008年用户数终于突破了亿的大关，这个时候他们引进了新的技术，那就是数据缓存层技术，在WEB和数据库服务器之间做了一次分割，增加了一个能存储频繁访问内容的数据库副本，这样极大地减少了访问的量，原先1000个用户查询同一数据，需查询数据库1000次，现在也许只需要1次。WEB缓存切割成功地支撑住了过亿用户访问量的巨大压力。当前网管项目组中通过自我编程的方式进行WEB缓存，并取得了不错的效果，这种思想正是切割技术的体现。

　　六、存储CACHE缓存分割技术

　　为了进一步提升在数据库方面的支撑能力，最后Myspace公司在数据库和物理存储中再次做了切割，引入了存储的多层CACHE机制，数据库在写入到多层CACHE后，交互就算完成，这样极大的减少了IO操作。而CACHE层面由于存在断电的危险，所以，在除了不断电设备外，还做了多个CACHE镜像，保证了安全性。七、结束语数据库的切割技术是一种重要的设计思想．Myspace公司当前的月访问量达400亿，甚至超过了YAHoo公司，在成功引入并实施了这些切割技术后，依然运行高效平稳！我们电信项目组也有使用了相关的部分切割技术，并且取得了不错的效果。但是随着业务发展的趋势，仅仅当前采用的切割技术是不够的．不过相信我们只要有这方面的良好意识，能借鉴Myspace等公司的成功案例，就一定能在将来应对飞速增长数据量的压力方面打个漂亮战．当然，光有分割的思想意识是不够的，实施方面还有着相当的难度，无论开发、维护、业务需求、总体架构等各方面都需综合考虑，任重而道远！

　　数据库表分割技术包含以下内容:水平分割/垂直分割/库表散列.接下来将对以上分割进行详细介绍，感兴趣的朋友可以了解下，对你日后维护数据库是很有帮助的。

　　一．水平分割

　　什么是水平分割？打个比较形象的比喻，在食堂吃饭的时候，只有一个窗口，排队打饭的队伍太长了，都排成S型了，这时容易让排队的人产生焦虑情绪，容易产生混乱，这时一个管理者站出来，增加多个打饭窗口，把那条长长的队伍拦腰截断成几队。更形象一点的理解，你拿一把“手术刀”，把一个大表猛的切了几刀，结果这个大表，变成了几个小表.

　　水平分割根据某些条件将数据放到两个或多个独立的表中。即按记录进分分割，不同的记录可以分开保存，每个子表的列数相同。水平切割将表分为多个表。每个表包含的列数相同，但是数据行更少。例如，可以将一个包含十亿行的表水平分区成12个表，每个小表表示特定年份内一个月的数据。任何需要特定月份数据的查询只需引用相应月份的表。

　　通常用来水平分割表的条件有：日期时间维度、地区维度等，当然还有更多的业务维度。下面我举几个例子来解说一下

　　案例1：某个公司销售记录数据量太大了，我们可以对它按月进行水平分割，每个月的销售记录单独成一张表。

　　案例2：某个集团在各个地区都有分公司，该集团的订单数据表太大了，我们可以按分公司所在的地区进行水平切割。

　　案例3：某电信公司的话单按日期、地市水平切割后，发现数据量太大，然后他们又按品牌、号码段进行水平切割

　　水平分割通常在下面的情况下使用：

　　（1）表数据量很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，加快了查询速度。

　　（2）表中的数据本来就有独立性，例如表中分别记录各个地区的数据或不同时期的数据，特别是有些数据常用，而另外一些数据不常用。

　　（3）需要把数据存放到多个介质上。

　　（4）需要把历史数据和当前的数据拆分开。

　　优点：

　　1：降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，加快了查询速度。

　　缺点：

　　1：水平分割会给应用增加复杂度，它通常在查询时需要多个表名，查询所有数据需要union操作。在许多数据库应用中，这种复杂性会超过它带来的优点，因为只要索引关键字不大，则在索引用于查询时，表中增加两到三倍数据量，查询时也就增加读一个索引层的磁盘次数。

　　二．垂直分割

　　什么是垂直分割呢？打个形象的比喻，一个小公司通过短短几年发展变成了一个跨国大企业，以前的部门架构明显不能满足现在的业务发展，CEO噼里啪啦的把公司分成了财务部、人事部、生产部、销售部门.....，一下子成立了多个部门，各司其职。这个还算比较形象吧，有木有？呵呵

　　你垂直分割表（不破坏第三范式），把主码(主键)和一些列放到一个表，然后把主码(主键)和另外的一些列放到另一个表中。将原始表分成多个只包含较少列的表。如果一个表中某些列常用，而另外一些列不常用，则可以采用垂直分割。

　　优点：

　　1：垂直分割可以使得行数据变小，一个数据块(Block)就能存放更多的数据，在查询时就会减少I/O次数(每次查询时读取的Block就少)。

　　2：垂直分割表可以达到最大化利用Cache的目的。

　　缺点：

　　1：表垂直分割后，主码(主键)出现冗余，需要管理冗余列

　　2：会引起表连接JOIN操作（增加CPU开销）需要从业务上规避

　　三.库表散列

　　表散列与水平分割相似，但没有水平分割那样的明显分割界限，采用Hash算法把数据分散到各个分表中,这样IO更加均衡。一般来说，我们会按照业务或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，散列128张表，则应就能够低成本的提升系统的性能并且有很好的扩展性。

　　小编结语：

　　更多内容尽在课课家教育！