資料庫分布式開發

⑴ 分布式資料庫系統(DDBS)概述

一 什麼是分布式資料庫

分布式資料庫系統是在集中式資料庫系統的基礎上發展來的 是資料庫技術與網路技術結合的產物

分布式資料庫系統有兩種 一種是物理上分布的 但邏輯上卻是集中的 這種分布式資料庫只適宜用途比較單一的 不大的單位或部門 另一種分布式資料庫系統在物理上和邏輯上都是分布的 也就是所謂聯邦式分布資料庫系統 由於組成聯邦的各個子資料庫系統是相對 自治 的 這種系統可以容納多種不同用途的 差異較大的資料庫 比較適宜於大范圍內資料庫的集成

分布式資料庫系統(DDBS)包含分布式資料庫管理系統(DDBMS)和分布式資料庫(DDB)

在分布式資料庫系統中 一個應用程序可以對資料庫進行透明操作 資料庫中的數據分別在不同的局部資料庫中存儲 由不同的DBMS進行管理 在不同的機器上運行 由不同的操作系統支持 被不同的通信網路連接在一起

一個分布式資料庫在邏輯上是一個統一的整體 即在用戶面前為單個邏輯資料庫 在物理上則是分別存儲在不同的物理節點上 一個應用程序通過網路的連接可以訪問分布在不同地理位置的資料庫 它的分布性表現在資料庫中的數據不是存儲在同一場地 更確切地講 不存儲在同一計算機的存儲設備上 這就是與集中式資料庫的區別 從用戶的角度看 一個分布式資料庫系統在邏輯上和集中式資料庫系統一樣 用戶可以在任何一個場地執行全局應用 就好那些數據是存儲在同一台計算機上 有單個資料庫管理系統(DBMS)管理一樣 用戶並沒有什麼感覺不一樣

分布式資料庫中每一個資料庫伺服器合作地維護全局資料庫的一致性

分布式資料庫系統是一個客戶/伺服器體系結構

在系統中的每一台計算機稱為結點 如果一結點具有管理資料庫軟體 該結點稱為資料庫伺服器 如果一個結點為請求伺服器的信息的一應用 該結點稱為客戶 在ORACLE客戶 執行資料庫應用 可存取數據信息和與用戶交互 在伺服器 執行ORACLE軟體 處理對ORACLE資料庫並發 共享數據存取 ORACLE允許上述兩部分在同一台計算機上 但當客戶部分和伺服器部分是由網連接的不同計算機上時 更有效

分布處理是由多台處理機分擔單個任務的處理 在ORACLE資料庫系統中分布處理的例子如

客戶和伺服器是位於網路連接的不同計算機上

單台計算機上有多個處理器 不同處理器分別執行客戶應用

參與分布式資料庫的每一伺服器是分別地獨立地管理資料庫 好像每一資料庫不是網路化的資料庫 每一個資料庫獨立地被管理 稱為場地自治性 場地自治性有下列好處

◆系統的結點可反映公司的邏輯組織

◆由局部資料庫管理員控制局部數據 這樣每一個資料庫管理員責任域要小一些 可更好管理

◆只要一個資料庫和網路是可用 那麼全局資料庫可部分可用 不會因一個資料庫的故障而停止全部操作或引起性能瓶頸

◆故障恢復通常在單個結點上進行

◆每個局部資料庫存在一個數據字典

◆結點可獨立地升級軟體

可從分布式資料庫的所有結點存取模式對象 因此正像非分布的局部的DBMS 必須提供一種機制 可在局部資料庫中引用一個對象 分布式DBMS必須提供一種命名模式 以致分布式資料庫中一個對象可在應用中唯一標識和引用 一般在層次結構的每一層實施唯一性 分布式DBMS簡單地擴充層次命名模型 實施在網路上唯一資料庫命名 因此一個對象的全局對象名保證在分布式資料庫內是唯一

ORACLE允許在SQL語句中使用全局對象名引用分布式資料庫中的模式對象(表 視圖和過程) 在ORACLE中 一個模式對象的全局名由三部分組成 包含對象的模式名 對象名 資料庫名 其形式如

SCOTT EMP@SALES DIVISION ACME

