保持冷静并明智地进行专栏

这里值得注意一个技术细节。我们看到，当我们添加属于嵌套字段的新列（例如，第 5 列，对应于 zip）时，第一个定义级别为 1，对应于缺失的 第一个文档中的 zip 值。但是我们如何获得此信息（即，当我们添加第二个文档时，定义级别为 1 而不是 0）？父文档可以维护子文档地址存在或缺失的所有先前文档的整数列表（即，地址的定义级别，在所有先前文档中可以是 0 或 1）。添加新列时，我们首先将父子文档地址的定义级别设置为新创建的列。在我们的示例中，地址出现在 customer_id = 201 的文档中。因此，地址的定义级别为 1。创建第 5 列时，我们添加了定义级别 1 首先表示地址存在于上一个文档中，但缺少 zip 值。由于上述原因，在每个嵌套节点中维护此列表是可选的（我们可以简单地为每个新创建的列添加 0）。但是，使用适当的数据结构在内存中维护此列表的成本相对较低。在 Capella Columnar 中，我们实现了一个简单的数据结构，该结构利用了定义级别的修复性质 – 我们的实验表明它的内存占用可以忽略不计。此外，这个整数列表受到每个物理页面上文档数量的限制，最多限制为 15,000 个（有关此限制的更多详细信息，请参阅论文）。维护父节点的实际定义级别简化了 JSON 文档组装算法（因此，文档组装代码的可维护性更好、更容易）。因此，我们选择在 Capella Columnar 中进行此操作。

处理 JSON 数组

在前面的示例中，我们处理了 JSON 对象（文档和子文档）。接下来，我们重点讨论 JSON 数组的处理。让我们从图 7 中所示的简单示例开始。在这个示例中，我们有三个文档，从架构中我们可以看到所有文档都有字段 id，它是主键。前两个文档有两个附加字段，a 和 b，其中 a 是整数数组，b是整数数组的数组。在上一个文档中，a 和 b 均缺失。

从id开始，我们可以看到它的值存储在第0列中。在本例中，我们对定义级别进行了颜色编码，以便我们可以直观地将列中的值与其文档，其中 greens 属于第一个文档，oranges 属于第二个文档，并且sky-blues 用于第三个文档。因此，第 0 列中的 id 1、2 和 3 分别属于第一个、第二个和第三个文档。

接下来，第 1 列存储所有三个文档的数组 a 的整数值。现在的问题是我们如何确定该列中的哪个值属于哪个文档。使用颜色编码，您可以观察到前四个值属于第一个文档 – 但机器如何确定这一点？我们可以看到第一个文档中的数组 a 具有三个整数 [1, 2, 3]，每个整数的定义级别等于 2（表示值存在 – 正如我们之前看到的），后面跟着定义级别 0在前面的示例中，我们使用定义级别来确定值是否存在。在数组中，定义级别还有一个额外的作用，即充当数组分隔符；因此，在前三个定义级别（2、2和2）之后，最后一个定义级别（0）是分隔符，它告诉我们已经到达数组末尾，因此以下值属于下一个文档。请注意，我们将 ‘]’ 放入 Value 向量中；然而，这仅用于说明目的——数组分隔符没有任何值。与第一个文档中一样，以下橙色定义级别（2、2 和 2）表示存在第二个文档的数组 a 的值，这些值是 [4, 5, 6]。同样，以下定义级别 (0) 表示第二个文档的数组末尾。在第二个文档的分隔符之后，我们看到天蓝色的定义级别 (0)，它对应于第三个文档，其中缺少数组 a。因此，(0) 的定义级别表明第三个文档中缺少数组 a – 您可能会问，为什么它不是分隔符？如果观察到数组元素是先验存在的，则定义级​​别可以解释为分隔符；否则，则表明存在缺失值。换句话说，分隔符前面必须有一个具有更高定义级别的值；否则，观察到的定义级别表示缺失值，而不是数组分隔符。

<表格样式=“最大宽度：100％；宽度：自动；表格布局：固定；显示：表格；”宽度=“自动”>
<标题>

文件

推断模式

数据列

<正文>

JSON

 

{
  “id”：1，
  “一”：[1,2,3],
  "b": [[1, 2], [3]]
}

