RethinkDB是否适合作为通用实时聚合平台

Question

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

用例

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

• 加入许多卡夫卡主题的数据
• 需要对原始数据进行连接
• 主题具有相同的关键字
• 主题中的数据有时是"快照"(可更新)，有时是"事件"(不可更新)
• 联接数据的目的地将是某个分析OLAP数据库。Clickhouse、Druid等，具体视情况而定。这些系统与"delta"(SCD)一起工作。由于"快照"，我需要有状态的处理
• 快照的更新最多可以在7天后出现
• 主题接收的信息量约为20k，峰值可达200k
• 主题中的数据是从100字节到5kB的json
• 主题中的数据可能重复
• 重复项通过"版本"json字段消除重复，json字段是每个主题的一部分。只有在new_version>old_version时才应处理数据。或者如果旧版本不存在

我已经和Cassandra进行了五个阶段的POC：

1. Cassandra Inserter-消耗所有Kafka主题。只为同一个Cassandra表中的所有主题执行插入操作。Sharding是在专栏上完成的，该专栏与卡夫卡的所有主题一样具有关键性。因此，所有具有相同密钥的消息最终都在同一个碎片中
2. 对于每个Cassandra插入，都会向Kafka生成InsertEvent
3. 增量计算器-使用InsertEvents并通过分片键查询Cassandra。获取所有原始数据，然后进行重复数据消除并创建增量。该状态保存在另一个Cassandra集群中。通过保存所有已处理的"版本"。下次出现新的InsertEvent时，我们使用保存的状态"version"只获取两个事件：previous和current，这样我们就可以创建DeltaEvent
4. DeltaEvent是为Kafka制作的
5. ClickHouse/Druid获取数据

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

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

重新思考数据库想法

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

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

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

非常感谢，Davor

附言：如果你更喜欢阅读文档，这里是：重新思考DB用例问题。

Answer 1

IMHO，RehinkDB非常适合您的用例。

来自RethinkDB文档

。。。RethinkDB扩展到每秒执行130万次单独读取。。。RethinkDB在50:50的混合读/写工作负载中每秒执行的操作远远超过10万次，同时具有完整的耐用性和数据完整性保证。。。在一系列集群大小上执行了所有基准测试，从1个节点扩展到16个节点。

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

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

选择工作负载和硬件

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

考虑到跨多个实例扩展RethinkDB集群的方便性，我们认为在从单个Rethink数据库实例移动到更大的集群时，有必要观察性能。我们在RethinkDB的单个实例上测试了所有工作负载，最多可以测试一个16节点的集群，集群大小的增量各不相同。

此外，我建议阅读RethinkDB的限制。我在这里抄了一些。

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

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

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