We have migrated from Cassandra (CS) to Aerospike (AS) due to low latency and predictability requirements, including lower time for maintenance.
Our data set is not as large as yours and I don’t know your Read/Write throughput, latency requirements and data model so it is difficult to answer about drawbacks. AS is one of the fastest and most predictable storages. Do you really need 74TB of data to be accessible as fast as possible?
AS is designed to perform best on SSD’s or in memory. For a large data sets we use SSD’s, in-memory for small. For our throughput we managed to downsize server count from 64 for CS to 6 for AS: 10 times less servers, saved on power and hardware costs! That allowed us to get a paid support - we found it invaluable. We also saved on development, since AS is much more predictable, Network load is also much lower if you used read repairs with CS.
AS requires much less maintenance, we even managed to lost 1 or two servers (hardware issues) without even knowing. With CS such situation is a pain. Adding new AS nodes is as easy as just start and forget. Replacing a dead one is the same as adding a new one.
CS sstables has a huge overhead, re-balancing is mostly manual, while AS has no such overhead and automatically balances the cluster - you even don’t have to monitor it. For the latency, CS can’t compete with AS due to GC pauses, compaction, etc. Even using the same hardware as for AS, Cassandra will just die due to a lot of overhead.
The one AS drawback on SSD’s is slow node startup after reboot - it needs to rebuild indexes scanning SSDs. The time depends on amount of data on your node. It may take a lot of time, may be over 1 hour. But it may happen once a year and you will not care a lot, since the cluster still performs well.
To get most from AS you need to learn its data models. When you learn it and design your model properly, you easily calculate your cluster capacity. You can’t do the same with Cassandra. The AS drawbacks, as for Cassandra - you need to know its limits. Such as 32k unique bin names and name length - CS has no such limits for dynamic columns. The size of the record (CS row) when not using large data types is also limited, but to read a record you will do exactly 1 read I/O, while you can’t count it for CS and 1 I/O for CS is much larger - a huge overhead for a throughput.
We do not use yet cross-DC replications, so no comments on this. But I’m sure AS will also win over CS repairs in case of failures, which is a most pain for CS maintenance.
With AS you concentrate on your business, not hot to survive with CS.