FASTER

在过去十年中,云中的数据密集型应用程序和服务有了巨大的增长。数据在各种边设施(例如,设备,浏览器和服务器)上创建,并由云应用程序处理用来获得数据价值或做出决策。应用程序和服务可以处理收集的数据,也可以实时监控数据。这些应用程序通常是更新密集型的,并且涉及大量的状态,超出了适合主存储器的处理能力。但是,它们在其访问模式中显示出重要的时间局部性(时间局部性解释维基百科=>https://en.wikipedia.org/wiki/Locality_of_reference)。一种用于点运算的新的键值存储。FASTER将高速缓存优化的并发哈希索引与“混合日志”结合在一起:跨越主内存和存储的并发日志结构记录存储,并且支持内存中“热插拔”的快速就地更新。FASTER扩展了标准键值存储接口,以处理读取 – 修改 – 写入,blind 更新和基于CRDT的更新。实验表明,与当前广泛部署的存储库相比,FASTER在单台机器上实现了更高的吞吐量(每秒高达1.6亿次操作),并且当工作负载大小适合内存大小时,他的性能将远胜于纯内存数据结构的性能。

背景

微软研究团队于2018年6月份在SIGMOD 宣布了一项名为FASTER的新的key-value存储库。FASTER支持快速和频繁的数据查找。它还有助于解决在当今云时代的应用程序更新大量状态信息的问题。

让我们以物联网为一种场景数十亿设备报告和更新状态,如每个设备的性能计数器。这将导致应用程序未充分利用机器上的存储库和网络等资源。他能更快地帮助解决此问题, 因为它利用这些应用程序中的时间位置来控制系统内存占用量。

根据微软的说法,“FASTER是一个单节点共享内存键值存储库”。键值存储是NoSQL数据库,它使用简单的键/值方法进行数据存储。它包含两项重要创新:

  • 缓存友好,并发和latch-free (闩锁释放,解释链接:https://www.dbtan.com/2010/05/latch-free.html)的哈希索引。它维护日志中记录的逻辑指针。FASTER哈希索引是指向一个缓存行大小的 hash buckets数组,每个都有8字节的条目来保存哈希标签。它还包含指向存储记录的逻辑指针。。
  • 一个新的并发和混合日志记录分配器这有助于支持包括快速存储(例如云存储和SSD)和主存储器的索引。

是什么让FASTER与众不同?

传统的键值存储利用日志结构记录数据。但是,FASTER是不同的,因为它有一个混合日志,它结合了日志结构和读取副本更新(适用于外部存储)和就地更新(适用于性能更高的内存)。因此,位于存储器中的混合日志的头部使用读取 – 复制 – 更新,而主存储器中的混合日志尾部使用就地更新。内存中有一个位于这两个区域之间的只读区域。它为核心记录提供了另一个被复制回尾部的机会。这捕获了更新的临时位置,并允许在内存中自动的收集热记录。

因此,FASTER甚至能够超越英特尔TBB hash map等纯内存数据结构。微软表示,它的性能远远优于今天流行的诸如RocksDB和Redis等键值存储的缓存系统。

除此之外,FASTER还为故障恢复提供支持,因为它包含一个恢复策略,有助于将系统以低成本恢复到最近的一致状态。这与传统数据库系统中的恢复机制不同,因为它不涉及阻止或创建单独“预写的日志”。

有关更多信息,请查看官方研究报告

FASTER项目Github地址:https://github.com/Microsoft/FASTER

 价值:

有人会问,有了这个FASTER,既然他速度这样快是不是可以代替redis或者mongodb,答案是目前不能,因为FASTER是内核级的,和Google的leveldb差不多层级,FASTER速度非常快毋庸置疑,但是目前缺少更高复杂业务场景的支持,比如集群,数据一致性之类的商用需求,不过如此诱人的性能必定吸引更多的人去投入FASTER中开发出类似redis和mongodb的产品出来,性能也必定更强,说不定redis后期底层就用FASTER改写了。

版权声明:本文为xiaoliangge原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/xiaoliangge/p/9539735.html