SAP HANA 中的 CPBTree 是什么？
What is CPBTree in SAP HANA?
我正在研究 SAP HANA 主内存数据库。
其中有一个名为 CPBTree 的索引。在它的文档中，是这样描述的：
CPB+-tree stands for Compressed Prefix B+-Tree; this index tree type
is based on pkB-tree. CPB+-tree is a very small index because it uses
'partial key' that is only part of full key in index nodes.
这有点含糊。网上没有其他关于CPBTree结构的解释
有没有哪位可以多解释一下或者介绍一下好的文档？
从哪里开始？
B-trees 是非常 深入研究和开发的数据结构，因此指向一个解释与这个问题和 SAP HANA 相关的所有方面的单个文档有点困难.
也许先解开这个术语会有所帮助：
压缩前缀
这基本上意味着，B 树索引和叶节点不包含键的完整字符串。相反，键中通用的键字符串部分（前缀）是单独存储的。然后叶节点和索引节点只包含
- 指向前缀的指针
- 一种包含剩余密钥的“增量”（这是来自 pkB 树的 部分密钥 的来源）
- 和指向数据记录的指针（行 ID）
这种技术在许多 DBMS 中相当普遍，通常附加到称为 “索引压缩” 或类似内容的功能。
所以，现在我们知道 HANA 使用压缩的 B 树索引（用于行存储表和可以表示为字符串的数据）。
为什么这对像 HANA 这样的内存数据库很重要？
简而言之：RAM 和 CPU 之间的内存传输工作量。
索引结构越小，可以放入 CPU 缓存的内容就越多。要遍历（通过）索引，必须执行更少的数据来回移动。
这是一个巨大的性能优势。
这与特定的“缓存敏感”索引协议（HANA 内核如何使用索引结构）相辅相成，这些协议试图最小化 RAM-CPU 数据传输。
所有这些都是过于简化的解释，但我希望它有助于理解更多内容。
如果您想“深入研究”并开始阅读围绕该主题的学术论文，那么 Cache-Conscious Concurrency Control of Main-Memory Indexes on Shared-Memory Multiprocessor Systems by Prof. Sang K. Cha. et al。
Sang K. Cha 在 2000 年代早期创建了 P*Time，一个内存中（行存储）DBMS。
众所周知，这个 P*Time 已被 SAP 收购（就像许多其他 DBMS 软件产品公司一样...Sybase...MaxDB...OrientDB...）并且该技术已被用作后来成为 SAP HANA 的研究基础。
如今，只有一小部分 P*Time 仍在 SAP HANA 中，大部分都简化为概念和算法，并没有在实际的 P*Time 代码中表达。
总而言之，对于 HANA 的用户（开发人员、管理员、数据消费者）来说，此索引实现的细节几乎不重要，因为 none 他们可以直接与索引结构交互。
重要的是，该索引采用现代服务器系统（许多内核、大型 CPU 缓存、大量 RAM）并从中提取出色的性能，同时仍允许“高速”交易。
我在我的博客中添加了这个答案的扩展文章：https://lbreddemann.org/what-is-cpb-tree-in-sap-hana/。
我正在研究 SAP HANA 主内存数据库。
其中有一个名为 CPBTree 的索引。在它的文档中，是这样描述的：
CPB+-tree stands for Compressed Prefix B+-Tree; this index tree type is based on pkB-tree. CPB+-tree is a very small index because it uses 'partial key' that is only part of full key in index nodes.
这有点含糊。网上没有其他关于CPBTree结构的解释
有没有哪位可以多解释一下或者介绍一下好的文档？
从哪里开始？
B-trees 是非常 深入研究和开发的数据结构，因此指向一个解释与这个问题和 SAP HANA 相关的所有方面的单个文档有点困难.
也许先解开这个术语会有所帮助：
压缩前缀
这基本上意味着，B 树索引和叶节点不包含键的完整字符串。相反，键中通用的键字符串部分（前缀）是单独存储的。然后叶节点和索引节点只包含
- 指向前缀的指针
- 一种包含剩余密钥的“增量”（这是来自 pkB 树的 部分密钥 的来源）
- 和指向数据记录的指针（行 ID）
这种技术在许多 DBMS 中相当普遍，通常附加到称为 “索引压缩” 或类似内容的功能。
所以，现在我们知道 HANA 使用压缩的 B 树索引（用于行存储表和可以表示为字符串的数据）。
为什么这对像 HANA 这样的内存数据库很重要？ 简而言之：RAM 和 CPU 之间的内存传输工作量。 索引结构越小，可以放入 CPU 缓存的内容就越多。要遍历（通过）索引，必须执行更少的数据来回移动。
这是一个巨大的性能优势。
这与特定的“缓存敏感”索引协议（HANA 内核如何使用索引结构）相辅相成，这些协议试图最小化 RAM-CPU 数据传输。
所有这些都是过于简化的解释，但我希望它有助于理解更多内容。
如果您想“深入研究”并开始阅读围绕该主题的学术论文，那么 Cache-Conscious Concurrency Control of Main-Memory Indexes on Shared-Memory Multiprocessor Systems by Prof. Sang K. Cha. et al。
Sang K. Cha 在 2000 年代早期创建了 P*Time，一个内存中（行存储）DBMS。
众所周知，这个 P*Time 已被 SAP 收购（就像许多其他 DBMS 软件产品公司一样...Sybase...MaxDB...OrientDB...）并且该技术已被用作后来成为 SAP HANA 的研究基础。
如今，只有一小部分 P*Time 仍在 SAP HANA 中，大部分都简化为概念和算法，并没有在实际的 P*Time 代码中表达。
总而言之，对于 HANA 的用户（开发人员、管理员、数据消费者）来说，此索引实现的细节几乎不重要，因为 none 他们可以直接与索引结构交互。
重要的是，该索引采用现代服务器系统（许多内核、大型 CPU 缓存、大量 RAM）并从中提取出色的性能，同时仍允许“高速”交易。
我在我的博客中添加了这个答案的扩展文章：https://lbreddemann.org/what-is-cpb-tree-in-sap-hana/。