Cassandra适合需要频繁查询（读/写）的系统吗？
我正在开发一个Web应用程序，需要很多用户位于同一个“宇宙”中，其中会发生很多频繁的查询：
- 频繁查找位于某个框区域（X1、X2、Y1和Y2)
- 客户端频繁更新位置 客户
- 端频繁更新聊天消息
- 客户端频繁更新状态
- 频繁连接和断开新旧客户端
我相信我的节点可以有足够的内存供所有当前在线用户使用 RAM。这就是我最初考虑Redis的原因。然而，我认为 Redis 在这里不适用，因为：
- 它有单点故障（一台主服务器），
- 只有主服务器可以写入，如果有 40 个节点，那么 39 个从服务器将不得不让一个主服务器写入每个条目
Cassandra 似乎解决了这些问题。
但是，Cassandra 也适合我频繁的查询吗？
I'm developing a web application that requires a lot of users to be in the same "universe", where a lot of frequent queries will happen:
- frequent lookups of clients that are in a certain box area (between X1, X2, Y1 and Y2)
- frequent position updates by clients
- frequent chat messages by clients
- frequent status updates by clients
- frequent connections and disconnections of new and old clients
I believe my nodes can have enough memory for all currently online users to be in RAM. This is why I originally considered Redis. However, I decided Redis is not applicable here because:
- it has a single point of failure (one master server)
- only the master server can write, if one has 40 nodes then 39 slaves would have to make the one master write each and every entry
Cassandra seems to solve these issues.
However, is Cassandra also suitable for my frequent queries?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Cassandra 优化写入而不是读取（读取比写入昂贵），但它仍然可以同时维持高读取和写入吞吐量。
有了正确的列族结构，您应该能够以高频率执行您想要的操作，具体取决于您的集群有多大。
就我个人而言，我会使用 Redis 来缓存大部分信息，并且仅在缓存未命中时从 Cassandra 读取。
Cassandra optimises writes over reads (reads are expensive compared to writes), but it can still sustain high read and write throughput simultaneously.
With the right column family structures you should be able to do what you want at high frequencies, depending on how big your cluster is.
Personally I'd use Redis for caching most of the information, and only read from Cassandra on cache miss.
Cassandra 绝对是处理写入的绝佳解决方案，但如果您可以告诉您的读取负载，那么您肯定可以期待一个精确的答案，但只要您有足够的 RAM，通常读取也很好。
您描述的用户案例似乎包含许多连接。
您是否有足够的理由从开发阶段就采用NoSQL解决方案？因为 Cassandra 基本上是一个需要高可扩展性的解决方案，但以非规范化和在很大程度上牺牲连接为代价。换句话说，您需要更高的磁盘空间但需要较低的 CPU。
或者您是否已完成数据库设计和表观方案（尽管 Cassandra 不受架构限制），以满足您的所有查询尤其是读取查询要求？ （它的 v.imp）
Cassandra is definitely a superb solution for handling writes but if you can tell your read load then definitely you can expect a precise answer but generally reads are also good as long as you have enough RAM.
The user case you described seems to include many joins..
Do you have enough reasons to adopt NoSQL solution right from the developmental stage? Because Cassandra is basically a solution for setups which require high scalability BUT at the expense of de-normalization and sacrificing Joins to a good extent. In other words you need higher disk space but low CPU.
Or have you finalized your database design and apparent scheme (though Cassandra is not schema bound) which fulfills all of your query especially read query requirements? (its v.imp)