# Spanner-關于程序員使用 NoSQL 規模的 SQL 語義構建應用程序 > 原文： [http://highscalability.com/blog/2012/10/22/spanner-its-about-programmers-building-apps-using-sql-semant.html](http://highscalability.com/blog/2012/10/22/spanner-its-about-programmers-building-apps-using-sql-semant.html) 很多人似乎都非常討厭 [NewSQL](http://blogs.the451group.com/information_management/2011/04/06/what-we-talk-about-when-we-talk-about-newsql/) 這個詞，或者幾乎是這個詞的任何新造詞，但是在看過高級軟件工作人員 Alex Lloyd 之后 Google 工程師，就 Building Spanner 進行了精彩的演講 [ ，這是最適合 Spanner 的術語。](http://vimeo.com/43759726) Spanner 將 OldSQL 的 SQL +事務模型包裝在全球分布式 NoSQL 系統的重新設計的骨骼上。 在我看來，這是 NewSQL。 由于 Spanner 不是 BigTable 的近親，因此 NoSQL 組件應該不足為奇。 Spanner 負責在任意數量的地理分布數據中心內跨越數百萬臺計算機。 令人驚訝的是，OldSQL 是如何被接受的。 Alex 在 HotStorage 會議上發表的 [](http://static.usenix.org/event/hotstorage11/tech/slides/lloyd.pdf)早期演講中，采用 OldSQL 的原因是希望使程序員更輕松，更快速地構建應用程序 。 主要思想似乎很熟悉： * 小型復雜數據庫與龐大，可擴展，簡單的數據庫之間存在錯誤的二分法。 我們可以擁有功能并對其進行擴展。 * 復雜性可以保留，可以放到某個地方，因此，如果不在數據庫中，則將其推送給開發人員。 * 將復雜性降低到堆棧中，以便開發人員可以專注于構建功能而不是數據庫而不是基礎結構。 * 創建快速發展的應用團隊的關鍵：ACID 交易； 全局可序列化； 編寫第一步交易，而不是十步工作流程； 編寫查詢而不是代碼循環； 加盟 沒有用戶定義的沖突解決功能； 標準化同步； 即付即用，獲得可預期的性能所需的費用。 Spanner 并非以成為 NewSQL 明星為目標。 Spanner 最初是 BigTable 克隆，帶有分布式文件系統隱喻。 然后，Spanner 演變為全局 ProtocolBuf 容器。 最終，Spanner 受到 Google 內部客戶的推動，以變得與關系和應用程序程序員更加友好。 顯然，在 Google 內部使用 [Dremel](http://highscalability.com/blog/2010/8/4/dremel-interactive-analysis-of-web-scale-datasets-data-as-a.html) 已向開發人員表明，可以大規模使用 OLAP 和 SQL，他們希望 OLTP 應用具有相同的易用性和上市時間。 看來 Google 有很多應用程序可供開發，程序員不喜歡處理在最終一致的系統之上生產可靠產品的現實世界中的復雜性。 訣竅是弄清楚如何使 SQL 真正大規模地工作。 為了表明我們仍處于編程經驗階段的深度，該過程甚至花費了 Google 五年的開發時間。 亞歷克斯說，真正的工作實際上是建立一個復雜的，可靠的分布式系統。 那是很難正確的部分。 在談論原子鐘等所有內容時，您可能會感到系統中存在魔力。 您可以進行巨大的跨表，跨數百萬條記錄的數據中心事務處理而不會受到任何損失。 那是不對的。 Spanner 是 OLTP 系統。 它使用兩階段提交，因此長時間的大型更新仍將鎖定和阻止，程序員仍處于進入和退出的困境。 想法是這些限制值得程序員提高生產力，并且確實出現的任何瓶頸都可以逐案處理。 通過演講，我逐漸感覺到，Spanner 的域中將包含諸如 pub-sub 之類的專用應用程序域。 盡管事務方面可能是常規事務，但除了所有的全局重新分區魔術在幕后透明進行之外，它們的事務時間戳方法在讀取路徑上確實具有很多不錯的功能。 為說明每個 Paxos 組很難擴展到大量副本的困難，Alex 轉向了水文隱喻： > 您可以將 Spanner 分區用作一種有序的 pub-sub 方案，在該方案中，您在某個分區的所有位置都有只讀副本，并且您正試圖使用??它來以有序方式將數據分配給很多 不同的數據中心。 這帶來了不同的挑戰。 如果您沒有足夠的帶寬訪問那些數據中心的某些子集，該怎么辦？ 您不希望數據在領導者中緩沖太久。 如果您將其溢出到磁盤上，那么當帶寬可用時，您就不會招致搜索損失。 它變得像水文學。 您需要將所有這些數據在不同的時間發送到不同的位置，并且希望在變化的條件下使所有流平穩地移動。 平穩地意味著更少的服務器重啟，意味著更好的延遲尾部，意味著更好的編程模型。 這也許是我最喜歡的部分。 我只是喜歡數據流過的圖像，就像水滴從數百萬臺機器和網絡中滴落，暫時聚集在內存和磁盤的洞穴中，總是分裂，總是重組，總是不斷變化，總是不斷進步，是巨大的不斷流動的一部分 [數據周期](http://en.wikipedia.org/wiki/Water_cycle)永不丟失。 太棒了。 如果您有機會觀看視頻，我強烈建議您這樣做，這的確很好，根本沒有什么毛病。 關于在分布式事務中使用時鐘的部分做得特別好。 但是，如果您時間緊缺，可以參考以下內容： * 5 年的努力。 * NoSQL 規模的 SQL 語義。 * 試圖獲得一個看起來像單個巨型 MySQL 的抽象。 * 關系數據庫是一個非常熟悉的生產環境，可以在其中建立應用程序。 * Spanner 是存在證明，可以將關系數據庫擴展到全局分布式存儲系統。 * 編寫應用時無需考慮事務語義。 正確無誤。 然后，您返回并優化一些高事務寫入，這些優化將真正獲得回報。 * 希望向應用程序開發人員提供真正直接的語義。 應用程序開發人員應考慮業務邏輯而不是并發性。 * 他們這樣做的方式是通過構建具有絕對絕對誤差的時鐘。 然后將它們與時間戳分配集成在并發控制中： * 時間戳的總順序遵循事務的部分順序。 如果交易 A 在交易 B 之前發生，我們知道交易 A 的時間戳小于交易 B 的時間戳。 * 這意味著對所有內容進行有效的可序列化查詢。 您可以將跨越數十個數據中心的 PB 級數據庫的總和提高到一分錢。 可能需要一段時間才能獲取所有數據。 但是您可以期望答案是正確的。 * BigTable 早期的 NoSQL 數據庫。 論文于 2006 年問世。 * MegaStore 建立在 BigTable 之上。 它添加了 Paxos 同步層和更豐富的數據模型。 論文在 2011 年問世。 * 底層架構中的 Spanner 很像 BigTable。 更新會附加到數據中心本地分布式文件系統中的日志中。 定期將它們壓縮為不可變的 b 樹（SSTables），并定期將這些 SSTable 合并在一起。 Leveldb 是一個開源版本。 * 開發人員仍必須考慮如何對數據進行分區以提高效率，但開發人員應盡可能地專注于業務邏輯。 * 目標不是數據重新分區的停機時間。 **Google 所做的一切都與數據移動息息相關，因為在數據中心之間移動用戶和重新分片是一項持續的后臺活動。** **因為這是一個連續的過程，所以各種并發性錯誤不斷出現**。 事務有助于正確地分配其連續的分區流邏輯。 在進行交易之前，他們有很多錯誤，這就是為什么花了 5 年的時間的一部分。 * 希望程序員減少在設計過程中早期做出的分區決策的束縛。 * 希望獲得 Megastore 最成功的部分： * 處理大規模數據中心中斷，而不會給用戶帶來明顯影響。 * 處理單元內部較小的中斷，微中斷。 示例：底層平板電腦因過載或損壞而中斷，僅一個機架上的電源就中斷了，等等。 * 用戶可能會在計時器觸發時看到延遲增加，并且他們移至另一個數據中心，但看不到對事務語義的影響。 * 但是 Megastore 有一些問題： * 數據庫被劃分為一堆實體組。 實體組是他們自己的交易域，您不能跨實體組進行交易。 * 它使用樂觀并發。 當副本之間的傳播間隔為 50 毫秒，而您正在執行同步復制時，寫入將至少花費 50 毫秒，這將為樂觀并發故障創建一個很大的漏洞窗口。 * 將分層系統整合為單個集成系統的好處。 與 Megastore 和 Bigtable 之間的接口相比，Spanner 與物理存儲之間的接口要豐富和優化。 * 向 SQL 的文化轉變 * 基于 SQL 的分析系統 Dremel 在 Google 上進行了許多 SQL 轉換，因為它可以將查詢的語義向下推送到存儲系統中，并讓其確定該怎么做。 * 這種文化根深蒂固，您可以擴展，也可以使用 SQL。 Dremel 表明，對于分析，您可以同時擁有。 Spanner 顯示您可以同時使用 OLTP。 * 由于業務問題，人們要求簡化地理分區。 例如，將用戶數據從一個區域移動到另一區域。 * 法律問題 * 產品增長意味著您想要盡可能高效地將多少人放到 * 扳手的數據模型 * 并不總是具有關系模型。 與 Jeff Dean 在 2009 年提出的內容完全不同。 * 帶有單個用戶關系表的示例，每個用戶都有一個名稱和家庭區域。 * User 數據庫可以分為幾個分區。 美國的一個只讀分區，歐洲的另一個分區。 大型數據庫將具有數百萬個分區。 分區 1 在美國將具有三個副本。 另一個分區在歐洲具有三個副本。 美國有一個只讀副本。 這很有用，因此您可以在歐洲擁有一個書面仲裁，這意味著您永遠不會阻塞跨大西洋的 RPC 調用，但是在美國，盡管它可能有些陳舊，但您仍然可以查詢所有數據。 * 主細節層次結構在物理上被聚在一起。 在分布式系統上，更為重要的是記錄將存儲在其他服務器上。 * 關系抽象的底層是程序員如何將密鑰手動編碼到 Bigtable 中。 每個表格單元格都只有一個條目，例如： * @ 10 部分是時間戳。 * 在 Bob 記錄開始之前，Alice 的訂單將與 Alice 一起存儲。 * 并發 * 在較高級別，Spanner 使用兩階段鎖定和快照隔離的組合。 * 并未嘗試創建瘋狂的新模型。 旨在找出如何擴展已驗證模型的目標。 * 此模型最適合讀取為主的工作負載。 您將大部分時間花在便宜的快照隔離讀取上，而不花大量時間在悲觀主義事務寫入上。 * Blogger 示例，它首先擔心正確性，然后擔心優化。 * Blogger 有 280 個 Servlet。 低頻高復雜度操作，例如用戶通過發送文本消息來創建博客，然后他們希望將該博客合并到現有博客中。 * 花費大量的時間才能將其創建為由精心設計的工作流程精心安排的一系列冪等操作。 * 使用 ACID 交易，Blogger 會更快。 在沒有性能優勢的情況下花費在這些復雜的編程任務上的時間本來可以減少某些高頻頁面的 50 毫秒，從而產生更大的整體影響。 * 與在單臺計算機上編程相同的過程。 您從互斥鎖開始，然后才嘗試原子操作。 * 僅執行弱一致性的 NoSQL 數據庫正在對整個系統實施廣泛應用的過早優化。 應該選擇值得的頁面。 * 在 Google 看到的模式中保留提交順序 * 他們在設計過程中考慮的經驗法則： * 如果 T1 在 T2 之前完成，那么他們想保留這一事實。 T2 與 T1 之間存在提交順序相關性。 * 假設 T3 寫了一些 T4 讀取的內容，因此存在傳統的數據依賴性，因此 T3 必須始終在 T4 之前發生。 * T1 和 T2 在 T3 和 T4 之間沒有關系。 * **系統性能來自并發運行沒有依賴性的事務。** * **目標是保留與原始歷史記錄相同的依存順序。** * 可序列化是一個帶有大量變化的重載術語。 * 線性化是從并發編程中借鑒的一種思想，并且很好地適用于在分布式數據庫之上對分布式系統進行編程。 * 包含可序列化性，無法上下班提交順序。 * 即使沒有可檢測的依存關系，即使一筆交易發生在另一筆交易之前，也必須保留該訂單，即使該交易發生在不同的機器上。 * 示例架構： * 一個分區是購買的廣告表。 在美國寫仲裁，在歐洲寫只讀副本。 * 這些廣告的展示在美國的一個分區。 例如，在 2:00 和 2:01，有人觀看了小狗廣告。 * 歐洲的一個分區，用于展示廣告。 * **在美國有一個只讀的歐洲數據副本，反之亦然。 這樣可以使雙方進行過時的讀取和快速的寫入，而無需越過池塘。 您仍然可以在任何一側高效地使用 MapReduce。** * 交易示例： * 交易 1：用戶購買了廣告。 * 在后臺，廣告投放系統正在不斷掃描分區以顯示廣告，并發送檢索廣告查詢。 * 廣告投放系統會隨著時間累積其要保存在數據庫中的一批展示次數。 * 事務 2：服務器寫入印象分區以記錄印象。 * 這是兩個不同的分區，不同的副本，不同的數據中心以及潛在的不同大陸。 * 現在，您想編寫一個 SQL 查詢來審核小時級別的展示次數。 選擇一個時間戳。 * 根據時間戳記只有三個合法結果： * 既看不到廣告也看不見。 * 看到廣告，但沒有展示。 * 查看添加和所有展示。 * 在所有系統中，他們都在替換 MapReduce 或查詢必須容忍結果的無限變化。 * 它可能會看到展示，但看不到廣告。 * **針對這種弱語義編寫查詢意味著很難分辨出腐敗，錯誤或并發異常之間的區別。** * 解決此問題的方法是通過單個中央服務器序列化每個更新。 如果更新位于一起，則有效，但不適用于分區遍布全球的分散式模型。 * 在全球分布式數據庫中擴展 Spanner 所需語義的選項： * **一個分區模型** 。 大量的 WAN 通信。 將所有分區都包含在每個事務中。 * **集中時間戳預言** 。 如果您同時在兩個不同的大陸上進行更新，則效果不佳。 * **Lamport 時鐘** 。 通過每個外部系統和協議傳播時間戳。 如果您的系統數量和協議數量都不足，則此方法有效，當您擁有大量不受控制的分布式系統或協議（例如與貿易伙伴一起使用）或它們只是協議時，您將無法正常工作 不碰。 在 Google 進行了幾次嘗試，但是在復雜的系統中始終無法成功完成時間戳。 * **建立一個分布式時間戳預告片** 。 其中的一個 TrueTime 是 Google 常規時間清理產生的。 時間有一個 epsilon 時間，因此您知道進行現在呼叫的實時時間在該時間間隔內。 源自一堆不同數據中心中的 GPS 接收器，這些數據中心由原子鐘備份。 GSP 系統有時確實存在錯誤。 一次代碼推送可以消除大量衛星，因此備份非常有用。 * TrueTime * 目標不變式：寫 A 和 B，如果 A 發生在 B 之前，則意味著 A 在 B 開始之前完成，那么 A 的時間戳應小于 B。完成意味著任何人都可以看到效果。 不僅是客戶，還有 Paxos 奴隸。 * 使用此不變式，意味著您可以說在特定時間戳記下的快照讀取是可序列化的。 * TrueTime 與天體導航的工作原理類似，只是那是硬錯誤界限，而不僅僅是猜測。 * 每臺 Google 服務器中都有一個時間守護程序，每臺服務器中都有一個水晶，每個數據中心都有一些來自不同制造商的 GPS 的時間主控器，以解決錯誤的多樣性，其中一些具有原子鐘來交叉檢查 GPS。 * 守護程序每 30 秒與時間主對話，并獲得時間修復。 在兩者之間，死者根據自己的晶體進行偵察。 服務器錯誤容限隨著時間的推移而擴大，他們選擇了百萬分之 200。 * 現在幾點了？ 在本地計算機上讀取時間。 將 GetTime 發送到時間主機。 返回時間為 T。再次讀取本地服務器時間。 你得到一些增量。 然后，您可以擴展該增量以獲得所需的任何誤差范圍。 回來了一個ε。 現在您可以說時間在[t t + e）]中。 時間不早于 t，因為時間主因您收到 t 的回應而報告了 t 的因果關系。 但是會有很多偏差，因為郵件可能是在 epsilon 之前發送的。 您不知道往返 t 產生的位置。 開始漂移之前的主要錯誤是與主設備的往返時間。 * 您可以建立 GPS 以外的其他系統來分配時間。 例如，LED 閃爍并為所有系統提供時鐘脈沖。 使用心跳系統，該系統定期與中央服務器對話，并且在這些心跳之間，所有服務器都認為時間是固定的。 GPS 在那并且可以工作。 原子鐘是一種方便的交叉檢查。 而且所有硬件都不貴。 * 當 Paxos 領導程序從客戶端接收到提交請求時，該分區的 Paxos 領導程序流 * 接收開始提交。 * 獲取事務鎖定。 任何兩階段提交系統中的典型值。 抓住讀寫鎖，以確保沖突的事務不會同時執行。 * 選擇一個時間戳記，以使 true.max 大于當前時間。 * 并行執行兩件事：運行 Paxos 以就寫入內容達成共識，等待真正的時間肯定超過該寫入時間戳記。 * 通常，Paxos 將花費比等待更長的時間，因此它不會增加額外的開銷。 * 通知 Paxos 奴隸解鎖。 * 確認返回客戶端。 * 為什么起作用？ 通過等到提交時間戳記過去，我們將所有將來的事務推向更大的時間戳記。 保證下一個事務的時間戳大于前一個事務的時間戳。 **每個事務都同意選擇一個比其起始點大的時間戳，并且每個事務都同意將其提交推遲到自己的提交時間戳記過去。** * 當 Paxos 進行得太快或只有一個副本，而您只是要提交到本地磁盤時，TrueTime epsilon 可能比提交該提交所需要的時間大。 * 當 TrueTime epsilon 達到峰值時發生，例如 TrueTime 母版下降并且您必須轉到更遠程的 TrueTime 母版的情況下。 或者當 Paxos 副本異常關閉時。 * 現實中的 epsilon 在 1 到 7 毫秒之間反彈。 * 當通過使用具有更高 QoS 的時間數據包來改進網絡時，尾部延遲降低了。 < SDN 的一個論點，即通過系統以更高的 QoS 獲得諸如時間和 Paxos 之類的控制數據包。 * 通過更頻繁地輪詢時間主數據，以高 QoS 輪詢，改善內核處理，在 NIC 驅動程序中記錄時間戳，購買更好的振蕩器，注意內核錯誤（節能模式（您使用的時鐘））來減少 epsilon。 ## 讀取路徑 * 類型： * 在讀取-修改事務中，看起來與標準的兩階段鎖定相同，只是它發生在 Paxos 領導者身上。 獲取讀鎖。 * 不屬于事務的強讀取，客戶端不會基于該讀取進行寫入。 Spanner 將選擇一個更大的時間戳并在該時間戳上進行讀取。 * 當您只想知道數據已使用 5 或 10 秒時，就會讀取陳舊的數據。 Spanner 將選擇落入陳舊范圍內的最大已提交時間戳。 * MapReduce /批量讀取-不在乎數據是否新鮮。 例如，讓客戶選擇一個時間戳并說我想知道所有事情。 * 為強讀而選擇的時間戳記： * 問 TrueTime，現在的時間比現在大。 您知道這也大于所有先前提交的事務的提交時間戳。 并非總是最好的時間戳，因為您希望最大化能夠在該時間戳上進行讀取的副本。 * 查看提交歷史記錄。 從最近的文章中選擇一個時間戳。 * 強制聲明預讀的范圍。 例如，這 5 個用戶和該系列產品。 范圍的概念高于分區的概念。 * 準備的分布式事務。 由于分布式事務必須在每個分區上同時提交時間戳，因此存在一個不確定性窗口，在此窗口中，您不會為某些對象提交什么數據來提交時間戳。 * 有效使用原則： * 數據局部性仍然很重要。 從一臺機器上讀取一堆東西比從一堆機器上讀取要好。 將客戶和訂單放在同一分區中。 * 大用戶將跨越多個分區，但是跨分區在事務級別上不會產生語義影響。 * 設計應用的正確性。 處理數百個需要處理但不需要那么快的細膩堅硬的角落案件。 例如，您一天更改幾次 Gmail 過濾器？ * 放寬仔細審核的高流量查詢的語義。 也許在某些情況下，閱讀會過時。 您過去讀得越遠，越能提供更多副本。 * Spanner 中的默認語義是它們是可線性化的。 * 使用閃存備份將允許毫秒寫入。 * 第一個大用戶：F1 * 已將對收入至關重要的共享 MySQL 實例遷移到 Spanner。 對 Spanner 數據模型的影響很大。 F1 需要一個強大的 MySQL。 * Spanner 最初是 BigTable 之子 * 包含許多分叉的 BigTable 代碼，并帶有分布式文件系統隱喻。 您有一棵目錄樹，每個目錄都是地理位置的單位。 這與建立數據庫的人無關。 * 他們添加了結構化密鑰，但最終他們只是在構建下一個 Megastore。 * 他們決定 Spanner 需要更豐富的數據模型，從而確定 Spanner 是協議緩沖區的存儲庫。 Spanner 將是一個巨大的協議緩沖區。 這似乎是合理的，但同樣，它不是用戶建模數據的方式。 * 他們認為 F1 是更好的模型，因此最終他們轉向了關系數據模型。 ## 他們現在在做什么？ * **完善 SQL 引擎**。 時間戳加迭代器的位置足以重啟跨分區查詢。 如果查詢需要一分鐘，并且負載平衡器在那一刻將您依賴的平板電腦移動到另一臺服務器，或者該服務器被搶占，因為您正在共享單元中運行，并且搶占迫使這些平板電腦移動，查詢會 不必中止，也不必扔掉工作。 像這樣移動服務器很難工作，但對用戶而言確實有價值。 * **對內存使用情況的精細控制**，因此您無需創建分布式死鎖，因為當一堆服務器都依賴于它們時，它們都需要內存才能取得進展，而它們都需要取得進展才能釋放該內存 。 * **細粒度的 CPU 調度**。 即使出現大得慢的大查詢，也要保持快的查詢快。應該對無希望的慢查詢進行時間劃分，以使快的查詢保持快。 保持延遲的尾巴。 * **基于快照隔離的強讀取仍然非常綠色**。 這些正在以越來越多的用例進入生產。 * **縮放到每個 Paxos 組**的大量副本。 您可以將 Spanner 分區用作嚴格有序的 pub-sub 方案，在該方案中，您在某個分區的所有位置都有只讀副本，并且您正嘗試使用它來以有序方式將數據分配到許多不同的數據中心。 這帶來了不同的挑戰。 如果您沒有足夠的帶寬訪問那些數據中心的某些子集，該怎么辦？ 您不希望數據在領導者中緩沖太久。 如果您將其溢出到磁盤上，那么當帶寬可用時，您就不會招致搜索損失。 它變得像水文學。 您需要將所有這些數據在不同的時間發送到不同的位置，并且希望在變化的條件下使所有流平穩地移動。 平穩地意味著更少的服務器重啟，意味著更好的延遲尾部，意味著更好的編程模型。 ## Q & A * 您如何證明交易之間沒有依賴關系？ 假設某人通過電子郵件向某人發送了一些數據，然后該人單擊了基于該數據的鏈接，從而導致了另一個數據中心的寫入。 很難說兩個不同中心之間的交易之間沒有因果關系。 他們希望您能夠在整個系統之間建立因果關系的前提下關聯整個系統中事務的順序。 * 最終的一致性和交易模型的空間。 * 移動是一種情況，用戶在更新本地緩存，并且數據將其返回服務器，因此您不必依賴事務，因此必須具有某種最終的一致性機制來合并更改并處理沖突。 * 允許并發編輯的 Google 文檔是另一種情況。 您有五個打開的窗口，它們每個都在進行本地更新。 這些更新異步地冒泡回到服務器。 應用用于合并更新的可操作轉換代數，然后才將這些更新應用于數據庫的規范副本。 ## 相關文章 * [Alex Lloyd-建筑扳手](http://vimeo.com/43759726) 視頻（ [幻燈片](http://berlinbuzzwords.de/sites/berlinbuzzwords.de/files/slides/alex_lloyd_keynote_bbuzz_2012.pdf) ） * [Google Spanner 的最令人驚訝的啟示：NoSQL 出現了，NewSQL 出現了](http://highscalability.com/blog/2012/9/24/google-spanners-most-surprising-revelation-nosql-is-out-and.html) * [面板：大數據，無需 SQL，大問題，無需擔心](http://static.usenix.org/multimedia/hotstorage11seltzer) （ [幻燈片](http://static.usenix.org/event/hotstorage11/tech/slides/lloyd.pdf) ）（ [視頻](https://www.usenix.org/conference/hotstorage11/panel-big-data-no-sql-big-problems-no-worries) ） * [互聯網規模的企業問題](http://static.usenix.org/event/hotstorage11/tech/slides/lloyd.pdf) 偉大的帖子托德。 這些方法正在合并！ 您的文章內容豐富，但有時我會覺得有些困惑。 謝謝托德。