存储的未来
对于某些用例，当前存储设计是次优的。我们相信可以通过在”heap”操作和存储之间添加一个抽象层来进行改进。当前，存储设计基于按行组织页的假设：heapam.h假设：每个tuple只有一个元组头和一个数据区域，即包括HeapTuple及tuple逻辑操作的代码，比如delete、update、加锁。类似，执行器代码表示TupleTableSlot抽象层的元组，该抽象层下面是HeapTuple。2015年2ndQuadrant致力于在PG中实施列式存储项目，以下是根据实施过程中吸取的经验得出的计划。
项目大纲
1) 垂直分区
2) 执行器批处理
3) 执行器向量化
4) 列索引
5) 表的可拔插存储
6) 列式存储插件
当将向量化执行引擎集成到列式存储中时，才能获得最高性能。列式存储不用向量化当然也可以，但是获得的收益却不是最大。因为CPU仍然是一次仅操作一个元素。也可以不在列式存储上做向量化，但收益也很小，因为要使向量化，必须将基于行的数据转换成基于列的数据，这是一个缓慢的操作。
垂直分区
将表的存储区域拆分为多个部分的能力，将列的子集放入每个存储区域。这有几点：
1) 跳过读取查询中不使用的列存储区域
2) 不同列使用不同存储策略（基于行或基于列；基于列的不同实现：实验、压缩或非压缩等）
3) 在具有多个存储区域的元组上读取元组，用于他们之间的join
挑战：
1) 表和存储区域之间进行join需要单独处理
2) Join消除是关键
3) 逻辑/物理元组表示需要改变（尤其是单个atrrelid值的pg_attribute不再表示一个表的元组描述符）
批量执行
指执行器在单个节点一次处理多个元组的能力，而不是当前一次仅处理一个。需要大改TupleTableSlot结构以及节点执行流程。这适用于9.7.
向量化执行
执行器在CPU级别使用SIMD指令用于函数操作的能力。这基于执行器批量执行。聚合操作需要提供专用代码。
列式索引
这个项目关于列存储的新索引访问方法。一个明显的输出是深入了解哪种列存储方法最有效。好处：索引比标准索引更加紧凑，因此扫描速度更快。
表的可拔插存储
这个项目关于为表存储创建一个类似访问方法的接口。目前，所有存储都通过heapam.c。这使编写不同实现成为可能。PG12开始已支持表访问方法的可拔插。Heapam.c接口假定用于有一个表和一个TID。目前TID只是关系中元组的物理位置。该项目可能需要更高元组标识符以适应不同的存储实现。同时，当前heapam.c实现返回一个包含元组的HeapTuple结构，但不同的实现可能有完全不同的方式来表示存储中的元组。因为我们希望利用元组的不同表示而不是heapify他们。所以可能需要进行更多修改，以便可以将元组传递给执行程序代码。这如何工作，还不清楚，需要更多研究。执行器批处理可以依靠他一次对多个元组进行操作。
Tom Lane的警示
我们需要避免DDL代码的重写。目前所有utility代码都假设HeapTuples可传递到任何地方。对于不同存储格式，这种假设就会失效。我们需要一些方法来避免这个项目陷入无休止的utility代码重构中。
解决方案似乎很简单：不需要在system catalog中立即解决这个问题，如果我们禁止对system catalog使用不同存储格式，我们就不需要边界大量utility代码。
将来有人可以重构涉及单个catalog的代码，以允许将可拔插（非堆）存储用于该catalog。这可以零碎地完成，取消对一个特定catalog的限定。
列存的插件
面向列存储的可拔插存储引擎。
现有用例分析
上面介绍的是PostgreSQL的，分析其他数据库也很有用。
MySQL/MariaDB
MySQL和MariaDB提供可拔插存储引擎，请参考其手册。
存储引擎 |
描述 |
我们在PG中需要这样类似的东西吗？ |
InnoDB |
提供索引组织表，行的老版本在undo表空间。二级索引是间接的，具有单独版本 |
是的。索引组织表、undo表空间、二级索引是有用的特性。看来，至少其中一些可以使用可拔插存储API来实现 |
MyISAM |
没有事务和恢复的表引擎 |
不用。如果需要，我们有unlogged表 |
CSV Federated Cassandra CONNECT SphinxSE |
这些表引擎要么访问本地数据，要么访问外部数据源 |
不需要。我们有FDWs |
MGR_MyIsam Merge |
这些引擎允许定义作为主表集联合的表。这种联合是可更新的：更新被推送到主表。 |
不需要。我们有可更新视图、分区、表继承等 |
Archive |
归档数据的存储：追加、可压缩存储 |
是的。归档存储非常有用 |
Blackhole |
静默“吃掉”所有插入数据的表引擎。它在代理中有有用的用例，通过在主端过滤复制流量来减少部分复制中的网络流量。 |
不需要。我们的逻辑解码已经具备这样能力。此外，还具有相同功能的Blackhole FDW |
Mroonga |
Mroonga 使用 FTS、地理空间和其他索引实现非事务性表。 |
不。PG中新的索引类型可以通过索引访问方法来实现 |
OQGraph |
允许查询和对图进行索引的表引擎 。允许用户查询某种视图，而注意数据存储在另一个表中 |
不。这个表引擎不打算存储主要数据。如果我们需要类似的解决方案，我们应该使用索引访问方法、视图、物化视图来实现它 |
Sequence |
提供generate_series()函数的类似功能 |
不用。generate_series()完全可以满足这个目的 |
Aria XtraDB |
MariaDB的MyISAM和InnoDB增强版本 |
不用。我们应该尽可能避免碎片化 |
TokuDB RocksDB |
这些引擎提供写优化表。TokuDB 实现了fractal树，而RocksDB实现了LSM树。 |
是的。写优化表很不错。 |
ScaleDB Spider |
提供内置在表引擎中的集群 |
不用。可拔插存储似乎不适合集群的机制 |
Memory |
内存表引擎实现了完全驻留在内存中的非持久表。除了MySQL 实现的缺点之外，内存引擎可以给我们带来以下好处：更快的内存操作绕过缓冲区管理器；优化磁盘IO相关操作 |
是的。如果内存表执行的更快，那就太好了。有人可能会反对PG不应该使用内存存储，但若这种存储引擎能够带来显著性能优势，用户就会对它感兴趣 |
MongoDB
mongoDB也提供可拔插存储，参考其手册。