{
  “id”：2，
  “一”：[4,5,6],
  “b”: [[4], [5, 6]]
}

{
  “id”：3
}

图 7：表示 JSON 数组

现在，让我们看看如何表示数组的数组（例如上面图 7 中的 b）。只需查找第 2 列中的分隔符（内部标记为 ‘]’ 和外部标记为 ‘]]’，我们可以看到有两个分隔符，其中两个分隔符不同的定义级别：1和0。在第2列中，我们需要两个分隔符来区分内部和外部分隔符。例如，第一个文档中的值 [1, 2] 之后放置一个定义级别为 1 的分隔符，表示内部数组的末尾，后面紧跟值 [3]，表示第二个文档的第一个元素内部数组。在值 [3] 之后，我们看到定义级别为 1 的两个连续分隔符，然后是 0。第一个定义级别为 1 的分隔符告诉我们内部数组的结尾，最后一个定义级别为 0 的分隔符告诉我们我们是第一个文档中数组 b 的末尾 – 因此，以下值属于第二个文档。类似地，对于第二个文档，我们有值 [4]，后跟定义级别为 1 的分隔符 – 指示第一个内部数组只有一个元素 [4]。然后，我们得到值 [5, 6]，后跟定义级别为 1 和 0 的分隔符——分别表示第二个内部数组和外部数组的结尾。最后，第三个文档中的定义级别 0 表示数组 b 丢失。

这就是表示一个数组和一个标量值数组的数组！接下来，我们解释对象数组的表示。让我们从下面图 8 中所示的示例开始，使用清单 2 中的第一个 Orders 文档。该示例仅显示两列（共六列）并省略其余部分（省略的列可以用作读者的练习）。我们主要关注第 3 列和第 6 列（即架构中的 item_id 和 promo）。两列都属于同一数组items。从“列的角度”来看，它“将自身视为”标量值的数组。换句话说，我们可以将 item_id 的值视为整数数组 [1001, 1002]，将 promo 的值视为字符串数组 [“BLACK-FRIDAY ，”缺失]。因此，表示一个对象数组可以看作表示两个具有相同数量元素的不同标量数组。因此，它们的分隔符将位于完全相同的位置。在下面的示例中，第 3 列和第 6 列的数组分隔符恰好出现在第 3^rd 位置。另一个区别（与实际的标量数组相比）是值存在于哪个定义级别。由于两列都是同一对象数组的后代，因此定义级别等于 3 表示当前值 – 因为 item_id 和 promo 的值都出现在从根部算起的第三层。例如，根 (0) →\rightarrow< span class="mrel">→ 项目 (1) $\to$

<表格样式=“最大宽度：100％；宽度：自动；表格布局：固定；显示：表格；”宽度=“自动”>
<标题>

文件

推断模式

数据列

<正文>

JSON

 

{
  “订单id”：5002，
  “客户 ID”：101，
  “日期”：“2023-11-24”，
  “项目”： [
    {
      “项目 ID”：1001，
      “数量”：1，
      “购买价格”：1200.00，
      “促销”：“黑色星期五”
    },
    {
      “项目 ID”：1002，
      “数量”：1，
      “购买价格”：30.00
    }
  ]
}

图 8：表示对象数组

处理异构类型

好吧！到目前为止，我们知道如何将 JSON 对象、数组及其标量值表示为列和如何处理架构更改（即推断新列）。接下来，我们解释如何处理异构数据类型。让我们以下面图 9 中所示的示例为例，使用清单 3 中所示的文档。首先，我们看到有四个文档，其中字段 price 可以是双精度值、字符串或双精度值数组，或缺失值。推断的模式将价格类型表示为双精度、字符串或数组的并集。模式树结构中的联合节点在图 9 中表示为菱形，具有三个子节点。推断模式中的联合类型在三个方面是一种特殊情况。首先，并集是一种逻辑描述，不能存在于实际文档中。其次，由于是逻辑描述，因此不影响定义层次。第三，联合值中只能存在单个值，其余值必须缺失 – 当所有值都缺失时，联合值本身就会指示为缺失。

