A. 分布式資料庫需要考慮哪些問題
在設來計分布式資料庫時，應特別考慮源如下幾個方面的問題： 1. 數據保存 (存儲分段/復制，橫向/縱向表分區); 2. 目錄管理(catalog management): 命名，數據獨立性 3. 查詢處理(基於代價的調優， 半合並)4. 數據更新(同步/非同步)
B. 簡述分布式資料庫的模式結構
布式資料庫系統通常使用較小的計算機系統，每台計算機可單獨放在一個地方，每台計算機中都有DBMS的一份完整拷貝副本，並具有自己局部的資料庫，位於不同地點的許多計算機通過網路互相連接，共同組成一個完整的、全局的大型資料庫。
這種組織資料庫的方法克服了物理中心資料庫組織的弱點。首先，降低了數據傳送代價，因為大多數的對資料庫的訪問操作都是針對局部資料庫的，而不是對其他位置的資料庫訪問；其次，系統的可靠性提高了很多，因為當網路出現故障時，仍然允許對局部資料庫的操作，而且一個位置的故障不影響其他位置的處理工作，只有當訪問出現故障位置的數據時，在某種程度上才受影響；第三，便於系統的擴充，增加一個新的局部資料庫，或在某個位置擴充一台適當的小型計算機，都很容易實現。然而有些功能要付出更高的代價。例如，為了調配在幾個位置上的活動，事務管理的性能比在中心資料庫時花費更高，而且甚至抵消許多其他的優點。
分布式資料庫系統主要特點：
· 多數處理就地完成；
· 各地的計算機由數據通信網路相聯系。
· 克服了中心資料庫的弱點：降低了數據傳輸代價；
· 提高了系統的可靠性，局部系統發生故障，其他部分還可繼續工作；
· 各個資料庫的位置是透明的，方便系統的擴充；
· 為了協調整個系統的事務活動，事務管理的性能花費高；
數據分片
類型：
（1）水平分片：按一定的條件把全局關系的所有元組劃分成若干不相交的子集，每個子集為關系的一個片段。
（2）垂直分片：把一個全局關系的屬性集分成若乾子集，並在這些子集上作投影運算，每個投影稱為垂直分片。
（3）導出分片：又稱為導出水平分片，即水平分片的條件不是本關系屬性的條件，而是其他關系屬性的條件。
（4）混合分片：以上三種方法的混合。可以先水平分片再垂直分片，或先垂直分片再水平分片，或其他形式，但他們的結果是不相同的。
條件：
（1）完備性條件：必須把全局關系的所有數據映射到片段中，決不允許有屬於全局關系的數據卻不屬於它的任何一個片段。
（2）可重構條件：必須保證能夠由同一個全局關系的各個片段來重建該全局關系。對於水平分片可用並操作重構全局關系；對於垂直分片可用聯接操作重構全局關系。
（3）不相交條件：要求一個全局關系被分割後所得的各個數據片段互不重疊（對垂直分片的主鍵除外）。
數據分配方式
（1）集中式：所有數據片段都安排在同一個場地上。
（2）分割式：所有數據只有一份，它被分割成若干邏輯片段，每個邏輯片段被指派在一個特定的場地上。
（4）全復制式：數據在每個場地重復存儲。也就是每個場地上都有一個完整的數據副本。
（5）混合式：這是一種介乎於分割式和全復制式之間的分配方式。
目前分布式資料庫分配的設計，越來越多的採用尋找最優解的演算法，比如遺傳演算法、退火機制等
查詢優化
指在執行分布式查詢時選擇查詢執行計劃的方法和關系運算符的實現演算法。根據系統環境的不同，查詢優化所使用的演算法也有所不同，通常分為遠程廣域網環境和高速區域網環境，其區別主要在網路的帶寬。對於一元運算符可以採用集中式資料庫中的查詢優化方法。而對於二元運算符，由於涉及場地間的數據傳輸，因此必須考慮通信代價。分布式查詢中常見的連接運算執行策略包括：
（1）半連接方法：利用半連接運算的轉換方法R∞S=（RµS）∞S。假設場地1和場地2上分別有關系R和關系S，首先在S上執行連接屬性上的投影並將結果傳輸至場地1，在場地1上執行關系R與投影的連接操作，再將結果傳輸至場地2與關系S執行連接操作。這種方法能夠降低執行連接運算時的網路通信代價，主要適用於帶寬較低的遠程廣域網路。
（2）枚舉法方法：指枚舉關系運算符的物理執行計劃，通過對比執行計劃的代價選擇執行演算法的方法。其中，連接運算符的物理執行計劃包括嵌套循環方法、哈希連接法和歸並連接法。枚舉法主要適用於以磁碟IO代價為主的高速區域網環境。
C. 資料庫設計分為哪幾個步驟
(1)存儲記錄結構設計綜合分析數據存儲要求和應用需求，設計存儲記錄格式
(2)存儲空間分配存儲空間分配有兩個原則：①存取頻度高的數據盡量安排在快速、隨機設備上，存取頻度低的數據則安排在速度較慢的設備上
②相互依賴性強的數據盡量存儲在同一台設備上，且盡量安排在鄰近的存儲空間上
從提高系統性能方面考慮，應將設計好的存儲記錄作為一個整體合理地分配物理存儲區域
盡可能充分利用物理順序特點，把不同類型的存儲記錄指派到不同的物理群中
(3)訪問方法的設計一個訪問方法包括存儲結構和檢索機構兩部分
存儲結構限定了訪問存儲記錄時可以使用的訪問路徑；檢索機構定義了每個應用實際使用的訪問路徑
(4)物理設計的性能評價①查詢響應時間從查詢開始到有結果顯示之間所經歷的時間稱為查詢響應時間
查詢響應時間可進一步細分為服務時間、等待時間和延遲時間
在物理設計過程中，要對系統的性能進行評價
性能評價包括時間、空間、效率、開銷等各個方面
⊙CPU服務時間和I/O服務時間的長短取決於應用程序設計
⊙CPU隊列等待時間和I/O隊列等待時間的長短受計算機系統作業的影響
⊙設計者可以有限度地控制分布式資料庫系統的通信延遲時間
②存儲空間存儲空間存放程序和數據
程序包括運行的應用程序、DBMS子程序、OS子程序等
數據包括用戶工作區、DBMS工作區、OS工作區、索引緩沖區、數據緩沖區等
存儲空間分為主存空間和輔存空間
設計者只能有限度地控制主存空間，例如可指定緩沖區的分配等
但設計者能夠有效地控制輔存空間
③開銷與效率設計中還要考慮以下各種開銷，開銷增大，系統效率將下降
⊙事務開銷指從事務開始到事務結束所耗用的時間
更新事務要修改索引、重寫物理塊、進行寫校驗等操作，增加了額外的開銷
更新頻度應列為設計的考慮因素
⊙報告生成開銷指從數據輸入到有結果輸出這段時間
報告生成佔用CPU及I/O的服務時間較長
設計中要進行篩選，除去不必要的報告生成
⊙對資料庫的重組也是一項大的開銷
設計中應考慮數據量和處理頻度這兩個因數，做到避免或盡量減少重組資料庫
在物理設計階段，設計、評價、修改這個過程可能要反復多次，最終得到較為完善的物理資料庫結構說明書
建立資料庫時，DBA依據物理資料庫結構說明書，使用DBMS提供的工具可以進行資料庫配置
在資料庫運行時，DBA監察資料庫的各項性能，根據依據物理資料庫結構說明書的准則，及時進行修正和優化操作，保證資料庫系統能夠搜凱保持高效率地運行
6
程序編制及調試在邏輯資料庫漏卜結構確定以後，應用程序設計的編制就可以和物理設計並行地展開程序模塊代碼通常先在模擬的環境下通過初步調試，然後再進行聯合調試
聯合調試的工作主要有以下幾點：(1)建立資料庫結構根據邏輯設計和物理設計的結果，用DBMS提供的數據語言(DDL)編寫出資料庫的源模式，經編譯得到目標模式，執行目標模式即可建立實際的資料庫結構
(2)調試運行資料庫結構建立後，裝入試驗數據，使資料庫進入調試運行階段
運行應用程序，測試(3)裝入實際的初始數據在資料庫正式投入運行之前，還要做好以下幾項工作：(1)制定資料庫重新組織的可行方案
(2)制定故障恢復規范(3)制定系統的安全規范7
運行和維護資料庫正式投入運行後，運行維護階段的主要工作是：(1)維護資料庫的安全性與完整性
按照制定的安全規范和故障恢復規范，在系統的安全出現問題時，及時調整授權和更改密碼
及時發現返漏穗系統運行時出現的錯誤，迅速修改，確保系統正常運行
把資料庫的備份和轉儲作為日常的工作，一旦發生故障，立即使用資料庫的最新備份予以恢復
(2)監察系統的性能
運用DBMS提供的性能監察與分析工具，不斷地監控著系統的運行情況
當資料庫的存儲空間或響應時間等性能下降時，立即進行分析研究找出原因，並及時採取措施改進
例如，可通修改某些參數、整理碎片、調整存儲結構或重新組織資料庫等方法，使資料庫系統保持高效率地正常運作
(3)擴充系統的功能在維持原有系統功能和性能的基礎上，適應環境和需求的變化，採納用戶的合理意見，對原有系統進行擴充，增加新的功能
D. 什麼是分布式資料庫結構
分類: 電腦/網路 >> 程序設計 >> 其他編程語言
問題描述:
請高人請點迷津
解析:
分布式軟體系統(Distributed Sofare Systems)是支持分布式處理的軟體系統,是在由通信網路互聯的多處理機體系結構上執行任務的系統。它包括分布式操作系統、分布式程序設計語言及其編譯(解釋)系統、分布式文件系統和分布式資料庫系統等。
分布式操作系統負責管理分布式處理系統資源和控制分布式程序運行。它和集中式操作系統的區別在於資源管理、進程通信和系統結構等方面。
分布式程序設計語言用於編寫運行於分布式計算機系統上的分布式程序。一個分布式程序由若干個可以獨立執行的程序模塊組成,它們分布於一個分布式處理系統的多台計算機上被同時執行。它與集中式的程序設計語言相比有三個特點：分布性、通信性和穩健性。
分布式文件系統具有執行遠程文件存取的能力,並以透明方式對分布在網路上的文件進行管理和存取。
分布式資料庫系統由分布於多個計算機結點上的若干個資料庫系統組成,它提供有效的存取手段來操縱這些結點上的子資料庫。分布式資料庫在使用上可視為一個完整的資料庫,而實際上它是分布在地理分散的各個結點上。當然,分布在各個結點上的子資料庫在邏輯上是相關的。
---------------
分布式資料庫系統是由若干個站 *** 而成。這些站又稱為節點，它們在通訊網路中聯接在一起，每個節點都是一個獨立的資料庫系統，它們都擁有各自的資料庫、中央處理機、終端，以及各自的局部資料庫管理系統。因此分布式資料庫系統可以看作是一系列集中式資料庫系統的聯合。它們在邏輯上屬於同一系統，但在物理結構上是分布式的。
分布式資料庫系統已經成為信息處理學科的重要領域，正在迅速發展之中，原因基於以下幾點：
1、它可以解決組織機構分散而數據需要相互聯系的問題。比如銀行系統，總行與各分行處於不同的城市或城市中的各個地區，在業務上它們需要處理各自的數據，也需要彼此之間的交換和處理，這就需要分布式的系統。
2、如果一個組織機構需要增加新的相對自主的組織單位來擴充機構，則分布式資料庫系統可以在對當前機構影響最小的情況下進行擴充。
3、均衡負載的需要。數據的分解採用使局部應用達到最大，這使得各處理機之間的相互干擾降到最低。負載在各處理機之間分擔，可以避免臨界瓶頸。
4、當現有機構中已存在幾個資料庫系統，而且實現全局應用的必要性增加時，就可以由這些資料庫自下而上構成分布式資料庫系統。
5、相等規模的分布式資料庫系統在出現故障的幾率上不會比集中式資料庫系統低，但由於其故障的影響僅限於局部數據應用，因此就整個系統來講它的可靠性是比較高的。
特點
1、在分布式資料庫系統里不強調集中控制概念，它具有一個以全局資料庫管理員為基礎的分層控制結構，但是每個局部資料庫管理員都具有高度的自 *** 。
2、在分布式資料庫系統中數據獨立性概念也同樣重要，然而增加了一個新的概念，就是分布式透明性。所謂分布式透明性就是在編寫程序時好象數據沒有被分布一樣，因此把數據進行轉移不會影響程序的正確性。但程序的執行速度會有所降低。
3、集中式資料庫系統不同，數據冗餘在分布式系統中被看作是所需要的特性，其原因在於：首先，如果在需要的節點復制數據，則可以提高局部的應用性。其次，當某節點發生故障時，可以操作其它節點上的復制數據，因此這可以增加系統的有效性。當然，在分布式系統中對最佳冗餘度的評價是很復雜的。
分布式系統的類型，大致可以歸為三類：
1、分布式數據，但只有一個總? 據庫，沒有局部資料庫。
2、分層式處理，每一層都有自己的資料庫。
3、充分分散的分布式網路，沒有中央控制部分，各節點之間的聯接方式又可以有多種，如鬆散的聯接，緊密的聯接，動態的聯接，廣播通知式聯接等。
---------------------
什麼是分布式智能?
NI LabVIEW 8的分布式智能結合了相關的技術和工具，解決了分布式系統開發會碰到的一些挑戰。更重要的是，NI LabVIEW 8的分布式智能提供的解決方案不僅令這些挑戰迎刃而解，且易於實施。LabVIEW 8的分布式智能具體包括:
可對分布式系統中的所有結點編程——包括主機和終端。尤為可貴的是，您可以利用LabVIEW圖形化編程方式，對大量不同類型的對象進行編程，如桌面處理器、實時系統、FPGA、PDA、嵌入式微處理器和DSP。
導航所有系統結點的查看系統——LabVIEW Project Explorer。您可使用Project Explorer查看、編輯、運行和調試運行於任何對象上的結點。
經簡化的數據共享編程界面——共享變數。使用共享變數，您可輕松地在系統間(甚至實時系統間)傳輸數據且不影響性能。無通信循環，無RT FIFO，無需低層次TCP函數。您可以利用簡單的對話完成共享變數的配置，從而將數據在各系統間傳輸或將數據連接到不同的數據源。您還可添加記錄、警報、事件等數據服務――一切僅需簡單的對話即可完成。
實現了遠程設備及系統內部或設備及系統之間的同步操作——定時和同步始終是定義高性能測量和控制系統的關鍵問題。利用基於NI技術的系統，探索設備內部並編寫其內部運行機制，從而取得比傳統儀器或PLC方式下更為靈活的解決方案。
--------------------
在分布式計算機操作系統支持下，互連的計算機可以互相協調工作，共同完成一項任務。
也可以這么解釋:
一種計算機硬體的配置方式和相應的功能配置方式。它是一種多處理器的計算機系統，各處理器通過互連網路構成統一的系統。系統採用分布式計算結構，即把原來系統內中央處理器處理的任務分散給相應的處理器，實現不同功能的各個處理器相互協調，共享系統的外設與軟體。這樣就加快了系統的處理速度，簡化了主機的邏輯結構.
易游貝貝祝你好運
E. NewSQL分布式資料庫發展策略討論
作者 石默研
本文對新一代NewSQL分布式資料庫發展策略中的普遍困擾進行討論，包括雲原生（Cloud Native）與本地部署(On Premise)、HTAP進展方向、分布式與單機需求等分布式資料庫商業與技術發展中難以決策的問題。
1. 困擾
分布式NewSQL資料庫近年來蓬勃興起，其原因顯而易見：切中了業務與數據量不斷增長的用戶對關系型資料庫RDBMS需求，這在傳統RDBMS到大數據的發展階段中，有相當一段時間是空白。同時，隨著互聯網技術的不斷發展與普及，用雲計算模式滿足IT需求似乎已經成為未來 社會 產業互聯網發展的明確趨勢，也就是說，有一種共識：不久的將來，絕大多數產業的IT服務是從公共的、行業的或者私有的、混合的雲計算中心提供的。這一共識又帶來了雲原生（Cloud Native）概念與技術的興起，而分布式NewSQL資料庫自然也應該是雲原生的，這決定了其相當多的產品設計決策應以符合這一趨勢為原則。然而，在當今的現實中，滿足業務與數據量不斷增長的RDBMS需求的用戶，與雲原生的用戶，除了互聯網企業外，大多數情況下，並不重合，需要On-Premise部署的用戶仍然佔有很大比重，這就帶來了第一個困擾：雲原生（Cloud Native）與本地部署(On Premise)對產品發展要求的矛盾。
另一個困擾，是關於HTAP，即交易與分析混合負載。HTAP是當今非常火的一個概念與技術，在交易庫上直接進行分析，而不再是將「數據從交易庫搬下來，挪到另一個資料庫中去」這樣的繁瑣過程。可以毫不誇張的說： 歷史 上規模性企業IT復雜度的相當一部分，都來自於「搬數據」，這導致了數據採集、實時採集、全增量合並、數據傳輸、數據載入、數據建模、數據質量、數據標准、企業級元數據管理等繁雜多樣的技術環節的產生，導致了企業數據分布、數據流向、數據模型、主數據、基礎數據平台、ODS/數據倉庫/數據集市、數據治理等復雜的數據架構設計優化領域，導致了由於多系統大規模數據搬遷而帶來的如數據交換平台之類的復雜調度工程......。咋眼一看，感覺該企業的數據技術好厲害，相關各領域的技術產品好豐富，技術人員的相關技能也好受歡迎。但如果在交易遲核宏庫就能直接滿足分析需求而不影響生產效能的話，這些復雜高級的技術環節不都成了「自己給自己造了一座山，還說自己爬的好辛苦」？然而，現實卻是，問題並不這么簡單，除了在交易庫中進行分析會影響業務效能外，還有很多原因導致這一現象產生：交易庫並不需要存儲那麼長的 歷史 數據，而分析往往是需要建立在大量 歷史 數據之上的；交易庫的模型往往並不適合分析需求，多碼冊數情況下需要重要建模，如非常流行且價值不菲的各行業數倉主題模型；用於交易的OLTP資料庫與用於分析的OLAP資料庫，其技術體系完全不同；以及大型企業已固化的內部業務結構並沒有留給交易/分析整合可實施的可行空間......等等。由於， 歷史 積累的企業級數據體系相當復雜，HTAP的發明者迄今為止都沒有系統表達完全替代數據分析需求、自頂而下重構企業數據體系的架構級策略，而是將產品重點定位在技術優化層面：在交易庫上直接完成實時統計分析，滿足高並發需求且不影響業務效能；或者是為實時分析統計/查詢而建設的數據服務中間平台。然而，即使是暫時沒有這種策略性的意向，在面向AP的產品具體研發中，又會發現明確的界限確實不好把握，隨著一個個具體功能的不斷完善，似乎假以時日，技術上也不是沒有完全替代純OLAP平台的可能性。那麼，HTAP究竟如何定位呢？
再者就是規模化的分布式需求，與小規模的單機資料庫需求（這里指邏輯上的單機）之間的矛盾：分布式資料庫，自然而然是要應對規模化的數據管理需求的，長尾的小規模需求當然不應在產品設計考慮之列，同時，大炮轟蒼蠅經常還打不好；然而，分布式NewSQL資料庫又應該是雲原生的，如果把雲原生的業務含義理解為「全自助」，它應該以支持什麼樣的需求為主呢？現實看來，小規模長尾業務對雲氏並原生資料庫的需求最起碼應該是占據相當大的比重的。顯而易見，如果是大規模的數據管理需求，即使是部署在雲上，DBPaaS的「全自助」是其核心需求嗎？這種規模化的業務，如果是雲上的On-Premise又需要做出哪些方面的改變？從互聯網與雲計算發展的 歷史 來看，「雲自助」，其最核心的商業動機當然包括給用戶側的運維帶來了方便，但更重要的可能是給雲服務運營商應對海量長尾客戶的安裝與運維帶來了極大的成本優勢。這正如銀行的小微及個人消費貸款都要走互聯網線上模式，而重客、大客甚至中小企業信貸仍然是以線下為主的策略一樣，本質是成本問題，而不是客戶方便性問題。於是，矛盾顯而易見：分布式是面向規模客戶的，起碼是中、大型客戶，而雲原生卻有可能、最起碼相當一段時間內是要以長尾客戶為主要服務對象的。
以上困擾實質上，都涉及到了NewSQL分布式資料庫的產品發展策略問題。
2. 討論
問題是客觀而又普遍的，但分析與應對策略往往包含主觀因素：人們的一個決定與決策，很多情況下並不由嚴格推理而來，而是心中已經有一個答案，再來找理由支持它。這里的討論或許也並不能例外。
首先，來看看Cloud Native與On Premise。雲原生本應是資料庫即服務，然而目前真正有規模化數據增長需求的NewSQL應用相當多的情況下卻是付費On Premise與免費On Premise區別，很多互聯網企業的應用也可能只是部署在雲基礎設施上而已，真正的雲原生更多是一些實驗性、嘗試性的需求。但雲原生資料庫在公有雲、行業雲以及大型私有雲上已經逐漸在形成一種意識上的共識，其商業前景不可限量。也就是說，未來的數字化轉型進程中，產業互聯網的資料庫部署，會逐漸向雲基礎設施遷移，長在雲上。它可能是公有雲，也可能是行業雲，也可能是私有雲，它們都是被定義為雲原生NewSQL資料庫的市場范圍。當然，肯定還會有相當一部分資料庫長在雲下，這也不用糾結，將其排除在雲原生市場戰略目標之外即可，就是說，不需要考慮這部分客戶需求對產品規劃的影響，因為前一部分的份額已經足夠大了。這樣看來，以雲原生為目標進行產品規劃的邏輯沒有問題，不過，還是要明確一點：長在雲上的資料庫是不是一定符合我們對「雲原生」的既有理解？這里認為，即使未來，在雲上形成了產業互聯網資料庫市場的主體，需要「全自助」的資料庫即服務可能也是以面向長尾客戶最為迫切、必不可少並且是核心本質，而對中大型以上的需求，「全自助」的意義相對有限，同時比較而言商業模式的轉變或者更關鍵些。那麼，如果是以「長在雲上」為市場目標，似乎可以將其定義為「廣義的雲原生」，同時，只要是「長在雲上」，那麼「雲原生」概念中高彈性、高可用、低成本、快速迭代、存算分離等技術優勢也都能方便獲得。而對「雲原生」策略中「雲原生」一詞的理解不同，對產品規劃決策的影響也應該有所不同：一是目前被認為是On Premise的客戶需求，或許也就是未來「雲原生」主體市場的需求；二是NewSQL資料庫關於雲原生服務的產品策劃，對用戶側「自助」水平的決策或許可以更靈活實用。高水平自助確實可以減輕客戶對IT的依賴程度，但這里認為，雲原生與用戶自行在雲上購買資源進行On-Premise部署相比，最關鍵的價值在於商業模式的改變，能自助多少，不一定是最重要的，因為成為雲服務商後，運營運維的工作只會更多，責任可能會更大，甚至有時連IaaS的運維也需要PaaS服務商兜底。但從一個個客戶的本地服務，變成集中化雲服務，就已經是本質性的模式轉變了。總之，需要就事論事，回到原點，仔細分析後決策，而不是用概念教條的判斷，因為概念本身的定義並不見得准確對應實際的業務需求。
再來看看HTAP，對這個問題，正如在其它文章中表達過的一樣，本文的觀點較為明確。一是隨著計算能力與架構的升級，從技術上講，AP與TP的界限會越來越模糊；另外特別是在雲原生的新世界裡，資料庫的這一特性又猶為重要，因為雲原生的重要作用之一就是要讓客戶盡量擺脫對IT運維的依賴，將越來越多的精力集中到自己的業務發展上來；同時端到端的能力提升對雲原生商業模式的貫徹也至關重要（需要仔細分析下目前DBPaaS的技術要求是否完全符合這一原點的、本質性的動力），過去與純OLAP資料庫的優勢比較糾結在這里也可以得到正面支持；再者，既然架構上已經走向了AP，就很難做到在產品規劃上時刻釐清純AP與混合負載的需求後，再將前者排除在外。於是，以「混合負載滿足部分AP需求」應該是由於投入與階段性市場策略導致的階段性產品規劃，而長遠來講，以一套技術架構滿足大多數需求，應該是雲原生NewSQL資料庫的追求。
接下來，就是關於規模化分布式與小規模單機需求的矛盾了。現在看來，經過上面的討論，這一點已經不是什麼問題了：因為「長在雲上」、從分散服務向集中服務的商業模式轉變就是指廣義的雲原生，而不一定要以小微的、迫切需要全自助的長尾為主流，那麼，雲原生NewSQL資料庫仍然應以規模化分布式為其主體的需求方向，而小規模單機則暫時可以不做為重點來考慮。
最後指出一點，希望也能引發進一步的思考：我們所批判的主機，也聲稱自己是分布式架構，暫且不論其是否客觀，但在現實中主機需要被替代的核心問題並不是有沒有分布式，而是：一、擴展不靈活帶來成本問題：「我只需要擴展一個節點，你卻讓我再買一台主機」；二、不自主可控；三、往往是軟硬體結合的設計策略，包括內存、網路、存儲與IO上的軟硬融合設計，而這一點，是否需要雲原生資料庫從廣義的定義出發進行學習參考，也是需要進一步討論的。
F. 分布式資料庫系統(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
G. 如何用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的高可用性、災難恢復、可擴展性和負載均衡。單個更大的、由更多的節點組成的集群往往比小的、只有少數節點的集群更好。大個集群允許更靈活環境，為了負載均衡和維護，實例可以從一個節點移動到另外的節點。
H. 什麼叫分布式資料庫，有什麼優點和缺點
①更適合分布式的管理與控制。
分布式資料庫系統版的結構更適合具有地權理分布特性的組織或機構使用，允許分布在不同區域、不同級別的各個部門對其自身的數據實行局部控制。
②具有靈活的體系結構。
分布式DBMS可以設計成具有不同程度的自治性，從具有充分的場地自治到幾乎是完全集中式的控制。
③系統經濟，可靠性高，可用性好。
由於數據分布在多個場地並有許多復制數據，在個別場地或個別通信鏈路發生故障時，不致於導致整個系統的崩潰，而且系統的局部故障不會引起全局失控。
④在一定條件下響應速度加快。
如果存取的數據在本地資料庫中，那末就可以由用戶所在的計算機來執行，速度就快。
⑤可擴展性好，易於集成現有系統，也易於擴充。
I. 分布式資料庫系統的數據分布方式有哪些(分布式資料庫的特點是)
數據分布是分布式資料庫的主要特徵。實現數據訪問的局部枯則化是分布式資料庫設計的重要內容。文中桐段介紹了分布式資料庫系統的主要特徵及關鍵技術,重點對關系的分沒輪棚割和分布式數據的訪問進行了討論。