分布式數據庫設計方案

1、1. 大型分布式數據庫解決方案 企業(yè)數據庫的數據量很大時候，即使服務器在沒有任何壓力的情況下，某些復雜的查詢操作都會非常緩慢, 影響最終用戶的體驗；當數據量很大的時候，對數據庫的裝載與導岀，備份與恢復，結構的調整，索引的 調整等都會讓數據庫停止服務或者高負荷運轉很長時間，影響數據庫的可用性和易管理性。 分區(qū)表技術 讓用戶能夠把數據分散存放到不同的物理磁盤中，提高這些磁盤的并行處理能力，達到優(yōu)化查詢性能的目 的。但是分區(qū)表只能把數據分散到同一機器的不同磁盤中，也就是還是依賴于一個機器的硬件資源，不能 從根本上解決問題。 分布式分區(qū)視圖 分布式分區(qū)視圖允許用戶將大型表中的數據分散到不同機器的數據庫

2、上，用戶不需要知道直接訪問哪個基 礎表而是通過視圖訪問數據，在開發(fā)上有一定的透明性。但是并沒有簡化分區(qū)數據集的管理、設計。用戶 ，而且必須單獨為每個表管理數 使用分區(qū)視圖時，必須單獨創(chuàng)建、管理每個基礎表（在其中定義視圖的表）據完整性約束，管理工作變得非常復雜。而且還有一些限制，比如不能使用自增列，不能有大數據對象。 對于全局查詢并不是并行計算，有時還不如不分區(qū)的響應快。 Databasel 月份 Database3 Databasel 庫表散列 在開發(fā)基于庫表散列的數據庫架構，經過數次數據庫升級，最終采用按照用戶進行的庫表散列，但是這些 都是基于自己業(yè)務邏輯進行的，沒有一個通用的實現?？蛻粼趯?/p>

3、際應用中要投入很大的研發(fā)成本，面臨很 大的風險。 面對海量數據庫在高并發(fā)的應用環(huán)境下，僅僅靠提升服務器的硬件配置是不能從根本上解決問題的，分布 式網格集群通過數據分區(qū)把數據拆分成更小的部分，分配到不同的服務器中。查詢可以由多個服務器上的 CPU、I/O來共同負載，通過各節(jié)點并行處理數據來提高性能；寫入時，可以在多個分區(qū)數據庫中并行寫 入，顯著提升數據庫的寫入速度。 管理工具 （ 甲童佟唱申福主 在訪問層掘坯庫 里聞* WtffSQL 語句 0 衛(wèi)用發(fā)務熬 1.ED i r ect cr5ij 訪問層 （調度 數撫展 （執(zhí)行 價值所在 通過分區(qū)把數據放到不同的機器中，每次查詢可以由多個機器上的C

4、PU,I/O來共同負載，通過各 節(jié)點并行處理數據來提高性能。 4 冗余的數據結構（矩陣列）消除了單點故障，任何一個機器岀現故障后都不會影響系統(tǒng)的正常 運行，數據庫集群能提供不中斷的服務。 無共享磁盤架構節(jié)省了硬件，利用中小型的服務器取代大型服務器大幅降低了硬件的成本，系統(tǒng) 中不再有閑置的資源，降低了系統(tǒng) TCO （總體擁有成本）。 * 分區(qū)把數據分成更小的部分，提高了數據庫的可用性和可管理性。 * 根據業(yè)務的需要，訪問層和數據層都可以增加，集群具有良好的擴展性。 *中間件宿主在數據庫中的創(chuàng)新使集群變得更透明，數據庫的管理成本，以及面向數據庫的開發(fā)成 本都最小化。 2. 數據實時復制解決方案 經

5、過分析，大多數應用系統(tǒng)以查詢操作為主，造成數據庫壓力迅速增加的主要因素也是復雜的查詢操 作，為了能夠得到同一份數據的多個副本來響應用戶的查詢，SQL Server提供了復制技術(Replication)， 主要有合并復制、事務復制、快照復制等，這些技術可以有效緩解查詢的壓力。伴隨著企業(yè)發(fā)展的需要， 企業(yè)對信息實時性要求越來越高，如股票、航空票務、連鎖店甚至是一些服務系統(tǒng)等等，這些系統(tǒng)的用戶 希望更新的數據馬上就可以查詢到。 SQL Server數據庫的復制/訂閱技術 復制/訂閱數技術可以實現讀、寫分離，數據先寫到中心數據庫上，寫成功即返回給應用程序；通過復制將 數據復制到只讀服務器，查詢時從只

6、讀服務器查 OU ft V Utttl曲肯用 F自己在賤用罠序 實境時多亍只讀垃 據咋的負做均襯 MSCS 意味著訂閱端的數據和中心數據庫的數據不同步，是個異步的過程，所以數據滯后嚴重，數據同步的實時 性得不到保障，中心數據庫在正常的壓力下 10秒左右。當訪問負荷很高或者中心數據庫在整理數據時，將 岀現大量DML操作延遲時間比較長或者岀現堵塞的情況； 某些修改操作需要重新建立復制關系并初始化，這期間需要停止數據庫的讀取服務，規(guī)模越大的應用停止 的時間越長，嚴重影響了數據庫的可用性。結論：復制訂閱技術的實時性差，初始化時對系統(tǒng)的影響非常大；在數據復制過程中沒有采用智能的策略, 數據的復制速度慢；

