Comparison : Aerospike vs Cassandra
If you need stable predictable performance with low latency and no hassle with maintanence, go with Aerospike. Want to play games, go Cassandra. I've bring Cassandra more than 4 years ago to my company with no regret, but today for the reasons above I choose Aerospike, which is open source and more available than a year ago and biult like a russian tank - with reason.
You just have to know the limits of both platforms. Play with both, choose wisely.
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.
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.
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.
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.
Edit:
One of the reasons currently to choose Cassandra over Aerospike is for when applications need certain consistency guarantees. For applications such as counters for example, Aerospike can become in an inconsistent state due to a network partition whereas Cassandra is capable of these through the use of conflict free replicated data types (CRDT). On a good network and also for many use cases in general this isn't an issue, but as stated earlier the performance of Aerospike can't be beaten and that's typically why it is chosen.
Edit 2:
Aerospike v4 has now introduced their version of a consistent mode (verified by Jepsen: https://jepsen.io/analyses/aerospike-3-99-0-3). Additionally Aerospike has implemented it through strong consistency whereas Cassandra only has eventual consistency through the use of CRDTs so it's still possible to read stale data. Also from personal testing I can say that the performance during normal operation did not suffer for our use case when using their strongly consistent mode.