本文是 StoneDB 学术分享会专栏的第五篇，我们来分享一下 HTAP 学术界上比较经典的一篇论文《A Common Database Approach for OLTP and OLAP Using an In-Memory Column DataBase》。

为什么说这篇论文经典呢，因为这篇论文来自国际著名厂商，号称欧洲最大的软件公司 SAP（思爱普，截止发稿市值为 1283.17 亿美元）的创始人 Hasso Plattner（哈索·普拉特纳）教授，该文作为 Keynote 在 2009 年的数据库国际顶会 SIGMOD 上正式发布，可以说，这篇把 Michael Stonebraker 都气到变脸的论文一经发表，就此掀开了 HTAP 数据库的历史序幕，也催生了后来都能和 Oracle 抢大笔生意的数据库 SAP HANA。

HANA，全称是 High Performance Analytic Appliance，是第一个全面支持 ACID 的事务型列式存储（Colunm-Store）数据库（不要觉得很简单哦，列式数据库做到这样很难的，StoneDB 的研发们都深知其中的坑有多深:D），也是第一个做 HTAP 的内存型（In-Memory）数据库。接下来，就让我们来一起学习一下这篇经典论文吧。

StoneDB 开源地址：https://github.com/stoneatom/stonedb

翻译｜王学姣

编辑｜宇亭

审校｜李浩、宇亭

A Common Database Approach for OLTP and OLAP Using In-Memory Column Database

《通过内存型行式存储数据库实现 OLTP 和 OLAP 的一种通用方式》

作者：Hasso Plattner

一、简介

二十多年以来，关系型数据库系统一直是商业应用的支柱。我们曾许诺为企业提供涵盖所有核心应用的管理信息系统，包括财务、销售、订单履行、制造以及人力资源，从规划到业务流程再到个性化分析。然而，我们并没有实现这一目标。当业务需求变得越来越复杂，我们就越关注所谓的事务处理部分，并相应地设计数据库结构。这类系统被称为联机事务处理系统（Online Transactional Processing，OLTP）。而出于灵活性和性能考虑，分析和财务规划类应用开始逐渐则开始更多地移到单独的系统中。这类系统被称为联机分析处理系统（Online Analytical Processing，OLAP）。实际上，部分规划流程甚至被转移到了主要围绕电子表格的专用软件上。

OLTP 和 OLAP 这两类系统都基于关系理论，只是使用了不同的技术手段^[13]。在 OLTP 系统中，元组（tuple）按行组织，行存储在块（block）中，而块存储在磁盘上也同时缓存在数据库服务器的主内存（main memory）中。我们可以通过复杂的索引来实现快速访问单个元组。但是，随着请求的元组数量的增加，访问速度将会变得越来越慢。相比之下，OLAP 系统中的数据以 Star Schema 组织。在这种结构下，可以借助字典实现对属性（列）的压缩。

在将属性转换为整数后，处理速度得到了提升。最近一段时间，用列式存储数据库来处理分析查询变得流行起来。在列式存储中实现的数据库级的字典压缩和只读取处理查询所必需的列显著地加快了查询处理。

在我看来，数据仓库的引入是一种妥协。在使用数据仓库获得灵活性和速度的同时，必须付出额外的成本用于提取和加载数据以及控制冗余。许多年来，这种讨论似乎已经结束，企业数据被拆分成 OLTP 和 OLAP 两部分^[9]。OLTP 是 OLAP 的必要先决条件，但是公司想要了解自身的业务，并得出如何为公司制定正确的路线，在何时需要改变路线的结论，则必须依靠 OLAP。当计划数据和实际数据匹配时，业务就会变得透明，并且可以作为决策制定的依据。虽然集中式仓库也能集成各种来源的数据，但是市场仍然希望能有这么一个系统可以同时提供 OLTP 和 OLAP 能力，从而使得 OLTP 和 OLAP 能为用户提供更大的价值。

在过去的 20 年里，摩尔定律使我们能够让企业系统同时在功能和容量上实现增长^[16]。当处理器时钟速度在 2002 年达到 3 GHz 水平之后，进一步的发展似乎变得遥不可及。然而，两项技术突破打破了这一困局：主内存实现了前所未有的增长；通过刀片计算和多核 CPU 实现的大规模并行处理^[14]。虽然主内存在缓存等场景中总是非常受欢迎且应用服务器支持大量的 CPU，大规模并行处理却并不是 OLTP 数据库系统的理想应用场景，OLTP 数据库系统仍然运行在对称多处理（Symmetric Multi Processing，SMP）服务器上。这样做是因为在并行事务中更新多个表时会造成被更新的数据存储段（Data Storage Segment）临时上锁并且有可能引发死锁。这就是为什么像 SAP 的 R/3 在一个线程中运行所有更新事务，并且严重依赖行锁和 SMP 机器上并行数据库进程之间的超快速通信的主要原因。这些缺点中的一部分可以通过更好的应用设计来克服，并没有对 OLTP 和 OLAP 的分离形成挑战。

