Let’s look at the performance-related complexities that teams commonly face with write-heavy workloads and discuss your options for tackling them 重写的数据库工作负载带来了显著不同的挑战,而不是重读的数据库工作负载。 扩展写作可以是昂贵的,特别是如果你支付每操作和写作比读取成本高5倍 锁定可以增加延迟并减少输出量 I/O瓶颈可以导致写放大和复杂的崩溃恢复 数据库 backpressure 可以阻止传入负载 虽然成本很重要 - 在许多情况下 - 它不是我们想在这里讨论的话题,相反,让我们专注于团队通常面临的性能相关的复杂性,并讨论您解决这些问题的选择。 什么是“实时写重工作负载”? 首先,让我们澄清我们所说的“实时写重”工作负载是什么。 摄入大量数据(例如,超过50K OPS) 涉及比阅读更多写作 受严格的延迟 SLA 约束(例如,单位毫秒 P99 延迟) 在野外,它们发生在从在线游戏到实时股票交易所的所有方面。 物联网(IoT)工作负载往往涉及小但频繁的附加时间序列数据。在这里,摄入率主要取决于收集数据的终端数量。 记录和监控系统也处理频繁的数据摄入,但它们没有固定的摄入率,它们可能不一定只附加,也可能容易出现热点,例如当一个终端行为不当时。 在线游戏平台需要处理实时用户交互,包括游戏状态的变化,玩家行动和消息传输。工作负载往往是尖锐的,活动突然上升。 电子商务和零售工作负载通常需要更新,通常涉及批量处理,这些系统必须保持准确的库存水平,处理客户评论,跟踪订单状态,并管理购物车操作,这通常需要在更新之前阅读现有数据。 广告技术和实时投标系统需要分秒决策,这些系统处理复杂的投标处理,包括打印跟踪和拍卖结果,同时监控用户的互动,如点击和转换。 实时交易所系统必须支持高频交易,不断更新股价和复杂的订单匹配流程,同时保持绝对数据一致性和最小延迟。 接下来,让我们看看影响写作性能的关键架构和配置考虑。 存储引擎架构 存储引擎架构的选择从根本上影响数据库的写作性能. 存在两个主要方法:LSM树和B树。 已知能够高效处理写作的数据库 – 如ScyllaDB、Apache Cassandra、HBase 和 Google BigTable – 使用Log-Structured Merge Trees(LSM)。 这种架构非常适合处理大量写作。 由于写作立即附加到内存中,这允许非常快速的初始存储。 一旦记忆中的“记载”填充,最近的写作会以排序排列到磁盘上。 例如,这里是 ScyllaDB 写字路径的样子: 随着数据集的增长,树可能需要额外的节点和重新平衡,导致更多的磁盘 I/O,这可能会影响性能。 付款大小 负载大小也会影响性能. 对于小负载来说,输出量很好,但CPU处理是主要的瓶颈。 最终,一个小写通常适合所有缓冲器,一切都可以相当快地处理,这就是为什么很容易获得高输出量。对于较大的负载,你需要分配更大的缓冲器或多个缓冲器。 压缩 磁盘利用率是需要密切关注的工作负载,虽然存储越来越便宜,但它仍然不是免费的。 压缩可以帮助保持控制,所以明智地选择压缩策略. 更快的压缩速度对于重写工作负载很重要,但也考虑您的可用CPU和内存资源。 请务必观察该 . 压缩基本上将数据分成较小的块(或块),然后单独压缩每个块。 在调整此设置时,请意识到较大的块更适合阅读,而较小的块更适合写作,并考虑您的负载大小。 压缩大小参数 同情 对于基于 LSM 的数据库,您选择的压缩策略也会影响写作性能。 压缩包括将多个 SSTables 合并成更少、更有组织的文件,以优化读取性能,恢复磁盘空间,减少数据碎片化,并保持整体系统效率。 当选择压缩策略时,您可以瞄准低读率放大,从而使读数尽可能高效。或者,您可以通过避免压缩过于攻击性来瞄准低写率放大,或者您可以优先考虑低读率放大,并尽可能有效地获得压缩净化数据。 (以及卡桑德拉提供类似的): 多种合并策略 尺寸级压缩策略(STCS):当系统有足够(默认情况下有四个)相似尺寸的SSTables时启动。 平衡压缩策略(LCS):系统使用分布在不同级别的小、固定尺寸(默认为160 MB)的SSTables。 增量压缩策略(ICS):共享与STCS相同的读写放大因子,但通过将巨大的stables打破成SSTable运行,这些运行由一组较小的(默认情况下为1 GB),不重叠的SSTables组成。 时间窗压缩策略(TWCS):设计用于时间序列数据。 对于重写工作负载,我们警告用户不惜一切代价避免平衡压缩。 该策略专为重读使用案例而设计。 蝙蝠 在 ScyllaDB 和 Cassandra 等数据库中,批量化实际上可能是一些陷阱,特别是对于写重的工作负载。如果你习惯了关系数据库,批量化可能看起来像是处理大量写作的好选择。 下面是如何思考当你处理重写时的批量: 按分区密钥分组:将你的写作分区密钥分组,以便批量转移到拥有数据的协调节点.这样,协调员不必接触其他节点以获取额外的数据.相反,它只是处理自己的,从而减少不必要的网络流量。 保持批量小和有针对性的:分割大批量成小批量以分区保持事物的效率. 它避免过载网络,并允许每个节点只在其所拥有的数据上工作。 坚持未登录的批次:考虑到您遵循前面的点,最好使用未登录的批次。 因此,如果您处于难以写作的情况下,请仔细构建您的批量,以避免大型跨节点批量引入的延迟。 包装上 我们提供了一些警告,但不要担心. 很容易编写一份学习的课程列表,因为许多团队非常成功地使用实时写重的工作负载。 如果你想了解更多,这里有一些来自团队的第一手观点,他们解决了相当有趣的写作挑战: Zillow:消耗来自多个数据生产商的记录,导致失序的写作可能导致错误的更新 Tractian:准备从物联网设备上写高频数据的10倍增长 狂热主义者:重写操作,如处理订单,购物车和此在线体育零售商的产品更新 黄金 特拉克 狂热者 此外,看看下面的视频,我们将深入了解这些重写的挑战,并通过这些工作负载在ScyllaDB上看起来如何。

This story contains new, firsthand information uncovered by the writer.

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

实时写重型数据库工作负载:考虑和提示

About Author

註釋

標籤

这篇文章刊登在

Related Stories

从论坛到信息流：社交媒体算法如何塑造数字互动

加密货币增长：创建有效的用户角色

比特币 UTXO 模型，为独特的生态系统提供动力

使用这 18 种开发工具来提高你的工作效率 🚀🔥

从论坛到信息流：社交媒体算法如何塑造数字互动

加密货币增长：创建有效的用户角色

比特币 UTXO 模型，为独特的生态系统提供动力

使用这 18 种开发工具来提高你的工作效率 🚀🔥

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps