分布式圖資料庫

1. 資料庫與hadoop與分布式文件系統的區別和聯系

1. 用向外擴展代替向上擴展
擴展商用關系型資料庫的代價是非常昂貴的。它們的設計更容易向上擴展。要運行一個更大
的資料庫，就需要買一個更大的機器。事實上，往往會看到伺服器廠商在市場上將其昂貴的高端機
標稱為「資料庫級的伺服器」。不過有時可能需要處理更大的數據集，卻找不到一個足夠大的機器。
更重要的是，高端的機器對於許多應用並不經濟。例如，性能4倍於標准PC的機器，其成本將大大
超過將同樣的4台PC放在一個集群中。Hadoop的設計就是為了能夠在商用PC集群上實現向外擴展
的架構。添加更多的資源，對於Hadoop集群就是增加更多的機器。一個Hadoop集群的標配是十至
數百台計算機。事實上，如果不是為了開發目的，沒有理由在單個伺服器上運行Hadoop。
2. 用鍵/值對代替關系表
關系資料庫的一個基本原則是讓數據按某種模式存放在具有關系型數據結構的表中。雖然關
系模型具有大量形式化的屬性，但是許多當前的應用所處理的數據類型並不能很好地適合這個模
型。文本、圖片和XML文件是最典型的例子。此外，大型數據集往往是非結構化或半結構化的。
Hadoop使用鍵/值對作為基本數據單元，可足夠靈活地處理較少結構化的數據類型。在hadoop中，
數據的來源可以有任何形式，但最終會轉化為鍵/值對以供處理。
3. 用函數式編程（MapRece）代替聲明式查詢（SQL ）
SQL 從根本上說是一個高級聲明式語言。查詢數據的手段是，聲明想要的查詢結果並讓資料庫引擎
判定如何獲取數據。在MapRece中，實際的數據處理步驟是由你指定的，它很類似於SQL
引擎的一個執行計劃。SQL 使用查詢語句，而MapRece則使用腳本和代碼。利用MapRece可
以用比SQL 查詢更為一般化的數據處理方式。例如，你可以建立復雜的數據統計模型，或者改變
圖像數據的格式。而SQL 就不能很好地適應這些任務。
4.
分布式文件系統（dfs）和分布式資料庫都支持存入，取出和刪除。但是分布式文件系統比較暴力，
可以當做key/value的存取。分布式資料庫涉及精煉的數據，傳統的分布式關系型資料庫會定義數據元
組的schema，存入取出刪除的粒度較小。
分布式文件系統現在比較出名的有GFS（未開源），HDFS（Hadoop distributed file system）。
分布式資料庫現在出名的有Hbase，oceanbase。其中Hbase是基於HDFS，而oceanbase是自己內部
實現的分布式文件系統，在此也可以說分布式資料庫以分布式文件系統做基礎存儲。

2. 這種分布式資料庫應用，有沒有現成的解決方案

很多公司都在開發自己的分布式資料庫架構，且不少公司都可能使用上了，也有很多人在講分布式資料庫架構，這些是真正意義上的分布式資料庫嗎?
若要我加一個詞的話, 我一般說偽分布式或者說所謂的分布式資料庫架構，是跟陳國慶分享的NoSQL一樣，只是起一個簡單且好聽點的名字，之所以談這個話題，就是想與大家分享一下個人對偽分布式資料庫架構的理解及所實踐的。
PPT主要的內容主要有幾點：什麼是分布式資料庫；什麼是偽分布式資料庫；分布式和偽分布式資料庫架構的優缺點；偽分布式資料庫架構適用的場景；二種偽分布式資料庫架構的設計思路，一類適用於電子商務等領域，另外一類適合於SNS游戲等領域。
首先申明二個要點：第一點不支持分布式事務的，肯定不是分布式資料庫；第二點分布式強調的是可用性、可靠性和數據一致性，其中數據一致性又分鬆散一致性和嚴密一致性，因為分布式資料庫有不同的實現演算法，為此數據一致性都有各種差異。
接下來，我們看一下分布式資料庫的定義：由一組存儲在網路中不同伺服器上的數據組成，網路中每個節點具有獨立執行局部應用的能力，也可以通過網路通信系統執行全局應用的能力。
為什麼需要偽分布式資料庫產品?是因為集中式資料庫，當數據量越來越大，數據的讀寫量也越來越大，且無法通過垂直增加或升級硬體設備而滿足的，以及越來越成為業務增長的瓶頸，那麼我們就不得不考慮革新，採用一種更加有效、可行的方案解決。
偽分布式資料庫的應用場景，稍微羅列了下：電子商務平台（C2C、B2B、B2C） 、SNS平台、IM即時通信軟體、電子郵件系統、日誌分析系統、SNS游戲、其他平台型網站。
大致總結了下，使用偽分布式資料庫架構場景的三要素：
 大數據容量，且垂直升級擴展受限的；
 高並發事務型的；
 數據更新量遠大於數據讀取，且數據更新量非常大；
