小蚂蚁与大象

在第二阶段，每个节点(i)将它的数据块加载到内存中，(ii)计算它们的iSAX摘要并将它们存储到多个摘要缓冲区中，以实现局部性，以及(iii)建立它的索引树。它形成节点组(复制组，见3.3节)，每个组的所有节点存储相同的数据块。这样做的意义并不明显）当然文中对数据的分组划分，在分布式系统中是常见的方法，文中缺少对协调者的选择和组之间通信，以及组怎样划分的细节文中没有提到，这是有些遗憾的部分，同时组中的成员不一定是固定不变的，可能随着时间成员会发生变化，这在分布式系统中是很常见的现象，但是文中并没有考虑。

针对并发访问问题，本文采用一种无锁设计，其灵感来自现有的无锁结构[19,50]，并对其进行扩展以支持HotRing所需的所有操作，包括热点移位检测、头指针移动和有序环rehash。在我们的设计中，链条中的最后一件物品与第一件物品相连，形成一个碰撞环。本文提出HotRing，一种在内存KVS中感知热点的哈希索引，利用优化的哈希索引对一小部分项目进行大规模并发访问，即热点。1）热点问题(即，在高度倾斜的工作负载中频繁访问的一小部分项目)是现实场景中的常见问题，并且在文献中得到了广泛的研究。

对于预测的工作负载跟踪中的每个轮班，SOPHIA与任何现有的静态配置调优器(我们在工作中使用RAFIKI，因为它已经为NoSQL数据库设计，并且是公开可用的[15])进行交互，以快速为新的工作负载提供最佳点配置，并从这个新配置中估计收益。针对三种不同的工作负载，证明了其有效性:一个多租户的全球规模的宏基因组学存储库(MG-RAST)、一个总线跟踪应用程序(Tiramisu)和一个高性能计算数据分析系统，所有这些都具有不同程度的工作负载复杂性，并展示了动态工作负载变化。(2)预测新的工作负载模式的暂态性。

为了预先确定无限循环的发生，CoCuckoo利用一个包含多个子图的有向伪森林来利用表示物品之间关系的布谷鸟路径。CoCuckoo发现共享布谷鸟路径的插入操作会访问相同的子图，因此需要一个锁来确保并发控制的正确性，即一次只允许一个线程访问共享路径;同时，伪森林只是cuckoo散列表的一个变体，并不会被存储。每个桶的元数据包括键所对应的值的位置(v pos)、桶所属子图的子图编号(sub id)。CoCuckoo利用一个包含多个子图的有向伪森林表示元素之间的哈希关系，用于表示插入操作中的布谷鸟路径。

SGCNAX采用基于外部产品的计算架构来缓解处理元素内部的负载不平衡，并采用分组和shuffle的方法来缓解处理元素之间的负载不平衡。仿真结果表明，与HyGCN、AWB-GCN和gcnax相比，SGCNAX的访问性能分别提高了9.2、1.6和1.2，访问次数分别减少了9.7、2.9和1.2。本文系统地探索了用于gcn加速的循环优化技术，并提出了一种灵活的GCNdataflow，可以适应不同的gcn配置以实现最优效率。提出的方法带来了显著的速度提升，比目前最先进的并行CPU算法快了一个数量级。

最后，SpanDB基于对两个分区的实时带宽监控，能够进行动态的树级布局。由于大型的、写密集型的KV存储不可避免地会占用大量的冷数据，将所有数据存储在这些相对较小且昂贵的设备上可能超出了用户或云数据库服务提供商的预算。•通过合并一个相对较小但速度较快的磁盘(SD)，它扩展了对最新数据的所有写和读处理，同时将数据存储扩展到一个或多个更大、容量更低的磁盘(CD)上。它根据KV系统的实际工作负载，有策略地、自适应地对数据进行分区，积极调动CD的I/O资源，特别是带宽，以帮助共享当前KV系统中常见的写放大。