一個遠程查詢為一查詢 是從一個或多個遠程表中選擇信息 這些表駐留在同一個遠程結點

一個分布式查詢可從兩個或多個結點檢索數據 一個分布式更新可修改兩個或兩個以上結點的數據

一個遠程事務為一個事務 包含一人或多個遠程語句 它所引用的全部是在同一個遠程結點上 一個分布式事務中一個事務 包含一個或多個語句修改分布式資料庫的兩個或多個不同結點的數據

在分布式資料庫中 事務控制必須在網路上直轄市 保證數據一致性 兩階段提交機制保證參與分布式事務的全部資料庫伺服器是全部提交或全部回滾事務中的語句

ORACLE分布式資料庫系統結構可由ORACLE資料庫管理員為終端用戶和應用提供位置透明性 利用視圖 同義詞 過程可提供ORACLE分布式資料庫系統中的位置透明性

ORACLE提供兩種機制實現分布式資料庫中表重復的透明性 錶快照提供非同步的表重復;觸發器實現同步的表的重復 在兩種情況下 都實現了對表重復的透明性

在單場地或分布式資料庫中 所有事務都是用MIT或ROLLBACK語句中止

二 分布式資料庫系統的分類

( ) 同構同質型DDBS 各個場地都採用同一類型的數據模型(譬如都是關系型) 並且是同一型號的DBMS

( )同構異質型DDBS 各個場地採用同一類型的數據模型 但是DBMS的型號不同 譬如DB ORACLE SYBASE SQL Server等

( )異構型DDBS 各個場地的數據模型的型號不同 甚至類型也不同 隨著計算機網路技術的發展 異種機聯網問題已經得到較好的解決 此時依靠異構型DDBS就能存取全網中各種異構局部庫中的數據

三 分布式資料庫系統主要特點

DDBS的基本特點

( )物理分布性 數據不是存儲在一個場地上 而是存儲在計算機網路的多個場地上

邏輯整體性 數據物理分布在各個場地 但邏輯上是一個整體 它們被所有用戶(全局用戶)共享 並由一個DDBMS統一管理

( )場地自治性 各場地上的數據由本地的DBMS管理 具有自治處理能力 完成本場地的應用(局部應用)

( )場地之間協作性 各場地雖然具有高度的自治性 但是又相互協作構成一個整體

DDBS的其他特點

( )數據獨立性

( )集中與自治相結合的控制機制

( )適當增加數據冗餘度

( )事務管理的分布性

四 分布式資料庫系統的優點

( )更適合分布式的管理與控制

分布式資料庫系統的結構更適合具有地理分布特性的組織或機構使用 允許分布在不同區域 不同級別的各個部門對其自身的數據實行局部控制 例如 實現全局數據在本地錄入 查詢 維護 這時由於計算機資源靠近用戶 可以降低通信代價 提高響應速度 而涉及其他場地資料庫中的數據只是少量的 從而可以大大減少網路上的信息傳輸量;同時 局部數據的安全性也可以做得更好

( )具有靈活的體系結構

集中式資料庫系統強調的是集中式控制 物理資料庫是存放在一個場地上的 由一個DBMS集中管理 多個用戶只可以通過近程或遠程終端在多用戶操作系統支持下運行該DBMS來共享集中是資料庫中的數據 而分布式資料庫系統的場地局部DBMS的自治性 使得大部分的局部事務管理和控制都能就地解決 只有在涉及其他場地的數據時才需要通過網路作為全局事務來管理 分布式DBMS可以設計成具有不同程度的自治性 從具有充分的場地自治到幾乎是完全集中式的控制

( )系統經濟 可靠性高 可用性好

與一個大型計算機支持一個大型的集中式資料庫在加一些進程和遠程終端相比 由超級微型計算機或超級小型計算機支持的分布式資料庫系統往往具有更高的性價比和實施靈活性 分布式系統比集中式系統具有更高的可靠性和更好的可用性 如由於數據分布在多個場地並有許多復制數據 在個別場地或個別通信鏈路發生故障時 不致於導致整個系統的崩潰 而且系統的局部故障不會引起全局失控

( )在一定條件下響應速度加快

如果存取的數據在本地資料庫中 那麼就可以由用戶所在的計算機來執行 速度就快

