分散式資料庫及表格複製Table Replication

f66666602 · 發表於 2007-9-6 14:47:27

技術專區 - 分散式資料庫及表格複製Table Replication
DBMaker有著另項強大的功能：「分散式資料庫」，但使用者往往忽略；本篇旨在說明，在什麼樣的環境需要使用這樣的功能，及這項功能能帶給使用者的好處。
1. 為什麼需要使用分散式資料庫
簡單地說，資料庫基本上是採集中式管理，但現實生活裏，使用者卻可能分佈在各地。若是使用者處於零散且無規律的地理位置，那麼使用Web或AP Server，來存取資料庫，宛如有個代理人幫您服務，這樣似乎是最好的解決方式，但現實生活中，使用者往往是聚集成數個大「群體」，常見的便是散佈在「分公司」的使用者。

那麼，若將資料庫放置到一個集中地點(例如：台北)，固然是管理上較為方便，但是台中、高雄的使用者，卻要忍受較慢的網路頻寬。
同時，有些地域性的資料，事實上存放在台北總行，並不見得合理，總行可能須要的是台中、高雄的統計性資料，而不需要知道台中分行的雜支費用、電話費用等細部費用。
以人事資料為例，台北有台北的人事資料，台中、高雄也都有各自的人事資料，若在設計表格時，可能會用以下這個方式來設計：
人事表格
姓名
員工編號
…
…
所在地
Sharon
001
…
…
台北
Alen
002
…
…
台中
或是：
台北人事表格
姓名
員工編號
…
…
Sharon
001
…
…




台中人事表格
姓名
員工編號
…
…
Sharon
001
…
…




想一想，所有的應用程式及使用者，必須從台中、高雄直接連接到台北來存取資料庫，可能會花上極為昂貴的時間成本，而所要得到的資料，可能竟是「台中」自己的人事資料!
「分散式資料庫」的設計理念便是：「將一個邏輯性的總體資料庫，分散成數個實體資料庫。」例如，上述公司資料庫，是一個邏輯的整體，我們可將它化整為零，用數個實體資料庫散佈在台中、高雄，如此一來，上述問題便可臨刃而解。
2.    分散式資料庫設計
(1) 橫向分割
橫向分割，即是台北、台中、高雄各地的資料庫，彼此有著相同的結構，而各自存放各自專屬的資料；例如：各地資料庫都有人事、會計、倉儲…等等表格，只是台中放台中的資料，台北放台北自己的資料。
(2) 垂直分割
縱向的垂直分割，便是功能別的切割，例如會計、人事資料放在台北總公司，但由於高雄是倉庫，故倉儲表格放在高雄，若廠商多在台中，那麼廠商、進貨等相關表格就放台中，主以功能別為導向。
(3) 綜合
現實考量上，上述結構未必符合實際需求，所以實際的例子中，往往是綜合上述兩種方式，調整出符合自身需求的架構，例如：倉儲資料可以分佈在各地，而人事、財務方面的資訊可以統一放在台北，方便管理；針對需求面，作兩方面綜合性設計。
1.       功能特性分析

以上圖來說明，實體有三個資料庫，但整個可視作一個邏輯上的資料庫。
在切割時，我們可先將整個系統的存取關係繪製成圖，然後檢視各個表格所含括的是何資料，各個功能又會去存取那些表格資料。

上圖中，以一個「訂貨-出貨」的功能來看，首先User必須先從「客戶-員工-產品」組成一張訂單，新增一筆應收帳款到會計表格、一張出貨單到出貨表格，及減少倉儲資料中存貨的數量。
客戶名單是否有地域性因素?若是台北的user，面對的幾乎都是台北的客戶，台中的user卻幾乎不會處理到台北的客戶，那麼客戶名單列成三份，各地處理各地的，就十分合理。
但是公司的員工，就沒有充分理由割成三地，所以三地的使用者，應該要用同一份的員工名單；同樣的，三地所面對的產品資料亦應一致。
接下來是組合成的訂單，參酌公司條件，在「訂貨-出貨」的動作中，台北下的訂單，與高雄下的訂單，三地資料可獨立，新增「應收帳款」到會計表格也是一樣，三地可各自獨立；(但如果現在總公司要進行「會計」相關的功能，使用者面對的應該是總體的訂單資料，分成台北、台中、高雄並沒有太大的意義)。
倉儲資料應是最地域性的，只要新增一張出貨單到各地倉儲即可，現在以台中的使用者為例，接到台中客戶訂單，在高雄出貨，製圖如下：