接下來我們看一下分布式資料庫一個最獨特的架構圖，但是看之前，先了解下分布式資料庫的四個是核心模塊。我們把四個名詞解釋一下：
什麼是局部資料庫管理系統?
什麼是全局資料庫管理系統?
什麼是全局數據字典?
什麼是通信管理?
 LDBMS
建立和管理局部資料庫，提供場地自治能力，執行局部應用及全局查詢的子查詢；
 GDBMS
提供分布透明性，協調全局事務執行，協調各局部DBMS完成全局應用，保證資料庫全局一致性、執行並發控制、實現更新同步和提供全局恢復等功能；
 全局數據字典
存放全局概念模式、分片模式、分布模式的定義以及各模式之間映像的定義，存放有關用戶存取許可權的定義，保證全局用 戶的許可權和資料庫的安全，存放數據完整性約束條件定義；
 通信管理
實現分布式資料庫各場地之間消息和數據傳遞；

3. 解析：怎樣理解分布處理和分布式資料庫

一個分布式資料庫在用戶面前為單個邏輯資料庫，但實際上是由存儲在多台計算機上的一組資料庫組成。在幾台計算機 上的資料庫通過網路可同時修改和存取，每一資料庫受它的局部的DBMS控制。分布式資料庫中每一個資料庫伺服器合作地維護全局資料庫的一致性。 在系統中的每一台計算機稱為結點。如果一結點具有管理資料庫 軟體，該結點稱為資料庫伺服器。如果一個結點為請求伺服器的信息的一應用，該結點稱為客戶。在ORACLE客戶，執行資料庫應用，可存取數據信息和與用戶交互。在伺服器，執行ORACLE軟體，處理對ORACLE資料庫並發、共享數據存取。ORACLE允許上述兩部分在同一台計算機上，但當客戶部分和伺服器部分是由網連接的不同計算機上時，更有效。 分布處理是由多台處理機分擔單個任務的處理。在ORACLE資料庫系統中分布處理的例子如： 客戶和伺服器是位於網路連接的不同計算機上。 單台計算機上有多個處理器，不同處理器分別執行客戶應用。 SQL*NET是ORACLE網路介面，允許運行在網路工作站的ORACLE工具和伺服器上，可存取、修改、共享和存儲在其它伺服器上的數據。SAQL*NET可被認為是網路通信的程序介面。SQL*NET利用通信協議和應用程序介面（API）為OARCLE提供一個分布式資料庫和分布處理。 SQL*NET驅動器為在資料庫伺服器上運行的ORACLE進程與ORACLE工具的用戶進程之間提供一個介面。 參與分布式資料庫的每一伺服器是分別地獨立地管理資料庫，好 像每一資料庫不是網路化的資料庫。每一個資料庫獨立地被管理，稱為場地自治性。場地自治性有下列好處： ◆系統的結點可反映公司的邏輯組織。 ◆由局部資料庫管理員控制局部數據，這樣每一個資料庫管理員責任域要 小一些，可更好管理。 ◆只要一個資料庫和網路是可用，那麼全局資料庫可部分可用。不會因一個資料庫的故 障而停止全部操作或引起性能瓶頸。 ◆故障恢復通常在單個結點上進行。 ◆每個局部資料庫存在一個數據字典。 ◆結點可獨立地升級軟體。 可從分布式資料庫的所有結點存取模式對象，因此正像非分布的局部的DBMS，必須提供一種機制，可在局部資料庫中引用一個對象。分布式DBMS必須提供一種命名模式，以致分布式資料庫中一個對象可在應用中唯一標識和引用。一般彩在層次結構的每一層實施唯一性。分布式DVMS簡單地擴充層次命名模型，實施在網路上唯一資料庫命名。因此一個對象的全局對象名保證在分布式資料庫內是唯一。 ORACLE允許在SQL語句中使用佤對象名引用分布式資料庫中的模式對象（表、視圖和過程）。在ORACLE中，一個模式對象的全局名由三部分組成：包含對象的模式名、對象名、資料庫名、其形式如： [email protected] 其中SCOTT為模式名,EMP為表名,@符號之後為資料庫名. 一個遠程查詢為一查詢,是從一個或多個遠程表中選擇信息,這些表駐留在同一個遠程結點. 一個分布式查詢可從兩個或多個結點檢索數據.一個分布式更新可修改兩個或兩個以上結點的數據. 一個遠程事務為一個事務,包含一人或多個遠程語句,它所引用的全部是在同一個遠程結點上.一個分布式事務中一個事務,包含一個或多個語句修改分布式資料庫的兩個或多個不同結點的數據. 在分布式資料庫中,事務控制必須在網路上直轄市,保證數據一致性.兩階段提交機制保證參與分布式事務的全部資料庫伺服器是全部提交或全部回滾事務中的語句. ORACLE分布式資料庫系統結構可由ORACLE資料庫管理員為終端用戶和應用提供位置透明性,利用視圖、同義詞、過程可提供ORACLE分布式資料庫系統中的位置透明性. ORACLE允許在SELECT(查詢)、INSERT、UPDATE、DELETE、SELECT…FOR UPDATE和LOCK TABLE語句中引用遠程數據。對於查詢，包含有連接、聚合、子查詢和SELECT …FOR UPDATE，可引用本地的、遠程的表和視圖。對於UPDATE、INSERT、DELETE和LOCK TABLE語句可引用本地的和遠程的表。注意在引用LONG和LONG RAW列、序列、修改表和封鎖表時，必須位於同一個結點。ORACLE不允許作遠程DDL語句。 在單場地或分布式資料庫中，所有事務都是用COMMIT或ROLLBACK語句中止。ORACLE提供兩種機制實現分布式資料庫中表重復的透明性：錶快照提供非同步的表重復；觸發器實現同步的表的重復。在兩種情況下，都實現了對表重復的透明性。