根据 SAP 和 HPI 对行存关系型内存数据库进行的早期测试结果，也无法得出行存内存数据库比拥有同等缓存内存的领先 RDBMS 有明显优势的结论。基于上述背景，我们产生了另外一种想法来研究列存数据库用于 OLTP 的优势。列式存储已经在 OLAP 领域成功使用了多年。在主内存变得充裕后，实现了爆发性增长^[20，5]。

我们从两年半前便在 HPI 开始分析在内存型列存数据库上执行 OLTP 操作是否可行。这也成为了许多学士、硕士和博士项目的主题。在接下来的内容中，我想讨论一下我们的发现。一些部分会对当前的普遍观点发起挑战，其他部分在讨论未来发展的选择。

二、列式存储最适合现代 CPU

具有多核架构的现代 CPU 提供了巨大的计算能力。下一代刀片服务器（编者注：刀片服务器是指在标准高度的机架式机箱内可插装多个卡式的服务器单元，是一种实现 HAHD(High Availability High Density，高可用高密度)的低成本服务器平台，为特殊应用行业和高密度计算环境专门设计。刀片服务器就像“刀片”一样，每一块“刀片”实际上就是一块系统主板。）单个刀片将拥有 8 个 16 核 CPU。这意味着单个刀片可以提供 128 个计算单元，近 500 GB 的主内存。为了优化这些计算设备的使用，我们必须了解内存层次结构（memory hierarchy）、缓存大小以及如何在一个程序中实现并行处理^[6]。我们首先讨论下内存。企业应用在很大程度上受限于内存，这意味着程序执行时长与读写操作所访问的内存量或移动的内存量的变化成比例变化。

例如，我们比较了 SAP 的会计文档行项目表的全表扫描以便计算所有元组的总值。该表有 160 个属性。我们对其中一家德国啤酒厂 5 年的会计数据进行了实验，这个表中的元组数量为 3400 万。在底层行存数据库中，该表每 100 万个元组的空间占用量大约为 1 GB。

因此，该表的大小为 35 GB。而在列存数据库中，该表所占用的存储空间仅为 8 GB，因为列式存储可以对列进行更高效的压缩。如果我们考虑到在实际应用中，一个 SQL 语句中通常只用得到一个表中的 1/10 的属性（见图 1），这意味着对于列式存储来说，最多只需要读取 800 MB 的数据就可以生成最终的查询结果^[1]。图 2（仅为示意图）显示，在面向集合（Set）的针对列的操作处理上，使用水平压缩的行式存储完全无法与列式存储匹敌。即使有合适的索引，行式存储需要访问的数据量也要比列式存储高出几个数量级。

图 1：查询和 Schema 示例

图 2：列式存储和行式存储中的数据访问

根据我们对有客户数据的真实系统的分析，企业计算中的大多数应用实际上是以集合为单位的处理而不是单个元组访问的。因此，将数据放在列式存储中的好处非常明显。除此之外，我们可以基于行（row level）使用压缩的整数格式执行大多数计算。我们在这里看到，与在应用级别对非压缩数据格式执行的相同计算相比，性能提高了 100 到 1000 倍。应用层必须在本地 SQL 语句中使用最少的预测，并避免在子例程中使用更通用的 SQL 语句来支撑对内存访问的减少。

除了这些好处，并行处理的引入也功不可没。根据 Hennessy 的说法，创建并行处理程序的难点在于如何将一个程序分解成大小相等的片段并通过少量同步对这些片段进行并行处理^[12]。而单列或者多列扫描恰恰就是我们所寻求的解决方案。这种扫描操作可以轻易地被等分为多个部分并分配给多个内核。OLAP 引擎的标准操作和计算到期日、货币兑换、给定日期间隔的工作日等常规应用逻辑，例如，可以由存储过程对压缩列的整数值进行操作来处理。

