[[207278]]

這是數據庫權威，圖靈獎獲得者 Michael Stonebraker 的一次訪談。 在這篇訪談里，他主要討論了硬件的發展是如何影響的數據庫的。 讀完的感受是私貨不少，有為其新公司 Tamr 打廣告的嫌疑，但是作為數據庫鼻祖，他的一些觀點還是很值得討論和回味的。所以花了幾個小時翻譯出來，以饗讀者。 匆匆翻譯，謬誤肯定不少。歡迎大家在評論里指出。

在20世紀70年代和80年代，加州大學伯克利分校成為軟件技術的溫床的原因之一是 Michael Stonebraker。 他是關系數據庫技術的先驅之一，也是業界最大和最具聲望的行動派之一 也是最連續多產的企業家之一。

和其他數據庫開發者一樣，Stonebraker 也讀了 IBMer Edgar Codd 的早期關系數據模型論文。從1973年開始，在IBM System R 數據庫的基礎上 Stonebraker 開始了 Ingres 數據庫的工作。這項工作最終成了后來的 DB2。 在進入這個領域數年之后，Stonebraker 也開始了 Oracle的同名數據庫開始工作。

在早期數據庫耕耘數十年之后，Stonebreaker 幫助創建了現在常用的Postgres。 Postgres 是 Ingres 下一代產品。 同時， 他也是關系數據庫制造商 Informix 的首席技術官。 Informix 在多年前被 IBM 收購;也最近剛剛被淘汰的數據庫產品。 更重要的是，他是共享數據倉庫的 C-store 的研究人員之一。 這個數據庫最終被商業化為 Vertica。 幾年之后，Stonebraker 和朋友們開始了 H-Store 的工作。 這是一個分布式，基于內存的 OLTP 系統，最終也被商業化為VoltDB。 Stonebraker 從來沒有一個人靜靜坐著，他一直努力創建一個基于數組名為 SciDB 的的數據庫。 這個數據庫是針對技術應用程序的需求進行了明確優化調整的。 這個數據庫是跟數組相關的，而不是傳統關系模型中的表格。

這是作為麻省理工學院計算機科學的兼職教授的，并一直在數據庫世界里貢獻自己力量的 Stonebraker 的一個非常簡短和過于簡單的歷史。

有了如此多的新的計算，存儲和網絡技術進入該領域以及如今可用的許多不同的數據庫和數據存儲技術，我們認為與 Stonebraker 接觸將是一個好主意，以了解這些可能對未來數據庫的影響。

Timothy Prickett Morgan：在數據和存儲方面，某種程度上，你熟知一切，所以我想要深入了解，了解新的計算和存儲硬件(特別是持久的內存)上市，將如何影響近期和遠期數據庫的。 與現在截然不同的是，讓我們假設DRAM和閃存再次變得更便宜，像3D XPoint這樣的技術在SSD和DIMM形狀因素中都會上市。 這些硬件上的進步使內存更大，更便宜，并且閃存獲得比磁盤驅動器更接近需要被計算的數據。 我們是否需要重新考慮把所有東西都塞進內存的想法嗎? 畢竟新技術開辟了很多可能性。

Michael Stonebraker：問題是不斷變化的存儲結構以及它與數據庫的關系。我們 OLTP 開始吧。在我看來，這是一個主要的內存系統，現在有一大堆新興的公司正在處理這個市場。1 TB 的大小的 OLTP 數據庫是一個非常大的數據庫，但是1 TB 的內存已經不是什么大不了的事情了。所以我認為將 OLTP 完全放在內存中是任何關心性能的人的選擇。如果您不關心性能，估計在手表上運行數據庫也是個不錯選擇。

在數據倉庫領域，所有的驅動力都來自于有著千萬億次計算( petascale) 的數據倉庫。 這個市場也將將無限期地成為一個基于磁盤的市場。業務分析師和數據科學家一直想要將越來越多的數據關聯的想法。存儲與數據倉庫的數據大小的增速遠遠超過磁盤驅動器越來越便宜的速度。

當然，這個反例就是 Facebook 這樣的公司。 如果你公司足夠大，你可能會有不同的策略。 Facebook 一直在 SSD 上一投資了很多錢。SSD是用于存儲熱數據。冷數據將永遠在磁盤上，或者直到一些其他真正便宜的存儲技術。

如果您擁有1 TB 的數據倉庫，那么 Vertica 社區版可以免費使用。低端系統軟件將基本上免費。如果你關心性能，它將在內存中;如果你不關心性能，它將在磁盤上。看看數據倉庫供應商是否投入更多的多層次存儲層次結構是非常有趣的。

TPM：當這些持久化內存技術(如3D XPoint或ReRAM)進入組合時會發生什么?