4. 大數據的分布式資料庫的發展趨勢如何

現在大數據是一個十分火熱的技術，這也使得很多人都開始關注大數據的任何動態，因為大數據在某種程度上來說能夠影響我們的生活。在這篇文章中我們就給大家介紹一下大數據的分布式資料庫的發展趨勢，希望這篇文章能夠幫助大家更好理解大數據的分布式資料庫的發展趨勢。
其實不論是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的部件拆開靈活使用，為使用場景和結果買單，而非平台本身買單。另外一個細分市場——非結構化小文件存儲，一直以來都是對象存儲、塊存儲，與分布式文件系統的主戰場。如今，一些新一代資料庫也開始進入該領域，可以預見在未來的幾年中，小型非結構化文件存儲也可能成為具備多模數據處理能力的分布式資料庫的戰場之一。
我們在這篇文章中給大家介紹了很多有關大數據分布資料庫的發展前景，通過這篇文章我們不難發現資料庫的發展是一個極其重要的內容，只有搭建分布式資料庫，大數據才能夠更好地為我們服務。

5. 大數據的分布式資料庫技術的對比

大數據技術的實現離不開很多其他的技術，我們提到最多的就是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查詢語言之外的其他訪問模式，大大豐富了傳統分布式資料庫單一的用途。一般來說，多模資料庫的主要目的是為了滿足具有高性能要求的操作型需求以及目標明確的數據倉庫功能，而不是類似大數據深度學習等數據挖掘場景。這就是分布式資料庫的實際情況。
我們在這篇文章中給大家介紹了大數據分析以及分布式資料庫的相關知識，通過這些內容相信大家已經理解了其中的具體區別了吧，如果這篇文章能夠幫助到大家這就是我們最大的心願。

6. 阿里雲分布式資料庫服務DRDS誰使用過 簡單講講！

淘寶開源的TDDL和cobar的結合，放到了阿里雲上就是DRDS，是商品，服務，可以購買使用的。可以在阿里雲官網上注冊免費試用。

