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

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

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