Michael Stonebraker：我沒有看到這些是威脅力的。因為這些所謂的持久化存儲是不夠快而去取代內存的。而且它們不夠便宜，無法替代磁盤， 也不足以替代閃存。現在還有待觀察：3D XPoint 將會如何快速發展以及多么便宜。

我預見在兩級 store 和三級 stroe 上運行的數據庫，但我懷疑他們將能夠管理四級 store，因為這樣做的話對于軟件工程而言太困難了。但是存儲層次結構將會在存儲層次結構中確定什么樣的內容。主內存將在頂部，磁盤將在底部，我們知道，并將有通用的系統之間的東西。對于 OLTP 系統，將會在主內存，故事結尾，像 VoltDB 和 MemSQL 這樣的公司是主要的內存 SQL 引擎。

對我來說，有趣的是，一旦我們可以訓練足夠的數據科學家去做，商業智能將被數據科學所取代。商業智能是SQL聚合友好的面孔。數據科學是預測分析，回歸，K均值聚類等等，它們都是數組上的線性代數。數據科學如何整合到數據庫系統中是關鍵。

現在，這是蠻荒的西部(美國歷史上的西部拓荒運動)。現在流行的是Spark，但它完全與數據存儲斷開連接。因此，一個選擇是數據科學只是數據庫系統外部的應用程序。

另外一個選擇是基于數組的數據庫系統將變得流行，SciDB，TileDB 和 Rasdaman 是三種這樣的可能性。不清楚數組數據庫的廣泛應用，但是在基因組學中肯定會受到歡迎，這些都是使用數組數據。

除此之外的選擇是，目前的數據倉庫供應商將允許用戶采用數據科學功能。他們已經在 R 中允許用戶定義的功能。尚待觀察 Spark 將會發生什么 – 無論今天如何，明天都會有所不同。所以在數據科學中，這是未開墾的處女地。

TPM：我們討論了不同的技術，以及它們如何插入存儲結構。 但是計算結構呢? 我正在考慮 GPU 加速的數據庫，如 MapD，Kinetica，BlazingDB 和 Sqream。

Michael Stonebraker：這是我更感興趣的事情之一，如果要進行順序掃描或浮點計算，GPU 會非常快速。 GPU 的問題是如果您將所有數據都存儲在 GPU 內存中，那么它們的速度非常快，否則您必須從其他地方加載數據，而加載是瓶頸。在你可以加載到 GPU 內存的小數據上，他們肯定會在低端獲得您想要超高性能的應用程序。數據庫空間的其余部分，還有待觀察 GPU 會如何流行。

對我來說最有趣的是，網絡速度越來越快，CPU 的速度越來越高，內存越來越快。基本上目前所有的多節點數據庫系統都是在網絡瓶頸的前提下設計的。原來，沒有人可以全部利用40 Gb/s 以太網。事實上，在過去五年中，我們已經從1 Gb/s 升級到 40Gb/s 以太網，而同時，雖然8個節點的集群已經變得更快一些，但是幾乎不到40倍，內存也是這樣。所以網絡可能不再是瓶頸了。

TPM：當然沒有100 Gb/s 以太網有魅力，供應商們表示可以提供可在未來一兩年內驅動200 Gb/s 甚至400 Gb/s 的ASICs。

Michael Stonebraker：這意味著每個人必須要都重新考慮他們的基本分區架構，我認為這將是一件大事。

TPM：那個拐點什么時候到呢，多少帶寬就夠了?當您可以執行400 Gb/s 甚至800 Gb/s 的時候，選擇一個的具有300納秒延遲的協議?

Michael Stonebraker：我們來看看 Amazon Web Services 的例子。機架頂部的連接通常為10 Gb/s。圖形為1 GB/s。通過比較，節點之間的交叉點是無限快的。但是網絡那么快，磁盤能這么快的把數據拿出來嗎?如果數據是從磁盤讀取的，每個驅動器是100 MB/s，RAID 配置為十個并行的磁盤才勉強跟上網絡的數獨。所以真正的問題是相對于網絡，存儲有多快。

我的一般懷疑是，網絡進步將至少與存儲系統一樣強大，數據庫系統在這一點上將不會受到網絡的約束，同時也會有一些瓶頸。如果你在做跟數據科學相關的工作，則瓶頸是 CPU。 因為你的工作需要進行奇異值分解，這是相對于查看的單元格數量的三倍運算。如果你正在做傳統的商業智能的工作，那么存儲可能是限制;如果你做OLTP，內存則會成為局限。

使用 OLTP，每秒執行100萬次交易是小事情。這些操作可以在 VoltDB和 MemSQL 等上進行。 Oracle，DB2，MySQL，SQL Server和其他人每秒無法做100萬次事務，這些軟件開銷太大了。