=====================================================
隨著互聯網時代的到來，計算機要管理的數據量呈指數級別地飛速上漲，而我們卻完全無法對用戶數做出准確預估。我們的系統所需要支持的用戶數，很可能在短短的一個月內突然爆發式地增長幾千倍，數據也很可能快速地從原來的幾百GB飛速上漲到了幾百個TB。如果在這爆發的關鍵時刻，系統不穩定或無法訪問，那麼對於業務將會是毀滅性的打擊。
伴隨著這種對於系統性能、成本以及擴展性的新需要，以HBase、MongoDB為代表的NoSQL資料庫和以阿里DRDS、VoltDB、ScaleBase為代表的分布式NewSQL資料庫如雨後春筍般不斷涌現出來。
本文將會介紹阿里DRDS的技術理念、發展歷程、技術特性等內容。
DRDS設計理念
從20世紀70年代關系資料庫創立開始，其實大家在資料庫上的追求就從未發生過變化：更快的存取數據，可以按需擴縮以承載更大的訪問量和更大的數據量，開發容易，硬體成本低，我們可以把這叫做資料庫領域的聖杯。
為了支撐更大的訪問量和數據量，我們必然需要分布式資料庫系統，然而分布式系統又必然會面對強一致性所帶來的延遲提高的問題，因為網路通信本身比單機內通信代價高很多，這種通信的代價就會直接增加系統單次提交的延遲。延遲提高會導致資料庫鎖持有時間變長，使得高沖突條件下分布式事務的性能不升反降（這個具體可以了解一下Amdahl定律），甚至性能距離單機資料庫都還有明顯的差距。
從上面的說明，我們可以發現，問題的關鍵並不是分布式事務做不出來，而是做出來了卻因為性能太差而沒有什麼卵用。資料庫領域的高手們努力了40年，但至今仍然沒有人能夠很好地解決這個問題，Google Spanner的開發負責人就經常在他的Blog上談論延遲的問題，相信也是飽受這個問題的困擾。
面對這個難題，傳統的關系資料庫選擇了放棄分布式的方案，因為在20世紀70~80年代，我們的資料庫主要被用來處理企業內的各類數據，面對的用戶不過幾千人，而數據量最多也就是TB級別。用單台機器來處理事務，用個磁碟陣列處理一下磁碟容量不夠的問題，基本上就能解決一切問題了。
然而，信息化和互聯網的浪潮改變了這一切，我們突然發現，我們服務的對象發生了根本性變化，從原來的幾千人，變成了現在的幾億人，數據量也從TB級別到了PB級別甚至更多。存在單點的單機系統無論如何努力，都會面對系統處理能力的天花板。原來的這條路，看起來是走不下去了，我們必須想辦法換一條路來走。
可是，分布式資料庫所面對的強一致性難題卻像一座高山，人們努力了無數個日日夜夜，但能翻越這座山的日子看來仍然遙遙無期。
於是，有一群人認為，強一致性這件事看來不怎麼靠譜，那徹底繞開這個問題是不是個更好的選擇？他們發現確實有那麼一些場景是不需要強一致事務的，甚至連SQL都可以不要，最典型的就是日誌流水的記錄與分析這類場景。而去掉了事務和SQL，介面簡單了，性能就更容易得到提升，擴展性也更容易實現，這就是NoSQL系統的起源。
雖然NoSQL解決了性能和擴展性問題，但這種繞開問題的方法給用戶帶來了很多困擾，系統的開發成本也大大提升。這時候就有另外一群人，他們覺得用戶需要SQL，覺得用戶也需要事務，問題的關鍵在於我們要努力地往聖杯的方向不斷前進。在保持系統的擴展性和性能的前提下，付出盡可能小的代價來滿足業務對資料庫的需要。這就是NewSQL這個理念的由來。
DRDS也是一個NewSQL的系統，它與ScaleBase、VoltDB等系統類似，都希望能夠找到一條既能保持系統的高擴展性和高性能，又能盡可能保持傳統資料庫的ACID事務和SQL特性的分布式資料庫系統。
DRDS發展歷程
在一開始，TDDL的主要功能就是做資料庫切分，一個或一組SQL請求提交到TDDL，TDDL進行規則運算後得知SQL應該被分發到哪個機器，直接將SQL轉發到對應機器即可（如圖1）。

