FPGA洗牌關係資料庫市場

暫且說你是一名系統架構師，想讓應用程序背後的資料庫運行起來快得多。有好多不同的方法可以做到這點；現在又多了另一種方法，這種方法可能更具顛覆性。

你可以將資料庫存儲的內容從磁碟驅動器移到快閃記憶體存儲器，可以從基於行的資料庫改成對數據分段、並加快數據訪問速度的列式資料庫。而為了進一步提升性能，你可以將該列式數據移到主存儲器，以存儲器的速度、而不是以磁碟或快閃記憶體的速度來讀取和處理數據。

所有的內存資料庫（in-memory database）都採用後一種方法，微軟的「Hekaton」版本的SQL Server、Oracle的12c資料庫、IBM針對DB2的BLU Acceleration附件以及SAP的HANA資料庫是市面上幾種主流的商業內存資料庫。（可以說Spark為Hadoop分析集群做同樣的事情，但是嚴格來說，Spark/Hadoop架構並不是關係資料庫，即便藉助一些覆蓋系統，可以教Spark/Hadoop架構支持SQL的語言，運行起來像有著諸多限制、速度又很慢的關係資料庫。）

你可以對資料庫表進行分片（shard）處理，並在機器集群上並行運行查詢；這令人討厭，卻又是長期以來唯一合理的方法。

你可以改用好多NewSQL資料庫和NoSQL資料庫，這類資料庫犧牲了關係資料庫擁有的部分屬性（尤其是數據一致性方面的屬性），以換取速度和規模。

你可以改用其中一種新型的GPU加速的資料庫，比如MapD或Kinetica。

或者，還可以將FPGA插入到伺服器節點，裝入來自初創公司Swarm64的資料庫加速層，不用告訴任何人你如何讓MySQL、MariaDB或PostgreSQL運行起來速度快一個數量級，而且能夠在規模大一個數量級的資料庫上做到這一點。如果你等一下，如果足夠的客戶要求這樣，Swarm64甚至可以支持Oracle資料庫加速，將來甚至還有這種可能性（前提是有足夠的客戶需求）：將FPGA加速機制應用於微軟的SQL Server，並沒有Hekaton內存處理功能帶來的任何局限性。

在運行Swarm64的系統上，響應時間、資料庫大小和數據獲取速度有望提高10倍，這勢必會引起資料庫應用系統受制於底層資料庫引擎的性能的任何人的注意。而事實上，可以對眾多企業使用的流行的關係資料庫透明地做到這一點，這意味著Swarm64有機會在伺服器市場由資料庫驅動的這個領域帶來極大的顛覆。

這在一方面有助於解釋為什麼英特爾早在2015年6月斥資167億美元收購FPGA製造商Altera，以及為什麼英特爾熱衷於開發CPU-FPGA混合計算引擎，先是研製單個封裝件上整合15個核心的「Broadwell」至強和Arria 10 FPGA的套件，最終將來擁有這樣的至強晶元：FPGA與至強核心蝕刻到同一塊裸片（die）上。使用Swarm64加速關係資料庫會給伺服器的出貨量帶來巨大的影響。

這是Swarm64的首席執行官卡斯滕·羅納（Karsten R?nner）對這個市場的認識和解讀。從他手頭的2015年數據來看，全球每年使用的伺服器大約是1200萬台。其中大約四分之一（即300萬台伺服器）用來運行關係資料庫和數據倉庫軟體，進行事務處理和分析任務；假設這些工作負載中大約一半是對延遲敏感、性能受限制的，那就相當於150萬台資料庫伺服器可以由FPGA來加速。如果該公司可以藉助其FPGA加速技術，將性能和資料庫大小提升10倍，那麼這可能意味著英特爾最終賣不出去大量的至強處理器。

正如我們之前所說，英特爾肯定非常害怕某種技術，要不然不會出大價錢收購Altera，英特爾想抄捷徑。這肯定是這宗收購的一方面原因，英特爾顯然想要掌控這個未來，而不是被它掌控。

