分布式資料庫與集群

㈠ 分布式資料庫的分布式資料庫相對傳統集中式資料庫的優點

大數據時代，面對日益增長的海量數據，傳統的集中式資料庫的弊端日益顯現，分布式資料庫相對傳統的集中式資料庫有如下優點。
● 更高的數據訪問速度：分布式資料庫為了保證數據的高可靠性，往往採用備份的策略實現容錯，所以，在讀取數據的時候，客戶端可以並發地從多個
備份伺服器同時讀取，從而提高了數據訪問速度。
● 更強的可擴展性：分布式資料庫可以通過增添存儲節點來實現存儲容量的線性擴展，而集中式資料庫的可擴展性十分有限。
● 更高的並發訪問量：分布式資料庫由於採用多台主機組成存儲集群，所以相對集中式資料庫，它可以提供更高的用戶並發訪問量。

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

1.分布式資料庫是資料庫的一種，是資料庫技術和網路技術的結合產物。

2.各有優點和缺點.分布式資料庫分為邏輯上分部物理上分布及邏輯上分布物理上集中兩種。

是的,分布式數據文件便於資料庫的管理維護。

㈢ 分布式資料庫 與 集群資料庫 之間的關系

分布式, 往往指數據被割裂, 分置不同地方
集群指, 在任何實例上, 看到的數據都是一致的.
兩者有非常大的不同.
mysql 做不了集群, 只能做分布. 可以認為你必須先知道數據在哪個mysql實例上.

㈣ 分布式與集群的區別是什麼

性質不同：分布式是不同的業務模塊部署在不同的伺服器上或者同一個業務模塊分拆多個子業務，部署在不同的伺服器上，解決高並發的問題。集群是同一個業務部署在多台機器上，提高系統可用性。

集群一般被分為三種類型，高可用集群如RHCS、LifeKeeper等，負載均衡集群如LVS等、高性能運算集群;分布式應該是高性能運算集群范疇內。

集群的使用環境

伺服器常見特性：伺服器集群在運行計算時，溫度較高，但聲音小，對辦公區域環境影響較小。當一組集群因節點多方便置放，需放置機櫃。

在伺服器裡面2U4路機器與需要IB交換機的集群，噪音偏大，不建議放在辦公環境內，伺服器集群建議使用環境：恆溫、恆濕、獨立的空間放置。

㈤ 什麼是資料庫集群 分布式資料庫

集群簡單理解的話，就是把資料庫放到不同的存儲設備當中
分布式就是存儲設備的地理位置不正同一個機房當中

㈥ 分布式與集群的聯系和區別

多台伺服器組成的一組計算機，作為一個整體存在，向用戶提供一組網路資源，這些單個的伺服器就是集群的節點。

集群擁有以下兩個特點：

集群必須擁有以下兩大能力：

負載均衡和錯誤恢復要求各服務實體中有執行同一任務的資源存在，而且對於同一任務的各個資源來說，執行任務所需的信息視圖必須是相同的。

例如：互聯網上訪問的人多了，就可以做一個集群，前面放一個響應伺服器，後面幾台伺服器完成同一業務，如果有業務訪問的時候，響應伺服器看哪台伺服器的負載不是很重，就將任務交給哪台去完成。

而分布式，從狹義上理解，也與集群差不多，但是它的組織比較鬆散，不像集群，有一定組織性，一台伺服器宕了，其他的伺服器可以頂上來。分布式的每一個節點，都完成不同的業務，一個節點宕了，這個業務就不可訪問了。

㈦ 分布式資料庫與資料庫集群的區別到底是什麼哪位高手幫忙解惑下~~~~~~~~~~跪求

來具體說說資料庫集群吧
集群主要分成三大類 （高可用集群， 負載均衡集群，科學計算集群）
高可用集群( High Availability Cluster)
負載均衡集群(Load Balance Cluster)
科學計算集群(High Performance Computing Cluster)

1、高可用集群(High Availability Cluster)
常見的就是2個節點做成的HA集群，有很多通俗的不科學的名稱，比如」雙機熱備」, 「雙機互備」, 「雙機」。高可用集群解決的是保障用戶的應用程序持續對外提供服務的能力。 (請注意高可用集群既不是用來保護業務數據的，保護的是用戶的業務程序對外不間斷提供服務，把因軟體/硬體/人為造成的故障對業務的影響降低到最小程度)。