圖1 TDDL資料庫切分
開始的時候，這種簡單的路由策略能夠滿足用戶的需要，我們開始的那些應用，就是通過這樣非常簡單的方式完成了他所有的應用請求。我們也認為，這種方案簡單可靠，已經足夠好用了。
然而，當我們服務的應用從十幾個增長到幾百個的時候，大量的中小應用加入，大家紛紛表示，原來的方案限制太大，很多應用其實只是希望做個讀寫分離，希望能有更好的SQL兼容性。
於是，我們做了第一次重大升級，在這次升級里，我們提出了一個重要的概念就是三層架構，Matrix對應資料庫切分場景，對SQL有一定限制，Group對應讀寫分離和高可用場景，對SQL幾乎沒有限制。如圖2所示。

圖2 資料庫升級為三層架構
這種做法立刻得到了大家的認可，TDDL所提供的讀寫分離、分庫分表等核心功能，也成為了阿里集團內資料庫領域的標配組件，在阿里的幾乎所有應用上都有應用。最為難得的是，這些功能從上線後，到現在已經經歷了多年雙11的嚴酷考驗，從未出現過嚴重故障（p0、p1級別故障屬於嚴重故障）。資料庫體系作為整個應用系統的重中之重，能做到這件事，真是非常不容易。
隨著核心功能的穩定，自2010年開始，我們集中全部精力開始關注TDDL後端運維系統的完善與改進性工作。在DBA團隊的給力配合下，圍繞著TDDL，我們成功做到了在線數據動態擴縮、非同步索引等關鍵特徵，同時也比較成功地構建了一整套分布式資料庫服務管控體系，用戶基本上可以完全自助地完成整套資料庫環境的搭建與初始化工作。
大概是2012年，我們在阿里雲團隊的支持下，開始嘗試將TDDL這套體系輸出到阿里雲上，也有了個新的名字：阿里分布式資料庫服務（DRDS），希望能夠用我們的技術服務好更多的人。
不過當我們滿懷自信地把自己的軟體拿到雲上的時候，卻發現我們的軟體距離用戶的要求差距很大。在內部因為有DBA的同學們幫助進行SQL review，所以SQL的復雜度都是可控的。然而到了雲上，看了各種渠道提過來的兼容性需求，我們經常是不自覺地發出這樣的感嘆：「啊？原來這種語法MySQL也是可以支持的？」
於是，我們又進行了架構升級，這次是以兼容性為核心目標的系統升級工作，希望能夠在分布式場景下支持各類復雜的SQL，同時也將阿里這么多年來在分布式事務上的積累都帶到了DRDS裡面。
這次架構升級，我們的投入史無前例，用了三年多才將整個系統落地完成。我們先在內部以我們自己的業務作為首批用戶上線，經過了內部幾百個應用的嚴酷考驗以後，我們才敢拿到雲上，給到我們的最終用戶使用。
目前，我們正在將TDDL中更多的積累輸出到雲上，同時也努力優化我們的用戶界面。PS：其實用戶界面優化對我們這種專注於高性能後端技術的團隊來說，才是最大的技術挑戰，連我也去學了AngularJS，參與了用戶UI編。
DRDS主要功能介紹
發展歷史看完了，下面就由我來介紹一下目前我們已經輸出到雲上的主要功能。
【分布式SQL執行引擎】
分布式SQL引擎主要的目的，就是實現與單機資料庫SQL引擎的完全兼容。目前我們的SQL引擎能夠做到與MySQL的SQL引擎全兼容，包括各類join和各類復雜函數等。他主要包含SQL解析、優化、執行和合並四個流程，如圖3中綠色部分。

圖3 SQL引擎實現的主要流程
雖然SQL是兼容的，但是分布式SQL執行演算法與單機SQL的執行演算法卻完全不同，原因也很簡單，網路通信的延遲比單機內通信的延遲大得多。舉個例子說明一下，我們有份文件要從一張紙A上謄寫到另外一張紙B上，單機系統就好比兩張紙都在同一個辦公室里，而分布式資料庫則就像是一張紙在北京，一張紙在杭州。
自然地，如果兩張紙在同一個辦公室，因為傳輸距離近，逐行謄寫的效率是可以接受的。而如果距離是北京到杭州，用逐行謄寫的方式，就立刻顯得代價太高了，我們總不能看一行，就打個「飛的」去杭州寫下來吧。在這種情況下，還是把紙A上的信息拍個照片，【一整批的】帶到杭州去處理，明顯更簡單一些。這就是分布式資料庫特別強調吞吐調優的原因，只要是涉及到跨機的所有查詢，都必須盡可能的積攢一批後一起發送，以減少系統延遲提高帶來的不良影響。
【按需資料庫集群平滑擴縮】
DRDS允許應用按需將新的單機存儲加入或移出集群，DRDS則能夠保證應用在遷移流程中實現不停機擴容縮容。