( )可擴展性好 易於集成現有系統 也易於擴充

對於一個企業或組織 可以採用分布式資料庫技術在以建立的若干資料庫的基礎上開發全局應用 對原有的局部資料庫系統作某些改動 形成一個分布式系統 這比重建一個大型資料庫系統要簡單 既省時間 又省財力 物力 也可以通過增加場地數的辦法 迅速擴充已有的分布式資料庫系統

五 分布式資料庫系統的劣勢

( )通信開銷較大 故障率高

例如 在網路通信傳輸速度不高時 系統的響應速度慢 與通信相關的因素往往導致系統故障 同時系統本身的復雜性也容易導致較高的故障率 當故障發生後系統恢復也比較復雜 可靠性有待提高

( )數據的存取結構復雜

一般來說 在分布時資料庫中存取數據 比在集中時資料庫中存取數據更復雜 開銷更大

( )數據的安全性和保密性較難控制

在具有高度場地自治的分布時資料庫中 不同場地的局部資料庫管理員可以採用不同的安全措施 但是無法保證全局數據都是安全的 安全性問題式分布式系統固有的問題 因為分布式系統式通過通信網路來實現分布控制的 而通信網路本身卻在保護數據的安全性和保密性方面存在弱點 數據很容易被竊取

分布式資料庫的設計 場地劃分及數據在不同場地的分配比較復雜 數據的劃分及分配對系統的性能 響應速度及可用性等具有極大的影響 不同場地的通信速度與局部資料庫系統的存取部件的存取速度相比 是非常慢的 通信系統有較高的延遲 在CPU上處理通信信息的代價很高 分布式資料庫系統中要注意解決分布式資料庫的設計 查詢處理和優化 事務管理及並發控制和目錄管理等問題

六 分布式資料庫系統 數據分片

類型

水平分片

按一定的條件把全局關系的所有元組劃分成若干不相交的子集 每個子集為關系的一個片段

垂直分片

把一個全局關系的屬性集分成若乾子集 並在這些子集上作投影運算 每個投影稱為垂直分片

導出分片

又稱為導出水平分片 即水平分片的條件不是本關系屬性的條件 而是其他關系屬性的條件

混合分片

以上三種方法的混合 可以先水平分片再垂直分片 或先垂直分片再水平分片 或其他形式 但他們的結果是不相同的

條件

( )完備性條件

必須把全局關系的所有數據映射到片段中 決不允許有屬於全局關系的數據卻不屬於它的任何一個片段

( )可重構條件

必須保證能夠由同一個全局關系的各個片段來重建該全局關系 對於水平分片可用並操作重構全局關系;對於垂直分片可用聯接操作重構全局關系

( )不相交條件

要求一個全局關系被分割後所得的各個數據片段互不重疊(對垂直分片的主鍵除外)

七 分布式資料庫系統 數據分配方式

( )集中式 所有數據片段都安排在同一個場地上

( )分割式

所有數據只有一份 它被分割成若干邏輯片段 每個邏輯片段被指派在一個特定的場地上

( )全復制式 數據在每個場地重復存儲 也就是每個場地上都有一個完整的數據副本

( )混合式 這是一種介乎於分割式和全復制式之間的分配方式

八 分布式資料庫系統 體系結構

數據分片和數據分配概念的分離 形成了 數據分布獨立型 概念

數據冗餘的顯式控制 數據在各個場地的分配情況在分配模式中一目瞭然 便於系統管理

局部DBMS的獨立性 這個特徵也稱為 局部映射透明性 此特徵允許我們在不考慮局部DBMS專用數據模型的情況下 研究DDB管理的有關問題

九 分布式資料庫管理系統

接受用戶請求 並判定把它送到哪裡 或必須訪問哪些計算機才能滿足該要求

訪問網路數據字典 了解如何請求和使用其中的信息

如果目標數據存儲於系統的多個計算機上 就必須進行分布式處理

通信介面功能 在用戶 局部DBMS和其他計算機的DBMS之間進行協調

在一個異構型分布式處理環境中 還需提供數據和進程移植的支持 這里的異構型是指各個場地的硬體 軟體之間存在著差別

分布式資料庫管理系統

⑵ 目前主流的分布式資料庫系統實現方案有哪些

