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