圖4 DRDS按需進行平滑擴縮
在內部的資料庫使用實踐中，這個功能的一個最重要應用場景就是雙11了。在雙11之前，我們會將大批的機器加入到我們的資料庫集群中，抗過了雙11，這批機器就會下線。
當DRDS來到雲上，我們發現雙11其實不僅僅隻影響阿里內部的系統。在下游的各類電商輔助性系統其實也面對巨大壓力。在雙11前5天，網聚寶的熊總就找到我說，擔心撐不過雙11的流量，怕系統掛。於是我們就給他介紹了這個自動擴容的功能怎麼用，他買了一個月的資料庫，掛接在DRDS上。資料庫能力立刻翻倍，輕松抗過了雙11，也算是我印象比較深刻的一個案例了。
因為我們完全無法預測在什麼時間點系統會有爆發性的增長，而如果在這時候系統因為技術原因不能使用，就會給整個業務帶來毀滅性的影響，風口一旦錯過，就追悔莫及了。我想這就是雲計算特別強調可擴展能力的原因吧。
【小表廣播】
小表廣播也是我們在分布式資料庫領域內最常用的工具之一，他的核心目的其實都是一個——盡可能讓查詢只發生在單機。
讓我們用一個例子來說明，小表廣播的一般使用場景。

圖5 小表廣播場景
圖5中，如果我想知道買家id等於0的用戶在商城裡面買了哪些商品，我們一般會先將這兩個表join起來，然後再用where平台名=」商城」 and buyerID = 0找到符合要求的數據。然而這種join的方式，會導致大量的針對左表的網路I/O。如果要取出的數據量比較大，系統延遲會明顯上升。
這時候，為了提升性能，我們就必須要減少跨機join的網路代價。我們比較推薦應用做如下處理，將左表復制到右表的每一個庫上。這樣，join操作就由分布式join一下變回到本地join，系統的性能就有很大的提升了，如圖6所示。

圖6
【分布式事務套件】
在阿里巴巴的業務體系中存在非常多需要事務類的場景，下單減庫存，賬務，都是事務場景最集中的部分。
而我們處理事務的方法卻和傳統應用處理事務的方案不大一樣，我們非常強調事務的最終一致性和非同步化。利用這種方式，能夠極大地降低分布式系統中鎖持有的時間，從而極大地提升系統性能。

圖7 DRDS分布式事務解決套件
這種處理機制，是我們分布式事務能夠以極低成本大量運行的最核心法門。在DRDS平台內，我們將這些方案產品化，為了DRDS的分布式事務解決套件。
利用他們，能夠讓你以比較低的成本，實現低延遲，高吞吐的分布式事務場景。
DRDS的未來
阿里分布式資料庫服務DRDS上線至今，大家對這款產品的熱情超出了我們的預期，短短半年內已經有幾千個申請。
盡管還在公測期，但是大家就已經把關繫到身家性命的寶貴在線數據業務放到了DRDS上，我能夠感受到這份沉甸甸的信賴，也不想辜負這份信賴。
經過阿里內部幾千個應用的不斷歷練，DRDS已經積累出一套強大的分布式SQL執行引擎和和一整套分布式事務套件。
我也相信，這些積累能夠讓用戶在基本保持單機資料庫的使用習慣的前提下，享受到分布式資料庫高性能可擴展的好處。
在平時的DRDS支持過程中，我面對最多的問題就是，DRDS能不能夠在不改變任何原有業務邏輯和代碼的前提下，實現可自由伸縮和擴展呢？十分可惜的是，關系資料庫發展至今，還沒有找到既能保留傳統資料庫一切特性，又能實現高性能可擴展資料庫的方法。
然而，雖不能至，吾心嚮往之！我們會以「可擴展，高性能」為產品核心，堅定地走在追尋聖杯的路上，並堅信最終我們一定能夠找尋到它神聖的所在。
作者簡介：王晶昱，花名沈詢，阿里巴巴資深技術專家。目前主要負責阿里的分布式資料庫DRDS（TDDL）和阿里的分布式消息服務ONS（RocketMQ/Notify）兩個系統。

