Cassandra 是否适合需要频繁查询（读/写）的系统？答案

【问题标题】：Is Cassandra suitable for a system that requires frequent queries (reads/writes)?Cassandra 是否适合需要频繁查询（读/写）的系统？
【发布时间】：2011-11-13 16:58:49
【问题描述】：

我正在开发一个 web 应用程序，它需要很多用户在同一个“宇宙”中，在那里会发生很多频繁的查询：

在特定框区域（X1、X2、Y1 和 Y2 之间）的客户端的频繁查找
客户经常更新位置
客户的频繁聊天消息
客户经常更新状态
新老客户端频繁连接和断开

我相信我的节点可以有足够的内存供所有当前在线用户在 RAM 中。这就是我最初考虑 Redis 的原因。但是，我决定 Redis 在这里不适用，因为：

它有一个单点故障（一个主服务器）
只有主服务器可以写入，如果一个有 40 个节点，那么 39 个从服务器必须让一个主服务器写入每个条目

Cassandra 似乎解决了这些问题。

但是，Cassandra 是否也适合我的频繁查询？

【问题讨论】：

说一下“频繁”的含义会很有用。每秒数十次更新，还是数千次？
@Malcolm，每个客户端、每个节点还是整个集群？
对于每种类型的更新，它们在您的系统中发生的频率如何？每个客户端和节点的值取决于您的设置假设。
@Malcolm，这不取决于活跃用户的数量吗？
当然可以——但你设计的目的是什么？每个系统都会在某个负载级别出现故障 - 但您需要一些参数，否则您无法看到设计是否有效

标签： database nosql scalability cassandra key-value-store

【解决方案1】：

Cassandra 优化了写而不是读（读比写更昂贵），但它仍然可以同时维持高读写吞吐量。

使用正确的列族结构，您应该能够在高频下做您想做的事情，具体取决于您的集群有多大。

我个人会使用 Redis 来缓存大部分信息，并且只在缓存未命中时从 Cassandra 读取。

【讨论】：

Twitter 和 Facebook 使用 Casandra。您是否知道他们是否也使用它来查找推文等，或者他们是否使用了不同的技术，例如将其与 redis 结合使用？ redis 组合对我来说似乎很复杂。
我都不为这两个工作，所以不能肯定地说，但如果他们在前面没有缓存的情况下使用它，我会感到惊讶。这就是 Redis 的全部 - 具有一些不错的数据结构的内存缓存。
当 redis 只能有一个写入的 master 时，如何将 redis 用作可扩展系统的内存缓存？由于 slave 无法写入，cassandra 数据库中的所有更改都必须由 redis master 写入 redis。现在我们又回到了一个故障点以及一个不可扩展的系统。我不是跟着你吗？
因为单个 redis 节点的扩展性将远高于您的站点。如果（或何时）用尽了它，只需对数据集进行分片。至于故障 - 保持一个从节点作为热备用并提升为主节点，或者只是启动一个新的主节点。如果你不喜欢 redis 作为缓存，那么 memcache 将无限扩展

【解决方案2】：

Cassandra 绝对是处理写入的绝佳解决方案，但如果您能判断读取负载，那么您肯定可以期待准确的答案，但只要您有足够的 RAM，通常读取也很好。

您描述的用户案例似乎包括许多连接..

您是否有足够的理由从开发阶段就采用 NoSQL 解决方案？因为 Cassandra 基本上是一种解决方案，适用于需要高可扩展性但以牺牲去规范化和在很大程度上牺牲连接为代价的设置。换句话说，您需要更大的磁盘空间，但需要较低的 CPU。

或者您是否已经完成了满足您所有查询（尤其是读取查询要求）的数据库设计和明显方案（尽管 Cassandra 不受模式限制）？ (它的 v.imp)

【讨论】：

"只要你有足够的内存。"这与将 redis 或 memcache 之类的东西与 Cassandra 一起使用相比如何？