元组之间完全彼此独立，所以元组级的所有计算都将自动并行处理。并且系统会对每一个符合条件的元组同步执行第一层级的聚合。核心进程之间的同步是最小的。沿着给定的层次结构（Hierarchy）进行的进一步聚合则是数据积累的第二步。这同样适用于按属性排序或按时间排序。

即使只有少数元组匹配选择谓词，也没有必要引入索引，因为扫描的速度非常快，尤其是在多核并行处理活跃的情况下。在当前的 CPU 上，预计每毫秒可以处理 1 MB 数据，而在 16 核 CPU 上每毫秒并行处理的数据量可超过 10 MB。据此我们可以判断，寻找压缩在 4 个字节中的某单个维度，我们可以在 1 毫秒内扫描 250 万个元组进行匹配。既然有了这个速度，我们甚至不再为大多数表提供主键索引，取而代之的是全列扫描。现代 CPU 可以使用所有关系代数，而不会有性能上的缺点。列式存储非常适合现代 CPU。值得注意的是，现在每个属性都代表一个潜在的索引。对于应用而言，则不再受限于预定义的导航路径进行数据选择了。将大部分计算委托给数据库层减轻了应用层的计算压力，使应用层工作更加聚焦。这有利于开发出更高质量的程序，并为持续开发提供了更优的生命周期。硬盘仅存储用于快速恢复的事务日志和快照。事实上，磁盘和磁带一样，早已成为明日黄花^[11]。

三、我们的主张：列式存储适合于更新密集型应用

很多人认为列式存储处理更新操作的成本很高^[8]。虽然将所有数据放在主内存中可以极大地提高列式存储的更新性能，我们仍然必须考虑属性字典的潜在扩展性，这可能会导致压缩需要重新计算，从而对整个列造成影响。因此，我们对金融系统中的更新进行了更为详尽的分析（如图 3 所示）。

图 3：金融系统的 Schema （现状）

3.1 SAP 数据库表设计的历史

乍一看，这么大量的物化视图和物化聚合（Materialized Aggregate）可能令人吃惊。但是这种冗余对于在可接受响应时间内显示行项目和账户总数是非常必要的。实现这种冗余会引入更多的插入和有问题的冗余数据更新（使用数据库触发器或过程代码造成的）。不过这些代价都是必要的。在系统的 OLAP 部分，由客户定义的 Cube 组合允许以合理的响应时间进行灵活的报告，但增加了复杂性和额外的系统管理开销。

3.2 客户数据分析

在分析 4 个不同的 SAP 客户的变更日志时，我们发现更新主要可以分为以下三种：

• 聚合更新（Aggregate Update）：属性被视作物化视图一部分的累积值（每个会计行项目在 1 到 5 之间）。

• 状态更新（Status Update）：状态变量的二进制变化，通常带有时间戳。

• 值更新（Value Update）：属性的值通过替换而改变。

3.2.1 聚合更新

大多数聚合更新发生在那些应用于遵循编码快结构的总记录的金融应用中。编码块包含账号、法律组织、年份等信息。这些总记录基本上是日志条目的物化视图，以便在请求聚合时加速响应。由于引入基于列式存储的数据仓库^[18]（例如，SAP Business Warehouse Explorer）后，多维 Cube 的汇总不在符合当下需求，因此我们分析了是否可以通过算法创建聚合，并始终保持动态。请求的聚合实例越多，列式存储的相对性能就越好（见图 4）。聚合的创建与全列扫描相对应，因此响应集（Response Set）中的聚合数量对响应时间几乎没有影响。在行式存储中，响应时间随着读取的聚合数量线性增加。

图 4：即时聚合 VS 物化视图读取

3.2.2  状态更新

状态变量（如未支付、已支付）通常使用一组预定义的值，因此在执行就地更新时不会产生问题，因为变量的基数不会改变。建议不要对状态字段进行列的序列压缩。如果应用更倾向于自动记录状态变化，我们也可以对这些变化使用仅插入（Insert-Only）的方法，这一点我们将在 3.2.2 节中进行讨论。如果状态变量只有两个值，那么最好的选择是一个空值（Null Value）和一个时间戳。即使针对基于时间的查询，就地更新也是完全透明的。

3.2.3  值更新

由于在大多数情况下，企业应用中的属性更改都必须记录到日志中，所以 Insert-Only 看起来是个恰当的方式。图 5 显示，在很长一段时间内，一个金融系统中平均只有 5% 的元组发生了实际变化。增量管理器的额外负载和主内存的额外消耗是可以接受的。增量管理器是用于处理更新和插入的列式存储数据库中的写优化存储。数据只插入到增量存储中。增量存储中的字典不会被排序，而是保持插入的顺序。使用 Insert-Only，我们还可以捕获变更历史，包括变更的时间和来源。