（1）方案一（資料庫保存所有伺服器索引信息）
全對稱結構，沒有中央伺服器
web方案：
只從本地資料庫檢索符合條件的記錄，給出結果
每次檢索都要從本地伺服器的海量數據中進行
資料庫方案：
資料庫保存所有伺服器的索引內容
緩存命中率高的記錄，減少檢索時間
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用，每個結點一萬條記錄
web伺服器：同時一百線程在本地資料庫伺服器檢索
資料庫伺服器：每次接收一百個查詢請求；每個請求要從一百萬條索引中檢索（最壞的情況）；緩沖機制可以稍微減輕負擔
數據更新操作：
同時更新所有資料庫/只更新本地，伺服器間相互同步

方案二（資料庫保存本地索引及少量緩沖）
每高校作為一個結點
所有結點全對稱結構，網路中沒有一個中央伺服器
web方案：
接收到請求時同時多線程向其它伺服器同時搜索（伺服器壓力問題？）
資料庫方案：
資料庫保存本地數據
資料庫保存一定量緩沖數據，
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用
則每個web伺服器同時發起一萬個線程向其它數據伺服器搜索（oops!）
每個資料庫伺服器會同時接收到一萬個查詢請求（oops！）
採用學習過程只能少量減少查詢請求和web伺服器搜索線程
數據更新操作：
只更新本地

方案三（中央伺服器方案一）
每高校一個結點
每結點結構相同，連接到同一個中央伺服器
web方案
每個查詢向中央伺服器進行，由中央伺服器實行檢索，中央伺服器返回檢索結果
資料庫方案
中央資料庫保存所有索引信息
每結點可以只用小型資料庫保存本地用戶和其它信息即可
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用，每結點資料記錄一萬條
web伺服器：同時發起一百個進程向中央資料庫查詢
資料庫伺服器（中央）：同時接收一萬條查詢請求並返回大容量結果
資料庫伺服器（結點）：少量工作
數據更新操作：
只更新中央伺服器

方案四（中央伺服器方案二）
每高校一個結點
每結點結構相同，連接到同一中央伺服器
web方案：
每個查詢向中央伺服器進行，由中央伺服器根據查詢內容進行轉發到結點資料庫，再由結點資料庫返回結果
資料庫方案：
中央伺服器保存各結點分類信息，根據頁面請求的分類轉發查詢到相應伺服器
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用，每結點資料記錄一萬條，每結點一百個類別
web伺服器：同時一百個進程向中央資料庫查詢
資料庫伺服器（中央）：同時接收一萬條請求並轉發
資料庫伺服器（結點）：從中央伺服器接收查詢請求，最壞情況下每結點接收到一萬條查詢請求
數據更新操作：
只更新本地伺服器
分類變化時更新中央伺服器

⑶ 如何編寫一個分布式資料庫

某種程度上看來，資料庫作為整個系統的核心，這句話其實並不誇張，資料庫的選型關繫到上層業務代碼實現的方方面面，現在比較流行的架構方案是上層業務邏輯微服務化，並且結合分布式緩存，這套框架已經基本能做到上層業務的彈性擴展，但是最底層的數據存儲還是很難去中心化（除非整個技術棧中去除關系型資料庫（RDBMS）, 全部採用 NoSQL）。所以，經常是 RDBMS 成為整個系統的瓶頸。
在長期的斗爭中，大家總結出了很多方式來擴展最底層的關系型資料庫：
1. 主從，一主多從，雙寫，通過隊列暫存請求... 這些方案其實並沒有解決問題，寫入仍然是單點，而且對於 DBA 的挑戰比較大，今天我們暫時就不討論了。
2. 通過中間件 Sharding，常見的開源方案有： Cobar, TDDL, Vitess, Kingshard, MyCat 等，這些方案的思路是攔截 SQL 的請求通過 sharding key 和一定規則，將請求轉發/廣播到不同的 MySQL 實例上，從而實現水平擴展的效果，這個方案基本解決了單點寫入的問題，對於業務來說整體的吞吐也上來了，看上去不錯，這個方案是大多數業務遇到性能瓶頸的解決方案，但是缺點也是有的：
1）大多中間件都沒有解決動態擴容的問題，多採用了靜態的路由策略，擴容一般還處於人工 x2 的狀態，對 DBA 要求比較高。
2）從一定程度上來說都放棄了事務，這是由於一條語句有可能會涉及到多個資料庫實例，實現分布式 事務是一個比較難的事情，我們後面會詳細的介紹。
3）對業務不透明，需要指定 sharding key， 心智負擔較大

