www.2900555.com当前位置: 老钱庄心水 > www.2900555.com > 正文

Redis streams:做为一个纯数据布局会若何

时间:2019-04-13浏览次数:

  正在本例中,我利用不异的ID做为范畴的起点和起点,以便识别单个元素。不外,我能够利用任何范畴和一个COUNT参数来成果的数量。同样也不需要指定完整的ID做为为range,我只需要利用ID的毫秒unix时间部门,就能够获得给按时间范畴内的元素:

  要申明的是,Redis Streams其实有点像是一个有序调集。正在append only模式中,按时间键入,每个元素都是一个小Hash。简而言之,这是Redis建模中的一次。

  需要留意的一件主要工作是,正在我看来,我们利用一个Stream来暗示网球角逐的用例取正在时间序列中利用Redis Stream常分歧的。从逻辑上讲,我们仍然正在记实某种事务,但有一个根基区别是,正在一种环境下,我们利用日记记实和建立条目来呈现对象。而正在时间序列的环境下,我们只是计量外部发生的工作,它并不实正代表一个对象。你可能会感觉这种差别微不脚道,但现实并非如斯。对于Redis用户来说,主要的是要建立如许一个概念,即能够利用Redis Streams建立具有总序的小对象,并为这些对象分派ID。

  正在Streams之前,我们往往需要建立一个按时间划分的有序调集(sorted set):有序调集的元素是角逐的ID,做为Hash值存正在于分歧的密钥中。这不只仅意味这要做更多的工做,它还华侈了大量的内存,比你想象的还要多(见后文)。

  这里没有需要向大师展现更多的Streams API消息,相关的内容能够查阅Redis文档。现正在,我们只关心这个利用模式:XADD来添加一些工具, XRANGE(也包罗XREAD)来获取范畴(取决于你想做什么),让我们看看为什么我说Redis Streams做为数据布局是如斯强大。

  虽然如斯,CSV条目标日记正在某种程度上还常棒的:没有固定的布局,字段可能会更改,生成起来很简单,并且终究很是紧凑。Redis Streams的是保留那些好工具,但要降服。其成果是一个取Redis排序集很是类似的夹杂数据布局:它们感受像是一个根基的数据布局,可是为了获得上述的结果,正在内部利用多个暗示。

  Redis Streams是矫捷的,有良多用例,最初简短地总结一下这篇文章。对于很多读者来说,这可能曾经很较着了,但正在过去几个月取人扳谈让我感觉Redis Streams和streaming用例之间存正在强烈联系关系,就仿佛这一数据布局只擅长取此——当然现实并不是如许。

  因而,“append only CSV文件”概念之上的第一个新的笼统概念是,因为我们利用星号做为XADD的ID参数,所以我们能够从办事器免费获得条目ID。如许的ID不只对指向流中的特定项很有用,还取将条目添加到流中的时间相关。现实上,利用XRANGE能够施行范畴查询或获取单个项:

  上述用例不只仅是一个愈加的模式。stream处理方案的内存成本取保守方式比拟,有很大的区别,后者对于每个对象都有一个有序调集 + Hash,这使某些工作会变得不成行,但对于前者完全没问题。

  看起来很简单,大师做了良多年,并且仍然如许做:这似乎是一个固定的模式。可是那正在内存中相当于什么呢?内存比append only文件更强大,能够从动删除CSV文件的如下:

  2、冗余消息太多:每个条目标时间几乎不异,字段反复。同时,若是我想切换到一组分歧的字段,删除它会降低格局的矫捷性。

  4.我无法删除条目,可是若是不克不及通过沉写日记,我只能正在没有垃圾收集功能的环境下将它们标识表记标帜为无效。出于几个缘由,日记沉写一般会很蹩脚,若是能够避免就很好了。

  几天前,我和一个正正在进修Redis的伴侣一路制做了一个使用法式:一个用来本地网球场、球员和角逐的使用法式。正在Redis中为球员建模的体例很是较着,球员是一个小对象,所以只需要一个Hash,环节名称为player:id。当你利用Redis做为次要东西,进一步对使用法式数据建模时,还需要一种方式来给定网球俱乐部的角逐。若是玩家1和玩家2玩了一场,而且玩家1赢了,我们能够正在Streams中写下以下条目:

  从的示例中能够看出,XADD号令从动生成并前往条目ID,该ID是枯燥递增的且包含两个部门:time - counter。时间是毫秒级的,对于条目生成,计数器将会正在不异毫秒内添加。

  此中的差距曾经跨越了一个数量级(精确点说是13倍),这意味着,之前对于内存来说成本太高的用例现正在是完全可行的。此中的奇异之处正在于Redis Streams的暗示:宏节点能够包含几个元素,这些元素以一种很是紧凑的体例编码正在名为listpack的数据布局中。例如,即便整数是语义上的字符串,listpack也会留意以二进制形式编码整数。正在此根本上,我们使用delta压缩和不异字段压缩。我们能够通过ID或时间来查找,由于这种宏节点是正在基数树中链接的,而基数树的设想也是为了利用很少的内存。所有这些要素加正在一路就带来了低内存利用量,但风趣的是,从语义上来说,用户看不到任何使Redis Streams无效的实现细节。

  然而,即便是时间序列最根基的用例,正在此处明显也是一个很是大的用例,由于正在Streams之前,Redis对于如许的用例是无法抱有但愿的。Streams的内存特征和矫捷性,正在加上有上限Stream的能力(拜见XADD选项),是开辟人员手中很是主要的东西。

  3、Item偏移只是文件中的字节偏移量:若是我们更改文件布局,那么偏移量会是错误的,因而这里没有从ID的实正概念。条目根基上没有以某种体例单一处置。

  Redis Streams暗示为由基数树链接正在一路的delta压缩宏节点。其结果是可以或许以很是快的体例寻找随机条目,正在有需要时获得范畴,删除旧项以建立有上限的流,等等。然而,我们为法式员供给的接口很是雷同于CSV文件:

  现正在,我们做一些简单的数算。若是我能够正在大约18 MB的内存中存储100万个条目,那么我就能够正在180 MB中存储1000万个,正在1.8 GB中存储1亿个。只需要18 GB的内存,我就能够具有10亿个项。

  若是你想记实一系列的布局化数据项,而且判断发觉数据库最终仍是被高估了,你可能会如许说:让我们以append only(只附加)模式打开一个文件,并将每一行记实为一个CSV(Comma Separated Value,逗号分隔值)项:

  Redis 5中以“Streams”的表面引入的新Redis数据布局,正在社区中惹起了极大的反应。正在这片文章中,笔者将试图处理如许一个问题:我起头思疑,良多用户只是将Streams做为处理类Kafka(TM)用例的一种方式。现实上,该数据布局的设想也合用于出产者和消费者的动静传送上下文的工做,可是,若是你认为Redis Streams只是为了这个目标而存正在的,那可想的太简单了。Streaming是一种很是棒的模式,能够正在系统设想获得庞大成功时使用,不外Redis Streams取大大都Redis数据布局一样,更为通用,可用于建模十几种分歧的、互不相关的问题。因而,正在这篇文章中,我将把Streams做为一个纯数据布局来关心,完全忽略它的堵塞操做、用户组和所有动静传送部门。

  相关链接: