比较：Aerospike与Cassandra

Question

比较：Aerospike与Cassandra

cassandraaerospikenosql

43

阿里云和卡桑德拉均声称在各自的基准测试中比另一个更好。

参考资料: http://java.dzone.com/articles/benchmarking-cassandra-right 等其他文章。

有人使用过这两个产品吗？
Aerospike是否像它所声称的那样好？
最终，是否建议用Aerospike替换Cassandra？

- holmes840

1

在什么情况下？您想要什么级别的一致性？您会花多少钱购买SSD？您是读重还是写重？ - John Powell

2

目前，我们有大约100个节点来维护我们在不同数据中心分散的数据。我们的读写比率约为2:1。下面的答案从财务角度提供了一些见解。我想尝试一下aerospike会很好。谢谢！ - holmes840

2

好的回答。感谢提问。我刚开始评估Cassandra，但现在会先看看Aerospike。 - John Powell

1

大家好。有人比较过Aerospike和Hyperdex的速度或功能吗？ - skan

4个回答

15

如果您需要稳定可预测的性能，低延迟且不需要维护麻烦，请选择Aerospike。如果想要玩游戏，请选择Cassandra。我四年前引入Cassandra到公司，没有后悔过，但今天出于上述原因我选择了Aerospike，它是开源的，并且比一年前更加可用，像俄罗斯坦克一样耐用。您只需要了解两个平台的限制。尝试使用两者，明智地选择。

- Viktor Jevdokimov

2

谢谢！我们一直在使用Cassandra，并了解了它的优点和缺点。我们将尝试使用Aerospike，然后做出决定。 - holmes840

10

虽然许多人将Aerospike部署为纯内存数据库，但它也支持混合内存配置，将数据库分布在RAM、SSD/Flash和磁盘上。以下是一些简短和更为详细的回答链接，以解决此问题。当然，人们希望兼得：将更持久的数据存储在更便宜的磁盘上，并将更快、更短暂的数据存储在更昂贵每GB的RAM或SSD中。https://www.aerospike.com/products/features/hybrid-memory-architecture/http://www.aerospike.com/docs/architecture/storage.html我很想听听大家在这方面的经验反馈。

- Peter Corless

9

这两种产品取决于使用情况，但毫不犹豫地说，Aerospike的可扩展性比Cassandra更好，并且配备SSD以及少量节点维护具有成本效益。

此外，对于在Aerospike中使用大量键时的内存使用情况，您可以在命名空间中的不同集合/数据桶中分桶记录。例如，如果您有100亿条记录，则可以将其分成5个集合和5个数据桶，其中哈希值为键提供查找值。因此，在命名空间中只需要保存20亿个记录，这将减少内存中的键数。

- Anand Prakash

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- user1084563 · Accepted Answer

选择Cassandra和Aerospike实际上更取决于您的使用情况。在同一个项目的生产系统中，我个人都使用过这两种数据库，对我而言，Aerospike是显而易见的胜者，但这是因为我们的使用情况需要高并发、低延迟、事务性、小型更新等要求，并且读比写大约10倍，并且涉及数十亿条记录。Aerospike擅长处理这些数据，它是我见过此类数据库中延迟最小的，即使使用SSD命名空间也是如此。出于这些原因，Aerospike是我们明确的选择。

另一方面，Cassandra适用于高写入量且可以处理较大的记录。它的所有操作都基于页面进行，因此在非SSD上运行良好，但除非记录适合缓存，否则它永远无法像Aerospike一样提供极低的延迟。值得注意的是，从运营角度来看，Cassandra比Aerospike难以维护。对于我们个人而言，它是一个运营噩梦，我知道Netflix不得不雇用一个庞大的运营工程师团队专门管理他们的Cassandra集群。还有一点需要说明的是，尽管系统现在可能更成熟了，但当我们使用它（大约在1.0版本左右）时，我们会遇到奇怪的 occasional assert 错误和异常，导致内部数据库操作无法进行，并且通常需要清除这些节点上的数据以修复问题。

另一个因素是成本，这可能与您的应用程序有关，也可能与您的决策无关。键空间越大，从硬件角度来看，Aerospike集群就越昂贵。所有键都需要存储在内存中，而不管它是内存还是SSD命名空间。一旦进入数十亿个键的范围，您将需要在集群中拥有数TB的RAM，以支持具有复制因子2的大规模集群。Cassandra显然没有这个问题，因为键和值都存储在磁盘上。为了回答你的第二个问题，是的，它确实像所声称的那样好，我们存储了约50亿个键，并且在峰值负载时每秒处理大约100万次交易，并且这一切都毫不费力（尽管每个集群需要近20个节点，每个节点有120GB内存）。至于是否建议用Aerospike替换Cassandra，对我们来说这是一个明显的胜利和正确的决定。如果您的应用符合Aerospike的设计，并且成本效益良好，则绝对建议进行转换。但归根结底，还是要看您的使用情况。如果不清楚哪种更适合您，则可以尝试两种并查看它们的表现如何。祝好运。

编辑：

目前选择Cassandra而不是Aerospike的原因之一是当应用程序需要某些一致性保证时。例如，对于计数器这样的应用程序，由于网络分区，Aerospike可能会处于不一致状态，而Cassandra则可以通过使用无冲突复制数据类型（CRDT）来解决这个问题。在良好的网络环境下以及许多常见情况中，这不是一个问题，但正如前面所述，Aerospike的性能无可比拟，这通常是选择它的原因。

编辑2：

Aerospike v4现在已经引入了他们的一致性模式(由Jepsen验证：https://jepsen.io/analyses/aerospike-3-99-0-3)。此外，Aerospike通过强一致性实现了它，而Cassandra仅通过使用CRDT实现了最终一致性，因此仍然可能读取过时数据。此外，从个人测试来看，在使用其强一致模式时，我们的用例在正常操作期间表现不受影响。