在 Cassandra 中存储大量原始请求和响应的时间序列
Storing timeseries of large raw requests and responses in Cassandra
我有许多 python 个进程，每个进程重复查询一个单独的投注 API。请求以 ~20-100 的形式同时出现，然后该过程离开以解析响应并在大约一秒钟后重复。我希望使用 Cassandra 作为请求和响应的原始存储。这将允许我调试已解析数据 and/or 稍后重新解析的问题。我正在尝试为此设计一个模式。
我想每个 API 我可以有一个单独的 table（列族），对此没什么好说的。我对 table 架构的最初想法是：
stripe text, // free text to describe the flavour of the request, e.g. live games
date int, // YYYYMMDD
requests map<datetime, text>,
responses map<datetime, text>
然后我可以在请求和响应发生时将其附加到正确的行，并以每天一行按时间排序的请求和响应结束。然后我可以轻松返回并找到给定日期的数据（这似乎是一次处理的合理块），然后根据需要转到当天的特定时间点。
这里的问题很明显，鉴于我的时间戳分辨率，同时发出的 2 个请求最终将相互覆盖。尽管不太可能，但它是错误的。
然后我继续第二个我不太喜欢的想法，使用时间戳和请求的散列来消除密钥的歧义，假设同一时间的相同请求应该 return 相同结果因此足够独特，即 str(timestamp) + str(hash(request))，这意味着模式变为（日期时间变为文本）
stripe text, // free text to describe the flavour of the request, e.g. live games
date int, // YYYYMMDD
requests map<text, text>,
responses map<text, text>
这很糟糕，因为文本需要更多 space 并且比较慢，但我愿意接受它，然后我遇到了这个问题：
E InvalidRequest: code=2200 [Invalid query] message="Map value is too long. Map values are limited to 65535 bytes but 435145 bytes value provided"
这基本上是在告诉我，无论如何我都不能将这些东西放在集合列中，因为响应的大小是任意的，而且几乎总是大于限制。
我是 Cassandra 世界的新手，但我认为这些 CQL 映射最终对应于记录中单独的列名和值，并且每列的大小限制为 2GB。我能想到的一件事是不使用地图并每次都不断更改 table 架构，然后将正常值插入单元格，但我不确定底层存储有何不同。
所以我想我有 2 个问题：
- 这只是 CQL 的限制还是整个 Cassandra 的限制？
- 更有经验的人可以想出一个总体上更好的方法吗？
感谢阅读
韩国中央银行
回答我自己的问题 - 我的误解在于，在 CQL 中，键的第一部分始终是行键，因此对于复合键，键的其余部分构成列键。映射也使用它们自己的键名 "unrolling" 约定但应用限制大小而在同一行的不同列中结束。
我有许多 python 个进程，每个进程重复查询一个单独的投注 API。请求以 ~20-100 的形式同时出现，然后该过程离开以解析响应并在大约一秒钟后重复。我希望使用 Cassandra 作为请求和响应的原始存储。这将允许我调试已解析数据 and/or 稍后重新解析的问题。我正在尝试为此设计一个模式。
我想每个 API 我可以有一个单独的 table（列族），对此没什么好说的。我对 table 架构的最初想法是：
stripe text, // free text to describe the flavour of the request, e.g. live games
date int, // YYYYMMDD
requests map<datetime, text>,
responses map<datetime, text>
然后我可以在请求和响应发生时将其附加到正确的行，并以每天一行按时间排序的请求和响应结束。然后我可以轻松返回并找到给定日期的数据（这似乎是一次处理的合理块），然后根据需要转到当天的特定时间点。
这里的问题很明显，鉴于我的时间戳分辨率，同时发出的 2 个请求最终将相互覆盖。尽管不太可能，但它是错误的。
然后我继续第二个我不太喜欢的想法，使用时间戳和请求的散列来消除密钥的歧义，假设同一时间的相同请求应该 return 相同结果因此足够独特，即 str(timestamp) + str(hash(request))，这意味着模式变为（日期时间变为文本）
stripe text, // free text to describe the flavour of the request, e.g. live games
date int, // YYYYMMDD
requests map<text, text>,
responses map<text, text>
这很糟糕，因为文本需要更多 space 并且比较慢，但我愿意接受它，然后我遇到了这个问题：
E InvalidRequest: code=2200 [Invalid query] message="Map value is too long. Map values are limited to 65535 bytes but 435145 bytes value provided"
这基本上是在告诉我，无论如何我都不能将这些东西放在集合列中，因为响应的大小是任意的，而且几乎总是大于限制。
我是 Cassandra 世界的新手，但我认为这些 CQL 映射最终对应于记录中单独的列名和值，并且每列的大小限制为 2GB。我能想到的一件事是不使用地图并每次都不断更改 table 架构，然后将正常值插入单元格，但我不确定底层存储有何不同。
所以我想我有 2 个问题：
- 这只是 CQL 的限制还是整个 Cassandra 的限制？
- 更有经验的人可以想出一个总体上更好的方法吗？
感谢阅读
韩国中央银行
回答我自己的问题 - 我的误解在于，在 CQL 中，键的第一部分始终是行键，因此对于复合键，键的其余部分构成列键。映射也使用它们自己的键名 "unrolling" 约定但应用限制大小而在同一行的不同列中结束。