⑷ 什麼叫分布式資料庫，有什麼優點和缺點

分布式資料庫系統優點：

①更適合分布式的管理與控制。

分布式資料庫系統版的結構更適合具有地權理分布特性的組織或機構使用，允許分布在不同區域、不同級別的各個部門對其自身的數據實行局部控制。

②具有靈活的體系結構。

分布式DBMS可以設計成具有不同程度的自治性，從具有充分的場地自治到幾乎是完全集中式的控制。

③系統經濟，可靠性高，可用性好。

由於數據分布在多個場地並有許多復制數據，在個別場地或個別通信鏈路發生故障時，不致於導致整個系統的崩潰，而且系統的局部故障不會引起全局失控。

④在一定條件下響應速度加快。

如果存取的數據在本地資料庫中，那末就可以由用戶所在的計算機來執行，速度就快。

⑤可擴展性好，易於集成現有系統，也易於擴充。

分布式資料庫系統缺點：

①通信開銷較大，故障率高。

②數據的存取結構復雜。

③數據的安全性和保密性較難控制。

⑸ 大數據的分布式資料庫的發展趨勢如何(分布式資料庫的優點)

現在大數據是一個十分火熱的技術，這也使得很多人都開始關注大數據的任何動態，因為大數據在某種程度上來說能夠影響我們的生活。在這篇文章中我們就給大家介紹一下大數據的分布式資料庫的發展趨勢，希望這篇文章能夠幫助大家更好理解大數據的分布式資料庫的發展趨勢。

其實不論是Hadoop還是分布式資料庫，技術體繫上兩者都已經向著計算存儲層分離的方式演進。對於Hadoop來說這一趨勢非常明顯，HDFS存儲與YARN調度計算的分離，使得計算與存儲均可以按需橫向擴展。而分布式資料庫近年來也在遵循類似的趨勢，很多資料庫已經將底層存儲與上層的SQL引擎進粗芹行剝離。傳統的XML資料庫、OO資料庫、與pre-RDBMS正在消亡；新興領域文檔類資料庫、圖資料庫、Table-Style資料庫與Multi-Model資料庫正在擴大自身影響；傳統關系型資料庫、列存儲資料庫、內存分析型資料庫正在考慮轉型。可以看到，從技術完整性與成熟度來看，Hadoop確實還處於相對早期的形態。直到今天，很多技術在很多企業應用中需要大量的手工調優才能夠勉強運行。同時，Hadoop的主要應用場景一直以來面向批處理分析型業務，傳統資料庫在線聯機處理部分不是其主要的發展方向。同時Hadoop技術由於開源生態體系過於龐大，同時參與改造的廠商太多，使得用戶很難完全熟悉整個體系，這一方面大大增加了開發的復雜度，提升了用戶使用的難度，另一方面則是各個廠商之間維護不同版本，使得產品的發展方向可能與開源版本差別逐漸加大。

而分布式資料庫領域經歷了幾十年的磨練，傳統RDBMS的MPP技術早已經爐火純青，在分類眾多的分布式資料庫中，其主要發展方向基本可以分為「分布式聯機資料庫」與「分布式分析型資料庫」兩種。對比Hadoop與分布式資料庫可以看出，Hadoop的產品發展方向定位，與分布式資料庫中列存儲數據戚棗庫相當重疊而在高並發聯機交易場景，在Hadoop中除了HBase能夠勉強沾邊以外，分布式資料庫則占據絕對的優勢。目前，從Hadoop行業的發展來看，很多廠商而是將其定位改變為數據科學與機器學習服務商。因此，從商業模式上看以Hadoop分銷的商業模式基本已經宣告結束，用戶已經體驗到維護整個Hadoop平台的困難而不願被強迫購買整個平台。大量用戶更願意把原來Hadoop的部件拆開靈活使用，為使用場景岩仔畢和結果買單，而非平台本身買單。另外一個細分市場——非結構化小文件存儲，一直以來都是對象存儲、塊存儲，與分布式文件系統的主戰場。如今，一些新一代資料庫也開始進入該領域，可以預見在未來的幾年中，小型非結構化文件存儲也可能成為具備多模數據處理能力的分布式資料庫的戰場之一。

