硬件是如何影響數(shù)據(jù)庫(kù)的發(fā)展

作者：zhexuany

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Michael Stonebraker：絕對(duì)不是。我在十年前寫(xiě)了一篇文章，解釋說(shuō)，一個(gè)的數(shù)據(jù)庫(kù)不會(huì)適合所有的使用場(chǎng)景，我的意見(jiàn)在這一點(diǎn)上沒(méi)有改變。

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

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

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

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

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

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

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

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

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

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

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

生成海報(bào)

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