An in-depth look at database and cache internals, and the tradeoffs in each. ScyllaDB 希望向 dormando (Memcached 维护者) 和 Danny Kopping 公开表扬他们对该项目的贡献,并感谢他们对支持和耐心。 睡觉 丹尼·科普 ScyllaDB背后的工程师 - 规模可预测性能的数据库 - 与Memcachediner dormando合力,以合作的供应商中立的方式对两种技术进行对比。 结果表明: 
 
 
 
 Memcached 和 ScyllaDB 都最大限度地提高了磁盘和网络带宽,同时在类似的条件下保持了类似的性能。 虽然ScyllaDB需要数据建模改变以完全饱和网络输出量,但Memcached需要额外的IO线程来饱和磁盘I/O。 虽然与 Memcached 管道请求到磁盘相比,ScyllaDB 显示了更好的延迟,但 Memcached 延迟对于单个请求来说更好。 本文件解释了我们对这些测试的动机,提供了测试的场景和结果的摘要,然后为任何可能在ScyllaDB和Memcached之间做出决定的人提出建议。 也有 通过更广泛的测试和结果,并链接到具体的配置,您可以使用自己执行测试。 这个项目的详细的Gitbook, 
 
 
 奖金:我和Dormando最近在P99 CONF上讨论了这个项目,这是一个关于性能和低延迟工程的高技术会议。 观察需求 奖金:我和Dormando最近在P99 CONF上讨论了这个项目,这是一个关于性能和低延迟工程的高技术会议。 Watch on demand 观察需求 为什么我们做到了这一点? 首先,ScyllaDB 投入了大量的时间和工程资源来优化我们的数据库,以便为实时数据密集型应用提供可预测的低延迟。 没有共享的建筑, 和 (完全绕过Linux页面缓存)是此类优化的一些显着例子。 黑色 核心 用户空间 I/O 时间表 内部缓存实施 其次,性能随着时间的推移而趋同,内存缓存已被认为是最快的基础设施组件之一(长期以来)。 If an in-memory cache can rely on flash storage, then why can’t a persistent database also work as a cache? 第三,我们之前讨论过 并最近探讨了具体的团队如何成功 . 不要在数据库前置缓存的7个理由 用 ScyllaDB 取代他们的缓存 第四,在去年的P99 CONF上,Danny Kopping给了我们一个启发性的演讲, ,他解释了Memcached Extstore如何帮助Grafana Labs在降低成本的同时,扩大其缓存足迹的42倍。 隐藏我如果你能 最后,尽管性能基准获得了(有效的)批评,但它们仍然在推动创新方面发挥着重要作用。 现在,回到比较。 设置 法院 使用以下 AWS 实例类型进行测试: 
 
 
 
 充电器: c7i.16xlarge(64 vCPU,128GB RAM) Memcached: i4i.4xlarge (16 vCPU, 128GB RAM, 3.75TB NVMe) ScyllaDB: i4i.4xlarge (16 vCPU, 128GB RAM, 3.75TB NVMe) 所有机构都可以提供 25Gbps网络带宽. 请记住,特别是在测试中最大限度地实现所承诺的网络容量时,我们注意到 . 向上 throttling 缩小带宽到实例的基线容量 优化和设置 为了克服潜在的瓶颈,应用了以下优化和设置: 
 
 
 
 AWS 侧面:所有实例都使用了集群放置策略,遵循 AWS 文档:“此策略允许工作负载实现对于紧密连接的节点到节点通信所需的低延迟网络性能,这是典型的高性能计算 (HPC) 应用程序。 Memcached: 版本 1.6.25 编译与 Extstore 启用. 除了指定的外,运行14个线程,附加到特定CPU。 剩余的 2 个 vCPU 被分配给 CPU 0 (核心和 HT 兄弟) 以处理网络 IRQ,如在 seastar perftune.py 中的 sq_split 模式规定的。 CAS 操作被禁用以节省每个项目的空间。 完整的命令行参数为:taskset -c 1-7,9-15 /usr/local/memcached/bin/memcached -v -A -r -m 114100 -c 4096 -lock-memory -threads 14 - scylla -C ScyllaDB:由 ScyllaDB Enterprise 2024.1.2 AMI (ami-id: ami-018335b47ba6bdf9a)在 i4i.4xlarge 中配置的默认设置。 压力者 对于 Memcached 装载器,我们使用 ,是 memcached 官方测试套件的一部分,适用的突出配置文件在 GitHub 存储库。 麦克斯雷德 / 对于 ScyllaDB,我们使用 ,如与ScyllaDB交付,并指定与Memcached使用的相似工作负载。 卡桑德拉压力 测试与结果 以下是我们进行的测试及其结果的摘要. 如果您想要更详细的描述和分析,请访问 . 该项目的扩展写作 RAM 缓存效率 您可以在RAM中放入的项目越多,获取缓存打击的机会就越好. 更多的缓存打击会导致比去到磁盘更快的访问。 这个项目始于测量我们可以存储到每个数据库的项目数量,在整个测试中,Memcached 的密钥为 4 到 12 个字节(key0 .. keyN),而 ScyllaDB 的密钥为 12 个字节。 记忆 Memcached 存储了大约 101 万件物品,直到驱逐开始。 它具有高效的内存。 在 Memcached 的 114G 分配内存中,这是大约 101G 的值,而不考虑密钥大小和其他旗帜: ScyllaDB ScyllaDB 在驱逐开始之前存储了 60 万至 61 万个项目,这并不奇怪,因为其协议需要作为写作的一部分存储更多的数据(例如从时代开始的写入时间印记,行活力等)。   Takeaways   
 
 
 
 Memcached 存储的内存项目比 ScyllaDB 多约 65%。 ScyllaDB 行具有较高的每个项目上图,以支持宽列定向。 在ScyllaDB中,Bloom 过滤器、索引缓存和其他组件也被存储在内存中,以支持高效的磁盘搜索,有助于创造另一个重叠层。 仅阅读的内存工作负载 该 (尽管不切实际的)缓存工作负载是所有数据都适合内存 - 因此读取不需要磁盘访问,不会发生疏散或错误。 ScyllaDB 和 Memcached 都使用 LRU (最不最近使用) 逻辑来释放内存:当系统在压力下运行时,项目会从 LRU 的尾巴中被疏散;这些通常是最不活跃的项目。 理想 将删除和缓存漏洞从图像中删除有助于衡量并为两个数据库设定性能基线,它将重点放在这些类型的工作负载中最重要的方面:读取流量和请求延迟。 在这项测试中,我们首先加热了前一次测试中使用的相同可用负载尺寸的两家商店,然后,我们开始对其各自范围进行30分钟的读取。 Memcached Memcached 实现了令人印象深刻的每秒 300 万次获取,最大限度地提高了 AWS NIC 带宽(25 Gbps)!   Memcached 保持了稳定的 3M rps,完全最大限度地提高了 NIC 输出量 巴塞尔 显示 p99.999 回复完成于 1ms 以下: 结果 此分類下載: cmd_get : 总操作量: 5503513496 速度: 3060908 / 秒 0 0 0 0 0 0 0 0 0 10-99us 343504394 6238% 100 - 999us 5163057634 93.762% 1-2ms 11500 0.00021% ScyllaDB 为了在 ScyllaDB 中阅读更多行,我们需要为客户端请求设计一个更好的数据模型,因为协议特征(特别是没有管道)。 因此,与之前显示的关键值数字相比,缓存中的记录数量显著提高。 正如 dormando 正确地指出的(谢谢!),这种配置与以前的 Memcached 设置有显著不同. 虽然 Memcached 工作负载总是会击中单个键值对,但在 ScyllaDB 中的单个请求会导致返回多个行。 我们解释了这些变化的原因。 在那里,我们涵盖了 CQL 协议的特征(例如每项对接(与 memcached 相比),并且没有支持管道),这使得 ScyllaDB 上的宽分区比单键采集更有效。 在详细的写作中 通过这些调整,我们的加载器在 30 分钟内运行了总计 187K 读取操作 / 秒. 每个操作导致 16 行被检索。 与 memcached 类似,ScyllaDB 也最大限度地提高了 NIC 输出量,仅从内存数据中提供大约 3 万行/秒服务:     ScyllaDB 暴露了服务器侧延迟信息,这对于分析没有网络的延迟是很有用的。   客户端百分位比服务器侧延迟更高,读数P99为0.9ms。   Takeaways 
 
 
 
 Memcached 和 ScyllaDB 都完全饱和了网络;为了防止每秒最大网络包饱和,Memcached 依赖于请求管道,而 ScyllaDB 则转向宽列方向。 ScyllaDB的缓存显示了大幅列图的显著收益,与以前的简单的关键值定位相比,可以存储更多的项目。 在协议层面上,Memcached的协议更简单和轻量级,而ScyllaDB的CQL提供更丰富的功能,但可以更重。 将磁盘添加到图片中 测量闪存性能带来了独特的挑战,这使得完全现实地描述给定的工作负载几乎是不可能的。 对于与磁盘相关的测试,我们决定衡量最悲观的局面:比较两个服务数据(主要是)从区块存储的解决方案,知道: 
 
 
 这样做的现实工作负载的概率在某个地方接近零 在实践中,用户应该期望在以前乐观的缓存工作负载和悲观的磁盘相关工作负载之间的数字。 Memcached Extstore 该 在高层次上,它允许 memcached在内存中保留其哈希表和密钥,但存储值到外部存储中。 超级维基页面 在我们的测试中,我们填充了 1.25B 元素的 memcached,其值大小为 1KB,密钥大小高达 14 字节:   通过Extstore,我们与以前的内存工作负载相比,存储了大约11倍的项目数量,直到删除开始启动(如上图中的右侧面面板所示)。 Read-Only Performance 对于实际的性能测试,我们强调了Extstore对1KB和8KB的项目大小。 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Test Type 
 Items per GET 
 Payload Size 
 IO Threads 
 GET Rate 
 P99 
 
 
 
 
 
 
 
 perfrun_metaget_pipe 
 16 
 1KB 
 32 
 188K/s 
 4~5 ms 
 
 
 
 
 
 
 
 perfrun_metaget 
 1 
 1KB 
 32 
 182K/s 
 <1ms 
 
 
 
 
 
 
 
 perfrun_metaget_pipe 
 16 
 1KB 
 64 
 261K/s 
 5~6 ms 
 
 
 
 
 
 
 
 perfrun_metaget 
 1 
 1KB 
 64 
 256K/s 
 1~2ms 
 
 
 
 
 
 
 
 perfrun_metaget_pipe 
 16 
 8KB 
 16 
 92K/s 
 5~6 ms 
 
 
 
 
 
 
 
 perfrun_metaget 
 1 
 8KB 
 16 
 90K/s 
 <1ms 
 
 
 
 
 
 
 
 perfrun_metaget_pipe 
 16 
 8KB 
 32 
 110K/s 
 3~4 ms 
 
 
 
 
 
 
 
 perfrun_metaget 
 1 
 8KB 
 32 
 105K/s 
 <1ms 16 1KB 32 188K / 秒 4 - 5 ms 代码 - 代码 1 1KB 32 第182章 · 1ms 16 1KB 64 第261章 5 - 6 ms 代码 - 代码 1 1KB 64 256K / 秒 1～2ms 16 8KB 16 92K / 秒 5 - 6 ms 代码 - 代码 1 8KB 16 90K / 秒 · 1ms 16 8KB 32 110K / 秒 3 - 4 ms 代码 - 代码 1 8KB 32 105K / 秒 · 1ms ScyllaDB 虽然 ScyllaDB 显示了比 memcached 更高的 GET 率,但与 memcached 的非管道工作负载相比,尾巴延迟略高。 
 
 
 
 
 
 
 
 
 
 
 
 Test Type 
 Items per GET 
 Payload Size 
 GET Rate 
 Server-side P99 
 Client-side P99 
 
 
 
 
 
 
 
 1KB Read 
 1 
 1KB 
 268.8K/s 
 2ms 
 2.4ms 
 
 
 
 
 
 
 
 8KB Read 
 1 
 8KB 
 156.8K/s 
 1.54ms 
 1.9ms 1KB 阅读 1 1KB 第268章 2ms 四、MS 8KB 阅读 1 8KB 第158章 第一百五十五章 1.9 米 Takeaways 
 
 
 
 Extstore 需要对其设置进行大量调节,以便完全饱和闪存存储 I/O。 由于 Memcached 架构,较小的负载无法充分利用可用的磁盘空间,与 ScyllaDB 相比,提供较小的收益。 ScyllaDB 率总体上高于 Memcached 在关键值定位中,特别是在更高的负载大小下。 过度写作工作 然后,根据我们之前的磁盘结果,我们比较了两个解决方案,其中主要是读取工作量,目标是相同的输出量(250K ops/sec)。 ,有10%的随机重写,被认为是“半坏的情况”。 “基本”测试为Extstore Memcached Memcached在测试期间获得了略低于249K的速率,尽管在测试期间写率保持稳定,但我们观察到读数略有波动。 : 在整个跑步   此外,我们还观察到略高 尽管读数比率下降,但延迟仍然很低,这些结果如下所述: 
 
 
 
 
 
 
 
 
 
 Operation 
 IO Threads 
 Rate 
 P99 Latency 
 
 
 
 
 
 cmd_get 
 64 
 224K/s 
 1~2 ms 
 
 
 
 
 
 cmd_set 
 64 
 24.8K/s 
 <1ms 64 224K / 秒 1 - 2 ms cmd 设置 64 24.8 K / 秒 · 1ms ScyllaDB ScyllaDB 测试使用了 2 个加载器,每个加载器都具有目标速度的一半。尽管 ScyllaDB 实现了略高的输出量(259.5K),但在整个运行过程中写延迟保持低,读延迟更高(类似于 memcached):   下表概括了两个加载器的客户端运行结果: 
 
 
 
 
 
 
 
 
 
 Loader 
 Rate 
 Write P99 
 Read P99 
 
 
 
 
 
 loader1 
 124.9K/s 
 1.4ms 
 2.6 ms 
 
 
 
 
 
 loader2 
 124.6K/s 
 1.3ms 
 2.6 ms 托马斯1 第129章 1.4 米 2.6 米斯 加载2 第126章 十三ms 2.6 米斯 Takeaways 
 
 
 
 Memcached 和 ScyllaDB 的写入率均保持稳定,读取率在整个过程中略有波动。 ScyllaDB 仍然为 commitlog overhead 写信,它坐落在热写路径中 ScyllaDB 服务器侧延迟与 Memcached 结果中观察到的延迟相似,尽管客户端延迟略高。 阅读该项目的Gitbook中更详细的分析 包装上 memcached 和 ScyllaDB 都成功地在所有测试中最大限度地利用了潜在的硬件,并保持了可预测的延迟。 如果您的现有工作量可以容纳简单的关键值模型,并且它受益于管道化,那么 memcached 应该更适合您的需求。 坚持Memcached的另一个原因是:它很容易提供比NIC能够维持的更远的流量。 , dormando提到,他可以将其扩展到超过5500万读取操作/秒的相当大的服务器,考虑到这一点,你可以使用更小的和/或更便宜的实例类型来维持类似的工作负载,只要可用的内存和磁盘足迹足够你的工作负载需求。 黑客新闻 thread 另一个要考虑的角度是数据集的大小. 虽然Extstore通过允许您存储超出RAM的项目提供了巨大的成本节省,但每GB内存可以容纳多少键有一个限制。 如果是,那么运行ScyllaDB作为复制的分布式缓存为您提供了更大的弹性和不间断操作,而交易是(和作为) )这种复制将有效的缓存大小减半。不幸的是,Extstore不支持热重启,因此单个节点的故障或维护可能会提高您的缓存缺失比率。这是否是可接受的还是不取决于您的应用程序语义:如果缓存缺失相当于访问数据库,那么端到端延迟会暂时更高。 正確的國家 至于一致的哈希,memcached客户端负责在您的分布式服务器中分发密钥,这可能会引入一些错误,因为不同的客户端配置会导致密钥分配不同,有些实现可能不兼容。 ScyllaDB采取了不同的方法:在服务器层面进行一致的哈希,并在首次建立连接时传播到客户端,从而确保所有连接的客户端在扩展时始终遵循相同的拓扑。 Memcached 的 Configuring 客户端 wiki 那么谁赢了(或谁输了)?好......这不一定是一个竞争,也不是一个概述每个解决方案的每个考虑的完整列表。ScyllaDB和memcached都使用不同的方法来有效地利用潜在的基础设施。 我们很高兴看到ScyllaDB匹配了业界认可的Memcached的数字,当然,我们没有预期我们的数据库会“更快”。

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Visit Website

ScyllaDB Vs. Apache Cassandra

ScyllaDB Vs. DynamoDB

Download ScyllaDB

Community Events

Work At ScyllaDB

該音頻是用故事的原始語言製作的！

缓存与数据库:比较 Memcached 和 ScyllaDB

About Author

註釋

標籤

这篇文章刊登在

Related Stories

如何将您的工作流程提高 10 倍：17 个必备应用程序

看不见的层面：为什么用户访谈是不可替代的资产

数字游民请注意：您需要了解泰国新推出的 DTV 签证

架构师指南：构建 AI/ML 数据湖参考架构

如何将您的工作流程提高 10 倍：17 个必备应用程序

看不见的层面：为什么用户访谈是不可替代的资产

数字游民请注意：您需要了解泰国新推出的 DTV 签证

架构师指南：构建 AI/ML 数据湖参考架构

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps