因此，作为一个链接答案（elasticsearch vs cassandra vs elasticsearch with cassandra）的作者，我想我应该在这里权衡一下。
这些所谓的损失可能是因为这些年来解决了一些问题。
这是一个绝对正确的说法。我写的答案已经有六年的历史了，而elasticsearch在那时已经发展成为一个更加可靠的产品。也就是说，Cassandra可以做一些elasticsearch没有设计好的事情（反之亦然）。
Cassandra提供了什么额外的功能。。。
我能想到一些，我将在这里总结：
写吞吐量/性能/延迟
elasticsearch是一个基于lucene项目的搜索引擎。在低延迟下处理大量的写吞吐量并不是它设计的目的；至少不是“开箱即用”。有一些方法可以将elasticsearch配置得更好，如下所述：使用elasticsearch实现高写吞吐量的技术。但就用最少的配置构建一个新集群而言，您将花费更少的时间来设计cassandra来完成这一任务。
“有时elasticsearch会丢失写入”
是的，我写的。同样，elasticsearch有所改进。很多。但我仍然看到这种情况在高写吞吐量条件下发生。当集群的吞吐量达到一定水平时，应用程序超出这些容差，导致节点无法承受回写压力，写操作将丢失。
Cassandra也不能幸免这个问题。它只是有一个更高的容忍度。如果您同时使用它们，那么设计类似kafka的东西来“限制”每一个的写吞吐量将是一个很好的方法。
多数据中心高可用性（mdha）
由于能够定义逻辑数据中心和可用性区域（机架），cassandra一直擅长在多个区域上复制数据集。这对于elasticsearch是有问题的，因为它没有逻辑数据中心的概念，并且它的“主”节点不是活动/活动的。
对等节点与基于角色的节点
作为我的mdha观点的后续，elasticsearch现在允许在集群中为节点指定一个“角色”。您可以指定多个节点作为“主”角色，负责添加和更新索引。任何节点都可以将搜索流量定向到在“数据”角色下工作的节点。事实上，提高写吞吐量的一种方法（我的第一个重点）是指定一个或两个具有“摄取”角色的节点，这可以防止读写通信量相互干扰。
这与cassandra的方法不同，在cassandra的方法中，每个节点都是对等的，可以处理读写操作。能够对所有节点一视同仁，简化了维护和管理。“不”，尽管普遍存在误解，“种子”节点并不是什么特别的东西。
查询与搜索
对我来说，这是两者的根本区别。查询不同于搜索。它们看起来很相似，但却大不相同。
通过匹配一个或多个列/属性上的模式来检索数据就是搜索。同样是搜索，结果的数量更多的是事先未知的。当然，cassandra在过去几年中添加了一些特性，允许基于 LIKE 查询（我不建议使用它）。但当需要“搜索”数据集的能力时，cassandra无法与elasticsearch竞争。
通过在特定键（列）上提供特定值来检索数据是查询。通过查询，还可以更容易地对要返回的结果的数量有准确的预期。如果我正在构建一个应用程序，并且我知道我只需要基于一个静态的、预定义的、带有特定键的查询来检索数据，那么每次我都会选择cassandra。
使用cassandra，我还可以调整查询一致性，需要从更多或更少的副本中进行操作确认。同样，我也可以根据应用程序的位置将这些操作定向到特定的地理区域。
…与elasticsearch结合使用时？
他们互相称赞得很好。Cassandra擅长一些elasicsearch所不擅长的事情（如上所述）。应用程序的需求可能需要搜索和查询。有时你的应用程序需要高速键查找“哦，我们也需要搜索”
总结，tl；博士；
因此，虽然我在这里写了很多东西，但我将继续讨论的重点是，为工作选择合适的工具。当我需要搜索时，我会选择elasticsearch。当我需要在一个高度可用、地理感知的场景中进行查询时，我会选择cassandra。我仍然看到应用程序同时使用这两者，所以两者都有各自的优点。