让我们解压它并使用下面的示例来理解联合类型的这三个标准。首先，我们看到第 1 列、第 2 列和第 3 列都属于 价格。与在子文档中一样，联合的分支可以具有任意数量的列。例如，第 1 列对应于 price 的双精度类型版本，第 2 列对应于 price 的字符串类型版本，第 3 列对应于双精度数组-类型版本的价格。当访问价值价格时，必须同时读取所有三列以确定价格的实际价值。从第 1 列开始，我们看到第一个值的定义级别等于 1，这表明该值存在，并且其值为 10.99。请注意，根和列本身之间的并集不会改变结果（即，结果仍然是第一个文档中所示的两倍 – 上面的第一个标准）。另请注意，即使从根到第 1 列的路径经过并集节点（第二个标准），定义级别仍为 1（而不是 2）。现在，由于第 1 列包含第一个文档的非缺失值，因此同一文档的第 2 列和第 3 列中的值缺失（第三个标准）。在第二个文档中，价格是一个字符串。因此，字符串值出现在第 2 列中，而第 1 列和第 3 列均缺失。在第三个文档中，价格是一个双精度数组，因此该数组的价格值存储在第 3 列中。最后，在第四个文档中，缺少字段 价格。因此，所有三列的定义级别均为 0 – 表明价格本身缺失。

<表格样式=“最大宽度：100％；宽度：自动；表格布局：固定；显示：表格；”宽度=“自动”>
<标题>

文档 推断的架构 数据列

<正文>

JSON

 

{
  “项目id”：3003，
  「价格」：10.99
}

{
  “项目id”：3004，
  “价格”：“10.99”
}

{
  “项目id”：3005，
  “价格”：[10.99，11.99]
}

{
  “项目id”：3006，
}

图 9：表示异构类型

编码

在此表示中，我们看到每列存储的值都具有相同的类型和域。即使在具有异构数据类型的字段（例如图 9 中的价格）中，每个物理列也专用于存储价格值的一种特定数据类型。这使我们有机会使用目前 Parquet 中使用的相同传出编码方案不包括字典编码（因为它需要额外的存储页面）。我们计划探索在未来版本中包含字典编码的潜在好处/缺点。

我们现在看到，Capella Columnar（使用这种柱状表示）能够处理 JSON 数据模型中架构的灵活性，以及​​在将数据存储为列时处理动态架构更改。此外，该表示能够处理 JSON 数据模型的嵌套性质。最后，当遇到异构值类型时，架构和列可以动态适应。

列式存储物理布局

既然我们知道如何将 JSON 文档表示为列，那么现在的问题是如何实际存储它们。之前，我们描述了 Capella Columnar 中的摄取管道，并解释了如何JSON 文档作为列写入磁盘上的 LSM 组件。那么，让我们深入了解一下磁盘组件的内部内容。磁盘组件是完全存储在磁盘上的 B⁺ 树。在 Capella Columnar 中，我们使用论文中描述的物理存储布局，称为 AsterixDB Mega Attributes across（或AMAX），用于存储数据列。图 10 描述了存储布局。每个 AMAX LSM 组件也是一棵 B⁺ 树；然而，B⁺树的叶子节点是巨型叶子节点，每个叶子节点可以占用多个数据页，而不是像原来那样占用单个数据页B⁺-树。在图 10 中，我们看到有四个巨型叶节点（四个箭头来自内部节点），每个节点占用不同数量的数据页。放大其中一个巨型叶子节点，我们看到它由 5 个数据页组成（第 0 页到第 4 页）。第 0 页是一个特殊页面，因为它存储包含有关巨型叶子节点的元信息的巨型叶子节点标头。另外，Page 0存储了所有mega leaf节点的主键，以及每列的最小值和最大值的固定长度前缀，可以用于在查询LSM组件时过滤掉mega leaf节点（更多稍后再说）。

接下来，第 1 页到第 4 页存储列的数据（即它们的定义级别及其值）。在同一张图中，我们看到一些称为 Megapages 的逻辑表示，每个逻辑表示都存储特定列的数据。例如，megapage 1 占用第 1 页、第 2 页和第 3 页的一部分，存储单个列的数据。 megapage 2也是如此，它占据了第3页和第4页，并且存储了另一列的数据。

