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直接支援的，但是可以通過一定的設計來實現。並且，這種方式已經由來已久，而且在現在的很多的大型的網站和應用中都用的比較多了。說的更加的通俗一點，這種方式很多時候和我們說的“根據業務拆分“有一定的聯絡。

下面，我們首先來看一個簡單的例子，

20120917102651.png(21.83 K)9/17/2012 10:34:14 AM

 

看到這個圖，大家基本心裡有數了。這個拆分用的很多了。進行拆分之後，查詢就被分散在各個不同的資料庫伺服器上。同時，對資料的更新操作也分散了。這樣可以再很大的程度上面提升效能，但是帶來的就是資料管理的複雜性：在查詢的時候，需要知道去哪一個或者那幾個資料庫上面查詢相應的資料；在進行更新等操作的時候，也是需要去操作哪一個或者哪些資料庫。

在上面的例子中，將Customer的ID作為分隔鍵，然後一定的演算法將不同的ID的資料分布在不同的資料庫中。考慮到Customer表在應用中的使用和相關的業務，也把與Customer相關的其他資訊，如訂單，等分布在相同的資料庫中，這樣就避免跨資料庫，跨網路查詢。

我們把這些與Customer相關的資訊稱之為Customer的實體集合資訊。所以在進行資料分割的時候，有點需要非常的注意：把Customer與Customer的實體集合資訊分布在一起，這樣就使得每個資料分割都是一個獨立包含的小完整體。隨著資料的不斷變多，那麼這些不同的資料分割小完整體再次分割。

通過上面的方式，我們已經把資料按照Customer的ID進行分割，接下來才是問題的關鍵：應用程式如何知道哪一個ID的Customer的相關資訊在哪裡？

上面的問題說的更加的通俗一點就是：對於某個Customer，我們怎麼知道它的資料在哪個伺服器上面。

一個最容易，也是最常用的方法就是：建立映射表。這個是必須的。

建立映射表的方式有很多，我這裡只是隨便的提幾個：

1.如把映射表放在某個共用記憶體中，如採用分布式緩衝，那麼應用程式的資料訪問層都去共用的記憶體中去尋找這個映射表，然後定位到對應的資料庫伺服器，然後進行資料的操作。

2.把映射表放在某個資料庫中，這個資料庫最好是單獨的，當然，也可以放在之前分割資料庫中的任一個。這個沒有硬性的規矩。

當然，上面的幾種方式不是“有你沒我”，可以結合在一起使用。映射表的基本結構如下：

20120917102743.png(20.82 K)9/17/2012 10:34:14 AM

 

映射表的設計可以有很多的方式，只要起到“映射”的效果就行了，一般是字典的形式。如果上述中的，通過映射表，可以知道Customer的ID<10000的資料，需要查詢資料庫伺服器A，以此類推。

DDR主要是使用在寫操作非常多的應用中，對於高並發的更新的應用來說效果非常的好。DDR需要應用程式的資料訪問層知道如何把請求發送到正確的資料庫。而且對於DDR而言，最好是在應用程式一開始設計的時候就採用，如果在現有的應用中採用，那麼應用程式就要發生很大的變化，因為甚至資料訪問層的邏輯都要改寫。當然，如何有合適的中介軟體，那麼倒是可以再現有的程式中使用DDR。

另外，給大家看一個案例，這個案例就是MSN中使用的。

20120917103155.png(25.47 K)9/17/2012 10:41:19 AM

 

在圖中：

1.Web Servers運行於IIS之上，用來處理用戶端使用者發送的請求

2.資料分割映射表位於LPS伺服器之上，並且儲存在SQL Server 2000中。

3.資料分割的小完整體儲存在很多的不同的資料庫伺服器上面。

4.MSN擴充管理層用來決定每個資料操作的正確資料庫

在MSN的案例中，資料的拆分是通過每個User的ID進行的。這個原理和之前講述的Customer很類似，這裡就不說了，大家多多的體會吧。

 

 

更多：

	SQL Server橫向擴充：設計，實現與維護(1)-不得不知道的問題

	SQL Server橫向擴充：設計，實現與維護(2)- 分散式資料分割檢視

SQL Server橫向擴充：設計，實現與維護（3）- 分散式資料分割檢視的實現