T-Tree 或 B-Tree

Question

T-tree 算法在this paper 中描述 而且 T*-Tree 是对 T-tree 的改进，可以更好地使用查询操作，包括范围查询，并且包含 T-tree 的所有其他良好特性。
该算法在本文“T*-tree: A Main Memory Database Index Structure for Real-Time Applications”中进行了描述。
根据这篇研究论文，当数据集适合内存时，T-Tree 比 B-tree/B+tree 更快。 我按照这些论文中的描述实现了 T-Tree/T*Tree，并将性能与 B-tree/B+tree 进行了比较，但在所有测试用例中，B-tree/B+tree 的性能都优于 T-Tree/T*Tree （插入、删除、搜索）。
我读到 T-Tree 是内存数据库的高效索引结构，Oracle TimesTen 使用它。但是我的结果并没有显示出来。
如果有人知道原因或对此有任何评论，很高兴收到她（或他）的来信。

Answer 1

T-Trees 与 AVL 树或 B-trees 不同，它不是一种基本的数据结构。它们只是平衡二叉树的破解版本，因此可能存在也可能不存在它们提供良好性能的利基应用程序。

在这个时代，无论是在预期的块/页面传输计数方面还是在缓存本地性方面，它们都必然会因为它们糟糕的局部性而遭受可怕的痛苦。后者很明显，因为在搜索的所有节点访问中，除了最后一个之外，只有边界值将根据搜索键检查 - 所有其余的都被分页或缓存为空。

将此与一般 B 树和特别是 B+ 树的出色访问局部性进行比较（更不用说在设计时明确考虑了内存性能特征的缓存遗忘和缓存意识版本）。

重新平衡也存在类似问题。在 B-tree 世界中，许多变体——从 B+ 和 Blink 开始——已经被开发和完善，以实现所需的摊销性能特征，包括并发（锁定/锁存）或不存在等方面。因此，大多数情况下，您可以简单地找到适合您性能配置文件的 B-tree 变体 - 或使用简单的经典 B+tree 并确保获得不错的结果。

T-trees 比可比较的 B-trees 更复杂，似乎它们在性能方面没有什么可提供的记忆“层次”已经消失了几十年。不仅硬盘是新的内存，反之亦然，现在主内存是新的硬盘。 IE。即使没有 NUMA，将数据从主内存带入缓存层次结构的成本也很高，以至于需要尽量减少页面传输——这正是 B-tree 及其变体所做的，而 T-tree 却没有。更接近处理器内核，重要的是缓存行访问/传输的数量，但情况保持不变。

事实上，如果您采用二分搜索（已证明是最佳的）的想法，并考虑以与内存层次结构（缓存）良好配合的方式排列搜索键的方法，那么您最终总会得到看起来出奇地像一棵 B-tree...

如果您为性能而编程，那么您会发现获胜者几乎总是位于排序数组、B 树和散列之间的三角形中的某个位置。即使是平衡的二叉树也只有在它们相对较差的性能在其他考虑因素中处于次要地位并且关键数量相当少（即不超过几百万）时才有竞争力。