比较：Aerospike和Cassandra [英] Comparison : Aerospike vs Cassandra

问题描述

Aerospike和Cassandra都表示，他们在各自的基准中比另一个更好。

Both Aerospike and Cassandra says they are better than the other in their own respective benchmarks.

参考： http://java.dzone.com / articles / benchmarking-cassandra-right 以及其他几个。

有人使用过这两个？

Aerospike是否声称有效？

最后是建议用Aerospike替换Cassandra 吗？

推荐答案

Cassandra和Aerospike之间的选择真的取决于你的用例比任何东西。我个人使用这两个作为同一个项目的生产系统，对我来说，Aerospike是显而易见的赢家，但这是因为我们的使用案例是具有高并发，低延迟，事务，小的更新数十亿条条目，写卷。这是Aerospike擅长的，它具有我在数据库中看到的最小延迟，即使在使用SSD命名空间。鉴于这些原因，Aerospike是我们的明确选择。

Choosing between Cassandra and Aerospike really depends on your use case more than anything. I have personally used both as a production system for the same project and for me Aerospike was the clear winner but that's because our use case is to have highly concurrent, low latency, transactional, small updates to billions of entries with ~10x more read than write volume. This is what Aerospike excels at, it has the minimal latency I have ever seen in a database of its kind even when using an SSD namespace. For these reasons Aerospike was the clear choice for us.

另一方面，Cassandra对于高写入量更好，可以处理更大的记录。一切都是基于页面的，所以它在非SSD上运行良好，但永远不会给你极低的延迟，Aerospike可以，除非你的记录适合缓存。它也值得注意，Cassandra从操作的角度来看比Aerospike更难以维护。对我们来说，这是一个操作噩梦，我知道Netflix必须雇佣一个庞大的运营工程师团队来管理他们的Cassandra集群。此外，虽然系统可能已经成熟了更多的现在，当我们使用它（1.0版本附近），我们会碰到奇怪的偶然断言错误和异常，停止内部数据库操作发生，通常不得不从这些节点擦除数据

On the other hand, Cassandra is better for high write volume and can handle larger records. Everything is page based so it operates well on non-SSDs but can never give you the extreme low latency that Aerospike can unless your records fit into the cache. Its also worth noting that Cassandra is much harder to maintain from an operations perspective than Aerospike is. For us personally it was an operations nightmare and I know that Netflix has to employ a sizable team of operations engineers solely to manage their Cassandra clusters. Also while the system may have matured more by now, when we were using it (around the 1.0 version) we would hit strange occasional assert errors and exceptions that stop internal db actions from taking place and typically had to wipe the data from those nodes in order to fix it every time.

这里的另一个因素是成本，这可能会或可能不会影响您的决定，取决于您的应用程序。密钥空间越大，Aerospike集群从硬件角度来看就越昂贵。所有的键都需要存储在内存中，而不管它是在内存还是在ssd命名空间。一旦你进入了数十亿的密钥范围，你将需要在你的群集中的太字节RAM来支持复制因子为2. Cassandra显然没有这个问题，因为键和值都是磁盘上的存储。

Another factor here is cost which may or may not play into your decision depending on your application. The larger the keyspace the more expensive your Aerospike cluster will be from a hardware perspective. All keys need to be stored in memory regardless of whether it is an in memory or ssd namespace. Once you get into the billions of keys range you will need terabytes of ram in your cluster to support that with a replication factor of 2. Cassandra obviously does not have this issue since the keys and values are both stores on disk.

为了回答你的第二个问题，是的，它是如它声称，我们存储约5B钥匙和高达负荷时约1M TPS，它不会打破汗水（虽然它需要几乎20个节点每个群集做到这一点，每个120GB ram）。至于是否可取代Cassandra与Aerospike，对我们来说是一个明确的胜利和正确的决定。如果您的应用程序符合Aerospike的设计，并且它的成本效益，那么它绝对是明智的做出切换。当它来到它虽然它关于你的用例。如果它不清楚哪一个更适合你，然后尝试他们两个，看看他们如何玩。祝你好运。

To answer your second 2 questions, yes it is as good as it claims, we store about 5B keys and do ~1M TPS at peak load and it does it without breaking a sweat (although it takes almost 20 nodes per cluster to do this with 120GB ram each). And as for is it advisable to replace Cassandra with Aerospike, for us it was a definite win and the right decision. If your application fits the design of Aerospike and it works out to be cost effective then it is definitely advisable to make the switch. When it comes down to it though its about your use case. If its not clear which one is the better fit for you then try them both and see how they play out. Good luck.

这篇关于比较：Aerospike和Cassandra的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！