Algorithm T-树还是B-树

Algorithm T-树还是B-树,algorithm,data-structures,tree,b-tree,in-memory-database,Algorithm,Data Structures,Tree,B Tree,In Memory Database,T-树算法在 T*-Tree是对T-Tree的改进,它更好地使用了查询操作,包括范围查询,并包含了T-Tree的所有其他良好特性。 该算法在本文“T*-树:一种用于实时应用程序的主存数据库索引结构”中进行了描述。 根据这篇研究论文,当数据集适合内存时,T-Tree比B-Tree/B+树更快。 我实现了这些论文中描述的T-Tree/T*Tree,并将其性能与B-Tree/B+树进行了比较,但B-Tree/B+树在所有测试用例(插入、删除、搜索)中的性能都优于T-Tree/T*Tree。 我听说T-

T-树算法在 T*-Tree是对T-Tree的改进,它更好地使用了查询操作,包括范围查询,并包含了T-Tree的所有其他良好特性。
该算法在本文“T*-树:一种用于实时应用程序的主存数据库索引结构”中进行了描述。
根据这篇研究论文,当数据集适合内存时,T-Tree比B-Tree/B+树更快。 我实现了这些论文中描述的T-Tree/T*Tree,并将其性能与B-Tree/B+树进行了比较,但B-Tree/B+树在所有测试用例(插入、删除、搜索)中的性能都优于T-Tree/T*Tree。
我听说T-Tree是内存数据库的一种高效索引结构,Oracle TimesTen使用它。但我的结果没有显示这一点。

如果有人知道原因或对此有任何评论,那么很高兴听到她(或他)的消息

T树不是与AVL树或B树相同的基本数据结构。它们只是平衡二叉树的黑客版本,因此可能存在也可能不存在提供良好性能的利基应用程序

在今天这个时代,由于本地性差,无论是在预期的块/页传输计数还是在缓存本地性方面,它们都注定会遭受可怕的损失。后者是显而易见的,因为在搜索的所有节点访问中,除了最后一个之外,只有边界值会根据搜索键进行检查,其余的都被分页或缓存为零

将其与一般的B-树和特殊的B+树的优秀访问局部性进行比较(更不用说明确设计内存性能特性的不在乎缓存和在意缓存的版本)

再平衡也存在类似的问题。在B-tree世界中,已经开发并完善了许多变体(从B+和Blink开始),以实现所需的摊销性能特性,包括并发性(锁定/锁定)或无并发性等方面。因此,大多数情况下,你可以简单地走出去,找到一个适合你的性能配置文件的B-树变体-或者使用简单的经典B+树,并确保获得不错的结果

T-树比可比的B-树更为复杂,考虑到具有单级内存“层次结构”的商品硬件时代已经过去了几十年,它们似乎在总体性能方面没有什么可提供的。硬盘不仅是新的内存,反之亦然,主内存现在是新的硬盘。也就是说,即使没有NUMA,将数据从主存引入缓存层次结构的成本也是如此之高,以至于最小化页面传输是值得的——这正是B-树及其变体所做的,而T-树所做的。更接近处理器核心的是缓存线访问/传输的数量,但情况保持不变

事实上,如果你采用二进制搜索的思想——这是可以证明是最优的——并考虑以一种与内存层次结构(缓存)配合良好的方式排列搜索键的方法,那么你最终总会得到一个看起来不可思议地像B树的东西


如果您为性能而编程,那么您会发现赢家几乎总是位于排序数组、B树和散列之间的三角形中的某个位置。即使是平衡二叉树也只有在其相对较差的性能在其他考虑因素面前处于次要地位,并且关键计数相当小,即不超过几百万的情况下才具有竞争力。

显示您的结果和测试方法。或者,这种老式的T形树效率不高。根据旧的T形树纸张,我们不能百分之百肯定t-Tree的效率。对于所有对我的问题持否定态度的人,我只是尽我最大的努力实现本文中描述的t-tree,并将其与b-tree进行比较,发现了这个结果。我自己也实现了B-tree,所以我对t-tree和B-tree做了同样的努力。三十年前的研究将使用具有非常不同的内存层次结构特征的硬件,CPU(当时没有多核,更不用说不均匀的CPU)很难饱和内存接口。@greybeard,谢谢你的回答。(好吧,即使是原始文章中提到的德高望重的DEC VAX-11/750也有惊人的4KB缓存,主内存从1MB开始(而不是(最初)变成多位数)。)