我有许多python进程，每个进程重复查询一个单独的投注API。这些请求一次性以~20-100的突发形式进行，然后该过程消失以解析响应并在稍后重复一秒钟。我希望使用Cassandra作为我的原始存储空间来处理请求和响应。这将允许我调试解析数据的问题和/或稍后重新解析。我正在尝试为此设计一个模式。
我想我可以为每个API提供一个单独的表（列族），对此没什么好说的。我对表模式的初步想法是：
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个请求，最终会相互覆盖。尽管不太可能是错误的。
然后我接着第二个想法，我并不是很喜欢，使用时间戳和请求的散列来消除密钥的歧义，假设同一个请求同时返回相同的结果，因此足够独特，即str（timestamp）+ str（hash（request）），意味着架构变为（datetime变为文本）
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>
这很糟糕，因为文本需要更多空间而且比较慢，但我愿意接受它，然后我遇到了这个问题：
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。我能想到的一件事是不使用地图并且每次都改变表模式，然后在单元格中插入一个正常的值，但我不确定在底层商店中这有什么不同。
所以我想我有两个问题：
感谢您阅读
KCH
答案 0 :(得分：0)
回答我自己的问题 - 我的误解在于，在CQL中，密钥的第一部分始终是行密钥，因此对于复合密钥，密钥的其余部分构成列密钥。地图也使用自己的键名称“展开”约定结束在同一行的单独列中，但应用限制大小。