7. 分布式資料庫和區塊鏈的區別在哪些方面

區塊鏈是一種共享的分布式資料庫技術。盡管不同報告中對區塊鏈的一句話介紹措辭都不相同，但以下4個技術特點是共識性的。
1. 去中心化（Decentralized）：圖1的左側描述了當今金融系統的中心化特徵，右側描述的是正在形成的去中心化金融系統，其沒有中介機構，所有節點的權利和義務都相等，任一節點停止工作都會不影響系統整體的運作；
2. 去信任（Trustless）：系統中所有節點之間無需信任也可以進行交易，因為資料庫和整個系統的運作是公開透明的，在系統的規則和時間范圍內，節點之間無法欺騙彼此；
3. 集體維護（Collectively Maintain）：系統是由其中所有具有維護功能的節點共同維護的，系統中所有人共同參與維護工作；
4. 可靠資料庫（Reliable Database）：系統中每一個節點都擁有最新的完整資料庫拷貝，修改單個節點的資料庫是無效的，因為系統會自動比較，認為最多次出現的相同數據記錄為真。
比特幣、以太坊、DECENT這些項目的區塊鏈都是具備這些特點的。

8. 圖資料庫和關系資料庫的區別

1、數據存儲方式不同。

關系型和非關系型資料庫的主要差異是數據存儲的方式。關系型數據天然就是表格式的，因此存儲在數據表的行和列中。數據表可以彼此關聯協作存儲，也很容易提取數據。

與其相反，非關系型數據不適合存儲在數據表的行和列中，而是大塊組合在一起。非關系型數據通常存儲在數據集中，就像文檔、鍵值對或者圖結構。你的數據及其特性是選擇數據存儲和提取方式的首要影響因素。

2、擴展方式不同。

SQL和NoSQL資料庫最大的差別可能是在擴展方式上，要支持日益增長的需求當然要擴展。

要支持更多並發量，SQL資料庫是縱向擴展，也就是說提高處理能力，使用速度更快速的計算機，這樣處理相同的數據集就更快了。

因為數據存儲在關系表中，操作的性能瓶頸可能涉及很多個表，這都需要通過提高計算機性能來客服。雖然SQL資料庫有很大擴展空間，但最終肯定會達到縱向擴展的上限。而NoSQL資料庫是橫向擴展的。

而非關系型數據存儲天然就是分布式的，NoSQL資料庫的擴展可以通過給資源池添加更多普通的資料庫伺服器(節點)來分擔負載。

3、對事務性的支持不同。

如果數據操作需要高事務性或者復雜數據查詢需要控制執行計劃，那麼傳統的SQL資料庫從性能和穩定性方面考慮是你的最佳選擇。SQL資料庫支持對事務原子性細粒度控制，並且易於回滾事務。

雖然NoSQL資料庫也可以使用事務操作，但穩定性方面沒法和關系型資料庫比較，所以它們真正閃亮的價值是在操作的擴展性和大數據量處理方面。

9. 資料庫都有哪些

資料庫是一組信息的集合，以便可以方便地訪問、管理和更新，常用資料庫有：1、關系型資料庫；2、分布式資料庫；3、雲資料庫；4、NoSQL資料庫；5、面向對象的資料庫；6、圖形資料庫。

計算機資料庫通常包含數據記錄或文件的聚合，例如銷售事務、產品目錄和庫存以及客戶配置文件。

通常，資料庫管理器為用戶提供了控制讀寫訪問、指定報表生成和分析使用情況的能力。有些資料庫提供ACID(原子性、一致性、隔離性和持久性)遵從性，以確保數據的一致性和事務的完整性。

資料庫普遍存在於大型主機系統中，但也存在於較小的分布式工作站和中端系統中，如IBM的as /400和個人計算機。

資料庫的演變

資料庫從1960年代開始發展，從層次資料庫和網路資料庫開始，到1980年代的面向對象資料庫，再到今天的SQL和NoSQL資料庫和雲資料庫。

