Membase 与 Cassandra？答案

【问题标题】：Membase vs. Cassandra?Membase 与 Cassandra？
【发布时间】：2011-06-06 08:13:42
【问题描述】：

对于大多数应用程序来说，哪种 NoSQL 数据库更好？

Cassandra (0.7x) 和 Membase：

键值数据库
速度很快
水平扩展
可与 Hadoop 结合使用以进行 Mapreduce 处理
支持递增和递减

Cassandra 具有可选择的每个查询的持久性/一致性保证

Cassandra 支持 BigTable 列

Membase 有异步（立即返回）写入

除了一致性保证之外，您为什么还要选择其中一个？

【问题讨论】：

还有其他产品可能比上述产品更好或更差。有什么理由挑出这两个？
对于具有高可用性和简单横向扩展的实时查询，他们似乎是领跑者。它们都承诺通过简单的同质单进程横向扩展实现快速低延迟写入和读取。
Cassandra 更倾向于写入而不是读取...
Cassandra 具有异步（立即返回）写入功能 - 只需选择 ConsistencyLevel.ZERO。

标签： nosql cassandra membase

【解决方案1】：

Cassandra 将行拆分为列，这些列可以被索引、有效地独立更新（而不必重写整个行/对象）并用作物化视图（与关系行不同，cassandra 列名可以动态确定在运行时）。

Cassandra 提供跨多个数据中心的完全多主复制，可针对每个键空间进行配置。（例如，我想要北美数据中心的 3 个数据集 X 副本和欧洲数据集的 1 个副本。但是我想要北美数据集的 2 个副本。）

说“Cassandra 更倾向于写入而不是读取”是不正确的。不同之处在于两者使用 Cassandra 都非常快，这与大多数仅读取速度快的系统不同。

FWIW，Cassandra 曾经提供异步写入，但我们将其取消，因为当您达到容量极限时，您的选择是 (1) 将服务器运行到地面或 (2) 丢弃请求而不向客户说这就是发生的事情。这不值得非常小的性能提升。

【讨论】：

这是否意味着，Cassandra 正在根据一致性级别同步写入？另一个问题是在哪些情况下，某些节点中的数据状态（旧值）可能会不一致，例如超过 1 分钟？以及您对 megastore 的看法，是否会从中对 cassandra 有所反映？
googles 我读到的一切都是一样的，kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis 说“最好用：当你写的比读的多时（记录）。” - 当然我只使用过 RavenDB 和 MongoDB。
菲尔，你引用的那篇文章是盲人引导盲人。
我其实很喜欢 Phill 的文章，但有几个不一致的地方。大多数文章都没有深入到理解真正的权衡。它类似于许多基准测试的问题。至于对 write 的误解，我认为归结为一个事实，即没有人喜欢以不好的方式展示我们的产品。由于考虑到一致性，Cassandra 的 reds 往往会慢一些，而不是说写入速度非常快。
Mongo 等内存数据库比 Cassandra 快，但牺牲了持久性。 Mongo 可以做得更耐用，但它会牺牲速度的卖点。据我所知，Membase 不允许每个操作的持久性设置。这是有道理的，因为它继承自 memcached。

【解决方案2】：

Membase 最近与 CouchDB 合并，并将将其磁盘/持久层从 sqllite 更新到 CouchDB，从而使 Membase 能够进行 map/reduce 和查询/索引。

没有人提到的一件事是 Membase 集群非常容易设置，而 Cassandra 需要更多的系统管理工作。

到目前为止，Cassandra 也得到了更广泛的采用，尽管有一些 Membase 的关键用例，例如 Zynga 及其社交游戏。

【讨论】：

"还没有人提到的一件事是 Membase 集群非常容易设置" ...尤其是在 mac 上，就像沙发一样

【解决方案3】：

这真是一个简单的问题。为什么不比较 riak、Couchdb、Hadoop 等？

没有比 NoSQL 数据库更适合大多数应用程序的东西。 Tokyo Tyrant 非常适合某些东西。 SQLITE 是一个出色的数据库，如果您知道自己在做什么，可以对其进行扩展。

noSql 的全部意义在于解构单体 RDBMS 并提供精简的 db 工具，这些工具专注于成为应用程序瓶颈的 db 访问方面。每个应用程序都不同，因此没有最佳选择。

但是，有一个最佳策略。那就是确定您的应用程序的原始性能需求，找出瓶颈所在，并选择支持这些瓶颈并帮助您管理它们的数据库工具（可能是 noSQL，也可能是 RDBMS）。

博客圈中充斥着人们从同样简单的问题开始，最终做出错误选择的故事。如果您想要正确的答案，您需要从提出正确的问题开始，有时您需要醒来并闻一闻咖啡味，并意识到从技术角度来看您的应用程序很难管理。其他人发现业务人员可以更好地解决扩展问题，但前提是技术人员必须能够解释系统、其瓶颈和自然约束，以及以某些方式更容易扩展的机会，只要业务将朝着不同的方向发展。

【讨论】：