注意，括号中的键不是元数据的一部分。同时，将当前指针设置为指向该段的第一个run选择器(0，图中的第五个选择器)，表示当前键(11)在R0的游标下。后续的键(23、29、31…当缓存中的更新达到一个阈值时，MemTable会被转换成一个不可变的MemTable进行合并，并创建一个新的MemTable来接收更新。分区中的合并会创建分区的新版本，其中包含新旧表文件的混合，以及新的REMIX文件。基于lsm树的设计体现了更新代价和搜索代价之间的权衡，与B+树相比，lsm树保持了较低的更新代价和较高的搜索代价。

一个存储引擎能通过调参来适应不同工作负载是很重要的；对于使用 SSD 的大部分应用来说，系统瓶颈是在 SSD 容量上；降低 CPU 开销也变得越来越重要；如果一台机器上运行了多个 RocksDB 实例，那全局的资源管理就会变得很必要；提供不同的 WAL 文件处理方式可以给上层应用带来性能提升；SSD TRIM 是个好命令，然而需要对文件删除操作进行限速以避免偶发性的性能问题；RocksDB 需要同时具有向前及向后兼容性；配置的自适应性对于简化配置管理来说很有帮助；

HashKV遵循KV分离[23]，在lsm树中只存储键和元数据，用于索引KV对，而值存储在一个单独的区域中。在KV分离的基础上，HashKV引入了几个核心设计元素，实现了高效的价值存储管理。KV分离通过仅将键存储在lsm树中，而将值存储在单独的存储中，从而减轻了I/O放大的影响。它支持标准的KV操作:PUT(即写一个KV对)、GET(即取得一个键的值)、DELETE(即删除一个KV对)和SCAN(即取得一个范围内的键的值)。HashKV是一个持久的KV存储，专门针对更新密集型的工作负载。

更多的细节这里没有详细描述，感兴趣的读者可以详细阅读这篇论文和论文里面提到的参考文献，并结合LevelDB和RockDB I/O流程和 Compaction机制，相应大家对LSM-tree的一些关键设计和问题都会有一个更清晰的认识。

因此，新的sstable中的段也是新生成的，它们的热度也应该改变。如果我们将新段的热度设置为0，那么ElasticBF将面临热度的冷启动，这可能会降低未来从新段读取的性能。然而，布隆过滤器存在误报问题，简单地增大布隆过滤器的大小会带来较大的内存开销，因此在内存受限的系统中仍然会造成额外的I/ o。对于热度识别，我们的目标是以较低的开销实现相对准确的热度估计。如果SSTable变热，我们将加载更多的布隆过滤器到内存中，当它变冷时，我们也可以禁用内存中的一些布隆过滤器。图4描述了ElasticBF的架构，

索引的模式如图1所示。之后，对于每个数据块，我们创建一个索引块，其中包含数据提取所需的元信息和一组指标——数据块的聚合统计信息，例如最小值、最大值或平均值。块元包括以下字段:数据块中元素的数量，编码表示的长度(更多细节请参见2.2节)，以及编码表示是否被压缩的标志。依赖时间序列数据处理的科学和工业领域的快速发展，提高了对能够高效处理几十甚至几百tb数据的存储的需求。本文提出了一种存储和索引数值时间序列的概念，允许创建为云存储优化的紧凑数据表示，并高速执行典型操作——上传、提取、采样、统计聚合和转换。

ARC用于DRAM中的Page替换。一般来说f(m)=m+2, 这个式子可以这么理解，如果我们为了找到一个key，访问了m个SST文件，假设每次磁盘IO可以读取一个SST文件的bloom过滤器，那么此时的IO开销为m，再假设SST文件的indexblock和一个datablock都可以通过一次IO获取到，那么f(m)=m+2。一般来说，缓冲区不可能持续增长，它的总大小是固定的，那么在一个固定的总大小下，ARC如何确定recency-cache-LRU与frequency-cache-LRU的大小比例呢？

本文全面研究了缓存KV、KP和块之间的权衡，并提出AC-Key，一种基于lsm的键值存储的自适应缓存，以结合它们在处理不同工作负载方面的优势。AC-Key利用一种新的缓存效率因子来量化不同的缓存成本和收益，以辅助缓存组件之间的边界调整以及每个缓存组件内的替换决策。AC-Key综合考虑了不同缓存项的异构代价和收益以及LSM-KVS独特的层次化结构，利用缓存效率因子定量地指导缓存组件之间的缓存大小调整以及缓存组件内部的替换策略。首先，LSM具有多级设计，每个缓存的键-值对(缓存好处)保存的存储I/O可能不同。

本节描述了如何选择守卫(§3.2)，如何插入和删除守卫(§3.3)，如何执行FLSM操作(§3.4)，如何针对不同的性能/写io权衡(§3.5)对FLSM进行调优，以及它的局限性(§3.6)。本文提出了一种新的数据结构——碎片化日志结构合并树(fragment - Log-Structured Merge Trees, FLSM)，它结合了跳跃表[47,48]和日志结构合并树的思想，并提出了一种新的合并算法。像LevelDB和RocksDB这样的键值存储提供了很好的写吞吐量，但受到了很高的写放大。

在128个节点的EC2集群上的实验结果表明，在Yahoo Streaming测试基准上，Drizzle可以获得小于100ms的端到端记录处理延迟，并且可以获得比Spark低2 ~ 3倍的延迟。我们认为可以从另一个方向出发，即从一个连续的操作员系统开始，修改它以添加对具有周期性集中协调的任务的支持，并获得类似的好处。2. 在这样的系统中，从故障中恢复(或适应变化)是昂贵的，因为即使是在单台机器故障的情况下，所有操作符的状态都必须重置到最后一个检查点，并且必须从该点恢复计算。我们的主要观察结果是，

目前的框架主要是针对单人训练案例设计的。遵循数据流依赖关系，提前为每个DNN内核计算分配所需的内存，并为GPU流发放尽可能多的内核，即为每个作业的GPU计算发放工作队列，以饱和GPU内部的计算资源。作为一个目前构建在TensorFlow之上的系统，该框架持续跟踪每次训练中使用的内存的寿命，并产生并发训练执行的时间表，以避免GPU内存超额订购。最近的一些工作提出了跨多个并行DNN训练作业共享GPU资源的解决方案，但都没有解决这种作业共存所带来的快速增加的内存占用问题，这极大地限制了共享GPU资源的有效性。

A Unified Architecture for Accelerating Distributed DNN Training in Heterogeneous GPU/CPU Clusters运行DNN训练任务的数据中心集群本质上是异构的。他们有用于计算的gpu和cpu，以及用于分布式训练的网络带宽。然而，现有的分布式DNN训练架构all-reduce和Parameter Server (PS)不能充分利用这些异构资源。本文提出一种新的分布式DNN训练架构BytePS。BytePS可以利用集群中空闲的C

其核心思想是利用神经网络模型的分层结构及其逐层计算模式，以模型感知分组的方式将模型在PCIe上的传输和任务在GPU上的执行流水线化。在多种DL模型和GPU卡上的实验表明，PipeSwitch仅产生3.6 ~ 6.6 ms的任务启动开销和5.4 ~ 34.6 ms的总开销(比NVIDIA MPS提高了10 ~ 50倍)，并实现了接近100%的GPU利用率。(i)通过细粒度的分时共享，使许多深度学习应用在GPU服务器上实现GPU高效复用，(ii)实现毫秒级的延迟和专用服务器的高吞吐量。目前的主流做法是提供。

更好的方法是测量操作员时间轴的有用时间，确定o1的真实速率为10 rec/s, o2的真实速率为200 rec/s，推断当o1的并行度增加到4时，o2的并行度也需要加倍才能跟上输出速率。DS2由实现§3.2模型的扩展策略组件和监控存储库的扩展管理器组成，当有新的度量可用时调用策略，并向流处理器发送扩展命令。本文确定了当前系统缺乏我们想要的控制器属性的两个领域:首先，所使用的指标没有提供足够的信息来就如何重新调整系统做出快速和准确的决定，其次，用于扩展的策略(以及它们所基于的模型)通常是简单的和基于规则的。

对于一个代表性的查询，我们的原型的性能比广泛使用的MySQL/memcached栈和商业数据库的物化视图高出2-10倍，它还将查询扩展到ec2vm集群上每秒数百万次的写操作和数千万次的读操作，优于最先进的数据流系统differential data flow。对Noria来说，仅仅维护最近的状态窗口是不够的，它需要存储所有的持久状态。这就是论文标题中的“部分有状态数据流”部分，因为Noria有一种机制，可以在内存中只保留记录的一个子集，并根据需要重新计算上游运算符（最终是基表）的任何缺失值。

Noria提供了高级查询接口(SQL)，但与传统系统不同的是，Noria通过尽可能返回预先计算的结果来加速复杂自然查询的执行。Noria证明，与传统观点相反，为所有应用查询维护物化视图是可行的。我们的实现Noria简化了需要大量读取的web应用程序的后端基础设施，同时提高了它们的性能。Noria的数据流操作符状态是局部的而不是窗口的，只保留应用程序查询过的记录的子集。现有的数据流系统要么不能对状态[36,52,75]执行细粒度的增量更新，要么使用“窗口”状态限制操作符状态的增长(例如，本周的故事)。

在4个使用单GPU的小规模数据集和2个使用多GPU的大型数据集上评估了tgl的性能，用于链接预测和节点分类任务。将TGL与5种方法的开源代码进行比较，TGL取得了类似或更好的精度，平均加速比为13倍。在一个4-GPU的机器上，TGL可以在1-10小时内训练一个超过10亿个时间边的epoch。据我们所知，这是第一项提出在多gpu上训练大规模时序图神经网络的通用框架的工作。一种用于大规模离线时序图神经网络训练的统一框架，用户可以用简单的配置文件组成各种时序图神经网络。许多现实世界的图包含时域信息。

例如，在图2(a)的底部，给定一个SRQ𝑞，由于𝑞与轨迹𝑇的MBR(最小边界矩形)相交，它需要获取𝑇来验证结果。然后，针对5种广泛使用的轨迹距离函数设计了统一的剪枝策略，并针对5种高级查询设计了大量定制的处理算法。我们提出VRE，一种多功能、健壮、经济的基于磁盘的轨迹管理系统，在存储层和处理层都有精心设计(见图1)。阅读者总结：这篇论文是轨迹数据操作的集成系统，可以看得出来，从存储到上层的查询都进行了有效的处理。在存储层，提出一种新的基于段的存储模型，利用基于点和基于轨迹的存储模型的优势。

ZooKeeper: Wait-free coordination for Internet-scale systems本文描述了一种分布式应用程序进程协调服务——ZooKeeper。由于ZooKeeper是关键基础设施的一部分，ZooKeeper的目标是提供一个简单的高性能内核，用于在客户端构建更复杂的协调原语。它将来自组消息传递、共享寄存器和分布式锁服务的元素合并到一个复制的集中服务中。ZooKeeper公开的接口具有共享寄存器的免等待特性，并具有类似于分布式文件系统缓存失效的事件驱动机制，从而提供

The Google File SystemABSTRACT我们设计并实现了谷歌文件系统，这是一个可扩展的分布式文件系统，适用于大型分布式数据密集型应用程序。它在廉价的商用硬件上运行时提供容错功能，并为大量的客户端提供较高的聚合性能虽然与以前的分布式文件系统有许多相同的目标，但我们的设计是由对应用程序工作负载和技术环境(当前和预期的)的观察驱动的，这些观察反映了与以前一些文件系统假设的明显背离。这促使我们重新审视传统的选择，探索完全不同的设计点。 文件系统已经成功满足了我们的存储需求...

The Chubby lock service for loosely-coupled distributed systems我们描述了自己使用Chubby锁服务的经历，该服务旨在为松耦合的分布式系统提供粗粒度锁和可靠(但容量较小)的存储。Chubby提供了一个很像分布式文件系统的接口，带有建议锁，但是设计重点是可用性和可靠性，而不是高性能。该服务的许多实例已经使用了一年多，其中几个实例分别处理数万个客户机。本文描述了最初的设计和预期的用途，将其与实际用途进行了比较，并解释了如何修改设计以适应差异1

Spanner: Google’s Globally-Distributed DatabaseSpanner 是谷歌公司研发的、可扩展的、多版本、全球分布式、同步复制数据库。它是第一个把数据分布在全球范围内的系统，并且支持外部一致性的分布式事务。本文描述 了 Spanner 的架构、特性、不同设计决策的背后机理和一个新的时间 API，这个 API 可以暴 露时钟的不确定性。这个 API 及其实现，对于支持外部一致性和许多强大特性而言，是非常 重要的，这些强大特性包括：非阻塞的读、不采用锁机制的只读事务.

Scaling Memcache at Facebook概要：Memcached 是一个知名的，简单的，全内存的缓存方案。这篇文章描述了facebook是如何使用memcached来构建和扩展一个分布式的key-value存储来为世界上最大的社交网站服务的。我们的系统每秒要处理几十亿的请求，同时存储了几万亿的数据项，可以给全世界超过10亿的用户提供丰富体验。1.摘要1.1.文关注于memcached，这是一个全内存哈希表的开源实现，它以较低的开销提供了对共享存储的低迟延访问。有了这些特性我们可以

Scaling Distributed Machine Learning with the Parameter Server摘要： 我们提出了一个用于分布式机器学习问题的参数服务器框架。数据和工作负载都分布在工作节点上，而服务器节点维护全局共享的参数，这些参数表示为密集或稀疏的向量和矩阵。该框架管理节点之间的异步数据通信，支持灵活的一致性模型、弹性伸缩性和持续的容错。为了演示所提框架的可伸缩性，我们展示了在pb级真实数据上的实验结果，包括数十亿个示例和参数，涉及问题从稀疏逻辑回归到潜在狄利克雷分配和分布

Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing 我们提出了弹性分布式数据集(rdd)，这是一种分布式内存抽象，允许程序员以容错的方式在大型集群上执行内存计算。rdd是由当前计算框架处理效率低下的两种应用程序驱动的:迭代算法和交互式数据挖掘工具。在这两种情况下，将数据保存在内存中可以提高一个数量级的性能。为了有效地实现容错，rdd提供了一种受限制的共享内存形式，基...

MapReduce: Simplified Data Processing on Large ClustersMapReduce是一个用于处理和生成大型数据集的编程模型和相关实现。用户指定处理键/值对的map函数来生成一组中间键/值对，以及合并与同一中间键相关的所有中间值的reduce函数。如本文所示，该模型可以表达许多现实世界中的任务。用这种函数式风格编写的程序可以自动并行化，并在大型的商品机器集群上执行。运行时系统负责对输入数据进行分区、跨一组机器调度程序执行、处理机器故障和管理所需的机器间通信

LSM-based Storage Techniques: A Survey回顾了LSM-tree的历史，以及leveling和tiering两种合并方式，接着介绍布隆过滤器和分区（对于tiering还有两种分区方案）这两个普遍的优化，简要带过并发控制和恢复技术后，最后在写，点查询，范围查询，空间放大等角度分析了两种合并方式的开销。1 Introduction1)日志结构的合并树(LSM-tree)被广泛应用于现代NoSQL系统的存储层.LSM树首先在内存中缓冲所有写操作，然后将它们刷新到磁盘，

