-1

这个问题可能看起来像这样。我正在尝试收集有关如何实施 BGP 管道的想法。

我每秒通过 Kafka 接收 100-1000 条消息（BGP 更新），每次更新几千字节。

我需要将它们以二进制格式存档，并带有一些元数据以便快速查找：我正在定期构建 BGP 表的“状态”，它将合并在一定时间内收到的所有更新。因此需要一个数据库。

到目前为止我在做什么：将它们分组在“5分钟”文件（端到端消息）中，因为这对于 BGP 收集工具来说很常见，并将链接添加到数据库中。我意识到一些缺点：复杂（必须按键分组，管理 Kafka 偏移提交），没有很好的选择从哪里开始/结束。

我在想什么：使用数据库（Clickhouse/Google BigTable/Amazon Redshift）并插入每个条目，其中包含元数据和指向存储在 S3/Google Cloud 存储/本地文件上的唯一更新的链接。

我担心下载性能（很可能是通过 HTTP），因为将所有更新编译成一个状态可能需要数千条这样的消息。你有批量下载这个的经验吗？我认为将更新直接存储在数据库中也不是最佳选择。

有什么意见、想法、建议吗？谢谢

4

2 回答 2

0

到目前为止我在做什么：将它们分组在“5分钟”文件（端到端消息）中，因为这对于 BGP 收集工具来说很常见，并将链接添加到数据库中。我意识到一些缺点：复杂（必须按键分组，管理 Kafka 偏移提交），没有很好的选择从哪里开始/结束。

你为什么不试试 Kafka-streams，它为你提供窗口功能，然后按键分组并转储到数据库中？使用 Kafka-streams，您不必担心按键分组和您提到的许多其他问题。

如果 Kafka-streams 不适合您，那么只需将消息一次更新一个存储在数据库中，dB 读取器可以按时间窗口和键进行分组。

于 2018-08-02T21:10:46.890 回答
0

Cloud Bigtable 每个“节点”每秒能够处理 10,000 个请求，每个节点每小时的费用为 0.65 美元。最小的生产集群是 3 个节点，每秒总共 30,000 行。您的应用程序每秒最多调用 1,000 个请求。虽然 Cloud Bigtable 可以处理您的工作负载，但我建议您考虑Firestore。

在每条消息几 K 的情况下，我还会考虑将整个值放入数据库中，而不仅仅是元数据以方便使用。

于 2018-08-03T16:24:36.137 回答