我正在开发一个web应用程序，需要很多用户在同一个"宇宙"中，在那里会发生很多频繁的查询:
- 在特定框区域(X1, X2, Y1和Y2之间)的客户端频繁查找
- 客户端的频繁位置更新
- 客户端的频繁聊天信息
- 客户端的频繁状态更新
- 新老客户端频繁连接和断开
我相信我的节点可以有足够的内存为所有当前在线用户在RAM中。这就是我最初考虑Redis的原因。然而，我决定Redis不适用于这里，因为:
- 它有一个单点故障(一个主服务器)
- 只有主服务器可以写，如果一个有40个节点，那么39个从服务器将不得不让一个主服务器写每个条目
Cassandra似乎可以解决这些问题。
然而，Cassandra也适合我的频繁查询吗?
Cassandra优化了写而不是读(读比写更昂贵)，但它仍然可以同时保持较高的读和写吞吐量。
有了正确的列族结构，你应该能够在高频率下做你想做的事情，这取决于你的集群有多大。
我个人会使用Redis缓存大部分信息，并且只在缓存丢失时从Cassandra读取。
Cassandra绝对是处理写的一个极好的解决方案，但如果你能告诉你的读负载，那么你肯定可以期待一个精确的答案，但通常读也很好，只要你有足够的RAM。
你描述的用户用例似乎包括许多连接…
你有足够的理由从开发阶段就采用NoSQL解决方案吗?因为Cassandra基本上是一个解决方案，它需要高可伸缩性，但在很大程度上要以反规范化和牺牲join为代价。换句话说，您需要更大的磁盘空间，但需要更低的CPU。
或者你已经完成了你的数据库设计和明显的方案(尽管Cassandra不是模式绑定)，它满足你所有的查询，特别是读查询需求?(其v.imp)