一種觀點認為，資料庫可以按照內容類型分類:書目、全文、數字和圖像。在計算中，資料庫有時根據其組織方法進行分類。有許多不同類型的資料庫，從最流行的方法關系資料庫到分布式資料庫、雲資料庫或NoSQL資料庫。

常用資料庫：

1、關系型資料庫

關系型資料庫是由IBM的E.F. Codd於1970年發明的，它是一個表格資料庫，其中定義了數據，因此可以以多種不同的方式對其進行重組和訪問。

關系資料庫由一組表組成，其中的數據屬於預定義的類別。每個表在一個列中至少有一個數據類別，並且每一行對於列中定義的類別都有一個特定的數據實例。

結構化查詢語言(SQL)是關系資料庫的標准用戶和應用程序介面。關系資料庫易於擴展，並且可以在原始資料庫創建之後添加新的數據類別，而不需要修改所有現有應用程序。

2、分布式資料庫

分布式資料庫是一種資料庫，其中部分資料庫存儲在多個物理位置，處理在網路中的不同點之間分散或復制。

分布式資料庫可以是同構的，也可以是異構的。同構分布式資料庫系統中的所有物理位置都具有相同的底層硬體，並運行相同的操作系統和資料庫應用程序。異構分布式資料庫中的硬體、操作系統或資料庫應用程序在每個位置上可能是不同的。

3、雲資料庫

雲資料庫是針對虛擬化環境(混合雲、公共雲或私有雲)優化或構建的資料庫。雲資料庫提供了一些好處，比如可以按每次使用支付存儲容量和帶寬的費用，還可以根據需要提供可伸縮性和高可用性。

雲資料庫還為企業提供了在軟體即服務部署中支持業務應用程序的機會。

4、NoSQL資料庫

NoSQL資料庫對於大型分布式數據集非常有用。

NoSQL資料庫對於關系資料庫無法解決的大數據性能問題非常有效。當組織必須分析大量非結構化數據或存儲在雲中多個虛擬伺服器上的數據時，它們是最有效的。

5、面向對象的資料庫

使用面向對象編程語言創建的項通常存儲在關系資料庫中，但是面向對象資料庫非常適合於這些項。

面向對象的資料庫是圍繞對象(而不是操作)和數據(而不是邏輯)組織的。例如，關系資料庫中的多媒體記錄可以是可定義的數據對象，而不是字母數字值。

6、圖形資料庫

面向圖形的資料庫是一種NoSQL資料庫，它使用圖形理論存儲、映射和查詢關系。圖資料庫基本上是節點和邊的集合，其中每個節點表示一個實體，每個邊表示節點之間的連接。

圖形資料庫在分析互連方面越來越受歡迎。例如，公司可以使用圖形資料庫從社交媒體中挖掘關於客戶的數據。

訪問資料庫:DBMS和RDBMS

資料庫管理系統(DBMS)是一種允許您定義、操作、檢索和管理存儲在資料庫中的數據的軟體。

關系資料庫管理系統(RDBMS)是上世紀70年代開發的一種基於關系模型的資料庫管理軟體，目前仍然是最流行的資料庫管理方法。

Microsoft SQL Server、Oracle資料庫、IBM DB2和MySQL是企業用戶最常用的RDBMS產品。DBMS技術始於20世紀60年代，支持分層資料庫，包括IBM的信息管理系統和CA的集成資料庫管理系統。一個關系資料庫管理系統（RDBMS）是一種資料庫管理軟體是在20世紀70年代開發的，基於關系模式，仍然是管理資料庫的最普遍的方式。

希望能幫助你還請及時採納謝謝

10. 什麼是分布式資料庫

分布式軟體系統(Distributed Software 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方式下更為靈活的解決方案。

--------------------

在分布式計算機操作系統支持下，互連的計算機可以互相協調工作，共同完成一項任務。

也可以這么解釋:
一種計算機硬體的配置方式和相應的功能配置方式。它是一種多處理器的計算機系統，各處理器通過互連網路構成統一的系統。系統採用分布式計算結構，即把原來系統內中央處理器處理的任務分散給相應的處理器，實現不同功能的各個處理器相互協調，共享系統的外設與軟體。這樣就加快了系統的處理速度，簡化了主機的邏輯結構.

易游貝貝祝你好運