ElasticSearch 与 ElasticSearch+Cassandra

Question

我的主要问题是集成 Cassandra 和 Elasticsearch 与仅使用 Elasticsearch 相比有什么好处？

事实上，在 StackOverflow 上有类似问题的答案（例如，这里和这里）。但是有几点：

• 很多答案都是旧的。这些年来可能发生了很多变化。
• 提到的一点是“有时 ElasticSearch 会丢失写入”。但是，可以想象，那些所谓的损失可能是因为这些年来已经解决了一些错误。可以假设，例如 Cassandra 也可能有一些导致数据丢失的错误。Cassandra 和 Elasticsearch 之间是否存在导致 Elasticsearch 丢失数据但不会导致 Cassandra 丢失数据的根本区别？
• 提到了“在 ElasticSearch 中，架构更改很难在不清除所有内容并重新加载的情况下进行。” 假设我们的数据模型相对稳定或至少向后兼容，这对我们来说可能不是主要问题。此外，由于 Elasticsearch 中的动态映射，它可以适应新的需求（例如，额外的字段）。
• 关于 Elasticsearch 中的索引延迟，Cassandra 也没有提供一致性。因此，在 Cassandra 中，您可能还会面临读取写入数据的延迟。

总的来说，Cassandra 与 Elasticsearch 结合使用时提供了哪些额外功能？

PS 如果问题得到普遍回答可能会更好。但是，如果有必要，假设我们只将行添加到数据库中，而从不删除或更新任何内容。我们希望能够在数据中进行全文搜索。

Answer 1

因此，作为链接答案之一（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 的方法不同，其中每个节点都是对等节点，并且可以处理读取和写入。能够一视同仁地对待所有节点，简化了维护和管理。“不”，尽管普遍存在误解，但“种子”节点 not 并不是什么特别的。

• 查询与搜索

对我来说，这是两者之间的根本区别。查询是不一样的搜索。它们可能看起来很相似，但它们完全不同。

通过匹配一个或多个列/属性上的模式来检索数据是搜索。同样通过搜索，结果的数量更多是事先未知的。当然，Cassandra 在过去几年中添加了一些功能以允许基于LIKE查询的模式匹配（我不建议使用它）。但是当需要“搜索”数据集的能力时，Cassandra 无法与 ElasticSearch 竞争。

通过在特定键（列）上提供特定值来检索数据是查询. 通过查询，对要返回的结果数量有准确的预期也更容易。如果我建立一个应用程序，我知道，我只曾经有检索基于一个静态数据，与特定键预先定义的查询，我会选择卡桑德拉每次。

使用 Cassandra，我还可以调整查询一致性，需要来自更多或更少副本的操作确认。同样，我还可以根据应用程序的位置将这些操作定向到特定的地理区域。

...当与 Elasticsearch 结合使用时？

他们互相称赞。Cassandra 擅长一些 ElasicSearch 不擅长的事情（详见上文）（反之亦然......说了很多）。对于应用程序的要求，可能需要两个搜索和查询。有时您的应用程序需要高速键查找“哦，我们也需要搜索”。

总结，tl;dr;

因此，虽然我在这里写了很多，但我将继续讨论的主要观点是为工作选择正确的工具。当我需要搜索时，我会选择 ElasticSearch。当我需要在高度可用、具有地理感知能力的场景中进行查询时，我会选择 Cassandra。我仍然看到应用程序同时使用两者（串联），因此两者都有其优点。