2、負載均衡集群(Load Balance Cluster)

負載均衡系統：集群中所有的節點都處於活動狀態，它們分攤系統的工作負載。一般Web伺服器集群、資料庫集群和應用伺服器集群都屬於這種類型。

負載均衡集群一般用於相應網路請求的網頁伺服器，資料庫伺服器。這種集群可以在接到請求時，檢查接受請求較少，不繁忙的伺服器，並把請求轉到這些伺服器上。從檢查其他伺服器狀態這一點上看，負載均衡和容錯集群很接近，不同之處是數量上更多。

3、科學計算集群(High Performance Computing Cluster)

高性能計算(High Perfermance Computing)集群，簡稱HPC集群。這類集群致力於提供單個計算機所不能提供的強大的計算能力。

高性能計算分類：

3.1、高吞吐計算(High-throughput Computing)
有一類高性能計算，可以把它分成若干可以並行的子任務，而且各個子任務彼此間沒有什麼關聯。象在家搜尋外星人（ SETI@HOME – Search for Extraterrestrial Intelligence at Home ）就是這一類型應用。
這一項目是利用Internet上的閑置的計算資源來搜尋外星人。SETI項目的伺服器將一組數據和數據模式發給Internet上參加SETI的計算節點，計算節點在給定的數據上用給定的模式進行搜索，然後將搜索的結果發給伺服器。伺服器負責將從各個計算節點返回的數據匯集成完整的 數據。因為這種類型應用的一個共同特徵是在海量數據上搜索某些模式，所以把這類計算稱為高吞吐計算。
所謂的Internet計算都屬於這一類。按照 Flynn的分類，高吞吐計算屬於SIMD（Single Instruction/Multiple Data）的范疇。

3.2、分布計算(Distributed Computing)
另一類計算剛好和高吞吐計算相反，它們雖然可以給分成若干並行的子任務，但是子任務間聯系很緊密，需要大量的數據交換。按照Flynn的分類，分布式的高性能計算屬於MIMD（Multiple Instruction/Multiple Data）的范疇。

下面說說這幾種集群的應用場景：

高可用集群這里不多作說明。

想Dubbo是比較偏向於負載均衡集群，用過的猿友應該知道（不知道的可以自行了解一下），Dubbo同一個服務是可以有多個提供者的，當一個消費者過來，它要消費那個提供者，這里是有負載均衡機制在裡面的。

搜索引擎Elasticsearch比較偏向於科學計算集群的分布計算。

而到這里，可能不少猿友都知道，集群的一些術語：集群容錯、負載均衡。

我們以Dubbo為例：
集群容錯（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99）

Dubbo提供了這些容錯策略：
集群容錯模式：
可以自行擴展集群容錯策略，參見：集群擴展
Failover Cluster

失敗自動切換，當出現失敗，重試其它伺服器。(預設)

通常用於讀操作，但重試會帶來更長延遲。

可通過retries="2"來設置重試次數(不含第一次)。

Failfast Cluster

快速失敗，只發起一次調用，失敗立即報錯。

通常用於非冪等性的寫操作，比如新增記錄。

Failsafe Cluster

失敗安全，出現異常時，直接忽略。

通常用於寫入審計日誌等操作。

Failback Cluster

失敗自動恢復，後台記錄失敗請求，定時重發。

通常用於消息通知操作。

Forking Cluster

並行調用多個伺服器，只要一個成功即返回。

通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。

可通過forks="2"來設置最大並行數。

Broadcast Cluster

廣播調用所有提供者，逐個調用，任意一台報錯則報錯。(2.1.0開始支持)

通常用於通知所有提供者更新緩存或日誌等本地資源信息。

負載均衡（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1）

Dubbo提供了這些負載均衡策略：

Random LoadBalance

隨機，按權重設置隨機概率。

在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。

RoundRobin LoadBalance

輪循，按公約後的權重設置輪循比率。

存在慢的提供者累積請求問題，比如：第二台機器很慢，但沒掛，當請求調到第二台時就卡在那，久而久之，所有請求都卡在調到第二台上。

LeastActive LoadBalance

