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改写了。