作者：zhexuany

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

在20世紀(jì)70年代和80年代，加州大學(xué)伯克利分校成為軟件技術(shù)的溫床的原因之一是 Michael Stonebraker。 他是關(guān)系數(shù)據(jù)庫技術(shù)的先驅(qū)之一，也是業(yè)界最大和最具聲望的行動派之一 也是最連續(xù)多產(chǎn)的企業(yè)家之一。

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

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

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

有了如此多的新的計算，存儲和網(wǎng)絡(luò)技術(shù)進(jìn)入該領(lǐng)域以及如今可用的許多不同的數(shù)據(jù)庫和數(shù)據(jù)存儲技術(shù)，我們認(rèn)為與 Stonebraker 接觸將是一個好主意，以了解這些可能對未來數(shù)據(jù)庫的影響。

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

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

在數(shù)據(jù)倉庫領(lǐng)域，所有的驅(qū)動力都來自于有著千萬億次計算( petascale) 的數(shù)據(jù)倉庫。 這個市場也將將無限期地成為一個基于磁盤的市場。業(yè)務(wù)分析師和數(shù)據(jù)科學(xué)家一直想要將越來越多的數(shù)據(jù)關(guān)聯(lián)的想法。存儲與數(shù)據(jù)倉庫的數(shù)據(jù)大小的增速遠(yuǎn)遠(yuǎn)超過磁盤驅(qū)動器越來越便宜的速度。

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

如果您擁有1 TB 的數(shù)據(jù)倉庫，那么 Vertica 社區(qū)版可以免費使用。低端系統(tǒng)軟件將基本上免費。如果你關(guān)心性能，它將在內(nèi)存中；如果你不關(guān)心性能，它將在磁盤上?？纯磾?shù)據(jù)倉庫供應(yīng)商是否投入更多的多層次存儲層次結(jié)構(gòu)是非常有趣的。

TPM：當(dāng)這些持久化內(nèi)存技術(shù)（如3D XPoint或ReRAM）進(jìn)入組合時會發(fā)生什么？

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

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

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

現(xiàn)在，這是蠻荒的西部（美國歷史上的西部拓荒運動）?，F(xiàn)在流行的是Spark，但它完全與數(shù)據(jù)存儲斷開連接。因此，一個選擇是數(shù)據(jù)科學(xué)只是數(shù)據(jù)庫系統(tǒng)外部的應(yīng)用程序。

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

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

TPM：我們討論了不同的技術(shù)，以及它們?nèi)绾尾迦氪鎯Y(jié)構(gòu)。 但是計算結(jié)構(gòu)呢？ 我正在考慮 GPU 加速的數(shù)據(jù)庫，如 MapD，Kinetica，BlazingDB 和 Sqream。

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

對我來說最有趣的是，網(wǎng)絡(luò)速度越來越快，CPU 的速度越來越高，內(nèi)存越來越快?；旧夏壳八械亩喙?jié)點數(shù)據(jù)庫系統(tǒng)都是在網(wǎng)絡(luò)瓶頸的前提下設(shè)計的。原來，沒有人可以全部利用40 Gb/s 以太網(wǎng)。事實上，在過去五年中，我們已經(jīng)從1 Gb/s 升級到 40Gb/s 以太網(wǎng)，而同時，雖然8個節(jié)點的集群已經(jīng)變得更快一些，但是幾乎不到40倍，內(nèi)存也是這樣。所以網(wǎng)絡(luò)可能不再是瓶頸了。

TPM：當(dāng)然沒有100 Gb/s 以太網(wǎng)有魅力，供應(yīng)商們表示可以提供可在未來一兩年內(nèi)驅(qū)動200 Gb/s 甚至400 Gb/s 的ASICs。

Michael Stonebraker：這意味著每個人必須要都重新考慮他們的基本分區(qū)架構(gòu)，我認(rèn)為這將是一件大事。

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

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

我的一般懷疑是，網(wǎng)絡(luò)進(jìn)步將至少與存儲系統(tǒng)一樣強(qiáng)大，數(shù)據(jù)庫系統(tǒng)在這一點上將不會受到網(wǎng)絡(luò)的約束，同時也會有一些瓶頸。如果你在做跟數(shù)據(jù)科學(xué)相關(guān)的工作，則瓶頸是 CPU。 因為你的工作需要進(jìn)行奇異值分解，這是相對于查看的單元格數(shù)量的三倍運算。如果你正在做傳統(tǒng)的商業(yè)智能的工作，那么存儲可能是限制；如果你做OLTP，內(nèi)存則會成為局限。

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

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

為了擺脫這種開銷，您必須重新構(gòu)建所有內(nèi)容，這是基于內(nèi)存中 OLTP 系統(tǒng)所做的。

TPM：相比之下，數(shù)組數(shù)據(jù)庫的效率如何，而且它們是長期的答案嗎？還是對 OLTP 系統(tǒng)無用？

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

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

TPM：機(jī)器學(xué)習(xí)的數(shù)據(jù)存儲怎么樣？對我來說有趣的是，GPU 加速的數(shù)據(jù)庫提供商都在談?wù)撍麄儗⑷绾巫罱K支持像 TensorFlow 這樣的機(jī)器學(xué)習(xí)框架的本機(jī)格式。事實上，TensorFlow 是他們似乎關(guān)心的一切。他們想在相同的數(shù)據(jù)庫平臺上嘗試橋接快速 OLTP 和機(jī)器學(xué)習(xí)。

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

TPM：這種轉(zhuǎn)換會阻礙多少性能？我認(rèn)為它是一個必須有一個成本，當(dāng)你的數(shù)據(jù)只有關(guān)系型或數(shù)組型的時候。

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

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

TPM：所以你的答案似乎是在數(shù)組上的 OLTP 和 SciDB 上使用 VoltDB。你現(xiàn)在完成了嗎

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

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

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

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

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。