我們在這篇文章中給大家介紹了很多有關大數據分布資料庫的發展前景，通過這篇文章我們不難發現資料庫的發展是一個極其重要的內容，只有搭建分布式資料庫，大數據才能夠更好地為我們服務。

⑹ 國內做分布式資料庫開發的現狀如何

基礎軟體創業其實我覺得是個好生意，尤其是資料庫，但是前提是確實在技術上有所創新，這么一來技術壁壘就巨高，這就是護城河。如果只是去模仿 Oracle，是沒有太大前途的（當然靠關系那種就另說了，反正我本人不認為這樣是正確的價值觀），想想人家 O 記在這個領域做了 30 年，你走人家的老路憑什麼幹得動人家？ 目前來說我覺得之所以國內還沒有太大成功的公司涌現說到底還是因為技術不行或者路子不對或者客戶的歷史包袱太重，拿個 Hadoop 改改就是大數據了嗎？真正的 OLTP 業務敢碰嗎？所以就造成了做項目掙快錢攢方案搞數據分析的公司扎堆，真正在 OLTP 端的創新沒人敢碰。另外一個重要的問題就是，國內幾乎沒人懂開源。最近幾年重要的基礎軟體創新都在開源社區，比如 Docker / Kubenetes (Mesos) / Spark ...憑一個公司的力量是很難跟上社區的發展速度的。國內的大多數開源項目不管是代碼質量，用心程度，設計的視野上都太弱了，連最基本的英文交流都很少有開源項目注意，更不用說生態了。不過，還是有希望的，至少學術界最近幾年的進展，讓我們看到了在分布式 OLTP 系統 (NewSQL) 上的一些希望，而且這塊在全球范圍內都是一個藍海。基於這個背景，我們創立了 PingCAP，從零開始拋開一切歷史包袱去實現一個全新的資料庫 TiDB，TiDB 的目標就是瞄準世界頂級的通用分布式資料庫開源項目和未來的行業標准去的。雖然這個東西確實很難, 但我也不覺得我們會比矽谷的頂級基礎軟體公司差:)，不客氣的講，我們在這個領域也遠遠走到了各個友商的前面，另外一方面如果不難也沒有做它的價值，如果未來的資料庫還是需要像現在分庫分表中間件 Oracle，我覺得就太無趣了。就說一個 Cloud-Native，目前來說基本沒有 OLTP 的資料庫能搞定。

⑺ 如何用SQLServer建立分布式資料庫

很多組織機構慢慢的在不同的伺服器和地點部署SQLServer資料庫——為各種應用和目的——開始考慮通過SQLServer集群的方式來合並。

將SQLServer實例和資料庫合並到一個中心的地點可以減低成本，尤其是維護和軟硬體許可證。此外，在合並之後，可以減低所需機器的數量，這些機器就可以用於備用。

當尋找一個備用，比如高可用性的環境，企橡納業常常決定部署Microsoft的集群架構。我常常被問到小的集群(由較少的節點組成)SQLServer實例和作為中心解決方案的大的集群哪一種更好。在我們比較了這兩個集群架構之後，我讓你們自己做決定。

什麼是Microsoft集群伺服器

MSCS是一個WindowsServer企業版中的內建功能。這個軟體支持兩個或者更多伺服器節點連接起來形成一個「集群」，來獲得更高的可用性和對數據和應用更簡便的管理。MSCS可以自動的檢查到伺服器或者應用的失效，並從中恢復。你也可以使用它來(手動)移動伺服器之間的負載來平衡利用率以及無需停機時間來調度計劃中的維護任務。

這種集群設計使用軟體「心跳」來檢測應用或者伺服器的失效。在伺服器失效的事件中，它會自動將資源(比如磁碟和IP地址)的所有權從失效的伺服器轉移到活動的伺服器。注意還有方法可以保持心跳連接的更高的可用性，比如站點全面失效的情況下。

