数据库优化-水平切分-以及在实际项目中的应用

    数据库水平分区,相对垂直分区,需要做的工作和事情要多一些,但是对一些行数据特别多的表,非常有必要。

    在我在BDC项目中的不断优化中,总结了下面几种常用的数据库水平切分方法:

1.  表分区;

2.  表拆分;

3.  表分库;

 

表分区

表分区是ORACLE和新版本的MYSQL数据库中,一个非常强大的功能。非常值得学习。

但是表分区如果用不好,性能反倒会下降。我记得我们的另外一个项目组,他们就尝试使用表分区,于是安排了一个没有相关经验的开发人员去研究,研究了几天,然后发现速度更加慢了,于是,表分区的计划就此终止。这是题外话。

    在选定表分区这个方案之后,首先要做的第一件事情,那就是要树立信心,表分区在处理大表数据的情况下,是一定有效果的,如果效果不明显或者没效果甚至效果变差了,那么首先要考虑是不是用的地方不太对。

    先说我们项目的实际情况,核心电话表当初的大小是1.2亿,我们选择的方案是表分区,那么接下来就是要根据数据情况,对这些数据进行不同维度的区分,让它更好的为业务服务。

我们的表中有一个很关键的内容,那就是地区;每一个电话信息,对应一个地区,这个是我们全国性电信数据的一个基本特征。

    那么是区分到省一级呢,还是到地市一级呢?我们有数据的省级行政区是32个,地市是300多个。分区不能太零碎,除非有确切的需要,否则以后运维是一个非常头疼的事情。那么我们在省一级区划上作为分区的条件。

    分区设计了,如果在SQL中就要体现出来,如果不体现分区,有可能会让效率降低。

    使用分区比较简单,一种是直接明确分区,比如

select * from tel PARTITION (310000) ;其中PARTITION (310000)是指上海的数据分区,其中310000是上海市对应的国家标准编码;

这是一种写法,我个人更加倾向于另外一种写法:

Select* from tel t where t.prov_code = 310000

其中,分区的标注就是创建在prov_code 这个字段上,ORACLE会自动调用分区的特性。

 

    就结果而言,通过类似的分区改造之后,峰值吞吐量从以前一天400万数据,数据库就要挂掉,最高达到了一天处理1200万数据,数据库貌似还有余力,效果还是不错的。

   

    表分区涉及的概念和功能蛮多的,有空整理下这方面的内容。

 

表拆分

    表拆分是一门古老的技术,也很实用。我们很久以前做电信黄页,那个时候表分区还没有成熟,我们处理大表最常用的技术就是表拆分了。

    表拆分从逻辑上非常简单,我们有一张9000万数据的号簿表,包含了31个省公司的号簿数据,这些数据同时由31个省公司进行维护。

    9000万的数据,无论是检索,修改,删除,对性能的影响都是很高。那就按照省份直接进行拆分吧。创建出31张表替代这一张,然后创建一个全国性视图,供集团使用。

 

表分库

    我们在表分区里提到了隔壁一个项目组,尝试使用表分区没有成功,但是活人不能被尿憋死,他们也找到了他们适合的方法,这个办法就是表分库。

    表分库是什么呢?其实我们的数据库主备机制,就是一个表分库的雏形。他们是怎么做的呢,首先准备硬件,购买了一组数据库硬件;然后把现有的数据库复制一份到新硬件上去,把业务数据清理干净,把常量数据保留;然后对系统做简单的调整,长江南边的进入老系统,访问老数据库;长江北面的进入新系统,访问新数据库。

    除了花钱有一点之外,改造风险确实蛮小的。当然,不是所有的系统都能这样分库。

 

    综上所述,当数据库到达一定规模,垂直切分和水平切分都是项目负责人必须要考虑的问题,无论使用哪种方式,都需要在了解业务的基础上,根据本系统的实际情况,选择一个最合适的方法。

 

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。