與Google Spanner跨越資料庫世界的對話 - nextplatform

回顧
Andrew Fikes：讓我稍微回顧一下我們如何發展打破這一步。我已經在谷歌待了很長時間 - 現在差不多18年了 - 隨著時間的推移，我已經能夠觀察到谷歌本身已經成長。當你看看谷歌建立的所有系統時，首先要注意的是加入公司的初始工程師是我稱之為主要的分散式系統工程師。他們有系統工程背景，而不是資料庫背景。

因此，當我們進入資料儲存時，其中很多都是從系統角度出發的，而且總是在考慮特定目標的情況下完成。當我們出去構建BigTable時，我們的第一個用例是儲存Web。這是在白板上繪製的一個非常簡單的事情：URL是關鍵，對於每個URL，我們想要儲存文件內容，我們希望能夠使用PageRank等內容來註釋這些文件內容。當時這些都是非常簡單的事情，它推動了我們需要一些可以擴充套件的東西的想法。

當時有趣的是，大多數這些物品本身都是獨立的，你可以想象一排機器。這是MapReduce出臺處理這個大型資料集的時間。但隨著時間的推移，谷歌本身已經改變。我們已經從搜尋業務轉變為廣告業務，從地理業務轉變為應用業務。在Spanner的背景下，當我們在意識到BigTable還不夠之後首次開始研究問題時 ，這個時機通常是在人們試圖構建應用程式的環境時發生的。

有幾個不同的問題。您正在嘗試解決水平分割槽 - 能夠佔用行空間的一部分並將它們放置在世界的不同部分。這是您今天在Cloud Spanner中使用此多區域功能所看到的功能之一。我們也開始發現構建在這些資料庫和資料儲存之上的應用程式邏輯比使用最終一致性合理化的程式要複雜得多。我們經歷了這段時間，聰明的人們試圖幫助應用程式人員在最終一致的系統BigTable之上構建東西，並意識到我們需要更多。

這幫助我們徹底解決了一大堆教條。那個時候，我非常相信最終的一致性。我非常相信事務不是我們在分散式系統中應該擁有的東西。當我們真正嘗試使用這些系統時，我們開始意識到這種一致性是我們實際需要的力量。有趣的是，Spanner帶領我們踏上了一個讓我們的分散式系統越來越接近資料庫的旅程。因此，我們開始對資料庫文化以及知識和經驗進行一些介紹。

例如，我們Google並不是強烈的SQL信徒。現在我很高興有型別鍵，而SQL已成為Google內部用於訪問資料的通用語言，我們看到它越來越多地滲透到我們的系統中。當我們向我們的兄弟們新增SQL時，我們在廣告中新增了F1團隊，我們將整個業務關鍵資料庫（在MySQL中）移植到了Spanner，我們與他們合作構建了一個SQL引擎。您已經看到我們更進一步，重新檢查堆疊的所有部分，以便更好地理解如何實現SQL。

SQL
當我們開始在Spanner中實現SQL時，我作為系統人員出現了，我想，有一個SQL標準，對吧？很明顯我們應該做的是我們應該實現SQL標準，我們將能夠來回溝通。這對我來說這是一個明確的學習時刻。我花了好幾個小時在大型PDF文件面前，抓住了SQL的指定方式，然後啟動了不同的資料庫引擎來了解每個人的行為方式。

這是在Spanner和BigQuery中使用的SQL語言內部產生的。在Google中，我們現在擁有一種標準化的單一SQL語言，它具有通用的表示式評估，常見的代數，型別和型別的東西。因此，我們的第一個目標是使用這種通用語言整合Google中使用的所有不同的SQL方言，這就是我們能夠為雲帶來的。

你知道所有語言都是某種意義上的環境的結果。這個人長大了，因為谷歌在內部使用 protocol buffers，這是我們外化的資料格式。因此，很多打字和其他型別的東西都可以與它結合得很好。您會發現型別集更類似於一組型別和協議緩衝區，您可以在BigQuery和Spanner中看到這些型別。但總的來說，我們非常努力地檢視其他引擎，瞭解它們的行為，試圖與當時谷歌中最常用的引擎 - 例如MySQL - 更相容 - 並且真的讓它變得如此沒有任何驚喜。有一些事情，比如對陣列的更自然的支援。

為什麼我們從最終的一致性到強烈的一致性做出了重大轉變？為什麼我們要從無型別資料轉換為型別化資料？SQL在哪裡發揮作用？這些更改是為了給開發人員提供更好的工具。讓他們重新開始工作。我認為我們必須弄清楚如何將基礎設施討論帶到現場位置，並弄清楚如何建立這些環境並使其執行良好。

最終的一致性是否已經死亡
我經過多年思考後得到的比喻，就是你編寫程式碼時經常用最直線寫的程式碼。你的目標是弄清楚如何從A到B.然後你執行該程式碼很多次，你發現一個特定的方法或特定的部分是值得最佳化的。這就是我認為最終一致性所屬的地方，在那種最佳化階段。

如果您有非常具體的用例，則可以實現最終的一致性。

高可用性叢集就是這樣。您可以執行非同步或同步複製，有時它必須是同步的，有時非同步很好。我會在一個資料中心或區域內本地使用同步複製，當跨越區域或地理位置時，使用非同步。

我們構建了一個BigTable，我們沒有事務。那裡有一個分裂和合並協議。我們所有人 - 你知道我們所有的驚人背景 - 可能寫了五次。我們寫了五次，因為無論我們處理這些事務多少次，並且認為我們知道我們在做什麼，實際上仍然會產生錯誤。我們已經完成了所有工作。但是，在Spanner中發生的事情之一是，透過構建一個強大的原語，即事務，然後構建事物，我們構建更復雜的應用程式和更復雜的分散式系統的能力增加了。因此，事務中的強一致性可以成為您產生更多有趣事物的能力的真正倍增。

Spanner不能執行的應用程式？
我們在OLTP和OLAP之間有這種混合，正如你所說，我們仍然在問：是否有一個資料庫可以統治它們？我們就這樣來回走動。我認為從效率的角度來看，純OLAP工作負載在BigQuery這樣的東西上做得更好，BigQuery已經為它們設計了更多功能。你確實看到外部資料庫之類的東西，它們利用一些技巧來混合它們中的兩個。但在谷歌內部，我們已經看到了對於Spanner的全面採用，從大到小，從昂貴到不貴到SQL，再到點查詢。我們已經工作了很長一段時間，填補了不同工作負載中出現的所有差距。

BigTable和Spanner之間的容量，效能，延遲是否存在規模差異？
構建BigTable的人們開始構建Spanner，因此有些部分非常相似。BigTable在支援我與您交談的狀態索引工作負載方面有更長的記錄，因此它對頻譜中的大資料進行了一些最佳化。但在谷歌，隨著Spanner的聚焦在內部使用開發，你知道差距繼續縮小。

Google搜尋引擎是執行在在BigTable和Spanner混合上
或Spanner只是執行搜尋引擎的控制皮膚？ 更大的搜尋引擎是一臺大型機器，我曾經理解，但是現在已經無法理解其中的部分內容。且我認為正確的說法是，今天這臺大機器的很多很多部分都是兩者兼而有之。​​​​​​​