kafka解决查找效率的两大法宝

数据文件的分段

Kafka解决查询效率的手段之一是将数据文件分段,比如有100条Message,它们的offset是从0到99。假设将数据文件分成5段,第一段为0-19,第二段为20-39,以此类推,每段放在一个单独的数据文件里面,数据文件以该段中最小的offset命名。这样在查找指定offset的Message的时候,用二分查找就可以定位到该Message在哪个段中。

为数据文件建索引

数据文件分段使得可以在一个较小的数据文件中查找对应offset的Message了,但是这依然需要顺序扫描才能找到对应offset的Message。为了进一步提高查找的效率,Kafka为每个分段后的数据文件建立了索引文件,文件名与数据文件的名字是一样的,只是文件扩展名为.index。
索引文件中包含若干个索引条目,每个条目表示数据文件中一条Message的索引。索引包含两个部分(均为4个字节的数字),分别为相对offset和position。

  • 相对offset:因为数据文件分段以后,每个数据文件的起始offset不为0,相对offset表示这条Message相对于其所属数据文件中最小的offset的大小。举例,分段后的一个数据文件的offset是从20开始,那么offset为25的Message在index文件中的相对offset就是25-20 = 5。存储相对offset可以减小索引文件占用的空间。
  • position,表示该条Message在数据文件中的绝对位置。只要打开文件并移动文件指针到这个position就可以读取对应的Message了。

index文件中并没有为数据文件中的每条Message建立索引,而是采用了稀疏存储的方式,每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间,从而可以将索引文件保留在内存中。但缺点是没有建立索引的Message也不能一次定位到其在数据文件的位置,从而需要做一次顺序扫描,但是这次顺序扫描的范围就很小了。

在Kafka中,索引文件的实现类为OffsetIndex,它的类图如下:

主要的方法有:

  • append方法,添加一对offset和position到index文件中,这里的offset将会被转成相对的offset。
  • lookup, 用二分查找的方式去查找小于或等于给定offset的最大的那个offset

    更多分享请关注:bbs.superwu.cn

    关注超人学院二维码,更多精彩内容抢先看

时间: 2024-10-21 23:30:30

kafka解决查找效率的两大法宝的相关文章

两大数据库缓存系统实现对比

和redis,作为近些年最常用的缓存服务器,相信大家对它们再熟悉不过了.前两年还在学校时,我曾经读过它们的主要源码,如今写篇笔记从个人角度简单对比一下它们的实现方式,权当做复习,有理解错误之处,欢迎指正. 两大数据库缓存系统实现对比两大数据库缓存系统实现对比一. 综述读一个软件的源码,首先要弄懂软件是用作干什么的,那memcached和redis是干啥的?众所周知,数据一般会放在数据库中,但是查询数据会相对比较慢,特别是用户很多时,频繁的查询,需要耗费大量的时间.怎么办呢?数据放在哪里查询快?那

如何在mysql查找效率慢的SQL语句

如何在mysql查找效率慢的SQL语句呢?这可能是困然很多人的一个问题,MySQL通过慢查询日志定位那些执行效率较低的SQL 语句,用--log-slow-queries[=file_name]选项启动时,mysqld 会写一个包含所有执行时间超过long_query_time 秒的SQL语句的日志文件,通过查看这个日志文件定位效率较低的SQL .下面介绍MySQL中如何查询慢的SQL语句 一.MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句 1,slow_query_log 这

微服务架构的两大解耦利器与最佳实践

这几年,微服务架构这个术语渐成热门词汇,但它不是一个全新架构,更不是一个包治百病的架构.那么,微服务架构究竟能够解决什么问题,又带来哪些痛点? 本文将与大家谈谈这个问题,以及微服务架构的两大解耦利器配置中心和消息总线的最佳实践. 微服务架构解决的问题与带来的痛点 一 互联网高可用架构为什么要服务化? 上图是互联网典型的高可用架构,大部分公司如果没有使用微服务,正在使用这样的架构: 用户端是浏览器 browser,APP 客户端 后端入口是高可用的 nginx 集群,用于做反向代理 中间核心是高可

