❶ 什麼叫分布式資料庫，有什麼優點和缺點
1.分布式資料庫是資料庫的一種，是資料庫技術和網路技術的結合產物。
2.各有優點和缺點.分布式資料庫分為邏輯上分部物理上分布及邏輯上分布物理上集中兩種。
是的,分布式數據文件便於資料庫的管理維護。
❷ 分布式資料庫 與 集群資料庫 之間的關系
分布式, 往往指數據被割裂, 分置不同地方
集群指, 在任何實例上, 看到的數據都是一致的.
兩者有非常大的不同.
mysql 做不了集群, 只能做分布. 可以認為你必須先知道數據在哪個mysql實例上.
❸ 分布式資料庫與資料庫集群的區別到底是什麼哪位高手幫忙解惑下~~~~~~~~~~跪求
（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是自己有相應的機制實現的。
❹ 分布式資料庫的分布式資料庫相對傳統集中式資料庫的優點
大數據時代，面對日益增長的海量數據，傳統的集中式資料庫的弊端日益顯現，分布式資料庫相對傳統的集中式資料庫有如下優點。
● 更高的數據訪問速度：分布式資料庫為了保證數據的高可靠性，往往採用備份的策略實現容錯，所以，在讀取數據的時候，客戶端可以並發地從多個
備份伺服器同時讀取，從而提高了數據訪問速度。
● 更強的可擴展性：分布式資料庫可以通過增添存儲節點來實現存儲容量的線性擴展，而集中式資料庫的可擴展性十分有限。
● 更高的並發訪問量：分布式資料庫由於採用多台主機組成存儲集群，所以相對集中式資料庫，它可以提供更高的用戶並發訪問量。
❺ 「分布式」與「集群」的區別是什麼
簡單說，分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。
例如：
如果一個任務由10個子任務組成，每個子任務單獨執行需1小時，則在一台伺服器上執行改任務需10小時。
採用分布式方案，提供10台伺服器，每台伺服器只負責處理一個子任務，不考慮子任務間的依賴關系，執行完這個任務只需一個小時。(這種工作模式的一個典型代表就是Hadoop的Map/Rece分布式計算模型）
而採用集群方案，同樣提供10台伺服器，每台伺服器都能獨立處理這個任務。假設有10個任務同時到達，10個伺服器將同時工作，10小後，10個任務同時完成，這樣，整身來看，還是1小時內完成一個任務！
以下是摘抄自網路文章：
一、集群概念
1. 兩大關鍵特性
集群是一組協同工作的服務實體，用以提供比單一服務實體更具擴展性與可用性的服務平台。在客戶端看來，一個集群就象是一個服務實體，但事實上集群由一組服務實體組成。與單一服務實體相比較，集群提供了以下兩個關鍵特性：
· 可擴展性－－集群的性能不限於單一的服務實體，新的服務實體可以動態地加入到集群，從而增強集群的性能。
· 高可用性－－集群通過服務實體冗餘使客戶端免於輕易遇到out of service的警告。在集群中，同樣的服務可以由多個服務實體提供。如果一個服務實體失敗了，另一個服務實體會接管失敗的服務實體。集群提供的從一個出 錯的服務實體恢復到另一個服務實體的功能增強了應用的可用性。
2. 兩大能力
為了具有可擴展性和高可用性特點，集群的必須具備以下兩大能力：
· 負載均衡－－負載均衡能把任務比較均衡地分布到集群環境下的計算和網路資源。
· 錯誤恢復－－由於某種原因，執行某個任務的資源出現故障，另一服務實體中執行同一任務的資源接著完成任務。這種由於一個實體中的資源不能工作，另一個實體中的資源透明的繼續完成任務的過程叫錯誤恢復。
負載均衡和錯誤恢復都要求各服務實體中有執行同一任務的資源存在，而且對於同一任務的各個資源來說，執行任務所需的信息視圖（信息上下文）必須是一樣的。
3. 兩大技術
實現集群務必要有以下兩大技術：
· 集群地址－－集群由多個服務實體組成，集群客戶端通過訪問集群的集群地址獲取集群內部各服務實體的功能。具有單一集群地址（也叫單一影像）是集群的一個基本特徵。維護集群地址的設置被稱為負載均衡器。負載均衡器內部負責管理各個服務實體的加入和退出，外部負責集群地址向內部服務實體地址的轉換。有的負載均衡器實現真正的負載均衡演算法，有的只支持任務的轉換。只實現任務轉換的負載均衡器適用於支持ACTIVE-STANDBY的集群環境，在那裡，集群中只有一個服務實體工作，當正在工作的服務實體發生故障時，負載均衡器把後來的任務轉向另外一個服務實體。
· 內部通信－－為了能協同工作、實現負載均衡和錯誤恢復，集群各實體間必須時常通信，比如負載均衡器對服務實體心跳測試信息、服務實體間任務執行上下文信息的通信。
具有同一個集群地址使得客戶端能訪問集群提供的計算服務，一個集群地址下隱藏了各個服務實體的內部地址，使得客戶要求的計算服務能在各個服務實體之間分布。內部通信是集群能正常運轉的基礎，它使得集群具有均衡負載和錯誤恢復的能力。
二、集群分類
Linux集群主要分成三大類(高可用集群， 負載均衡集群，科學計算集群)
高可用集群(High Availability Cluster)
負載均衡集群(Load Balance Cluster)
科學計算集群(High Performance Computing Cluster)
具體包括：
Linux High Availability 高可用集群
(普通兩節點雙機熱備，多節點HA集群，RAC, shared, share-nothing集群等)
Linux Load Balance 負載均衡集群
(LVS等....)
Linux High Performance Computing 高性能科學計算集群
(Beowulf 類集群....)
三、詳細介紹
1. 高可用集群(High Availability Cluster)
常見的就是2個節點做成的HA集群，有很多通俗的不科學的名稱，比如"雙機熱備"，"雙機互備"，"雙機"。
高可用集群解決的是保障用戶的應用程序持續對外提供服務的能力。 (請注意高可用集群既不是用來保護業務數據的，保護的是用戶的業務程序對外不間斷提供服務，把因軟體/硬體/人為造成的故障對業務的影響降低到最小程度)。
2. 負載均衡集群(Load Balance Cluster)
負載均衡系統：集群中所有的節點都處於活動狀態，它們分攤系統的工作負載。一般Web伺服器集群、資料庫集群和應用伺服器集群都屬於這種類型。
負載均衡集群一般用於相應網路請求的網頁伺服器，資料庫伺服器。這種集群可以在接到請求時，檢查接受請求較少，不繁忙的伺服器，並把請求轉到這些伺服器上。從檢查其他伺服器狀態這一點上看，負載均衡和容錯集群很接近，不同之處是數量上更多。
3. 科學計算集群(High Performance Computing Cluster)
高性能計算(High Perfermance Computing)集群，簡稱HPC集群。這類集群致力於提供單個計算機所不能提供的強大的計算能力。
3.1 高性能計算分類
3.1.1 高吞吐計算(High-throughput Computing)
有一類高性能計算，可以把它分成若干可以並行的子任務，而且各個子任務彼此間沒有什麼關聯。象在家搜尋外星人（ SETI@HOME -- Search for Extraterrestrial Intelligence at Home ）就是這一類型應用。這一項目是利用Internet上的閑置的計算資源來搜尋外星人。SETI項目的伺服器將一組數據和數據模式發給Internet上參加SETI的計算節點，計算節點在給定的數據上用給定的模式進行搜索，然後將搜索的結果發給伺服器。伺服器負責將從各個計算節點返回的數據匯集成完整的 數據。因為這種類型應用的一個共同特徵是在海量數據上搜索某些模式，所以把這類計算稱為高吞吐計算。所謂的Internet計算都屬於這一類。按照 Flynn的分類，高吞吐計算屬於SIMD（Single Instruction/Multiple Data）的范疇。
3.1.2 分布計算(Distributed Computing)
另一類計算剛好和高吞吐計算相反，它們雖然可以給分成若干並行的子任務，但是子任務間聯系很緊密，需要大量的數據交換。按照Flynn的分類，分布式的高性能計算屬於MIMD（Multiple Instruction/Multiple Data）的范疇。
四、分布式（集群）與集群的聯系與區別
分布式是指將不同的業務分布在不同的地方；而集群指的是將幾台伺服器集中在一起，實現同一業務。
分布式中的每一個節點，都可以做集群。 而集群並不一定就是分布式的。
舉例：就比如新浪網，訪問的人多了，他可以做一個群集，前面放一個響應伺服器，後面幾台伺服器完成同一業務，如果有業務訪問的時候，響應伺服器看哪台伺服器的負載不是很重，就將給哪一台去完成。
而分布式，從窄意上理解，也跟集群差不多， 但是它的組織比較鬆散，不像集群，有一個組織性，一台伺服器垮了，其它的伺服器可以頂上來。
分布式的每一個節點，都完成不同的業務，一個節點垮了，那這個業務就不可訪問了。
❻ 分布式資料庫和集中式資料庫的區別是什麼
分部式資料庫是資料庫的一種，是資料庫技術和網路技術的結合產物.各有優點和缺點.分布式資料庫分為邏輯上分部物理上分布及邏輯上分布物理上集中兩種. 是的,分布式數據文件便於資料庫的管理維護.
分部式資料庫是資料庫的一種，是資料庫技術和網路技術的結合產物.各有優點和缺點.分布式資料庫分為邏輯上分部物理上分布及邏輯上分布物理上集中兩種. 是的,分布式數據文件便於資料庫的管理維護.
❼ oracle資料庫的分布式和tomcat的集群式有什麼區別
分布式是架構部署模式的一種。分布式多用於描述架構設計上，當然現在有各種新用法。
集群是硬體部署模式的一種，是集中部署在一個機房裡的計算機群體的集中稱謂。
分布式網站集群系統是一種多網站架構模式，支持生成獨立網站、多個網站,完成各個網站橫向一體化和縱向一體化網站群的構建，主站、子站、網站間的信息可共享和信息互聯。
簡單的說：就是一個企業/個人可以像申請博客那樣自助建站，維護，更新，而分布式，就是把問題分開解決的意思，即系統分布在幾個不同伺服器上。
❽ 如何理解分布式與集群，二者區別是什麼
分布式是指不同的業務分布在不同的地方，集群指的是將幾台伺服器集中在一起，實現同一業務。白話理解的話，比如公司項目上線初期（舉例電子商務網站）
初期：用戶訪問量低，只弄了一台伺服器，一個tomcat項目運行一個web工程。
中期：用戶訪問量提高，伺服器崩了，為了解決這個問題，購買伺服器，增加伺服器數量，然後每個伺服器中個各放了一份，使用nginx代理轉發。（這就是運用集群原理）
後期：用戶訪問量不斷增加，響應速度變慢，伺服器又崩了，在不考慮增加伺服器帶寬、內存和CPU的情況下如何解決這個問題？先解決響應速度變慢，用戶頻繁調用資料庫，在客戶端與資料庫之間，使用redis緩存。解決之後，又發現問題：由於每台伺服器運行一個tomcat，放著一個web工程，用戶有可能在商品詳情存在大幅度調用資料庫，而訂單列表調用幅度小，此時就存在著模塊之間耦合度高，一個功能升級其他也需要升級，擴展性差，不能靈活部署。是該考慮項目重構，把項目按照模塊分為不同的系統（使用zookeeper進行模塊之間通信），例如：訂單系統，會員系統、搜索系統、商品信息系統。把每個模塊進行拆分，用戶在哪個系統訪問頻繁，就針對哪個系統進行對症下葯，增加緩存還是使用其他技術。（這樣我們就可以單獨對這個模塊進行服務性能的提升，不用全部都一起提升。也降低了代碼的耦合度，模塊之間互不影響，即使後期增加開發人員，也可按照敏捷開發思想只對其負責模塊進行開發，效率大大提升）。這樣一個web工程就拆分成多個web工程（多個tomcat部署）。那這個項目就可以在一台伺服器部署多個工程（不同埠進行通信）或者多台伺服器運行單個項目。（這就是分布式原理）
總而言之，分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。
❾ 大數據的分布式資料庫技術的對比
大數據技術的實現離不開很多其他的技術，我們提到最多的就是Hadoop技術，其實就目前而言，Hadoop技術看似是自成一套體系，其實並不是這樣的，Hadoop和Spark以及分布式資料庫其實也是存在差異的，我們就在這篇文章中給大家介紹一下這些內容。
首先我們說一說大數據分析，現在的大數據分析體系以Hadoop生態為主，而近年來逐漸火熱的Spark技術也是主要的生態之一。可以這么說，Hadoop技術只能算是以HDFS+YARN作為基礎的分布式文件系統，而不是資料庫。我們提到的Hadoop的歷史可以向前追溯10年，當年穀歌為了在幾萬台PC伺服器上構建超大數據集合並提供極高性能的並發訪問能力，從而發明了一種新的技術，而這個技術，也是Hadoop誕生的理論基礎。如果我們從Hadoop的誕生背景可以看出，其主要解決的問題是超大規模集群下如何對非結構化數據進行批處理計算。實際上，在Hadoop架構中，一個分布式任務可以是類似傳統結構化數據的關聯、排序、聚集操作，也可以是針對非結構化數據的用戶自定義程序邏輯。
那麼Hadoop的發展道路是什麼樣的呢。最開始的Hadoop以Big、Hive和MapRece三種開發介面為代表，分別適用於腳本批處理、SQL批處理以及用戶自定義邏輯類型的應用。而Spark的發展更是如此，最開始的SparkRDD幾乎完全沒有SQL能力，還是套用了Hive發展出的Shark才能對SQL有了一部分的支持。但是，隨著企業用戶對Hadoop的使用越發廣泛，SQL已經漸漸成為大數據平台在傳統行業的主要訪問方式之一。
下面我們就說一說分布式資料庫，分布式資料庫有著悠久的歷史，從以Oracle RAC為代表的聯機交易型分布式資料庫，到IBM DB2 DPF統計分析性分布式資料庫，分布式資料庫覆蓋了OLTP與OLAP幾乎全部的數據應用場景。而大部分分布式資料庫功能集中在結構化計算與在線增刪改查上。但是，這些傳統的分布式資料庫以數倉及分析類OLAP系統為主，其局限性在於，其底層的關系型資料庫存儲結構在效率上並不能滿足大量高並發的數據查詢以及大數據數據加工和分析的效率要求。因此，分布式資料庫在近幾年也有著極大的轉型，從單一的數據模型向多模的數據模型轉移，將OLTP、聯機高並發查詢以及支持大數據加工和分析結合起來，不再單獨以OLAP作為設計目標。同時，分布式資料庫在訪問模式上也出現了K/V、文檔、寬表、圖等分支，支持除了SQL查詢語言之外的其他訪問模式，大大豐富了傳統分布式資料庫單一的用途。一般來說，多模資料庫的主要目的是為了滿足具有高性能要求的操作型需求以及目標明確的數據倉庫功能，而不是類似大數據深度學習等數據挖掘場景。這就是分布式資料庫的實際情況。
我們在這篇文章中給大家介紹了大數據分析以及分布式資料庫的相關知識，通過這些內容相信大家已經理解了其中的具體區別了吧，如果這篇文章能夠幫助到大家這就是我們最大的心願。