图 5：会计更新频率

尽管事实上典型的企业系统并不是真正的更新密集型，但是通过使用 Insert-Only 和不维护总数，我们甚至可以减少这些更新。因为更新变少了，所以锁问题也减少了，并且表可以更容易地通过 Shared-Nothing 方法在独立的计算单元（刀片）之间实现水平分布（分区）^[19]。基本上消除了更新之后，我们现在只需要考虑插入和读取。下一节将讨论如何区分元组的最新表示和旧版本，以及如何维护读取和更新之间的并发性。

根据对金融系统的这些推荐修改，主要表格的数量将从 18 个以上降至 2 个（不包括变更历史、指数和 OLAP Cube），如图 6 所示。我们只在表格中保留会计文档——标题和行项目。在文件上执行的 Insert-Only 方法和计算算法会替换所有索引、物化视图和更改历史。

图 6：简化后的金融系统（目标）

四、 Insert-Only 的后果

Insert-Only 会对应用和数据库级别的加锁处理方式产生影响。

4.1 应用级锁

许多业务事务同时处理几个关系表和一个表的多个元组。应用程序在对象中“思考”，对象是建立在关系模型之上的一层。尽管我们可以用我们独有的数据库锁处理大多数并发情况，但我们必须在对象（应用）层级引入一个共享锁（Shared Lock）。例如，应用对象 customer 转换成多达 15 个数据库表。客户对象的变化可以包括银行信息、送货地址等。为了保持一致性，一次只能有一个事务更改该特定对象。另一个例子是应付账款或应收账款中未清项目的对账。多个未清项目将在一次交易中标记为已支付。锁没有加在会计行项目表上，而是加在对象 creditor 或 debitor 上。这些应用级锁是使用内存中的数据结构实现的。

4.2 数据库锁

利用 Insert-Only，除了二进制状态变量之外，可以消除应用对元组的更新。在数据库中拥有同一个元组的多个版本需要将较旧的版本标记为不再有效。每个插入的元组都带有它的创建时间戳，如果该元组更新了，还会带有更新的时间戳。只有元组的最新版本没有更新时间戳，因此很容易识别出来。这个概念的好处是，可以通过使用关于查询的基准日期的两个时间戳来重建元组的任何状态。这种方法在 1987 年时已经被 POSTGRES 采用^[21]，称为“时间旅行”。扩展 SQL 必须支持基准日期参数，通过该参数可以识别元组的有效版本。

在同一个表中携带元组的所有旧版本具有显著的应用优势，尤其是在检索旧版本数据是常见操作的规划应用中^[7]。除此之外，它完全消除了单独创建变更日志的必要性。其带来的额外存储容量要求可以忽略不计。

时间戳属性不参与任何压缩算法，因此在更新时不会导致列的任何重组。因为多个查询可能与插入和更新同时发生，所以必须非常小心地避免在表、列或字典级别的过多锁定。

现在我们来看看插入。插入的数据被添加至表中恰当的分区中的增量存储内。查询开始时的时间戳定义了哪些元组是有效的（只有时间戳更早的元组）。万一插入操作正在进行中，新查询的开始时间戳将会被设置为插入事务的时间戳减 1，并且正在进行的插入将再次被忽略。此过程相当于通过时间戳实现的快照隔离^[15，3]。

在当前的研究系统中，我们观察到当多个查询同时运行时，每次插入的时间都会显著增加。我们认为这是一个实现问题，因为在过去，只读应用的设计目标是实现压缩最大化。因为插入被作为增量存储的追加实现，从而不需要排他锁。如果一个事务包括多个插入，则适用和插入/更新相同的逻辑。所有并发运行的查询将通过时间戳比较看到一致的快照。

未来的研究将会特别关注并发性和锁问题。作为一般规则，数据库系统应该以最大速度执行每个任务，即使会占用所有资源（例如 CPU 核）以避免潜在的冲突和管理开销的增加。

与之前的插入一样，后续所有的针对改变后的元组的插入都带有一个全局唯一的用户标识符。与时间戳一起，提供了完整的更改历史。

