Oracle RAC vs SQL Server 第六篇: Data Dependent Routing（又称“数据拆分方案”）
Oracle RAC vs SQL Server 第六篇: Data Dependent Routing（又称“数据拆分方案”）
在之前的文章中，我们已经讲述了很多有关SQL Server水平扩展的话题，今天我们就来看看最后一种方案，其实关于SQL Server扩展的方案非常多，我们本系列文章只是介绍了其中的几种。其实，很多的时候，我更愿意这些方案称之为“数据库水平扩展模式”，因为真的和我们编程世界中的“设计模式“的很多的概念类似。
如果使用了Data Dependent Routing（后文简称之为DDR），那么数据被分割，放在不同的数据库中，然后应用程序通过相关的逻辑或者采用中间件的方式将对数据的操作路由到正确的数据库上。使用DDR之后，它对应用程序的透明性明显的减弱，因为应用程序需要知道它所操作的数据到底在哪里。
DDR不是SQL Server直接支持的，但是可以通过一定的设计来实现。并且，这种方式已经由来已久，而且在现在的很多的大型的站点和应用中都用的比较多了。说的更加的通俗一点，这种方式很多时候和我们说的“根据业务拆分“有一定的联系。
下面，我们首先来看一个简单的例子，如图：
看到这个图，大家基本心里有数了。这个拆分用的很多了。进行拆分之后，查询就被分散在各个不同的数据库服务器上。同时，对数据的更新操作也分散了。这样可以再很大的程度上面提升性能，但是带来的就是数据管理的复杂性：在查询的时候，需要知道去哪一个或者那几个数据库上面查询相应的数据；在进行更新等操作的时候，也是需要去操作哪一个或者哪些数据库。
在上面的例子中，将Customer的ID作为分隔键，然后一定的算法将不同的ID的数据分布在不同的数据库中。考虑到Customer表在应用中的使用和相关的业务，也把与Customer相关的其他信息，如订单，等分布在相同的数据库中，这样就避免跨数据库，跨网络查询。
我们把这些与Customer相关的信息称之为Customer的实体集合信息。所以在进行数据分割的时候，有点需要非常的注意：把Customer与Customer的实体集合信息分布在一起，这样就使得每个数据分割都是一个独立包含的小完整体。随着数据的不断变多，那么这些不同的数据分割小完整体再次分割。
通过上面的方式，我们已经把数据按照Customer的ID进行分割，接下来才是问题的关键：应用程序如何知道哪一个ID的Customer的相关信息在哪里？
上面的问题说的更加的通俗一点就是：对于某个Customer，我们怎么知道它的数据在哪个服务器上面。
一个最容易，也是最常用的方法就是：建立映射表。这个是必须的。
建立映射表的方式有很多，我这里只是随便的提几个：
1.如把映射表放在某个共享内存中，如采用分布式缓存，那么应用程序的数据访问层都去共享的内存中去查找这个映射表，然后定位到对应的数据库服务器，然后进行数据的操作。
2.把映射表放在某个数据库中，这个数据库最好是单独的，当然，也可以放在之前分割数据库中的任一个。这个没有硬性的规矩。
当然，上面的几种方式不是“有你没我”，可以结合在一起使用。映射表的基本结构如下：
映射表的设计可以有很多的方式，只要起到“映射”的效果就行了，一般是字典的形式。如果上述中的，通过映射表，可以知道Customer的ID<10000的数据，需要查询数据库服务器A，以此类推。
DDR主要是使用在写操作非常多的应用中，对于高并发的更新的应用来说效果非常的好。DDR需要应用程序的数据访问层知道如何把请求发送到正确的数据库。而且对于DDR而言，最好是在应用程序一开始设计的时候就采用，如果在现有的应用中采用，那么应用程序就要发生很大的变化，因为甚至数据访问层的逻辑都要改写。当然，如何有合适的中间件，那么倒是可以再现有的程序中使用DDR。
另外，给大家看一个案例，这个案例就是MSN中使用的。
在图中：
1.Web Servers运行于IIS之上，用来处理客户端用户发送的请求
2.数据分割映射表位于LPS服务器之上，并且保存在SQL Server 2000中。
3.数据分割的小完整体保存在很多的不同的数据库服务器上面。
4.MSN扩展管理层用来决定每个数据操作的正确数据库
在MSN的案例中，数据的拆分是通过每个User的ID进行的。这个原理和之前讲述的Customer很类似，这里就不说了，大家多多的体会吧。
更多：
| SQL Server横向扩展：设计，实现与维护(1)-不得不知道的问题 |
|---|
| SQL Server横向扩展：设计，实现与维护(2)- 分布式分区视图 |
|---|