图 10：列式存储物理布局 (AMAX)

列式集合的查询处理技术

当查询集合主索引的 LSM 组件时，将处理上面图 10 中 B⁺ 树中的每个巨型叶节点（从左到右）。但是，在每个大型叶节点中只会访问相关的大型页面（或列）。例如，假设执行以下查询：

SQL

 

选择平均值(i.price)
来自项目我

在每个大型叶节点中，只有第 0 页以及与价格值（或列）对应的大型页面一起被访问。例如，假设 megapage 2 存储价格值；那么只会访问 Page 0、Page 3 和 Page 4，而 Page 1 和 Page 2 将被跳过 – 减少 I/O 成本。

正如我们提到的，Page 0 还存储每列的最小值和最大值的固定长度前缀。假设我们要运行另一个查询，如下所示：

SQL

 

选择 *
来自客户 c
WHERE 地址.city =“哥谭”

当访问大型叶子节点时，我们读取的第一页是 Page 0。因此，在读取查询所需的其他页面（在上面的查询的情况下，是所有列）之前，我们使用当最小/最大过滤器无法满足条件 address.city = "Gotham" 时，Page 0 中的过滤器会跳过读取大型叶节点的大型页面。因此，可以跳过许多巨型叶节点。如果过滤器是选择性的，则此类过滤器可以显着加速查询的执行。

上面的查询执行SELECT *，这需要将 JSON 文档组装回其原始形式。如果列数较多，则组装成本（CPU 成本）可能会很高。为了避免支付不必要的成本，Capella Columnar 会将 WHERE 子句的谓词下推到存储层。更具体地说，Capella Columnar 所做的是，它首先读取计算查询中的 WHERE 子句所需的列，并推迟读取其他列。当 Capella Columnar 找到满足 WHERE 子句条件的 JSON 文档时，它会读取其他列，并仅组装满足查询条件的 JSON 文档。当第 0 页上的最小/最大过滤器的范围太“宽”时，这种二级过滤方法可以充当“第二道防线”。此外，通过避免组装不满足执行查询条件的 JSON 文档，可以降低重组成本。

上述技术适用于各种查询。例如，Capella Columnar 的编译器甚至可以针对数组项检测和使用过滤器，如下面的查询所示：

SQL

 

--返回至少包含一个已购买的订单数
-- 购买价格低于 10.0 的商品
选择计数(*)
FROM 订单 o
-- o.items 是 Orders 中的一个数组（参见清单 2）
-- 过滤器将被推送并应用在
-- 存储层甚至针对数组项
WHERE（o.items 中的某些 i 满足 i.purchase_price < 10.0）

最后，Capella Columnar 还支持在列式集合上创建和使用二级索引（如传统上对行集合所做的那样）以进行进一步过滤。

结论

Couchbase 列式服务旨在提供零 ETL 方法来提供各种将数据整合到一个平台中进行实时分析。它的 JSON 数据模型、高效的存储引擎以及查询编译器和查询处理器是此配方的秘密关键成分。现在你知道这个秘密了！

参考文献

• Dremel：网络规模数据集的交互式分析
• 现代列式数据库系统的设计与实现
• 基于无模式 LSM 的文档存储的列格式
• 迈向分析优化的文档存储

相关文章

技术实践

2024年1月10日

使用 Hibernate 6 进行 Postgres 全文搜索

休眠 Hibernate 本身不支持全文搜索。它必须依赖数据库引擎支持或第三方解 &hellip; Read More

阅读全文

技术实践

2019年9月20日

可能是全网最好的MySQL重要知识点

什么是MySQL? MySQL 是一种关系型数据库，在Java企业级开发中非常常 &hellip; Read More

阅读全文

技术实践

2024年3月5日

守护GenAI之门：AI演进中的安全挑战

生成式人工智能 (GenAI) 代表了一次重大飞跃在人工智能领域，能够创建新颖且 &hellip; Read More

阅读全文

技术实践

2024年1月10日

数据工程中的自动化测试：质量和效率的必要条件

在当今数据驱动的环境中，自动化已成为各行业不可或缺的一部分，不仅是为了最大限度地 &hellip; Read More

阅读全文