拥有表中元组的完整历史意味着开发事实随着时间演变（Evolution of Facts Over Time）的表示。一个例子是与外部事件相关的一个季度内每天的销售预测的演变，从而可以更好地了解趋势并改进推断（图 7）。尽管应用对滑块的每次增量移动都要进行全表扫描（见虚线），用户体验类似于在 Microsoft Word 中使用滚动条。

五、就内存消耗而言，列式存储优于行式存储

在为 OLTP 和 OLAP 构建一个组合系统的假设下，数据必须针对集合处理、快速插入、最大（读取）并发性和重组的低影响进行组织。这限制了行式存储和列式存储的压缩程度。虽然在行式存储中实现与列式存储相同程度的压缩是可能的（例如 IBM 的 Blink 引擎^[17]），但是要将行式存储和列式存储作比较的户啊，必须要在满足上述要求（尤其是快速插入）的情况下进行才客观，这就将只读行式存储排除在讨论之外了。

在列式存储中，通过属性值的转换和完全消除只有空值的列进行压缩是非常高效的，但在本研究系统中可以通过将值解释为：所有字符空白，所有字符零，以及小数点零作为空值来改进。应用考虑默认值，不能正确处理空值。通过在进入数据库的过程中自动将默认值转换为空值，并在输出的过程中转换回默认值。

当我们比较列式存储和行式存储中的表对内存的要求，二者的压缩比存在着明显差异。对现有客户数据的各种分析显示，在磁盘上，列式存储的典型压缩率为 20%，而写优化的行式存储的压缩率为 2%。为了进一步得出内存消耗估计，我们使用了有利于列式存储的压缩使用因子 10。正如在另一章中所讨论的，列式存储允许我们消除所有物化视图（聚合），并且在需要的时候可以根据算法计算出来。与这些聚合相关的存储要求随应用的不同而变化。通常在 OLAP 系统中用于物化汇总的多维 Cube 随着个体维度的基数而增长。因此，基于消除冗余聚合的有利于列式存储的因子 2 是一个保守估计值。

将基于时间和租户使用表的水平分区。为了将不同质量的和处理器速度用于特定维度，划分为多个维度的选项非常有用。在讨论内存消耗时，将表分为每年的当前数据和历史数据的选项非常有意思。对客户数据的分析表明，通常 5-10 年的历史数据（不允许更改）会保存在运营数据库中。

历史数据可以保持可访问性，不过需要存放在更便宜、更慢的存储介质上（闪存或磁盘）。当前数据加上上一年完成的数据应保存在刀片式服务器的 DRAM 内存中，以便在企业系统中进行典型的年度对比。对于按时间的分离，我们使用两个时间戳，即创建时间和完成时间。完成时间由应用逻辑控制，例如订单处理完毕或发票支付完毕。完成日期决定了数据成为历史数据的年份，这意味着不可能进行进一步的更改。关于主内存需求，我们可以考虑有利于列式存储的因子 5。公平地讲，水平分区也可以在记录存储中实现。如果当前和上一年分区的剩余表大小仍然很大，数据库管理可能会进行水平分区。忽略索引和维度字典的内存需求，我们可以假设存储容量减少了 10 x 2 x 5 倍（从磁盘到主内存）。刀片服务器中使用的下一代主板会提供大约 500 GB 的主内存，甚至更多。由于 100 个刀片的阵列已经上市，OLTP 和 OLAP 容量高达 50 TB 的安装可以转换为 DRAM 上的纯内存系统。就存储容量而言，这涵盖了大多数客户，例如 SAP 的业务套件客户。

六、典型的数据输入事务会发生什么？

数据输入事务由三部分组成：用户数据输入、数据验证和数据库更新。大多数数据验证保持不变。事实上，只有作为索引运行的属性才能帮助提高验证的质量，例如检查客户、供应商、零件条目是否重复或收到的发票是否重复。数据库更新被减少到仅仅是一个插入操作。没有索引（不管是一级还是二级）需要维护，且客户订单、股票变动等日志条目不会产生聚合更新。因此，事务数据输入的吞吐量将会提高。增量管理器处理新元组的初始插入。

增量存储再次被组织为列式存储。由于数据检索和插入会相互影响，因此在实现时必须格外小心，以避免不必要的锁定。对于分区表中的插入，尤其如此。为了减少插入对字典表的影响，并减少增量存储和主存储之间的合并操作的影响，增量存储的两层组织是目前正在研究的概念。因此，研究和开发的重点从最大限度地压缩数据转移到在其他同时运行的查询上以最小的影响进行高速插入。

七、对应用开发的影响

