我正在考虑是否使用MongoDB或Kafka作为时间序列数据集。
乍一看，使用Kafka显然是有意义的，因为这就是它的目的。但我也希望在查询等方面有一些灵活性。
这让我产生了一个问题："为什么不直接使用MongoDB来存储带时间戳的数据并按时间戳索引它们？
天真地认为，这感觉它有与 Kafka 类似的好处(因为它按时间偏移量索引(，但具有更大的灵活性。但话又说回来，我相信人们在这种类型的用例中使用Kafka而不是MongoDB有很多原因。
有人可以解释为什么在这种情况下可能想要使用Kafka而不是MongoDB的一些原因吗？
我将尝试回答这个问题，因为您正在尝试随着时间的推移收集指标
是的，Kafka 主题具有可配置的时间保留，我怀疑您是否在使用主题压缩，因为您的消息可能是(time, value)的形式，因此无论如何时间都无法重复。
Kafka 还提供了流处理库，以便您可以在时间窗口内找出平均值、最小值/最大值、异常值和异常值、前 K 值等。
但是，虽然处理所有这些数据既出色又有用，但您的消费者将难以对这些数据进行线性扫描，无法轻松查询任何给定时间范围内的数据切片。这就是时间索引(不仅是开始索引，还有结束索引(会有所帮助的地方。
因此，当然您可以使用 Kafka 创建排队指标的积压工作并随着时间的推移处理/过滤它们，但我建议将这些数据使用到适当的数据库中，因为我假设您希望能够更轻松地查询它，并可能创建一些可视化数据。
使用该架构，您可以让高度可用的 Kafka 集群在一段时间内保留数据，而下游系统不一定必须一直在线才能接收事件。但是一旦它们成为，它们就会从最后一个可用的偏移量和拾取器中消耗掉它们之前的位置
。就像上面评论中的答案一样 - Kafka 和 MongoDB 都不适合作为具有灵活查询功能的时间序列数据库，原因@Alex Blex 解释得很好。
根据处理速度、查询灵活性和数据大小的要求，我会做以下选择：
- Cassandra [最佳处理速度、最佳/良好数据大小限制、最差查询灵活性]
- PostgresDB 之上的 TimescaleDB [良好的处理速度、良好/确定的数据大小限制、良好的查询灵活性]
- ElasticSearch [良好的处理速度，最差的数据大小限制，最佳的查询灵活性+可视化]
附言这里的"处理"是指在需要时引入、分区和汇总 附言在我看来，我选择了现在使用最广泛的选项，但是还有数十种其他选项和组合，以及更多的选择标准 - 有兴趣听听其他工程师的经验！