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加速。它们往往这么做，即使它们经常重新发明轮子。

云头条编译、未经授权谢绝转载

相关阅读：