Swarm64在挪威奧斯陸和德國柏林設有兩個總部，2012年由艾文德·利蘭（Eivind Liland）、托馬斯·里克特（Thomas Richter）和阿方索·馬丁內斯（Alfonso Martinez）共同創辦。這家公司通過兩輪風險融資活動，已融資870萬美元，擁有19名員工，現正在大力宣稱：它與英特爾合作，將其可擴展數據加速器（Scalable Data Accelerator）推向更廣闊的市場。Swarm64架構並不與Altera FPGA綁在一起，可以在搭載賽靈思（Xilinx）FPGA的系統上運行，但如果你試圖把至強計算技術換成FPGA加速技術，要是英特爾站在你這邊，顯然是有利條件，而不是不利條件。

領先超大規模公司

羅納告訴The Next Platform：「使用FPGA或GPU加速資料庫面臨的挑戰是，需要藉助分析引擎塞入足夠多的數據，以便擁有儘可能高的帶寬。對於外設卡上的FPGA加速而言，這顯然局限於PCI-Express匯流排速度，這是一個限制因素。這方面的另一個要素是，儘可能少接觸數據，因為接觸數據越多，所需的帶寬就越高。」

Swarm64可擴展資料庫加速器的幾種使用場合

當然，這是列式資料庫的指導原則之一，但是Swarm64並不是列式資料庫。相反，它是一種高度壓縮的資料庫，將活動數據保留在處理器的主存儲器中，將已提交的數據保留在快閃記憶體存儲器上。Lempel-Ziv（LZ）無損數據壓縮方法用來壓縮和展開該數據，它用VHDL語言實施在FPGA上，以獲得很高的帶寬和很快的速度。FPGA還用於加速MySQL、MariaDB和PostgreSQL資料庫中所用的底層存儲引擎的功能，這就是Swarm64架構的致勝法寶。

羅納表示，說到使用FPGA實現資料庫加速，目前有兩條思路。第一條思路是，用FPGA的VHDL語言翻譯/轉換SQL查詢，人們已經這麼做了。但是這種方法存在諸多問題，尤其是：一旦你實施該方法，就無法更改查詢或資料庫管理系統，而且實施起來很費時間。另一條思路就是，在FPGA上處理SQL查詢的一部分任務，包括過濾和SQL查詢預處理，因而為CPU減輕了負載，但同時也縮減了用於將數據轉移到CPU來處理的有效帶寬。Swarm64存儲引擎不是列式存儲庫，而是擁有無索引結構的行式存儲庫，但是它像列式存儲庫那樣只能處理數據的必要部分。由於沒有索引，這大大減少了元數據以及與關係資料庫有關的其他開銷，並且在數據進入時，讓用戶可以近實時獲取和處理數據。Swarm64確實將數據存儲在自己的表中，它們使用的格式與MySQL、MariaDB和PostgreSQL生成的索引表顯然不一樣。

在過去的兩年間，這家公司一直在兜售自己的FPGA卡（基於Altera的晶元），而現在，它與英特爾達成合作夥伴關係，銷售基於英特爾生產的最新Arria 10 FPGA和板卡的硬體架構，不僅有條件使用英特爾推出的功能較強大的Stratix 10 FPGA，還有條件使用今年晚些時候推出的CPU-FPGA混合引擎。Swarm64的當前架構將單塊Arria 10 FPGA卡放在雙插座至強伺服器中。

Swarm64資料庫存儲引擎的壓縮和無索引特性讓資料庫表得以被壓縮到64 TB大小；僅僅直觀地比較一下，擁有同樣數據的「實際」MySQL、MariaDB或PostgreSQL資料庫將佔用640 TB的空間。那是眼下支持的最大的資料庫規模，考慮到在實際企業環境中move資料庫大小是數十GB或數十TB左右，這足以滿足大多數使用場合的需要。據羅納聲稱，這個640 TB有效容量限額可滿足全球使用的95%的定址資料庫的需要。

為了擴展Swarm64資料庫存儲引擎的性能，客戶可以將多個FPGA或更強大的FPGA放入到節點，如果他們需要橫向擴展，可以對資料庫進行分片處理（大企業和超大規模公司常常這麼做），進一步提升吞吐量。（當然，這種分片操作並不有助於縮短延遲）。羅納表示，在將來，Swarm64會實施一種更先進的橫向擴展方法，它擁有更緊密的耦合機制，不需要對數據進行分片。而在這之前，客戶可以從一個插座擴展到兩個插座、四個乃至八個，主存儲器空間越大，可容納的資料庫表就越大。

