这是数据库权威，图灵奖获得者 Michael Stonebraker 的一次访谈。 在这篇访谈里，他主要讨论了硬件的发展是如何影响的数据库的。 读完的感受是私货不少，有为其新公司 Tamr 打广告的嫌疑，但是作为数据库鼻祖，他的一些观点还是很值得讨论和回味的。所以花了几个小时翻译出来，以飨读者。 匆匆翻译，谬误肯定不少。欢迎大家在评论里指出。
在20世纪70年代和80年代，加州大学伯克利分校成为软件技术的温床的原因之一是 Michael Stonebraker。 他是关系数据库技术的先驱之一，也是业界最大和最具声望的行动派之一 也是最连续多产的企业家之一。
和其他数据库开发者一样，Stonebraker 也读了 IBMer Edgar Codd 的早期关系数据模型论文。从1973年开始，在IBM System R 数据库的基础上 Stonebraker 开始了 Ingres 数据库的工作。这项工作最终成了后来的 DB2。 在进入这个领域数年之后，Stonebraker 也开始了 Oracle的同名数据库开始工作。
在早期数据库耕耘数十年之后，Stonebreaker 帮助创建了现在常用的Postgres。 Postgres 是 Ingres 下一代产品。 同时， 他也是关系数据库制造商 Informix 的首席技术官。 Informix 在多年前被 IBM 收购;也最近刚刚被淘汰的数据库产品。 更重要的是，他是共享数据仓库的 C-store 的研究人员之一。 这个数据库最终被商业化为 Vertica。 几年之后，Stonebraker 和朋友们开始了 H-Store 的工作。 这是一个分布式，基于内存的 OLTP 系统，最终也被商业化为VoltDB。 Stonebraker 从来没有一个人静静坐着，他一直努力创建一个基于数组名为 SciDB 的的数据库。 这个数据库是针对技术应用程序的需求进行了明确优化调整的。 这个数据库是跟数组相关的，而不是传统关系模型中的表格。
这是作为麻省理工学院计算机科学的兼职教授的，并一直在数据库世界里贡献自己力量的 Stonebraker 的一个非常简短和过于简单的历史。
有了如此多的新的计算，存储和网络技术进入该领域以及如今可用的许多不同的数据库和数据存储技术，我们认为与 Stonebraker 接触将是一个好主意，以了解这些可能对未来数据库的影响。
Timothy Prickett Morgan：在数据和存储方面，某种程度上，你熟知一切，所以我想要深入了解，了解新的计算和存储硬件(特别是持久的内存)上市，将如何影响近期和远期数据库的。 与现在截然不同的是，让我们假设DRAM和闪存再次变得更便宜，像3D XPoint这样的技术在SSD和DIMM形状因素中都会上市。 这些硬件上的进步使内存更大，更便宜，并且闪存获得比磁盘驱动器更接近需要被计算的数据。 我们是否需要重新考虑把所有东西都塞进内存的想法吗? 毕竟新技术开辟了很多可能性。
Michael Stonebraker：问题是不断变化的存储结构以及它与数据库的关系。我们 OLTP 开始吧。在我看来，这是一个主要的内存系统，现在有一大堆新兴的公司正在处理这个市场。1 TB 的大小的 OLTP 数据库是一个非常大的数据库，但是1 TB 的内存已经不是什么大不了的事情了。所以我认为将 OLTP 完全放在内存中是任何关心性能的人的选择。如果您不关心性能，估计在手表上运行数据库也是个不错选择。
在数据仓库领域，所有的驱动力都来自于有着千万亿次计算( petascale) 的数据仓库。 这个市场也将将无限期地成为一个基于磁盘的市场。业务分析师和数据科学家一直想要将越来越多的数据关联的想法。存储与数据仓库的数据大小的增速远远超过磁盘驱动器越来越便宜的速度。
当然，这个反例就是 Facebook 这样的公司。 如果你公司足够大，你可能会有不同的策略。 Facebook 一直在 SSD 上一投资了很多钱。SSD是用于存储热数据。冷数据将永远在磁盘上，或者直到一些其他真正便宜的存储技术。
如果您拥有1 TB 的数据仓库，那么 Vertica 社区版可以免费使用。低端系统软件将基本上免费。如果你关心性能，它将在内存中;如果你不关心性能，它将在磁盘上。看看数据仓库供应商是否投入更多的多层次存储层次结构是非常有趣的。
TPM：当这些持久化内存技术(如3D XPoint或ReRAM)进入组合时会发生什么?
Michael Stonebraker：我没有看到这些是威胁力的。因为这些所谓的持久化存储是不够快而去取代内存的。而且它们不够便宜，无法替代磁盘， 也不足以替代闪存。现在还有待观察：3D XPoint 将会如何快速发展以及多么便宜。
我预见在两级 store 和三级 stroe 上运行的数据库，但我怀疑他们将能够管理四级 store，因为这样做的话对于软件工程而言太困难了。但是存储层次结构将会在存储层次结构中确定什么样的内容。主内存将在顶部，磁盘将在底部，我们知道，并将有通用的系统之间的东西。对于 OLTP 系统，将会在主内存，故事结尾，像 VoltDB 和 MemSQL 这样的公司是主要的内存 SQL 引擎。
对我来说，有趣的是，一旦我们可以训练足够的数据科学家去做，商业智能将被数据科学所取代。商业智能是SQL聚合友好的面孔。数据科学是预测分析，回归，K均值聚类等等，它们都是数组上的线性代数。数据科学如何整合到数据库系统中是关键。
现在，这是蛮荒的西部(美国历史上的西部拓荒运动)。现在流行的是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：完全正确。企业由于分为业务单位，因此可以完成业务，并将孤岛整合为交叉销售或总体购买或社交网络，甚至获得客户的单一视图，是巨大的负担。