最少活躍調用數，相同活躍數的隨機，活躍數指調用前後計數差。

使慢的提供者收到更少請求，因為越慢的提供者的調用前後計數差會越大。

ConsistentHash LoadBalance

一致性Hash，相同參數的請求總是發到同一提供者。

當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。

演算法參見：http://en.wikipedia.org/wiki/Consistent_hashing。

預設只對第一個參數Hash，如果要修改，請配置<bbo:parameter key="hash.arguments" value="0,1" />

預設用160份虛擬節點，如果要修改，請配置<bbo:parameter key="hash.nodes" value="320" />

㈧ oracle資料庫的分布式和tomcat的集群式有什麼區別

分布式是架構部署模式的一種。分布式多用於描述架構設計上，當然現在有各種新用法。
集群是硬體部署模式的一種，是集中部署在一個機房裡的計算機群體的集中稱謂。
分布式網站集群系統是一種多網站架構模式，支持生成獨立網站、多個網站,完成各個網站橫向一體化和縱向一體化網站群的構建，主站、子站、網站間的信息可共享和信息互聯。
簡單的說：就是一個企業/個人可以像申請博客那樣自助建站，維護，更新，而分布式，就是把問題分開解決的意思，即系統分布在幾個不同伺服器上。

㈨ 集群和分布式的區別 區別是什麼

1、從概念上就可以看出兩者最主要的區別就是分布式是將一種業務拆分成多個子業務部署在多台伺服器上，進而對外提供服務；而集群就是將多台伺服器組合在一起提供同一種服務

2、集群強調在多台伺服器位置集中，並且容易統一管理；而分布式沒有具體要求，不論放置在哪個位置，只要通過網路連接起來就行

3、集群是一種物理形態，即多台伺服器在一起提供一種服務；而分布式是一種工作方式，即一個程序或業務分解到多台伺服器分別完成

㈩ 分布式資料庫與資料庫集群的區別到底是什麼哪位高手幫忙解惑下~~~~~~~~~~跪求

（1）另外一位博主的觀點（http://blog.csdn.net/bluishglc/article/details/5483162）

博主有對他的表述有作一點修改補充，方便各位猿友明了他的意思。

簡單說，分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。

例如：

如果一個任務由10個子任務組成，每個子任務單獨執行需1小時，則在一台伺服器上執行改任務需10小時。

