一条群公告被很多人同时打开，数据库不一定需要被重复问很多次。Discord 的消息存储案例里，请求合并比“换了哪款数据库”更值得拆开看。 Alex Xu 的… · @BaiBtw · TwKit

@BaiBtw

一条群公告被很多人同时打开，数据库不一定需要被重复问很多次。Discord 的消息存储案例里，请求合并比“换了哪款数据库”更值得拆开看。 Alex Xu 的英文整理回顾了 MongoDB → Cassandra → ScyllaDB 的演进。再对照 Discord 2023 年的工程原文，可以把这次改造分成三部分。 先看问题怎么产生。Discord 按频道 ID 和固定时间窗口分区，同一频道、同一时间段的消息放在一起。大频道遇上集中访问，就可能形成热点分区。读取要查内存中的 memtable，也可能查多个磁盘上的 SSTable；再叠加压缩整理和垃圾回收暂停，延迟就容易抖动。这是他们当时的数据量与访问模式下遇到的问题，不是对所有 Cassandra 部署的结论。 接着减少重复访问。他们在 API 和数据库之间加了一层 Rust 数据服务。多个人同时请求同一行数据时，第一个请求启动查询任务，后面的请求订阅这个任务，查询结果回来后一起拿到。原文举的例子是大服务器发布通知，用户集中打开同一条消息。 为了让相同频道的请求更容易碰到同一个服务实例，他们还用了基于一致性哈希的路由。这一步很重要：请求如果分散到不同实例，就不容易在同一个任务里合并。这里讲的是合并正在进行的相同查询，不等于把所有历史结果一直缓存下来。 最后才是迁移与验证。新消息先双写，历史消息另行搬迁，再把少量读取同时发给两边，比较结果。迁移临近完成时，还遇到了大量未清理 tombstone 导致的超时，处理后才完成切换。换库并没有省掉这些检查。 按官方披露的这次改造结果，历史消息读取的 p99 从 40—125 毫秒降到约 15 毫秒，消息写入的 p99 从 5—70 毫秒变成约 5 毫秒。这是数据库、上游服务和部署一起改造后的结果，不能直接当作两款数据库的通用性能排名。 拿这个案例检查自己的服务，可以先问一个具体问题：流量高峰时，是有很多不同查询，还是很多人在重复等同一个答案？两种情况需要的处理方式并不一样。 英文整理：https://x.com/alexxubyte/status/1690749934818185216 官方原文：https://discord.com/blog/how-discord-stores-trillions-of-messages

曝光 22 · 评论 0 · 点赞 0 · 书签 0