基于使用列式存储的关系型数据库的应用应该使用关系代数和扩展的 SQL 特性，将尽可能多的逻辑委托给数据库级和存储过程。在重写现有应用时，我们希望减少 30% 以上的代码量（在金融等更正式的应用中，我们希望这一数字达到 40-50%）。使用列存储的全索引特性，许多部分可以完全重构。在理想情况下，应用只需要为一个算法设置参数，而这个算法仅由扩展 SQL（作为存储过程）定义且在数据库级别进行执行。然后，应用对结果集进行处理，产生输出（屏幕、电子邮件、打印、电话等）。如前所述，建议严格使用最小投影。数据库的高性能使得应用级别的数据缓存非常流畅。

在多个维度（租户、时间、主键范围等）对表进行分区表的支持有助于为更大的表实现最短的响应时间。由于除了 100 字节的 Stub 之外，尚未填充的列不占用任何存储空间，因此向现有表添加新列变得十分简单。

为了验证我们的发现，一个研究团队开始基于 SAP 的按需系统 ByDesign，为应收账款、应付账款、总账和成本会计（包括规划）建立下一代会计系统。所有用户交互、配置等都相同，以便进行完整的平行测试。

日记账分录表只有一个索引，即会计凭证号（加上行项目号）。没有将日记帐分录与帐户（借方、贷方、G/L 或成本中心等）联系起来的索引存在。唯一更新的属性是：创建、失效和协调时间戳。所有其他更改都会导致插入已更改的条目，并使旧条目无效。

没有实体化视图形式的聚合，相反，它们将通过实时算法创建。数据输入速度提高了，因为只有两个表（单据标题、单据行项目别名日记帐分录）接收插入。事务的简单性允许重新考虑前向恢复方法，而不是退出失败的事务。

会计数据的每一种表示都可以定义为电子表格，识别账户、它们的层次结构（集合）、要计算的值（集合）。在翻译成扩展 SQL 后，可以验证语句的正确性，并且假设 SQL 处理器工作正常，不需要进一步测试。应用程序可以完全专注于用户交互和信息呈现。在第二阶段，一个包括商业专家在内的研究项目将关注响应时间接近于零的全索引数据库的潜力。

不仅消除了冗余表，还消除了系统的 OLTP 和 OLAP 部分之间的更新过程或 ETL 过程形式的冗余表维护。

八、SaaS 应用中的列式存储

针对 SaaS（软件即服务）应用中，列式存储的在以下几个方面有优势：未使用的列仅由 Stub 表示。向表中引入新属性意味着更新元数据并为列创建 Stub^[2]。然后应用便可以使用这些属性。对于正在进行的应用开发来说，这是一个重要的特性，且该特性不会对用户造成任何干扰。与外部数据的连接在导入到主机系统后保存在列式存储中，即使对于非常大的表（访问的最小主存），这也是非常高效的。在这两种情况下，响应时间将大大得到缩短。

现在，应用不仅可以确定查询的基准日期，还可以监控单个元组内容（属性）的发展（例如，客户订单的生命周期、人力资源或应付账款中敏感数据的控制）。

九、后续研究

我们后续的研究方向集中在为 OLTP 和 OLAP 混合负载系统创建一个基准，该基准将基于真实的客户系统和数据^[4]、内存型列式存储数据库的多租户以及围绕增量合并过程的优化。

我们今后研究的重点方向为：

• 灾难恢复

• TCO：当前版本的 SAP 按需会计系统与基于列式存储的版本之间的总拥有成本（Total Cost of Ownership，TCO）比较，包括能耗

• 非结构化数据模型的扩展

• 基于生命周期的数据管理：基于不同应用的语义，可以指定单个记录是否支持再次修改，或是保持只读模式从而允许不同的压缩和分区策略。

• 垂直分区：在企业应用中，单个表中的块倾向于按照他们的访问模式组合在一起。使用垂直分区方法可以在读取这些组的内容时提高性能。

十、结论和展望

过去两年半中获得的经验鼓励我们为更大的公司企业系统（例如，每年多达 1 亿次销售活动）进行设想，其中所有的业务交易、查询，包括无限聚合和基于时间的序列，都可以在几秒钟内得到结果（包括成本惊人的表示层，presentation layer）。我们预计列式存储的发展将会对企业管理产生翻天覆地的影响，就像当初互联网搜索引擎颠覆了我们的生活一样。图 8 描绘了一个未来的管理会议，您想要的信息，动动手指就能搞定^[10]。

图 8：未来的管理会议