再次強調，這樣的架構還是要依公司需求為主，有些公司就不認為客戶資料須要有特別的地域化，而是全公司都使用同一份客戶資料。
我們必須以「功能」(例如：上述的訂單動作)來評斷「分割」的理由性，例如：訂單資料，目前暫定為「分割」，台中組合成的訂單放在台中自己這裏，但是若是現在要作全公司的訂單統計時，這樣的分割反而不好。參酌公司的各項「功能」後，給予衡量權數，來評定「分割」的理由充分性，例如「倉儲資料」的理由性就很夠，因為任何一個倉儲功能(例如：盤點)，不太可能叫台北總公司的人去進行各分公司的盤點，而是交給各地倉管人員，所以在此已經確定倉儲必須分割。
2.       網路速度
接下來，在作這方面的規劃時，也要考量到網路的速度，因為地域性的遠近常伴隨著一個問題，便是網路速度無法像區域網路這般快速，若是集中式的資料(如圖中的會計、財務表格)需要常常被存取的話，那麼台中、高雄常常要到老遠的台北作資料存取、異動，這樣的規劃反而會拖跨效能，不見得好。
3.       因應需求及分析，折衷決定最後架構
3.    DBMaker分散式資料庫的使用
(1) 分散式資料庫的設定步驟
在DBMaker中，要使用分散式資料庫非常的簡單，只要購買的授權範圍內許可，只要在dmconfig.ini中加上DD_DDBMD=1，重新啟動資料庫，便發生效果了。
使用者可以使用「select * from SYSUSER」，會發現多了一個GTRECO_D的daemon，這個Daemon主要的功用是用來作「全域交易」的管理(Global Transaction)，何謂「全域交易」呢??一般的交易多發生Local的資料庫內部，但是全域交易須要與外部的實體資料庫作連接，所以必須要考慮網路是否穩定、對方資料庫的constraint限制，這種機制多是用「二階段commit」來實作。
兩階段commit的意思是說，當應用程式連至DB_A要進行交易，同時此交易會去更動DB_B的資料庫內容，此時不會逕行對DB_B作commit的動作，而是先去詢問：「DB_B是否允許commit??」，當DB_B回答「可」時，才會在第二階段真正執行Commit，這當中，由於需要各個參與者，對協調者作出回應，故稱之為「全域交易」。GRECO_D便是在進行這樣的協調工作。
注意，在參與者的DB兩端，都需設定DD_DDBMD=1，但對於對方的設定，則無需設定此keyword(此keyword只在Server端發生效用)。但兩邊對當地的DB都需設定，如下例所示：
在Site A
[DB_A]
….
DB_DDBMD=1
[DB_B]
…
(無需設定)
Site B
[DB_B]
….
DB_DDBMD=1
[DB_A]
…
(無需設定)
兩邊重新開啟DB後，兩者就可說是已經同是參與者了。現在使用工具進入DB_A，若是想要知道DB_B的資料，只要下達：
select * from DB_B:OWNER_NAME.TABLE_NAME;
便可擷取遠方資料。
(2) 分散式資料庫的權限控管
另外要注意的是：由於這屬於「分散式資料庫」，儘管各個參與資料庫可能散落各地，但是邏輯上-「大家都是同一國」的。那麼在各地的使用者管理上，就要稍加留意。
例如：在DB_A中的「sharon」，當login進DB_A時，想要存取DB_B的資料時，DBMaker是以sharon在login DB_A時所用的UserName及Password來登入DB_B，所以若是在DB_B中無sharon其人時，便會出現錯誤訊息，表示該名使用者未通過驗證。
DmSQL>connecto to DB_A Sharon ******;
dmSQL> select * from DB_B:t1;
ERROR (6804): [DBMaker] (remote error occurred) invalid authorization specification (invalid password when connecting)  at: DB_B@B [rmbind.c 70],0,0,6804
(3) 應用程式調整
當要存取各地資料時，只要指明資料所在位置(如圖中台北)即可，例如前面所說的訂單動作，若是要將存貨(分散在各地)減少，同時增加會計的應收帳款(假設為集中式)，程式可以寫成：
update 存貨 set …….;
insert into 台北:應收帳款 values (….);
這兩句SQL指令，第一句所指的，都是在地的資料庫，但第二句都會去集中地台北的資料庫的應收帳款作新增適用；故應用程式到各地皆可一體適用(想一想，由於應收帳款只存在於台北，所以可設定synonym，將「應收帳款」設定成「台北:應收帳款」即可，那麼上述第二句指令又可再簡化)。
(4) 資料庫鏈(Database Link)
分散式資料庫需要兩邊都有相同的使用者與密碼，但這個動作卻會對各地的資料庫管理員產生許多管理工作，所以「資料庫鏈」就應運而生；所謂的「資料庫鏈」，可以視作使用某特定身份去連接遠端資料庫的固定連接，將這個「鏈結」視作是某種代理人，那麼應用程式連接到DB_A時，可能是使用User_A的身份，當透過DB_A連接到DB_B時，可使用DB_B_Link(這個鏈結可能是DB_A這裏的DBA設定完成，統一使用User_B、Password_B去連接DB_B)，那麼User_A可用自己的身份登入DB_A，但在使用DB_B_Link時，就變成了User_B、Password_B了。(同樣地，若User_C登入DB_A，使用DB_B_Link時，仍是使用User_B)
設定的方式十分容易，首先將DB_A、DB_B設定成「分散式資料庫」的環境，接著，以DBA的身份登入DB_A，鍵入以下命令：
create [private|public] database link Link_Name connect to DB_B identified by User_B Password_B;
其中private或public是設定該DB_LINK是私人使用，或是可開放給其他人使用，預設是private，為了能讓其他人能享用到這條資料鏈結，最好是設定成「public」較好。
接著，當其他人要存取遠端DB_B的資料時，只要使用：
select * from Link_Name:[Owner_Name.]Table_Name;
便可存取，但一般在撰寫這樣的SQL指令時，未免有些麻煩，所以更簡便的方式，是建立一個synonym，這樣一來，使用者連上來時，連DB_Link是什麼都可以不用知道：
create synonym Table_Name for Link_Name:[Owner_Name.]Table_Name;
當使用者下：select * from Table_Name; 時，這個Table_Name可能是遠在他方的另一個資料庫。
資料庫鏈的觀念十分好用，可使用這個方式來避免掉分散式資料庫一定得在兩邊有相同的使用者及密碼的麻煩，故讀者應多加練習及熟悉。
4.    表格複製與分散式資料庫的搭配
(1) 同步及非同步表格複製簡介
在集中式資料量小的情形下，上面的分散式資料庫架構，尚可運作得順利，若是集中式資料量大，地域性資料量小，那麼各地的應用程式還是拚命地將資料異動往集中地傳送，只有少數的資料可在近端得到，效能的低落是可以預期的。
DBMaker另有一項強大的功能，稱之為表格複製；這項功能是可將各地資料庫，同步或非同步地複製到其他資料庫，甚至可跨越到其他廠牌資料庫。
先重新瀏覽一次原始架構：

