4

我需要你的帮助来验证 RethinkDB 是否适合我的用例。

用例

我的团队正在构建一个通用的实时聚合平台，它需要：

  • 加入来自许多 Kafka 主题的数据
  • 需要对原始数据进行连接
  • 主题具有相同的键
  • 主题中的数据有时是“快照”（可更新），有时是“事件”（不可更新）
  • 连接数据的目的地将是一些分析型 OLAP DB。Clickhouse、Druid 等。视情况而定。这些系统与“增量”（SCD）一起工作。因为“快照”，我需要有状态的处理。
  • 最多可在 7 天后更新快照
  • 主题接收大约 20k msg/s，峰值高达 200k msg/s
  • 主题中的数据是从 100 字节到 5kB 的 json
  • 主题中的数据可以有重复
  • 重复项使用“版本” json 字段进行重复数据删除，该字段是每个主题的一部分。仅当 new_version > old_version 时才应处理数据。或者如果 old_version 不存在。

我已经有了一个包含五个阶段的 Cassandra 的 POC：

  1. Cassandra Inserter - 使用来自所有 Kafka 主题。仅对同一个 Cassandra 表中的所有主题进行插入。分片是在作为所有 Kafka 主题的键的列上完成的。因此，具有相同密钥的所有消息最终都在同一个分片中。
  2. 对于每个 Cassandra 插入，都会向 Kafka 生成一个 InsertEvent
  3. Delta 计算器 - 使用 InsertEvents 并通过分片键查询 Cassandra。获取所有原始数据，然后删除重复数据并创建增量。状态保存在另一个 Cassandra 集群中。通过保存所有已处理的“版本”。下次有新的 InsertEvent 出现时，我们使用保存的状态“版本”只获取两个事件：previous 和 current，因此我们可以创建一个 DeltaEvent
  4. DeltaEvent 生成到 Kafka
  5. ClickHouse / Druid 摄取数据

所以它基本上是一个 50/50 的插入/读取工作负载，没有更新 Cassandra。

使用 14 个 Cassandra 数据节点和 8 个状态节点节点，它可以在高达 20k InsertEvent/s 的情况下正常工作。在 25k InsertEvent/s 时，系统开始滞后。节点有 16GB 内存，磁盘是由 SSD 支持的网络存储（我知道这并不理想，但现在无法更改）。网络 10 Gbit。

重新思考数据库的想法

我想做一个新的 POC 来尝试 RethinkDB 并使用 changefeeds 创建增量和重复数据删除。为此，我将使用一张桌子。主键/分片键将是 Kafka 键，来自具有相同键的所有主题的所有 Kafka 数据将在单个文档中加入/更新。

工作量可能是 10/90 插入/更新。我会使用 squash: true，以避免过度读取并减少 DeltaEvents 的数量。

  1. 你认为这是 RethinkDB 的一个很好的用例吗？
  2. 它会扩展到 200k msg/s，即 20k insert/s、180k update/s 和大约 150k/reads 通过 changefeeds？
  3. 我需要删除超过 7 天的数据，这将如何影响插入/更新/查询工作量？
  4. 你有一个更适合这个用例的系统的建议吗？

非常感谢，达沃尔

PS：如果你喜欢阅读文档，这里是：RethinkDB use case question。

4

1 回答 1

4

恕我直言，RehinkDB 非常适合您的用例。

来自 RethinkDB文档

...RethinkDB 可扩展为每秒执行 130 万次单独读取。...RethinkDB 在混合的 50:50 读/写工作负载中每秒执行超过 100,000 次操作 - 同时具有完整的持久性和数据完整性保证水平。...在一系列集群规模上执行所有基准测试，从 1 个节点扩展到 16 个节点。

RethinkDB 的人们使用YCSB 基准套件中的工作负载测试了类似的场景并报告了他们的结果。

我们发现，在混合读/写工作负载中，具有两台服务器的 RethinkDB 能够在 16 节点集群中每秒执行近 16K 查询 (QPS) 并扩展到近 120K QPS。在只读工作负载和同步读取设置下，RethinkDB 能够从单个节点上的约 150K QPS 扩展到 16 个节点上的超过 550K QPS。在相同的工作负载下，在异步“过时读取”设置中，RethinkDB 从一台服务器上的 150K QPS 变为 16 节点集群中的 1.3M。

选择工作负载和硬件

...在 YCSB 工作负载选项中，我们选择运行包含 50% 读取和 50% 更新操作的工作负载 A，以及执行严格读取操作的工作负载 C。YCSB 测试存储的所有文档都包含 10 个字段，其中包含随机的 100 字节字符串作为值，每个文档的总大小约为 1 KB。

鉴于跨多个实例扩展 RethinkDB 集群很容易，我们认为在从单个 RethinkDB 实例迁移到更大的集群时有必要观察性能。我们在一个 RethinkDB 实例上测试了我们所有的工作负载，最多有 16 个节点的集群，集群大小的增量不同。

此外，我建议通读RethinkDB 的限制。我这里复制了一些。

  • 有 64 个分片的硬性限制。
  • 虽然对单个文档的大小没有硬性限制，但出于内存性能原因，建议限制为 16MB。
  • JSON 查询的最大大小为 64M。
  • 主键限制为 127 个字符。
  • 二级索引不存储对象或空值。
  • 主键字符串可能不包括空代码点 ( U+0000)。
  • 默认情况下，RethinkDB 服务器上的数组的大小限制为 100,000 个元素。这可以通过运行 arrayLimit（或 array_limit）选项在每个查询的基础上进行更改。
  • RethinkDB 不支持 Unicode 排序规则，也不对具有多个代码点的相同字符进行规范化（即，\u0065\u0301两者\u00e9都表示字符“é”，但 RethinkDB 将它们视为不同的字符，并将它们分类）。

由于您的系统是实时系统，因此 RethinkDB内存要求和崩溃恢复也值得一读。

此外，缺少删除性能基准。

于 2019-11-06T22:59:03.310 回答