# 如何制作無限可擴展的關系數據庫管理系統（RDBMS） > 原文： [http://highscalability.com/blog/2013/11/25/how-to-make-an-infinitely-scalable-relational-database-manag.html](http://highscalability.com/blog/2013/11/25/how-to-make-an-infinitely-scalable-relational-database-manag.html)  *這是 [InfiniSQL](@infinisq) 的創始人 [Mark Travis](@infinisq) 的來賓帖子。* [](http://www.infinisql.org)InfiniSQL 是標題所指的特定“無限擴展 RDBMS”。 它是免費軟件，有關其獲取，構建，運行和測試的說明，請參見[指南](http://www.infinisql.org/docs/guide/)。 [基準測試](http://www.infinisql.org/blog/2013/1112/benchmarking-infinisql)顯示，一個 InfiniSQL 群集每秒可以處理 500,000 個復雜事務，并具有 100,000 多個并發連接，所有這些都位于十二臺小型服務器上。 測試的方法已記錄在案，并且所有代碼都可用，因此任何從業人員都可以取得類似的結果。 InfiniSQL 具有兩個主要特征： 1. 它比任何集群/分布式 RDBMS 更好地執行在多個節點上具有記錄的事務 2. 它是免費的開放源代碼。 不僅僅是具有專有技術的預告片“社區”版本。 準備就緒時，InfiniSQL 的社區版本也將是企業版本。 InfiniSQL 仍處于開發的早期階段-它已經具有許多功能，但是要使其在生產環境中有用，還需要更多的功能。 ## 誰會做這種事情？ 我的職業背景可以在 [LinkedIn](http://www.linkedin.com/pub/mark-travis/1/a3a/1a2) 上找到。 我已經為一些相當大的事務處理環境進行了容量規劃，系統工程，性能工程等工作，其中幾秒鐘的停機時間使成千上萬的客戶損失了成本。 保姆式的環境告訴我，傳統的企業數據庫基礎結構非常適合需要 24x7 全天候運行，持續增長并快速響應新業務需求的現代環境。 這確實是一個典型的故事-我們都知道 70 年代設計的系統無法滿足當今的需求。 因此，我決定構建適合現代事務處理環境的東西。 ## 目標用戶/用例 我敢肯定，大多數[高可擴展性](http://highscalability.com/)的讀者都會理解為什么新的數據庫體系結構如此必要的原因，而且我們當中許多人也認為更快，更大的規模是自我調整的價值。 我們就像賽車手。 但是重要的是要知道用例，以幫助其他人學習如何利用我們正在構建的強大功能。 就 InfiniSQL 而言，有幾種主要客戶類型，每種類型都有各種特定的用例。 我將簡要介紹一下客戶類型，以及我如何看待 InfiniSQL 為他們解決業務問題。 * Look no further than the example application cited in [Design Decisions For Scaling Your High Traffic Feeds](http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html), which is a very recent entry on this site. Imagine there's no *Part Two* and *Part Three*, meaning that their original RDBMS of choice was able to perform "`select * from love where user_id in (...)`" well beyond 100M rows and 1M users. There'd be no need to design a new framework from scratch, or to rip and replace two back ends before settling on one that seems fine for the time being. InfiniSQL is capable of performing that kind of query. I haven't benchmarked that specific workload--but it's the type of thing that I designed InfiniSQL for: transactions with records distributed across multiple nodes. 成功的 Internet 應用程序幾乎不可避免地從它們啟動時所使用的基礎結構中發展而來。 RDBMS 通常是首選的初始數據庫-但實現了變通方法，并且實現了完全不同的體系結構-所有這些都是因為原始數據庫無法處理成功。 那是一個非常破壞性的過程。 InfiniSQL 適用于具有 RDBMS 工作負載但由于其原始 RDBMS 不能隨業務增長而被迫實施變通方法的任何公司。 這些解決方法包括分拆 SQL 數據庫以及將一些工作負載遷移到各種 NoSQL Point 解決方案。 實際上，InfiniSQL 應該成為公司開始使用的數據庫，以避免將來的遷移成本。 * InfiniSQL 的另一類目標用戶包括那些在單片平臺上負責每秒處理數以萬計的復雜事務的應用程序的用戶。 這種工作負載很難脫離大型系統架構。 這類公司包括信用卡協會，旅行預訂系統和交易所。 這些不是新的業務模型。 數十年來，他們的基礎設施一直在掙扎。 他們執行的每項操作都代表著（至少）兩方之間的資金轉移-他們轉移了人們的資金。 穩定性和數據完整性是最重要的價值。 InfiniSQL 能夠以預期的數量和更高的容量執行此類工作負載，但可以在運行 Linux 而不是大型的超昂貴平臺的 x86_64 服務器上執行。 實際上，InfiniSQL 會進一步擴展-因為這些大型的整體平臺在其擴展插槽用完的情況下會用光。 ## 問題及其原因（以及幾個相關問題） （如果我能找到其他在我之前說過的夸夸其談的聲明，我會編成信譽，否則，我會接受-每個人都需要報價，對嗎？我會接受。） *問題*使多個節點全部組成一個數據庫。 通過將靜態 Web 服務器與數據庫進行比較，可以輕松說明此問題。 通過簡單地將 Web 服務器的內容鏡像到不同的盒子上，然后以循環方式或其他方式向它們噴射流量，來擴展 Web 服務器很簡單。 簡單。 但是對于數據庫而言，并不是那么簡單。 取兩個盒子，然后將您喜歡的數據庫放在上面。 給每個相同的模式。 然后，連接到框 A 并插入一條記錄-任何舊記錄。 然后連接到方框 B 并查找該記錄。 當然不存在！ 這就是水平擴展數據庫的問題：邏輯和數據都在同一個盒子中！ ### 鎖定主要是壞的 傳統數據庫設計在性能方面的另一個問題是鎖定。 為了數據完整性，每個工作程序（線程或進程）都鎖定與其操作的記錄關聯的內存或存儲區域。 這些不是高級數據鎖，例如行或表鎖（盡管它們也可能有問題）。 不，它們被實現為互斥或信號量。 互斥體和信號量是多線程/進程應用程序阻止其他線程/進程踩踏共享數據的方式。 隨著共享內存區域的鎖爭用增加，性能下降。 鎖定爭用的一個很可能的指標是數據庫速度很慢，但是有大量可用的 CPU，并且沒有 I / O 瓶頸。 ### I / O 慢，沒有問題，它有多快 傳統數據庫的另一個大性能問題是事務日志瓶頸。 為了[持久性](http://en.wikipedia.org/wiki/Durability_(database_systems))，傳統數據庫在完成事務之前，會將包含書面記錄的所有事務實時實時寫入等效于日志文件的日志。 當電源關閉時，當指示燈重新點亮時，數據仍將存在。 問題在于這會減慢寫入速度。 在最快的固態存儲和海量 I / O 總線上使用任何經過調整的數據庫。 它將成為寫入事務日志的瓶頸。 ## InfiniSQL 解決這些問題的方法 InfiniSQL 并不是解決某些或所有這些問題并成功實現集群 RDBMS 的唯一項目。 我敢肯定，此博客的大多數讀者都知道這樣的各種系統，即使它們還不是用戶。 我正在描述如何解決這些問題，以及它們如何有助于 InfiniSQL 的獨特優勢。 其他人則以自己的方式解決了這些問題。 ### 演員們 InfiniSQL 在并發編程的[參與者模型](http://en.wikipedia.org/wiki/Actor_model)上實現了一種變體。 C ++是用于創建 InfiniSQL 的主要語言，該語言本身不支持 actor 模型。 實現 InfiniSQL 的許多工作涉及使角色在 C ++中工作。 actor 模型通過將事務處理邏輯與存儲斷開耦合并且不鎖定內存區域來解決上述前兩個問題。 有關詳細信息，請閱讀[概述](http://www.infinisql.org/docs/overview/)。 這與傳統的 RDBMS 體系結構完全不同。 角色模型解決了[問題](#0.1_theproblem)，因為處理邏輯由一組角色處理，而數據存儲由另一組角色處理。 它們的功能在 InfiniSQL 中松散耦合。 無論參與者位于哪個節點，消息傳遞都是在參與者之間進行的：管理特定事務的參與者不知道或不在乎數據是駐留在本地還是遠程。 并且管理特定數據分區的參與者響應消息，而不管其來源。 從理論上講，參與者模型允許 InfiniSQL 無限擴展。 基于其第一字段的哈希值將每個記錄分配給特定的數據區域，并且基于索引值的哈希將每個索引記錄分配給一個區域。 actor 模型的另一個有益效果是它解決了低級別鎖定的問題。 由于每個數據區域僅具有一個關聯的參與者，因此不需要互斥或信號量來限制訪問。 分區的參與者根據來自交易參與者的消息來處理對數據操作的請求。 發送方參與者無需等待（阻止）等待響應，而是可以自由地處理其他任務。 當分區的 actor 用數據響應時，發出請求的事務 actor 從中斷的地方繼續。 它要么完成交易并向客戶端發送回復，要么與其他參與者保持互動。 下面的示例試圖以圖形方式說明數據庫設計的傳統共享內存模型與 InfiniSQL 的參與者模型之間的區別：  對于參與者，沒有 鎖定。 當需要更多處理時，將添加更多的參與者，每個參與者*大致*最佳對應于單個 CPU 線程或內核。 隨著內核的添加，基于角色的體系結構可以保持很好的狀態。 但是，傳統的鎖定共享內存模型在添加內核方面會遭受更多的痛苦-因為鎖爭用只會增加。 大型整體數據庫具有非常復雜的鎖管理方法，可以最大程度地減少此問題。 actor 模型的另一個好處是它支持大量并發。 InfiniSQL 實現角色的方式與傳統角色模型略有不同，但是在保持高吞吐量的同時，它仍然可以實現很高的連接速率。 大多數傳統數據庫都有一個連接閾值，超過此閾值，聚合系統的性能將大大降低。 這主要與已經描述的爭用有關，并且還因為每個連接的成本都很高-如果每個客戶端在服務器端都需要專用的進程（或線程），則會消耗大量內存。 此外，高度多線程的應用程序會遭受過多的上下文切換。 內核調度程序始終必須使線程進入睡眠狀態，復制它們的狀態，然后復制并激活另一個線程。 使用 InfiniSQL，維護每個連接的成本相對較低-內核必須管理一個開放的套接字。 另外，將創建一個用于管理連接的對象。 添加了兩個地圖條目，以允許相關角色識別連接。 與必須啟動一個新線程（更不用說進程）相比，每個連接的開銷要低得多。 為了最大程度地減少上下文切換，每個參與者大致對應一個 CPU 線程，因此等待 CPU 的線程更少。 為了解決 I / O 緩慢的問題，InfiniSQL 目前已成為內存數據庫，從而避免了這種情況。 與塊支持的存儲相比，在內存中實現起來更簡單，尤其是使用 actor。 但這顯然帶來了一些問題。 即，耐久性和成本。 如果斷電，則內存中數據庫的單個副本將消失。 并且 RAM 的成本高于磁盤的成本。 [概述](http://www.infinisql.org/docs/overview/)描述了計劃在開發工作中花時間解決這些問題的計劃。 InfiniSQL 計劃的內存持久性的關鍵在于強調-它是從高端存儲領域借來的。 高端存儲系統之所以表現出色，是因為它們將更改寫入內存中，并且僅在以后將這些更改寫入磁盤中。 他們可以避免這種情況，因為它們具有冗余的備用電池系統，并且每次寫入都分布在多個緩存區域中。 斷電或單點故障都不會導致高端存儲系統中的數據丟失，這才是真正重要的。 世界上最大的交易處理平臺依賴于這種存儲陣列。 除了冗余和電源管理將保護數據庫服務器節點本身以外，InfiniSQL 打算實現相同的模型。 這尚未完全實現，但是如果可用，將意味著 InfiniSQL 將提供持久的內存性能。 ## 事務處理 事務處理的詳細信息在[概述](http://www.infinisql.org/docs/overview/)中進行了描述。 我發現使用參與者實現 ACID 功能的原因是還需要實現其他技術。 即，參與者間遠程過程調用（RPC）是一種在 OSI 模型和后續版本上受到寬松啟發的本地協議棧。 這引入了一定程度的實現復雜性-我正在尋找重構和降低復雜性的方法。 但是所有的 ACID 特性（如上所述的耐用性除外）都可以發揮作用。 ## 基于行的表，索引和類似的東西 基于參與者的核心和事務處理功能*可以與任何數量的不同類型的數據庫一起使用。 基于列的簡單密鑰庫，xml 文檔庫，graphdb。 任何需要擴展并從并行性中受益的事物。 但是我選擇實現基于行的 RDBMS 作為 InfiniSQL 的第一個底層存儲方案。 盡管有其他類型，該模型仍支持多種應用程序。 大多數備用數據組織類型都針對特定類型的工作負載進行了優化，而其他類型的組織則非常糟糕。 例如，列數據存儲不適合事務處理。 除了獲取/設置簡單對象之外，密鑰庫實際上不能做任何其他事情。 關于 InfiniSQL 組織和操作數據的方式，沒有什么破天荒的創新，但是底層體系結構克服了許多限制，這些限制促使采用許多備用數據庫類型。* PostgreSQL 客戶端用于執行 SQL 查詢，因此實際上任何平臺和語言都應該能夠使用 InfiniSQL。 他們已經很好地記錄了[前端/后端協議](http://www.postgresql.org/docs/7.4/static/protocol.html)，因此為 InfiniSQL 實施它非常簡單。 （InfiniSQL 和 PostgreSQL 是完全獨立的項目。） ## 摘要 就 InfiniSQL 的介紹以及如何將其設計為無限可擴展的 RDBMS 而言，這幾乎就是如此。 到目前為止，從字面上看，這是一個人在他的客廳里全天候敲出代碼的工作。 請喜歡 InfiniSQL，并從中學習，如果您想談論它，請在上述鏈接中找到我！ 另外，請考慮參與-它仍處于早期狀態，并且正在積極尋求貢獻。 它是免費的開放源代碼，并且有很大的發展空間。 愿意進行此項目的 Alpha 測試的人們也很受歡迎-如果您認為 InfiniSQL 可以解決您的某些問題，請與我談談！ [關于黑客新聞](https://news.ycombinator.com/item?id=6795263) *主頁： [http://www.infinisql.org](http://www.infinisql.org/) 博客： [http://www.infinisql.org/blog/](http://www.infinisql.org/blog/) IRC： [irc.freenode.net](http://irc.freenode.net/) #infinisql Twitter：@infinisql 論壇： [https://groups.google.com/forum/#!forum/infinisql](https://groups.google.com/forum/#!forum/infinisql)* 雖然這是一個有趣的開始，但我最想知道 InfiniSQL 如何計劃處理聚合功能和大表的聯接。 尤其是聯接是使關系數據庫吸引人的原因，但是當您擴展規模時，尤其是對于復雜數據，它們也是最難的事情之一。 我很好奇，想知道 InfiniSQL 是否計劃提供某種東西來比在外部進行連接（例如在 map reduce 中）或購買帶有硬件的數據庫設備來使更大的連接成為可能。 您的徽標與 VoltDB 有點類似：http://i.imgur.com/93x1CWJ.jpg 嗨，戈登。 對于聚合，我認為它應該相對簡單： 向每個分區發送一條消息，以使其返回其自身數據集的聚合結果。 然后讓交易代理收集結果，并簡化為正確的答案。 地圖/縮小效果如何？ ;-)我還在考慮為每個表（甚至字段）提供一個選項，以便在每個插入/更新/刪除操作中更新其聚合值，以節省聚合查詢的時間。 對于聯接，我正在考慮讓每個分區創建一個臨時表，該表代表相關表中的聯接值，并將這些值返回給事務代理。 在 InfiniSQL 上，某些大規模的多方聯接很可能無法很好地完成工作-這很可能是只有整體數據庫（或 MPP 數據倉庫）才能很好地工作的領域。 我認為 InfiniSQL 至少對于現有的基于行的存儲而言，并不是真正繁重，長時間運行的分析的最佳選擇。 現在，對于柱狀存儲，可能會有不同的故事。 我還編寫了大多數代碼來支持子查詢，但尚未對其進行完整的測試。 因此，幾乎*支持子查詢。 您想幫忙嗎？ :-) 我真的不認為可以基于“ 12 臺小型服務器”來“證明”“無限可擴展性”。 在那 12 之后再加上兩個零； 如果每個服務器的數量看起來仍然相同，那將更有說服力。 如果我沒記錯的話，VoltDB 說了類似的話，第三方稍后顯示當您達到 50 到 100 臺服務器（不確定精確限制）時，數字下降了。 I don't really think that "infinite scalability" can be "proved" based on "12 small servers." Add another two zeros after that 12; if the numbers per server *still looked the same*, that would be a lot more convincing. If I remember well, VoltDB said something similar, with third party showing later that the numbers went down when you reached 50 to 100 servers (not sure about precise limit). ------ 嗨，塞巴斯蒂安。 我認為演員模型很適合擴展規模。 本質上，限制因素將是節點間通信。 我不確定隨著節點的增加，效率會降低多少。 另外，諸如高性能節點間聯網之類的技術將改善這一狀況。 有一次，我正在研究 Infiniband 動詞作為集群間通信協議，但是 TCP / IP 更容易并且無處不在。 但是我想為 InfiniSQL 實現一個選項，以使其本機使用 Infiniband 進行群集通信-我認為這對于擴展可伸縮性將大有幫助。 我不認為我們不同意-至少，到目前為止，我已經很清楚自己已經能夠走多遠了，我希望有機會進一步走好。 如果像 SGI 這樣的人能像為 VoltDB 一樣借給我無數的服務器，那就太好了。 ;-) 我也不認為我們不同意。 我只是指出“ 12 臺小型服務器”。 不是那么...令人印象深刻。 我也是 Actor 模型的忠實擁護者，因為我是新的（仍然是 1.0 之前的版本）Actor API 的提交者。 但是對于許多 DB 而言，節點間的通信很快成為瓶頸，因此需要 12 個以上的節點來說明是否（或以何種大小）這種情況。 > 如果像 SGI 這樣的人能像為 VoltDB 一樣借給我無數的服務器，那就太好了。 ;-) ：D >我還在考慮為每個表（甚至字段） >提供一個選項，以便在每次插入/更新/刪除時將其匯總值更新為 >，從而節省匯總時間 查詢。 您是說要維護每個表的每個字段的*每個*匯總值？ 我認為這沒有太大意義。 例如，您將使用以下查詢做什么： 從員工那里選擇 AVG（薪水）WHERE employee_name LIKE'H％'; ？ 或者您將如何處理用戶創建的聚合函數？ 當將記錄插入表中時，這些功能甚至不存在。 只要考慮一下 postgresql 的 CREATE AGGREGATE 語句。 我有一個問題，這個帖子沒有答案 -根據文檔，每個寫入都可以同步復制。 但是，即使在內存中，同步復制也很難擴展（CAP 定理？）。 盡管該功能尚未完成，但我認為這可能是對無限可擴展性的很大限制。 你同意嗎 ？ Csongor 說： “您是說要維護每個表的每個字段的*每個*聚合值？我認為這樣做沒有太大意義。” -------------- 僅作為選擇。 該用例適用于希望為每個插頁上的列收集 AVG 的人員。 保存每個分區的滾動總條目數和條目數量會節省計算時間。 但是對于您提到的情況，不，這不是一個好主意。 主要是想表達我在 InfiniSQL 中進行聚合沒有問題。 slefebvr 說： 我有一個問題，這個帖子沒有答案 -根據文檔，每個寫入都可以同步復制。 但是，即使在內存中，同步復制也很難擴展（CAP 定理？）。 盡管該功能尚未完成，但我認為這可能是對無限可擴展性的很大限制。 Do you agree ? --------------- 不，我不同意。 我幾乎完成了同步復制。 擴展并不難-盡管它會消耗一定數量的系統資源才能完成。 但是隨著節點的增加，每個節點的系統資源有望保持穩定。 我看到的關于可伸縮性的唯一硬性限制是打開的可用 TCP / IP 套接字的數量-副本中的每個節點都連接到網格中的每個其他節點。 類似 UNIX 的系統不能同時處理無限數量的 TCP / IP 連接。 我認為極限是無限 10。 ;-) 塞巴斯蒂安寫道： I'm a believer in the Actor model too, as I'm a commiter to a new (still pre-1.0) Actor API. But for many DB, inter-node communication quickly becomes a bottleneck, and a lot more then 12 nodes are needed to show if (or at which size) this is the case. --------------------- InfiniSQL 批處理節點間消息并使用 LZ4 壓縮。 它犧牲了一些延遲，但是在我看來，吞吐量的增加是值得的。 同樣，10GB 以太網比 1GB 更好，多個 NIC RX 隊列比單個更好。 我想使用 Infiniband Verbs API（https://www.openfabrics.org/index.php）來實現 RDBMA，但是 TCP / IP 較容易編碼，并且用戶基礎更加廣泛。 但是我認為 Infiniband 可以大大減少集群內部的通信開銷。 有趣的項目。 在許多情況下，您可以將聚合推送到參與者。 AVG 怎么了？ 您從每個演員返回計數和平均值，然后根據計數加權最終平均值。 感覺就像一個很簡單的地圖/縮小模型。 正如其他人所提到的，問題可能是節點間通信，尤其是在某些聯接情況下。 我喜歡您已經認識到這一點，但是您可以將 10GB 擴展到某種上限。 我不知道我會稱其為無窮大，但“高”似乎是可能的。 期待看到這片土地，尤其是當您獲得 ACID 中的 D 以后，您會發現更多。 干杯! - 八月 >如果像 SGI 這樣的人像為 VoltDB 一樣借給我無數的服務器，那就太好了。 ;-) EC2 FTW :-) FWIW，我認為正確處理節點故障和分區，最終獲得一個可靠且性能良好的系統至關重要。 沒有人愿意為后者犧牲前者。 第一部分是所有群集節點必須在配置上達成一致。 如果您以前從未接觸過它，則可能想看看[木筏](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf)算法作為 Multi-Paxos 的替代方法。 但是，為了確定哪些寫入已傳播到副本節點，還需要在某種程度上進行類似的操作。 您可以確定，每種可能的故障模式-節點消失并在事務處理周期的不同點返回-*或早或晚都會發生。