在證明Swarm64引擎性能的一項測試中，該公司使用網路監控數據流，測試了獲取數據的速度有多快。它拿來一台配備256 GB主存儲器和幾個閃驅的雙插座至強伺服器，將一半的計算和存儲器分配給了MariaDB資料庫。使用默認的存儲引擎，這個半節點能夠以每秒約10萬個數據包的速度，獲取和查詢從生成遙測數據的網路設備流入的數據；改用Swarm64引擎提升了處理該工作負載的性能，對應用軟體或MariaDB資料庫管理系統沒有進行任何改動，提升到每秒114萬個數據包。IBM幾年前收購的FPGA加速的Netezza設備與之形成了對比，該設備基於PostgreSQL的專有實施方法，很難跟得上開源PostgreSQL發展的步伐。你還可以購買配備12個、16個或32個插座的大型NUMA機器，並將數量與插座一樣多的FPGA裝入到機器，構建一個可近乎線性擴展的大規模加速資料庫。

Swarm64對於其軟體架構收取每個FPGA每月1000美元的許可費；讓Swarm64可以與FPGA和資料庫對話的Linux驅動程序最終將開源，所以從理論上來說，你可以自行搭建、自行支持。不管怎樣，你都要購買自己的硬體，包括FPGA加速器；雖說FPGA不便宜，但是現代平衡系統中沒有哪個主要部件比主存儲器來得昂貴。而為IT員工隊伍增添了解資料庫分片或內存資料庫、將應用程序移植到這些系統上的專家，也需要不菲的成本。羅納認為，就性能單位而言，SAP HANA等內存資料庫的成本比使用其軟體和FPGA的伺服器要高十倍；此外，內存資料庫的容量限制在兩位數TB，而Swarm64能擴展到客戶想要的龐大容量，當然前提是客戶願意容忍分片，或願意掏錢購買龐大的NUMA系統。試想由一組龐大NUMA機器組成的集群――這些機器可能類似惠普企業（HPE）的32插座SGI UV 300機器，每個NUMA機器搭載64 TB的物理存儲器和640 TB的有效容量，各自運行Swarm64引擎。整齊劃一的16個節點就能獲得有效容量超過1 PB的龐大資料庫。

在某個時候，Swarm64能夠充分利用Optane 3D XPoint SSD和存儲棒，真正擴展一個節點或節點集群的有效容量，現正在與英特爾商討如何最有效地實現這一點。

該公司的路線圖還要求Swarm64資料庫存儲引擎使用相當於Oracle的Data Cartidge的機制，為Oracle資料庫提供支持，這將意味著許多客戶不需要求助於12c內存處理功能：這項功能的成本為每個核心23000美元，相比之下，Oracle 12c企業版資料庫的收費標準是每個核心47500美元。對於使用Oracle資料庫的公司來說，這有望大幅節省成本。與之相仿，據說微軟為SQL Server使用一種非常類似存儲引擎的機制；羅納認為，若能得到微軟的一點幫助，它只要三四個月的時間就可以將Swarm64添加到該機制中。

如果這一切都能如願以償，那麼按照核心對資料庫許可證收費的那些商家會看到收入下滑，就像英特爾看到至強處理器的收入下滑、伺服器廠商看到伺服器收入下滑那樣。但是英特爾會通過FPGA銷售額來至少抵消部分損失。

所有這一切都提出了這個問題：既然超大規模公司那麼聰明，為何它們在往快閃記憶體、分片和NoSQL投入大量的財力和精力之前不對存儲引擎實行FPGA加速？它們肯定確實喜歡擁有整體式的X86 CPU架構，但是隨著Swarm64驅動程序開源，可能向各大超大規模廠商開放代碼，Swarm64也許能夠在市場高端達成一些大宗交易，而不僅僅是它瞄準的企業數據中心。暫且不說別的，這起碼證明這行得通；如果這個想法（FPGA加速）流行起來，超大規模公司可能會完全自行發明FPGA加速。它們往往這麼做，即使它們經常重新發明輪子。

雲頭條編譯、未經授權謝絕轉載

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！