採用分布式方案，提供10台伺服器，每台伺服器只負責處理一個子任務，不考慮子任務間的依賴關系，執行完這個任務只需一個小時。(這種工作模式的一個典型代表就是Hadoop的Map/Rece分布式計算模型）

而採用集群方案，同樣提供10台伺服器，每台伺服器都能獨立處理這個任務。假設有10個任務同時到達，10個伺服器將同時工作，10小後，10個任務同時完成，這樣，整身來看，還是平均1小時完成一個任務！（注意這里的任務和子任務的區別）

（2）知乎（https://www.hu.com/question/20004877）

這個猿友描述得很簡單明了：

分布式：一個業務分拆多個子業務，部署在不同的伺服器上
集群：同一個業務，部署在多個伺服器上

另外一位猿友從另外一個角度去表述：

集群是個物理形態，分布式是個工作方式。

這位猿友的描述也很簡潔，但是比較抽象：

按照我的理解，集群是解決高可用的，而分布式是解決高性能、高並發的

（3）網路（http://ke..com/view/4804677.htm、http://ke..com/view/3022776.htm）

集群：

集群是一組相互獨立的、通過高速網路互聯的計算機，它們構成了一個組，並以單一系統的模式加以管理。一個客戶與集群相互作用時，集群像是一個獨立的伺服器。集群配置是用於提高可用性和可縮放性。

分布式：

一種基於網路的計算機處理技術，與集中式相對應。由於個人計算機的性能得到極大的提高及其使用的普及，使處理能力分布到網路上的所有計算機成為可能。分布式計算是和集中式計算相對立的概念，分布式計算的數據可以分布在很大區域。

看完這些是不是有種似懂非懂的感覺？博主也是一樣！所以我們接下來繼續了解。

上面博主有說過自己有接觸過分布式服務框架Dubbo，那麼我們看看它為什麼說自己是分布式服務架構？（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%83%8C%E6%99%AF）

分布式服務架構

當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
此時，用於提高業務復用及整合的 分布式服務框架(RPC) 是關鍵。

偶然之間，有發現據說「Git就是分布式版本控制系統」，為什麼它是分布式的呢？

Git就是分布式版本控制系統，對應的是集中式的版本控制如SVN。簡單的說，分布式的版本控制就是每個人都可以創建一個獨立的代碼倉庫用於管理，各種版本控制的操作都可以在本地完成。每個人修改的代碼都可以推送合並到另外一個代碼倉庫中。而像SVN這樣，只有一個中央控制，所有的開發人員都必須依賴於這個代碼倉庫。每次版本控制的操作也必須鏈接到伺服器才能完成。很多公司喜歡用集中式的版本控制是為了更好的控制代碼。如果個人開發，就可以選擇Git這種分布式的。

從一般開發者的角度來看，git有以下功能：

1、從伺服器上克隆完整的Git倉庫（包括代碼和版本信息）到單機上。
2、在自己的機器上根據不同的開發目的，創建分支，修改代碼。
3、在單機上自己創建的分支上提交代碼。
4、在單機上合並分支。
5、把伺服器上最新版的代碼fetch下來，然後跟自己的主分支合並。
6、生成補丁（patch），把補丁發送給主開發者。
7、看主開發者的反饋，如果主開發者發現兩個一般開發者之間有沖突（他們之間可以合作解決的沖突），就會要求他們先解決沖突，然後再由其中一個人提交。如果主開發者可以自己解決，或者沒有沖突，就通過。
8、一般開發者之間解決沖突的方法，開發者之間可以使用pull 命令解決沖突，解決完沖突之後再向主開發者提交補丁。

看了分布式服務框架Dubbo和分布式版本控制系統Git的這些描述後，細想一下，似乎和上面的「分布式：一個業務分拆多個子業務，部署在不同的伺服器上，集群：同一個業務，部署在多個伺服器上」的觀點些相似。

Dubbo將核心業務抽取出來，作為獨立的服務模塊，各個模塊之間只需要依賴介面，介面實現分離，那麼開發人員可以各自完成自己負責的服務模塊，最後完成一個完整的系統。他們的目標是完成一個系統，而各個子服務模塊相當於子業務。Git也類似。

事實上，分布式很多時候都開不了集群的，在Dubbo、Hadoop、Elasticsearch都有體現。

現在分布式概念可能我們相對比較清晰了，集群概念可能還比較模糊。另外，集群是如何跟分布式配合的呢，接下來我們繼續了解集群。

集群主要分成三大類 （高可用集群， 負載均衡集群，科學計算集群）

高可用集群( High Availability Cluster)
負載均衡集群(Load Balance Cluster)
科學計算集群(High Performance Computing Cluster)

1、高可用集群(High Availability Cluster)

常見的就是2個節點做成的HA集群，有很多通俗的不科學的名稱，比如」雙機熱備」, 「雙機互備」, 「雙機」。

高可用集群解決的是保障用戶的應用程序持續對外提供服務的能力。 (請注意高可用集群既不是用來保護業務數據的，保護的是用戶的業務程序對外不間斷提供服務，把因軟體/硬體/人為造成的故障對業務的影響降低到最小程度)。

2、負載均衡集群(Load Balance Cluster)

負載均衡系統：集群中所有的節點都處於活動狀態，它們分攤系統的工作負載。一般Web伺服器集群、資料庫集群和應用伺服器集群都屬於這種類型。

負載均衡集群一般用於相應網路請求的網頁伺服器，資料庫伺服器。這種集群可以在接到請求時，檢查接受請求較少，不繁忙的伺服器，並把請求轉到這些伺服器上。從檢查其他伺服器狀態這一點上看，負載均衡和容錯集群很接近，不同之處是數量上更多。

3、科學計算集群(High Performance Computing Cluster)

高性能計算(High Perfermance Computing)集群，簡稱HPC集群。這類集群致力於提供單個計算機所不能提供的強大的計算能力。

高性能計算分類：

3.1、高吞吐計算(High-throughput Computing)

有一類高性能計算，可以把它分成若干可以並行的子任務，而且各個子任務彼此間沒有什麼關聯。象在家搜尋外星人（ SETI@HOME – Search for Extraterrestrial Intelligence at Home ）就是這一類型應用。

這一項目是利用Internet上的閑置的計算資源來搜尋外星人。SETI項目的伺服器將一組數據和數據模式發給Internet上參加SETI的計算節點，計算節點在給定的數據上用給定的模式進行搜索，然後將搜索的結果發給伺服器。伺服器負責將從各個計算節點返回的數據匯集成完整的 數據。因為這種類型應用的一個共同特徵是在海量數據上搜索某些模式，所以把這類計算稱為高吞吐計算。

所謂的Internet計算都屬於這一類。按照 Flynn的分類，高吞吐計算屬於SIMD（Single Instruction/Multiple Data）的范疇。

3.2、分布計算(Distributed Computing)

另一類計算剛好和高吞吐計算相反，它們雖然可以給分成若干並行的子任務，但是子任務間聯系很緊密，需要大量的數據交換。按照Flynn的分類，分布式的高性能計算屬於MIMD（Multiple Instruction/Multiple Data）的范疇。

下面說說這幾種集群的應用場景：

高可用集群這里不多作說明。

想Dubbo是比較偏向於負載均衡集群，用過的猿友應該知道（不知道的可以自行了解一下），Dubbo同一個服務是可以有多個提供者的，當一個消費者過來，它要消費那個提供者，這里是有負載均衡機制在裡面的。

搜索引擎Elasticsearch比較偏向於科學計算集群的分布計算。

而到這里，可能不少猿友都知道，集群的一些術語：集群容錯、負載均衡。

我們以Dubbo為例：

集群容錯（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99）

Dubbo提供了這些容錯策略：

集群容錯模式：
可以自行擴展集群容錯策略，參見：集群擴展

Failover Cluster
失敗自動切換，當出現失敗，重試其它伺服器。(預設)
通常用於讀操作，但重試會帶來更長延遲。
可通過retries="2"來設置重試次數(不含第一次)。

Failfast Cluster
快速失敗，只發起一次調用，失敗立即報錯。
通常用於非冪等性的寫操作，比如新增記錄。

Failsafe Cluster
失敗安全，出現異常時，直接忽略。
通常用於寫入審計日誌等操作。

Failback Cluster
失敗自動恢復，後台記錄失敗請求，定時重發。
通常用於消息通知操作。

Forking Cluster
並行調用多個伺服器，只要一個成功即返回。
通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。
可通過forks="2"來設置最大並行數。

Broadcast Cluster
廣播調用所有提供者，逐個調用，任意一台報錯則報錯。(2.1.0開始支持)
通常用於通知所有提供者更新緩存或日誌等本地資源信息。

負載均衡（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1）

Dubbo提供了這些負載均衡策略：

Random LoadBalance
隨機，按權重設置隨機概率。
在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。

RoundRobin LoadBalance
輪循，按公約後的權重設置輪循比率。
存在慢的提供者累積請求問題，比如：第二台機器很慢，但沒掛，當請求調到第二台時就卡在那，久而久之，所有請求都卡在調到第二台上。

LeastActive LoadBalance
最少活躍調用數，相同活躍數的隨機，活躍數指調用前後計數差。
使慢的提供者收到更少請求，因為越慢的提供者的調用前後計數差會越大。

ConsistentHash LoadBalance
一致性Hash，相同參數的請求總是發到同一提供者。
當某一台提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。
演算法參見：http://en.wikipedia.org/wiki/Consistent_hashing。
預設只對第一個參數Hash，如果要修改，請配置<bbo:parameter key="hash.arguments" value="0,1" />
預設用160份虛擬節點，如果要修改，請配置<bbo:parameter key="hash.nodes" value="320" />

還有比較好奇它們是怎麼通信的？

像早期版本的Elasticsearch的話，自動發現節點機制，ES是一個基於p2p的系統，它先通過廣播尋找存在的節點，再通過多播協議來進行節點之間的通信，同時也支持點對點的交互。

而Dubbo是有個注冊中心，它支持多個注冊中心，但是推薦使用ZooKeeper。關於ZooKeeper可以自行了解，很多集群相關的框架都有使用到它。當然像Elasticsearch是自己有相應的機制實現的。