7、中心數據庫仍然為失敗轉移集群模式 構建數據庫集群，節(jié)點間數據同步都是實時的，數據是一致性的，可以部署為讀、寫分離，也可以部署為 所有節(jié)點可讀可寫；中間件監(jiān)測到數據庫變化并同步數據，數據同步完成后客戶端才會得到響應，同步過 程是并發(fā)完成的，所以同步到多個數據庫和同步到一個數據庫的時間基本相等；另外同步的過程是在事務 的環(huán)境下完成的，保證了多份數據在任何時刻數據的一致性。中間件在同步數據時采用了多項智能同步策 略，滿足了不同類型的應用模式，可以同步數據，同步SQL語句，并行執(zhí)行SQL語句，升級數據庫的鎖, 啟用數據壓縮等。 覲均嶺JT廷. 通過虛擬掙描 節(jié)點 H 戌劃SAL Ssi vsr 200

8、8 Htnagewfl Siudio中 同步過程是在SQL Server的執(zhí)行環(huán)境中進行的，整個操作是在事務的環(huán)境下完成的，解決了數據實時性 問題，滿足了用戶對數據實時性的要求。 中間件在同步數據時采取了智能同步策略，同步速度更快；提供了多種人工干預的機制，對數據庫表結構 的調整、批量更改數據等操的時間大幅縮減 無需搭建失敗轉移集群，中心數據庫Cluster中閑置的一臺機器被利用起來，提高了整個系統(tǒng)的使用率; 系統(tǒng)支持無共享磁盤架構，可以節(jié)省共享的存儲設備。 連接數據庫，提供專門針對數據庫系統(tǒng)的負載均衡軟件，無需使用昂貴的均衡硬件，無需程序員自己實現。 提供故障檢測及失敗轉移功能。 3. 數據

9、庫選擇 在SQL中使用Oracle鏈接服務器，因為是異地數據，在SQL中的更新，刪除等是隱式事務，而在Oracle 中是顯示的，所以直接調用速度是很慢的并且很容易崩掉。 4. 數據查詢 1秒鐘時間，在幾千億條話單數據中找到用戶想要的數據，在分區(qū)、并行查詢、列存、集群等技術統(tǒng) 統(tǒng)粉墨登場仍無法滿足響應要求時，數據壓縮和索引技術成為了致勝的關鍵。無論是使用傳統(tǒng)的 B樹索引, 或通用的壓縮算法，都不是問題的正解，在如此大的數據量下，需要使用更加專業(yè)高效的技術方法。 基于特定條件（產品型號、產品名稱、起止時間等）組合的詳單查詢，絕大多數查詢只會返回少量的結 按列壓縮 -規(guī)則列內十列間）和后 端兩層壓縮

10、 后端支持使用第三方的 逋用壓縮模塊 行列混合存儲 9支持多壓縮級別 壓縮總體結構 壓縮的主要目的不是減少空間占用，而是提高查詢性能 CPU平均處理帶寬3.6GB/秒（7000萬行/秒/核），I/O平均處理帶寬300MB/秒，通過壓縮提升I/O帶寬, 實現CPU與I/O處理均衡，提高查詢性能 宛曲 讒間翻道語卜濮.5 RATE ID 最基酣的編碼方法 1M1 創(chuàng) 7 叭適用于中低密度的屈 性列.大大減少空間 咄字典有潯組織. 提離查詢性能 列內規(guī)則 他WIT 1鮒1倔 1如討6 1鮒l鉗E 使用通用壓縮算法 LZMA : CPU處理帶寬太低 壓縮比18.9 : 1，解碼速度171MB/秒/核

11、（折算后）CPU處理帶寬991MB/秒，I/O處理帶寬5.7GB/秒 LZOP :壓縮率太低 壓縮比7.2 : 1，解碼速度891Mb/秒/核 （折算后）CPU處理帶寬2.4GB/秒，I/O處理帶寬2.2GB/秒 一 適用干近似）常量的屬性列 r實際應用中大量存在 列內規(guī)則 對壓縮的要求 壓縮率不低于15 : 1 CPU處理帶寬不低于5GB/秒 索引 查詢高選擇率的特點適合選擇索引 傳統(tǒng)索引 空間占用大 維護成本高，對裝載速度影響大 對索引的要求 占用空間對壓縮率貢獻可忽略不計 維護開銷對裝載速度無明顯影響 選擇率接近于數據的實際選擇率，遠快于表掃描 J適用干兩列（近似1相等的場合 對于高密度

12、列之間存在的相等關系非常有效 CALLED閣0惦0尺 THlRDNUMBEft CALLEDuNUMBR Exception TUHD NCMBER 列內規(guī)則 傳統(tǒng)索引的不足 維護成本高 對數據裝載速度影響極大 先建模式下：索引需要同步維護，隨機插入影響性能，插入過程中無法引入壓縮 后建模式下：需要大規(guī)模的排序，創(chuàng)建成本高 空間占用大 以B樹為例，鍵值，ROWID二元組，按照鍵值順序排列，按列壓縮 ROWID隨機性強，難以被壓縮，整體空間成本 6字節(jié)/ 分片索引 技術要點： 將表按照一定行數據分成多個數據包 為每個壓縮包建立其中各列的摘要信息（如最大值、最小值），所有數據包上的屬于特定列的全部摘要 信息，構成該列的分片索引 禾U用摘要信息，來判定對應的數據包中是否包含滿足特定的查詢條件的行，如確定不存在這樣的行， 則整個數據包無須