MSCS不要求在客戶計算機上安裝任何特殊軟體，因此用戶在災難恢復的經歷依賴於客戶-伺服器應用中客戶一方的本質。客戶的重新連接常常是透明的，因為MSCS在相同的IP地址上重啟應用、文件共享等等。進一步，為了災難恢復，集群的節點可以處於分離的、遙遠的地點。

在集群伺服器上的SQLServer

SQLServer2000可以配置為最多4個節點的集群，而SQLServer2005可以配置為最多8個節點的集群。當一個SQLServer實例被配置為集群之後，它的磁碟資源、IP地址和服務就形成了集群組來實現災難恢復。

SQLServer2000允許在一個集群上安裝16個實例。根據在線幫助，「SQLServer2005在一個伺服器或者處理器上可以支持最多50個SQLServer實例，」但是，「只能使用25個硬碟驅動器符，因此如果你需要更多的實例，那麼需要預先規劃。」

注意SQLServer實例的災難恢復階段是指SQLServer服務開始所需要的時間，這可能從幾秒鍾到幾分鍾。如果你需要更高的可用性，考慮使用其神拆他的方法，比如logshipping和資料庫鏡像。

單個的大的SQLServer集群還是小的集群

下面是大的、由更多的節點組成的集群的優點：

◆更高的可用新(更多的節點來災難恢復)。

◆更多的負載游如棗均衡選擇(更多的節點)。

◆更低廉的維護成本。

◆增長的敏捷性。多達4個或者8個節點，依賴於SQL版本。

◆增強的管理性和簡化環境(需要管理的少了)。

◆更少的停機時間(災難恢復更多的選擇)。

◆災難恢復性能不受集群中的節點數目影響。

下面是單個大的集群的缺點：

◆集群節點數目有限(如果需要第9個節點怎麼辦)。

◆在集群中SQL實例數目有限。

◆沒有對失效的防護——如果磁碟陣列失效了，就不會發生災難恢復。

◆使用災難恢復集群，無法在資料庫級別或者資料庫對象級別，比如表，創建災難恢復集群。

虛擬化和集群

虛擬機也可以參與到集群中，虛擬和物理機器可以集群在一起，不會發生問題。SQLServer實例可以在虛擬機上，但是性能可能會受用影響，這依賴於實例所消耗的資源。在虛擬機上安裝SQLServer實例之前，你需要進行壓力測試來驗證它是否可以承受必要的負載。

在這種靈活的架構中，如果虛擬機和物理機器集群在一起，你可以在虛擬機和物理機器之間對SQLServer進行負載均衡。比如，使用虛擬機上的SQLServer實例開發應用。然後在你需要對開發實例進行壓力測試的時候，將它災難恢復到集群中更強的物理機器上。

集群伺服器可以用於SQLServer的高可用性、災難恢復、可擴展性和負載均衡。單個更大的、由更多的節點組成的集群往往比小的、只有少數節點的集群更好。大個集群允許更靈活環境，為了負載均衡和維護，實例可以從一個節點移動到另外的節點。

⑻ java的某些項目為什麼要採用分布式開發什麼是分布式開發

java的某些項目為什麼要採用分布式開發，分布式開發

在資料庫應用程序的開發過程中，網路已走到社會的各個角落。從金融行業的銀行聯網、交通行業的售票系統、公安系統的全國戶籍管理等等，這些企業或行業單位之間地理分布性或業務分布性，使得一個企業或行業擁有多個網路伺服器，如何在這種分布式的網路環境下實現高效的資料庫應用程序的開發是一個重要的問題。

分布式應用開發簡單的說，是指將用戶界面、控制台服務、資料庫管理三個層次部署在不同的位置上。其中用戶界面是客戶端實現的功能，控制台服務是一個專門的伺服器，數據管理是在一個專門的資料庫伺服器上實現的。

提示：這里的Web伺服器，都是指軟體（如IIS等Web伺服器軟體），它和Web伺服器應用以及其它程序等，共同存在於伺服器計算機上。

控制台CGI應用：是一個獨立的控制台EXE。它在一個標准輸入設備上接收客戶端的請求信息，在標准輸出設備上將結果返回給伺服器。