In Search of an Understandable Consensus Algorithm(Extended Version)摘要：Raft是一种用于管理日志复制的一致性算法。它能和Paxos产生同样的结果，有着和Paxos同样的性能，但是结构却不同于Paxos；Raft比Paxos更易于理解，并且能够为实际的系统构建提供更好的基础。为了增强可理解性，Raft将一致性涉及的例如leader 选举, 日志复制及安全性等关键元素进行了分离，并且提供了更强的一致性以减少必须考虑的状态。基于实际的个人

Dynamo: Amazon’s Highly Available Key-value Store大规模的可靠性是我们亚马逊面临的最大挑战之一，亚马逊是世界上最大的电子商务运营公司之一;即使是最轻微的故障也会造成严重的财务后果，并影响客户信任。亚马逊平台为全球许多网站提供服务，它是在位于世界各地许多数据中心的数万台服务器和网络组件的基础设施之上实现的。在这种规模下，大大小小的组件都会不断地发生故障，在这些故障面前管理持久状态的方式会提高软件系统的可靠性和可伸缩性。本文介绍了Dynamo的设计和实现，

Druid是一个开源的数据存储，专为大型数据集的实时探索性分析而设计。该系统结合了面向列的存储布局、分布式的、无共享的体系结构和高级索引结构，允许任意探索具有次秒延迟的10亿行表。在本文中，我们描述了Druid的架构，并详细说明了它是如何支持快速聚合、灵活过滤和低延迟数据吸收的。近年来，随着互联网技术的普及，机器生成的事件激增。单独来看，这些事件包含的有用信息很少，价值也很低。考虑到从大型事件集合中提取意义所需的时间和资源，许多公司愿意放弃这些数据。虽然已经建立了处理基于事件的数据的基础设施(如IBM.

Cassandra是一个分布式存储系统，管理分布在很多商业服务器节点上的非常大量的结构化数据，同时提供无单点失效的高可用服务。Cassandra目标是在几百个基础节点上运行（可能分布在不同的数据中心）。在这个规模上，大大小小的组件经常失效。Cassandra对这些失败持久状态的管理方式促使软件系统的可靠性和扩展性依赖这一服务。虽然在许多方面Cassandra类似于一个数据库，并且共享很多设计和相关实现策略，但Cassandra并不支持完整的关系数据模型；相反，它为客户提供了一个支持动态控制数据布局并且格式简

Bigtable: A Distributed Storage System for Structured Data Bigtable是一种分布式存储系统，用于管理结构化数据，旨在扩展到非常大的规模:跨越数千台商品服务器的pb级数据。谷歌的许多项目都在Bigtable中存储数据，包括web索引、谷歌Earth和谷歌Finance。这些应用程序对Bigtable提出了非常不同的要求，无论是在数据大小(从url到web页面到卫星图像)和延迟需求(从后端批量处理到实时数据服务)方面。尽管有这些不同的需...