SQL借助于NewSQL開始回歸

jopen 10年前發布 | 8K 次閱讀 SQL

  英文原文:SQL Makes a Comeback through NewSQL

  新一輪的數據庫開發風潮展現出了向 SQL 回歸的趨勢,只不過這種趨勢并非是在更大、更好的硬件上(甚至不是在分片的架構上)運行傳統的關系型存儲,而是通過 NewSQL 解決方案來實現。

  在市場被 NoSQL(一開始叫做“No more SQL”,后來改為“Not only SQL”)逐步蠶食后,近一段時間以來傳統的 SQL 開始回歸。其中廣為傳頌的一個解決方案就是分片,不過對于某些情況來說這還遠遠不夠。因此,人們推出了新的方式,有些方式結合了 SQL 與 NoSQL 這兩種技術,還有些方式是通過改進關系型存儲的性能與可伸縮性來實現,人們將這些方式稱作 NewSQL。Google(NoSQL 最初的支持者之一)構建了 F1,這是一個分布式的關系型數據庫,將 BigTable 的高可用性與可伸縮性與 SQL 的“一致性和可用性”結合起來。Google 在白皮書 F1: A Distributed SQL Database That Scales(PDF)中是這樣介紹 F1 的:

這是由 Google 構建的一個容錯、分布式的 OLTP 與 OLAP 數據庫,作為新的存儲系統用在 Google 的 AdWords 系統上。設計它的目標旨在替換掉分片的 MySQL 實現,因為后者已經無法滿足日益增長的可伸縮性與可靠性的需求了。

  MemSQL 就是眾多的 NewSQL 解決方案中的一個,這是個完全的內存解決方案,用于對結構化與半結構化(JSON)數據進行實時分析。它并沒有使用列式存儲,而是使用了“無鎖的 skip 列表與無鎖的 hash tables”以實現更快的數據訪問,并且對非分片架構使用了并行處理,不會出現單點失敗的情況。

  另一個 NewSQL 解決方案是 ClustrixDB,這是個點對點的非分片的分布式數據庫,用于事務處理與實時分析。根據 Clustrix CEO Robin Purohit 所述,他們的數據庫在 Twoo.com 每天能夠處理 4.4B 個事務,21 個節點(每個節點的配置是 8 核,48GB 內存)的平均延遲為 5 到 10 毫秒,其構建方式是這樣的:

從頭開始構建的點對點分布式 SQL 數據庫,沒有單獨的協調者(因此就不會出現單個的失敗點)。ClustrixDB 使用了分布式事務,事務使用了 Paxos 的一致性協議。ClustrixDB 針對寫使用了 2 階段鎖,還使用了分布式的多版本并發控制,用于確保讀與寫不會互相干擾。這可以保證分布式環境下單個節點數據庫嚴格的 ACID 屬性。

ClustrixDB 并沒有使用分片架構,這種方式也是唯一一種可以實現線性伸縮的架構。ClustrixDB 將原來只有數據倉庫中才擁有的用于實時分析的 Massively Parallel Processing (MPP)帶到了主流數據庫上。

  我們也向 Twoo.com 的 CEO Toon Coppens 提出了這樣一個問題:為何最初的 MySQL 分片解決方案無法滿足他們的要求,轉而去選擇一個 NewSQL 呢:

我們花了一些時間了解 Netlog.com 的架構,他們擁有成百個 MySQL 分片,重新平衡與管理這些分片的代價是非常高昂的,更不必說即時修改查詢或是在所有分片上創建新查詢時的不靈活性了,這種方式并不可取。我們希望一個查詢就能將數據查出來。

雖然 NoSQL 提供了不錯的可伸縮性,但我們并不想將自己綁定在底層的數據表示上。我們希望在修改產品與特性需求時擁有完全的靈活性,同時又不必修改每天都在變化的網站 的數據層(clustrix 提供了快速的變化,同時又能在高負載下運行良好,當然了,它還有其他很多優秀的特性)。

  雖然 NoSQL 因其性能、可伸縮性與可用性而廣受贊譽,但其開發與數據重構的工作量要大于 SQL 存儲。因此,有些人開始轉向了 NewSQL,它將 NoSQL 的優勢與 SQL 的能力結合了起來。最為重要的是使用能夠滿足需要的解決方案。

來自: InfoQ
                    <span id="shareA4" class="fl">                          </span>                 </div>
 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!