硬件是如何影响数据库的发展

现在，这是蛮荒的西部(美国历史上的西部拓荒运动)。现在流行的是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：完全正确。企业由于分为业务单位，因此可以完成业务，并将孤岛整合为交叉销售或总体购买或社交网络，甚至获得客户的单一视图，是巨大的负担。