Master-Slave databases are well known for more than three decades. Whatever a database is monolithic or distributed,
SQL or NoSQL, when an outage occurs, a master-slave system requires a runtime decision to promote a slave node or a slave datacenter to the master role.
The runtime decision to switch must be taken carefully, not too fast, otherwise you can get an unstable system.
By contrast, Cassandra and Elassandra are Multi-Master, they relaxe the consistency and repair the data asynchronously and thus continuously take read/write operations with no downtime, and no runtime decision.
When moving from Apache Cassandra to Elassandra
On the search path, there is two way to request Elasticsearch. If the partition key column is known, the search (or aggregation) request is directed to one node hosting the targeted data (like routing in Elasticsearch). Thus, search throughput scale lineary with the number of nodes. Without the partition key, all nodes in the datacenter are queried like with a Cassandra secondary index. If your Cassandra replication factor is 2 for example, you can use an optimized search strategy to request half the number of nodes in the datacenter, and thus, increase the search throughput by increasing the replication factor.
Finally, comparing Elassandra performances to Cassandra or Elasticsearch ones is not really meaningful, you should rather compare the TCO of an equivalent architecture delivering the same services, same throughput and resiliency. By synchronously writing in Elasticsearch indices without duplicating the data, Elassandra drastically reduce the total volume of disk and network IOs compared to more sophisticated architectures.