分布式數據庫系統
一、分布式數據庫系統
分布式數據庫系統
分布式數據庫系統：物理上分散而邏輯上集中的數據庫系統.
物理上分散：指各網站分散在不同的地方。大可為不同國家。小可為同一建築物的不同位置。邏輯上集中：指各網站之間不是互不相關的，它們是一個邏輯總體。並由一個統一的分布式數據庫管理系統進行管理。
分布式數據庫系統 =硬件+軟件（OS。Compiler,App.) +DB（全局DB ，局部DB ） +DBMS（全局DBMS ，局部DBMS ） +DBA（全局DBA ，局部DBA ） +用戶（全局用戶。局部用戶）
同構型：假設各個網站上的數據庫的數據模型都是同一數據模型的（比如都是關系型）的，則稱為同構型分布式數據庫系統。
同質型: 假設是同一種DBMS(比如有Oracle,DB2等),則稱為同質的,否稱為異質的.
分布式數據庫系統和分散的數據庫系統的差別？
假設用戶既能夠通過客戶機對本地server中的數據庫運行局部應用。也能夠對兩個或兩個以上結點中的數據庫運行全局應用，這種系統是分布式數據庫系統
不支持全局應用的系統不能稱為分布式數據庫系統，即僅僅是分散的數據庫系統。
分布式的特征
場地自治性（Local Autonomy)非集中式管理（NoReliance On Central Site)
高可靠性（Contiuous Operation) (連續執行）
位置獨立性（Location Transparency and Location Independence)
數據切割獨立性（Fragmentation Independence)
數據復制獨立性（Replication Independence)
分布式查詢處理（Distributed Query Processing)
分布式事務管理（Distributed Transaction Management)
硬件獨立性（Hardware Independence)
操作系統獨立性 (Operating System Independence)
網絡獨立性(Network Independence)
數據庫管理系統獨立性(DBMS Independence)
3 數據分片
數據分片（Data Fragmentation）。亦稱數據切割
------在分布式數據庫中。全局數據庫是由各個局部數據庫邏輯組合而成，反之，各個局部數據庫是由全局數據庫的某種邏輯切割而得.
邏輯片段：切割後得到的各部分元組，存放在對應的網站上
------數據存放的單位
分片（割）方法：
1 水平分片：按特定條件把全局關系的全部元組，分劃成若幹個互不相交的子集。每一個子集位全局關系的一個邏輯片段。對全局關系施加選擇運算
.
2 垂直分片：把全局關系的屬性集分成若幹個子集。對全局關系施加投影運算.
3 混合分片：先水平分片再垂直分片，或先垂直分片再水平分片.
分片原則：
2. 重建性條件： 全局關系可從各分片中產生
3. 不相交條件：不同分片無公共數據（控制數據冗余）
位置透明性：全局關系切割為分片後。要把分片定位到各個節點上。使每一分片至少有一個節點地址。假設應用程序中不必包含數據的節點地址。稱為系統的位置透明性，應用程序中僅僅提供要訪問的關系名或分片名，節點地址由系統從數據字典中查出。具有位置透明性的系統，分片在節點間有移動時僅僅要改變數據字典中的登錄數據，不影響應用程序的可用性。
實現位置透明時。數據字典中要有分片的地址信息，系統對數據操縱語句要作多復本處理:改動語句要自己主動地改動全部復本，查詢語句要選擇最合適的復本。
全局關系的垂直切割是把屬性分組。然後把關系投影到每一組得到各分片。這樣的方法適用於各節點有自已特殊屬性的全局關系。
1 全然性條件:取全部節點的屬性為全局關系的屬性即滿足
2 垂直切割方法的不相交條件和可重建條件是矛盾的
------由於全局關系是各分片的自然聯接，可重建條件就是關系分解的無損性條件。即要滿足投影聯接依賴。比如在分解成兩個分片時，僅僅有這兩個分片相交。且交集能多值決定任一分片時，全局關系才是可重建的。
解決的方法：有的系統中設有系統維護的元組標識，如ORACLE的rowid
（該元組標識可函數決定全局關系中全部屬性，且對用戶是透明的(可使用而不能改動)。因此在這些系統中就用戶定義的屬性而言能夠使垂直切割不相交且可重建。僅僅要把全局關系的元組標識用作各分片的附加屬性。）
數據分片的長處是：數據不是依照關系而是按片段來存放，有利於更好地依據用戶需求來組織數據的分布。也有利於控制數據的冗余度。
4 數據分布
所謂數據分布是指分布式數據庫中的數據不是存儲在一個網站的計算機存儲設備上，而是依據須要將數據劃分成邏輯片斷，按某種方法將這些片斷分散地存儲在各個網站上。
分布透明性包含分片透明性、位置透明性和局部數據模型透明性。
1 分片透明性指用戶或應用程序僅僅對全局關系進行操作而不必考慮關系的分片。
當分片模式改變了，因為全局模式到分片模式的映象。全局模式不變，應用程序不必改寫。
2 位置透明性指用戶或應用程序不必了解片段的存儲場地，當存儲場地改變了，因為分片模式到分布模式的映象，應用程序不必改變。
同一時候，若片段的反復副本數目改變了，數據的冗余度改變了，用戶也不必關心怎樣保持各副本的一致性，這就是反復副本的透明性。
3 局部數據模型透明性指用戶或用戶程序不必了解局部場地上使用的是哪種數據模型。
為什麽會出現上述問題？
由於在分片策略上的問題和數據庫系統的問題，設計表時我們就首先對其分片，選擇水平或垂直或混合分配策略。然後選擇網站存放。
所以就出現了上述現象。
只是依據系統字典這樣的現象應該能夠解決。在設計時我們就建立相應的表。
這樣程序猿使用表時能夠建立最高的分布透明性。
------------------------------------
二、分布式數據庫系統的設計
1 數據庫設計
數據庫設計的基本步驟：需求分析
概念結構設計
邏輯結構設計
物理結構設計
數據庫的建立和測試
數據庫執行和維護。
2 命名規範
不使用tab或tbl作為表前綴（本來就是一個表，為什麽還要說明）表名以代表表內的內容的一個和多個名詞組成，下面劃線分隔。每一個名詞的第一個字母大寫。
使用表的內容分類作為表名的前綴：如，與用戶信息相關的表使用前綴User_，與內容相關的信息使用前綴Content_。
表的前綴以後。是表的詳細內容的描寫敘述。
如：用戶登錄信息的表名為：User_Login。用戶在論壇中的信息的表名為：User_BBS_Info
一些作為多對多連接的表，能夠使用兩個表的前綴作為表名：
如：用戶登錄表User_Login，用戶分組表Group_Info，這兩個表建立多對多關系的表名為：User_Group_Relation
當系統中有一些少量的。反復出現的值時。使用字典表來節約存儲空間和優化查詢。如地區、系統中用戶類型的代號等。
這類值不會在程序的執行期變化。可是須要存儲在數據庫中。
字段不使用不論什麽前綴（表名代表了一個名稱空間，字段前面再加前綴顯得羅嗦）
字典名也避免採用過於普遍過於簡單的名稱：比如，用戶表中，username的字段為UserName比Name更好。
布爾型的字段。以一些助動詞開頭。更加直接生動：如，用戶是否有留言HasMessage，用戶是否通過檢查IsChecked等。
字段名為英文短語、形容詞+名詞或助動詞+動詞時態的形式表示。大寫和小寫混合，遵循“見名知意”的原則。
3 SQL語句規範
在一些塊形式的SQL語句中，就算僅僅有一行代碼。也要加上BEGIN…END塊。
如：IF EXISTS(…)
SET @nVar = 100
應該寫成：
IF EXISTS(…)
BEGIN
SET @nVar = 100
END
全部的SQLkeyword大寫
4 存儲過程編碼規範
僅僅同意應用程序通過存儲過程訪問數據庫將基本的業務邏輯封裝在存儲過程中，可以避免在應用程序層寫大量的代碼（在應用程序中通過字符串插入太長的SQL語句影響效率，並且維護困難）
在站點一類的應用系統中，SQL註入式漏洞一直是難以全然杜絕的漏洞。假設僅僅通過存儲過程來訪問數據庫，可以大大降低這類安全性問題。
需求變更。表的結構必須要改變。使用存儲過程，僅僅要參數不變，我們就僅僅須要改動對應的存儲過程。而不須要改動應用程序的代碼。
為提高效率。使部分字段冗余；為提高效率，使用冗余表（拆分表）；
使用存儲過程。便於在項目後期或者執行中集中優化系統性能。
問題一：存儲過程編譯後。將作為數據庫的全局對象保存，太多的存儲過程將占用大量的數據庫server的內存。
問題二：在存儲過程中實現大量的邏輯，將使大量的運算在數據庫server上完畢，而不是在應用server上完畢。當訪問量非常大的時候。會大大消耗數據庫server的CPU占用率。
每一個存儲過程內的代碼前後必須加上SET NOCOUNT ON 和SET NOCOUNT OFF。
5 數據庫設計規範
5.1 數據完整性規範（編碼期）
1、為便於在程序的編碼期查錯，能夠在設計數據庫的時候盡可能多的加上約束(check)。如，整型的字段的取值範圍等，經常為field>0。
2、同理，盡可能地在開發期間使用觸發器來驗證數據的完整性。
3、假設字段之間存在冗余，應該編寫觸發器來管理冗余的字段
3、在開發階段保存完整的主鍵、外鍵和唯一索引的約束。
4、原則：編碼期間，數據完整性優先於性能。在保障系統正確執行的前提下盡可能的提高效率。
6 數據庫優化
6.1 數據庫性能優化規範
1、在執行階段刪除不必要的約束(check)。
2、盡量不要使用觸發器
3、盡量保留主鍵約束
4、適當刪除外鍵，以提高性能
5、在執行期間，通過分析系統的訪問量。創建索引來優化性能
6、分析每一個表可能的數據增長量，定義自己主動拆分表規則。將大表進行拆分來提高性能。
7、預先考慮數據清理規則：在什麽情況下刪除數據庫中的舊數據，以此來提高性能。
8、制定數據庫備份和災難恢復計劃。
9、為效率考慮，能夠在系統測試階段適當添加冗余字段，或者冗余表。
10、分頁的記錄輸出必須通過存儲過程來實現。不能使用API遊標來分頁，這樣能夠提高分頁的效率。
6.2 拆分表演示樣例
案例：站點有200萬用戶，有非常多模塊環繞用戶提供服務。
為提高效率，每一個表最多僅僅保存與用戶有關的10萬記錄，200萬條記錄拆分到20個表中。編號為1-10萬的用戶將記錄保存到表一。100001-200000編號的記錄保存到表二，以此類推。
建立一個拆分信息表，表中保存了哪些表是經過拆分的。拆分到什麽程度，拆分規則是什麽。
當插入記錄的時候。首先推斷插入這條記錄的用戶的ID。存儲過程依據ID的範圍，自己主動把表插入到對應的拆分表中去。
當依照條件查詢。存儲過程自己主動連接全部的拆分表，叢中篩選出記錄。（普通情況下：同類型的查詢遠遠大於依照條件的全體查詢）
6.3 冗余字段建立演示樣例
案例：留言本表中，要保存用戶的ID作為外鍵。
通常。通過連接留言表和用戶表來得知是哪個用戶公布了留言。
為提高效率，在留言本表中增建username的字段。
插入記錄的時候。同一時候保存用戶ID和username。這樣。當查詢時。就不必連接兩個表，使效率大大提高。
可是，當用戶改動username時，要嗎更新其它表中的username。要嗎忽略這樣的username不一致的影響。怎樣處理取決於username在模塊中的重要程度。
6.4 冗余表建立演示樣例
案例：實用戶表和分組表，兩個表之間是多對多的關系。建立一個用戶與組的關系表來實現這樣的關系。
用戶表中有百萬條記錄。組表中幾千條記錄。假設每一個用戶都屬於多個組的化。關聯表中將存在幾百萬條記錄。
如今將用戶表和關聯表進行拆分。拆分規則為用戶的ID範圍。
當查詢某用戶的組時。效率大大提高。可是當查詢某組下的用戶時，須要關聯全部的拆分表，效率非常低。
為提高效率，建立一個冗余的用戶和組的關系表，這個關系表中保存第一個關系表中統一的內容，可是拆分規則為組ID的範圍。這樣，當查詢組中的用戶時，叢第二個關系表中查詢。效率大大提高。
6.5 存儲過程中分頁方案
方案一：
1、首先統計得到符合條件的記錄數2、定義表變量：表變量的第一個字段為自增長類型。第二個字段為記錄集中的唯一值字段（通常是主鍵）
3、使用insert () select 語句將符合條件的記錄的唯一值字段保存在表變量中。
4、使用where ID in (select ID From 表變量 WHERE ……) 的方法從表兩邊中讀出須要的唯一值字段。
方案二：
1、首先統計符合條件的記錄數。並依據頁大小計算頁數2、假設讀取第一頁，直接使用TOP子句讀取
3、假設頁數在前一半：
結果集1：SELECT TOP CurPage*PageSize Fields FROM Table ORDER BY ID ASC
結果集2：SELECT TOP PageSize * FROM (結果集1) ORDER BY ID DESC
終於結果：SELECT * FROM (結果集2) ORDER BY ID ASC
4、假設頁數在後一半：
結果集1：SELECT TOP (PageCount-CurPage)*PageSize Fields FROM Table ORDER BY ID DESC
終於結果：SELECT TOP PageSize * FROM Table ORDER BY ID ASC
聲明：
博客轉載地址：blog.csdn.net/longronglin/article/details/5469463.分布式數據庫系統