❶ 如何編寫一個分布式資料庫
基於hadoop的分布式資料庫有hbase。安裝hbase除了要安裝hadoop外，還要安裝Zookeeper。
分布式hbase安裝和分布式hadoop安裝方法差不多，hbase要有master和regionserver，regionserver相當於slave，你可以在maser上面安裝好hbase，然後把它拷貝到其它slave伺服器，再修改一些配置.
❷ 目前主流的分布式資料庫系統實現方案有哪些
（1）方案一（資料庫保存所有伺服器索引信息）
全對稱結構，沒有中央伺服器
web方案：
只從本地資料庫檢索符合條件的記錄，給出結果
每次檢索都要從本地伺服器的海量數據中進行
資料庫方案：
資料庫保存所有伺服器的索引內容
緩存命中率高的記錄，減少檢索時間
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用，每個結點一萬條記錄
web伺服器：同時一百線程在本地資料庫伺服器檢索
資料庫伺服器：每次接收一百個查詢請求；每個請求要從一百萬條索引中檢索（最壞的情況）；緩沖機制可以稍微減輕負擔
數據更新操作：
同時更新所有資料庫/只更新本地，伺服器間相互同步
方案二（資料庫保存本地索引及少量緩沖）
每高校作為一個結點
所有結點全對稱結構，網路中沒有一個中央伺服器
web方案：
接收到請求時同時多線程向其它伺服器同時搜索（伺服器壓力問題？）
資料庫方案：
資料庫保存本地數據
資料庫保存一定量緩沖數據，
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用
則每個web伺服器同時發起一萬個線程向其它數據伺服器搜索（oops!）
每個資料庫伺服器會同時接收到一萬個查詢請求（oops！）
採用學習過程只能少量減少查詢請求和web伺服器搜索線程
數據更新操作：
只更新本地
方案三（中央伺服器方案一）
每高校一個結點
每結點結構相同，連接到同一個中央伺服器
web方案
每個查詢向中央伺服器進行，由中央伺服器實行檢索，中央伺服器返回檢索結果
資料庫方案
中央資料庫保存所有索引信息
每結點可以只用小型資料庫保存本地用戶和其它信息即可
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用，每結點資料記錄一萬條
web伺服器：同時發起一百個進程向中央資料庫查詢
資料庫伺服器（中央）：同時接收一萬條查詢請求並返回大容量結果
資料庫伺服器（結點）：少量工作
數據更新操作：
只更新中央伺服器
方案四（中央伺服器方案二）
每高校一個結點
每結點結構相同，連接到同一中央伺服器
web方案：
每個查詢向中央伺服器進行，由中央伺服器根據查詢內容進行轉發到結點資料庫，再由結點資料庫返回結果
資料庫方案：
中央伺服器保存各結點分類信息，根據頁面請求的分類轉發查詢到相應伺服器
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用，每結點資料記錄一萬條，每結點一百個類別
web伺服器：同時一百個進程向中央資料庫查詢
資料庫伺服器（中央）：同時接收一萬條請求並轉發
資料庫伺服器（結點）：從中央伺服器接收查詢請求，最壞情況下每結點接收到一萬條查詢請求
數據更新操作：
只更新本地伺服器
分類變化時更新中央伺服器
❸ 如何在海量數據環境下，搭建分布式資料庫系統
如果做分布式的話，首先需要對數據做個有效的劃分， 可以通過地區屬性或者其他類似屬性做水平擴展，把不同地域的數據放在不同資料庫上。 但是這種水平分割應當盡量避免跨區的訪問。或者設計一個數據中心，把各個區中和報表相關的匯總數據抽取到倉庫裡面去，提供報表。
這樣的做法在聯機游戲中非常常見，比如魔獸世界，fifa on line等
或者做垂直分割，根據時間或者類似屬性把數據分割到不同資料庫上去，基本架構是一台在用伺服器支持讀寫操作，幾台歷史伺服器提供數據查詢，一些轉儲腳本定期把數據從在用伺服器遷移到歷史伺服器上去...
❹ 分布式資料庫系統(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之間進行協調
在一個異構型分布式處理環境中 還需提供數據和進程移植的支持 這里的異構型是指各個場地的硬體 軟體之間存在著差別
分布式資料庫管理系統
lishixin/Article/program/Oracle/201311/16998
❺ 如何編寫一個分布式資料庫
某種程度上看來，資料庫作為整個系統的核心，這句話其實並不誇張，資料庫的選型關繫到上層業務代碼實現的方方面面，現在比較流行的架構方案是上層業務邏輯微服務化，並且結合分布式緩存，這套框架已經基本能做到上層業務的彈性擴展，但是最底層的數據存儲還是很難去中心化（除非整個技術棧中去除關系型資料庫（RDBMS）, 全部採用 NoSQL）。所以，經常是 RDBMS 成為整個系統的瓶頸。
在長期的斗爭中，大家總結出了很多方式來擴展最底層的關系型資料庫：
1. 主從，一主多從，雙寫，通過隊列暫存請求... 這些方案其實並沒有解決問題，寫入仍然是單點，而且對於 DBA 的挑戰比較大，今天我們暫時就不討論了。
2. 通過中間件 Sharding，常見的開源方案有： Cobar, TDDL, Vitess, Kingshard, MyCat 等，這些方案的思路是攔截 SQL 的請求通過 sharding key 和一定規則，將請求轉發/廣播到不同的 MySQL 實例上，從而實現水平擴展的效果，這個方案基本解決了單點寫入的問題，對於業務來說整體的吞吐也上來了，看上去不錯，這個方案是大多數業務遇到性能瓶頸的解決方案，但是缺點也是有的：
1）大多中間件都沒有解決動態擴容的問題，多採用了靜態的路由策略，擴容一般還處於人工 x2 的狀態，對 DBA 要求比較高。
2）從一定程度上來說都放棄了事務，這是由於一條語句有可能會涉及到多個資料庫實例，實現分布式 事務是一個比較難的事情，我們後面會詳細的介紹。
3）對業務不透明，需要指定 sharding key， 心智負擔較大
❻ 分布式資料庫的工作原理是什麼
分布式數據有不同的理論支撐，TiDB 官方社區（AskTUG）
目前國產數據排名靠前的可以了解下 TiDB
水平彈性擴展
通過簡單地增加新節點即可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕松應對高並發、海量數據場景。
分布式事務
TiDB 100% 支持標準的 ACID 事務。
真正金融級高可用
相比於傳統主從 (M-S) 復制方案，基於 Raft 的多數派選舉協議可以提供金融級的 100% 數據強一致性保證，且在不丟失大多數副本的前提下，可以實現故障的自動恢復 (auto-failover)，無需人工介入。