我們在2009年寫了一大堆文章，我們配置了一個開源數據庫系統，并對其進行了詳細的測量，我們假設所有的數據都適合主內存。所以基本上一切都在緩存中。我們想衡量不同數據庫功能的成本。在數量上，管理緩沖池是個大問題。一分鐘你有一個緩沖池，那么你必須從中獲取數據，將其轉換為主內存格式，對其進行操作，然后將其放回來，如果它是一個更新，并找出哪些塊是臟的并保持 LRU 列表和所有這些東西。所以這是大約三分之一的開銷。多線程是開銷的三分之一，數據庫系統有很多關鍵部分和一大堆 CPU，它們都與關鍵部分相沖突，最終只能等待。在 OLTP 世界中編寫日志是15%，你必須講操作前和操作后的東西寫入日志，并將其寫在數據之前。所以也許15%，還有一些額外的開銷，是實際有用的工作。這些商業關系數據庫的開銷在85%到90%之間。

為了擺脫這種開銷，您必須重新構建所有內容，這是基于內存中 OLTP 系統所做的。

TPM：相比之下，數組數據庫的效率如何，而且它們是長期的答案嗎?還是對 OLTP 系統無用?

Michael Stonebraker：絕對不是。我在十年前寫了一篇文章，解釋說，一個的數據庫不會適合所有的使用場景，我的意見在這一點上沒有改變。

事實證明，如果要執行 OLTP，則需要一個基于行的內存存儲，如果要進行數據倉庫，則需要基于磁盤的列存儲。這些是根本不同的事情。而且如果你想做數據科學，你想要一個基于數組的數據模型，而不是一個基于表的數據模型，你想優化回歸和奇異值分解和那些東西。如果你想做文字挖掘，這些都不行。我認為應用程序特定的數據庫系統可能是十幾類問題，就我而言可以看到。

TPM：機器學習的數據存儲怎么樣?對我來說有趣的是，GPU 加速的數據庫提供商都在談論他們將如何最終支持像 TensorFlow 這樣的機器學習框架的本機格式。事實上，TensorFlow 是他們似乎關心的一切。他們想在相同的數據庫平臺上嘗試橋接快速 OLTP 和機器學習。

Michael Stonebraker：所以再說一次。 機器學習是基于數組的計算。 TensorFlow是一個面向數組的平臺，允許您將一組原始數組操作組裝到工作流中。 如果您有一個基于表的系統和一個100萬個100萬個數組，即1萬億個單元格的數組，如果將其存儲為任何關系系統中的表，那么將要存儲三列或每行都包含所有value的一個巨大的blob。 在基于陣列的系統中，你將這些數據存儲為一個陣列，并優化存儲。 無論是讀還是寫，這都是一件大事。 任何在存儲于關系引擎數據都將被轉換為數組，才能在 TensorFlow 或 R 或其他任何使用數組的代碼中運行，而這種轉換是極其昂貴的。

TPM：這種轉換會阻礙多少性能?我認為它是一個必須有一個成本，當你的數據只有關系型或數組型的時候。

Michael Stonebraker：讓我給你兩個不同的答案。如果我們有一個密集的數組，這意味著每個單元都被占用，那么這將是一個昂貴的轉換。如果我們有一個非常稀疏的數組，那么將稀疏數組編碼為一個表就不是一個壞主意。所以它真的取決于細節，它完全取決于應用程序，而不是依賴機器學習框架。

這回到了我之前說的：在一起做數據科學和存儲的時候，這是未開墾的處女地。

TPM：所以你的答案似乎是在數組上的 OLTP 和 SciDB 上使用 VoltDB。你現在完成了嗎

Michael Stonebraker：對于公司來說數據整合似乎是一個更大的弱點，這就是為什么我參與了第三家創于2013年的創業公司 Tamr。

Tamr的客戶之一是通用電氣，通用電氣有75個不同的采購系統，也許更多 – 他們真的不知道他們有多少。 GE的首席財務官總結說，如果這些采購系統可以一起運作，并且與供應商一起要求最受歡迎的國家地位，那么該公司每年將節省約10億美元的。但他們必須整合75個獨立構建的供應商數據庫。

TPM：使用像 Tamr 這樣的工具的推測是，將不同的東西整合起來比試圖將其全部轉換成一個巨大的數據庫并重寫應用程序或至少選擇一個應用程序要容易得多。

Michael Stonebraker：完全正確。企業由于分為業務單位，因此可以完成業務，并將孤島整合為交叉銷售或總體購買或社交網絡，甚至獲得客戶的單一視圖，是巨大的負擔。