大数据行业里的两大误区

http://www.cognoschina.net/club/thread-68835-1-1.html http://www.cognoschina.net/club/thread-68837-1-1.html 大数据行业里的误区 大数据这个词,恐怕是近两年IT界炒的最热的词汇之一了,各种.会议,言必谈大数据,“大数据”这个词,在IT界已经成了某果一样的“街机”或者叫 “街词”,不跟风说两句“大数据长,大数据短”都不好意思跟人说自己是搞IT的.从某种程度来讲,大数据这个“圈”太乱了,一点不比

数据库两大神器【索引和锁】

前言 只有光头才能变强 索引和锁在数据库中可以说是非常重要的知识点了,在面试中也会经常会被问到的. 本文力求简单讲清每个知识点,希望大家看完能有所收获 声明:如果没有说明具体的数据库和存储引擎,默认指的是MySQL中的InnoDB存储引擎 一.索引 在之前,我对索引有以下的认知: 索引可以加快数据库的检索速度 表经常进行INSERT/UPDATE/DELETE操作就不要建立索引了,换言之:索引会降低插入.删除.修改等维护任务的速度. 索引需要占物理和数据空间. 了解过索引的最左匹配原则 知道索引

List和Dictionary泛型类查找效率浅析

List和Dictionary泛型类查找效率存在巨大差异,前段时间亲历了一次.事情的背景是开发一个匹配程序,将书籍(BookID)推荐给网友(UserID),生成今日推荐数据时,有条规则是同一书籍七日内不能推荐给同一网友. 同一书籍七日内不能推荐给同一网友规则的实现是程序不断优化的过程,第一版程序是直接取数据库,根据BookID+UserID查询七日内有无记录,有的话不进行分配.但随着数据量的增大,程序运行时间越来越长,于是开始优化.第一次优化是把所有七日内的数据取出来,放到List<T>中,

提高Order by语句查询效率的两个思路

提高Order by语句查询效率的两个思路 2011-03-01 13:07 水太深 ITPUB 字号:T | T 在MySQL数据库中,Order by语句的使用频率是比较高的.但是众所周知,在使用这个语句时,往往会降低数据查询的性能.因为可能需要对数据库的记录进行重新排序.在这篇文章中,笔者就谈谈提高Order By语句查询效率的两个思路,以供大家参考. AD: 在MySQL数据库中,Order by语句的使用频率是比较高的.但是众所周知,在使用这个语句时,往往会降低数据查询的性能.因为可能

hadoop两大核心之一:MapReduce总结

MapReduce是一种分布式计算模型,由Google提出,主要用于搜索领域,MapReduce程序 本质上是并行运行的,因此可以解决海量数据的计算问题. MapReduce任务过程被分为两个处理阶段:map阶段和reduce阶段.每个阶段都以键 值对作为输入和输出.用户只需要实现map()和reduce()两个函数即可实现分布式计算. 执行步骤: map任务处理: 1.读取输入文件内容,解析成键值对(key/value).对输入文件的每一行,解析成 键值对(key/value).每一个键值对调

【光伏电站运维观点】无人机巡检开启光伏电站运维两大优势和亟待攻克难题

近日,国家发改委.能源局联合下发<电力发展"十三五"规划>,明确到2020年止,太阳能发电装机目标在110GW以上,其中分布式光伏60GW以上.以光伏发电为代表的集中式.分布式光伏电站如雨后春笋般爆发,但这对组件成千上万块的光伏电站巡检.光伏电站检测带来了巨大的挑战. 随着无人机的普及问世,对光伏电站巡检.电站智能运维可以说是锦上添花,无人机巡检代替了人工危险的高空作业和超大的工作量,对于提高电站运维工作效率和降低维护成本具有重要的优势. 下面是对无人机在光伏电站巡检过程中