我们有：
用户，每个用户都有事件，每个事件都有几个属性（时间，类型等）。我们的基本用例是在给定的时间跨度内获取给定用户的所有事件。
我们一直在考虑在Cassandra中为事件列族提供以下替代方案。所有备选方案共享：key = user_id（UUID），column_name = event_time
column_value =事件属性的序列化对象。需要每次都读/写所有属性（不是问题），但也可能难以调试（不能轻易使用Cassandra命令行客户端）
列实际上是一个超级列，子列是单独的属性。意味着每次都读取所有事件（？）（尽管可能是次优的）。还有其他缺点吗？
column_value是另一个CF的行键，其中存储了事件属性。意味着维持两个表 - ＆gt;复杂的调用+读/写速度较慢（？）。
我们缺少什么？这里有标准的最佳做法吗？
答案 0 :(得分：0)
备选方案1：如果要存储序列化对象，为什么要去Cassandra？ MongoDB或类似的产品在这个任务上表现得更好，如果我得到它的话（从来没有真正尝试过基于NoSQL的文档，所以如果我在这个问题上错了，请纠正我）。无论如何，我在6年前曾在MySQL中尝试过这种方法，今天仍然很难维持。
备选方案2：抱歉，我还没有玩过超级colunm。只有当我必须经常在一个查询中显示许多用户的许多信息（即，不仅仅是他们的用户名和一些限定符）及其各自的事件时，才会使用此功能。如果用户本身也存在条件，也可以使基于给定时间跨度的查询有点棘手，因为用户的行可能具有适合跨度的事件列而不适合其他列。
备选方案3：在大多数情况下，肯定是我的选择。您不太可能在同一事务中编写事件并创建用户，因此不必担心一致性。使用用户名本身作为标准事件列（不要忘记将其编入索引），这样您的调用将非常快。有关http://www.datastax.com/docs/0.8/ddl/index的此类数据模型的更多信息。 是的，它是一个两个调用读取，但它确实是两个不同的数据系列。
至于最佳实践，该领域有点新，不确定是否有任何广泛认可。