首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

翻译:The Log-Structured Merge-Tree (LSM-Tree)

高性能事务系统应用程序通常在提供活动跟踪的历史记录表;同时,事务系统生成$日志记录,用于系统恢复。这两种生成的信息都可以受益于有效的索引。众所周知的设置中的一个例子是TPC-a基准应用程序,该应用程序经过修改以支持对特定账户的账户活动历史记录的有效查询。这需要在快速增长的历史记录表上按帐户id进行索引。不幸的是,基于磁盘的标准索引结构(如B树)将有效地使事务的输入/输出成本翻倍,以实时维护此类索引,从而使系统总成本增加50%。显然,需要一种以低成本维护实时索引的方法。日志结构合并树(LSM树)是一种基于磁盘的数据结构,旨在为长时间内经历高记录插入(和删除)率的文件提供低成本索引。LSM树使用一种延迟和批量索引更改的算法,以一种类似于合并排序的有效方式将基于内存的组件的更改级联到一个或多个磁盘组件。在此过程中,所有索引值都可以通过内存组件或其中一个磁盘组件连续进行检索(除了非常短的锁定期)。与传统访问方法(如B-树)相比,该算法大大减少了磁盘臂的移动,并将在使用传统访问方法进行插入的磁盘臂成本超过存储介质成本的领域提高成本性能。LSM树方法还推广到插入和删除以外的操作。然而,在某些情况下,需要立即响应的索引查找将失去输入/输出效率,因此LSM树在索引插入比检索条目的查找更常见的应用程序中最有用。例如,这似乎是历史表和日志文件的常见属性。第6节的结论将LSM树访问方法中内存和磁盘组件的混合使用与混合方法在内存中缓冲磁盘页面的常见优势进行了比较。

05

elasticsearch之Roaring Bitmaps的结构

如果你是刚刚接触搜索引擎,你可能会感到奇怪,构建搜索引擎中存储块的一个很重要的原因是搜索引擎能够有效地压缩和快速解码有序的数字集合。 为什么这个很有用?你可能知道elasticsearch的分片,是基于lucene的索引基础上的,将数据分割成一个个小片段(segment)进行存储的, 然后有规律地将这些小片段进行合并。在每个片段里面,每个文档都会有一个从0到2的31次方减1之间的唯一标识。这种结构像是数组的下标一样: 它存储在任何地方,而且足以标识一个条目。文档有序地存储在片段中,而且doc ID就是文档在存储片段中的索引。所以存储片段中的第一篇文档 的doc ID为0,第二篇为1。直到最后一篇文档,它的doc ID和这个存储片段中所有文档的数量减一是一样的。

02

Xcelsius(水晶易表)系列8——动态选择器高级用法

今天继续跟大家分享关于水晶易表的动态选择器高级用法。 该案例所用到的函数和选择器工具还是我们之前用到的基本选择工具——单选按钮,组合框。 用到的思想与昨天讲到的思想基本一致,不过这里会有而迂回,你可以了通过对比参照,对excel中的动态交互函数与思想有更为深入的理解。 昨天使用的查询关键字是我用的&文本合并函数直接将年份、产品、地区名称链接在一起作为最终的查询字段,这里我会将三个字段(年份、产品、地区名称)分别编码,然后再利用&文本合并函数进行编码合并进而作为查询字段。 该篇用到的函数:&文本合并函数、V

06

InnoDB bugs found during research on InnoDB data storage(10.在研究InnoDB数据存储时发现的InnoDB bug)

在研究InnoDB的存储格式和构建innodb_ruby和innodb_diagrams项目的过程中,我和Davi Arnaut发现了很多InnoDB的bug。我想我应该提几个,因为它们相当有趣。 由于innodb_space实用程序使重要的内部信息以一种以前从未有过的方式可见,所以这些漏洞在很大程度上可以被发现。使用它来检查生产表提供了许多信息,可以继续寻找导致错误的原因。当我们最初查看由innodb_space数据生成的按页空闲空间的图形图时,我们非常惊讶地看到许多页面不到一半的填充(包括许多几乎为空的页面)。经过大量研究,我们找到了所有我们发现的异常现象的原因。

00

扫码

添加站长 进交流群

领取专属 10元无门槛券

手把手带您无忧上云

扫码加入开发者社群

相关资讯

热门标签

活动推荐

    运营活动

    活动名称
    广告关闭
    领券