在第(2)、(3)步驟中，都需要向集中式的表格查詢，這兩者的表格特性，最好是屬於少量、少變動；否則總公司在查詢訂單資料、應收帳款時，由於資料散佈在遠端的台北、台中、高雄，效率會十分的緩慢；但若是因此改採集中式，又變成了台中、高雄每新增一筆資料或查詢也變得很緩慢。無論是集中、分散都有一方需要忍受緩慢的效能。
當產品資料的量很大時，若是每次查詢要到台北去查，似乎太遠了點，在此例中，我們可以將產品資料放一份在各地，之後各地的應用程式就無須千里迢迢到台北總公司去找了，而台北總公司一旦有最新變動(產品價格、廠商)，必須儘速將新資訊往各分公司傳送。
DBMaker提供了「同步」與「非同步」表格複製的功能，便可「立即」或是「定期」地，將某些表格的資料，同步到各地資料庫去。
所謂的「同步表格複製」，是指一旦資料輸入到DB_A中，DB_B會馬上隨之更新，由於這兩個動作視作同一筆「交易」，所以若是同步到DB_B的動作失敗，會相對的連DB_A的輸入動作也失敗。

(2) 同步與非同步表格適用情形
「同步表格複製」適用於需要即時的資料更新、網路品質是可信賴、且傳送的資料量不大的情況。若是網路品質本身有問題，那麼不單是對DB_B的更新會有問題，連帶的會使DB_A也無法輸入，反而對正常業務帶來更大的不便。
而「非同步表格複製」，則適用於可忍受資料更新速度在一定的期限(例：一天、三天、一星期)，且傳送的資料量較大的狀況。在上述例子中，DB_A的輸入將不會被DB_B及網路所影響。實際例子中，若是傳輸的資料量大，多指定某些冷門時間，將資料在該時段同步到DB_B中，而使用者能夠忍受在尚未同步前，資料不一致的問題。
無論是同步、非同步表格複製，DB_B都是單純的受方，使用者若對DB_B進行update、delete的動作的話，將會造成兩邊不一致，且DB_A是無法消弭此種不一致的現象。
有些使用者則想要讓DB_A、DB_B能互相複製，這種要求看來合理，細探之下，卻又有其困難處。例如：若要求DB_A的Table1的「新增」資料，必須要複製到DB_B的Table1去，同時又要求DB_B的Table1資料，也要能複製到DB_A去，在T0(第一次同步排程)，DB_A的資料過去了DB_B，在T1(第二次同步排程)時，DB_B由於也新增了資料(由DB_A過來的)，所以又再複製回去DB_A(這個動作應該會失敗，原因是複製是用primary key來設定，容後再述)；結果變成了一個循環，所以類似此種DB_A

		自動登錄	找回密碼
密碼			註冊