oracle分表开源框架,<Oracle优化新常态>第四章 分库分表

第四章 分库分表

小凡仙 海鲨数据库架构师

市面上流行的分库分表的说法,其实都是来自MYSQL那伙人的.MYSQL DBA 太弱鸡了,毛办法,没有分区表,数量那么太,用户那么变态。什么根据水平拆表，USER_ID= 分到其他库中。

MYSQL DBA 爱拆法

Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。不太严格的讲，对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密(比如同一模块)的表切分出来放在一个server上。如果表并不多，但每张表的数据非常多，这时候适合水平切分，即把表的数据按某种规则(比如按ID散列)切分到多个数据库(server)上。当然，现实中更多是这两种情况混杂在一起，这时候需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列。下面分别详细地介绍一下垂直切分和水平切分.

垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。(这也就是所谓的”share nothing”)。

水平切分于垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更为复杂一些。

让我们从普遍的情况来考虑数据的切分：一方面，一个库的所有表通常不可能由某一张表全部串联起来，这句话暗含的意思是，水平切分几乎都是针对一小搓一小搓(实际上就是垂直切分出来的块)关系紧密的表进行的，而不可能是针对所有表进行的。另一方面，一些负载非常高的系统，即使仅仅只是单个表都无法通过单台数据库主机来承担其负载，这意味着单单是垂直切分也不能完全解决问明。因此多数系统会将垂直切分和水平切分联合使用，先对系统做垂直切分，再针对每一小搓表的情况选择性地做水平切分。从而将整个数据库切分成一个分布式矩阵。

ORACLE DBA 爱拆法

第一 业务拆分法 也就是前面两张讲的按业务，按功能业务拆分法

第二 就是按 SQL请求特性 拆分法 ： OLAP OLTP OLQP OLHP

第三 分表法

3.1 垂直拆分法：

根据字段使用频率拆分， 就是有些常用的字段放在一个表中，其他不常用的字段放在另外个表中。 垂直拆分叫法跟 MYSQL 不一样了

3.2 水平拆分法：

一般使用分区技术。根据某个字段的值 把数据分在不同表中。 比如根据时间字段，状态字段， ID值。 时间字段采用范围分区，状态字段采用列表分区，ID采用散列分区。

3.3 根据生命周期拆分法：

根据用户对数据的使用频繁度来把表拆成，热表，温表，冷表或者是说 当前表 历史表。

第四 物理服务器架构

对于 按业务拆分的库， 一般都是独立的数据库，数据库之间的数据不做同步，减少耦合性。只是在应用程序上做个服务接口，为其他业务提供本库的数据服务。

对于 SQL请求特性拆库的话，就需要完成数据同步服务了！

比如OLTP 一般采用集群模式，或者是主备模式

而OLAP 一般采用独立的数据库，通过OGG来或者简单的DBLINK来从OLTP里获得数据。

OLAP 主要是为了统计而重新设计的，可以在使用32KB空间，压缩技术，结果集缓存，创建N多索引，而不用当心影响OLTP插入性能。

OLQP 一般可以同过 主备模式 从OLTP 及时同步数据到DG库上。 主库可以单独拿出一个实列完成DG的数据传输，使用LGWR +ASYNC 及时把数据传给到DG库上。log_archive_dest_30 可以支持30个DG。

这样会对主数据库带来性能压力。毕竟太多了，需要LGWR进程工作。支持4-5台DG，还是可以的。 4-5台ORACLE DG性能完胜MYSQL 100台服务器。

应用程序可以通过 TNSNAME.ORA里面的配置进行负载均衡到不同的DG上。

说实在的MYSQL 分库分表技术难度很高，实现很麻烦，还需要数据库中间件来帮忙，需要这个分区表是存在哪个库中。而ORACLE 就容易多了。

一般通过DG 就能很好完成分库分表的工作。20台ORACLE服务器就能跟100台MYSQL服务器一样出色。可以支持中小型电商网站的用户请求量。

关于费用！ 基本上很多民营企业使用D版的，而且也没人去查。如果要买正版可以买一个CPU的LINCES 大约20-30万。 至于你日后装在多少台服务器上，它也不那么管。