ElasticSearch对ElasticSearch+Cassandra

Question

我的主要问题是，集成Cassandra和Elasticsearch相对于只使用Elasticsearch有什么好处？

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

• 很多答案都是老掉牙的。这几年可能发生了很大变化。
• 提到的一点是，“有时ElasticSearch会丢失写”。然而，可以想象，那些所谓的损失可能是由于这些年来已经解决的一些错误。可以假设，例如，Cassandra也可能有一些导致数据丢失的bug。卡桑德拉和Elasticsearch之间是否有根本的区别，导致Elasticsearch丢失数据，但不导致Cassandra的数据丢失？
• 需要指出的是，“在ElasticSearch中进行架构更改是很困难的，如果不将所有内容都吹走并重新加载的话。”假设我们的数据模型相对稳定，或者至少向后兼容，这对我们来说可能不是一个大问题。此外，由于Elasticsearch中的动态映射，它可能会适应新的需求(例如，额外的字段)。
• 关于Elasticsearch的索引延迟问题，Cassandra也没有提供一致性。因此，在卡桑德拉，你也可能面临阅读书面数据的延迟。

总的来说，卡桑德拉在与Elasticsearch一起使用时提供了哪些额外功能？

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

Answer 1

因此，作为一个链接答案(Elasticsearch vs Cassandra vs Elasticsearch Cassandra)的作者，我想我应该在这里称一下。

那些所谓的损失可能是因为这些年来已经解决的一些错误。

这是绝对正确的说法。我写的答案已经将近六年了，在那个时候，ElasticSearch已经成为一个更可靠的产品。话虽如此，有些事情卡桑德拉可以做，ElasticSearch只是设计不做(反之亦然)。

卡桑德拉提供了什么额外的功能。

我可以想到一些，我将在这里总结如下：

• throughput/performance/latency写

ElasticSearch是一个基于Lucene项目的搜索引擎。在低延迟情况下处理大量的写吞吐量并不是它设计的目的，至少不是“开箱即用”。有一些方法可以将ElasticSearch配置得更好，如下所述：用ElasticSearch实现高写入吞吐量的技术。但是，在构建一个配置最小的新集群方面，您将花费更少的时间来完成这一任务。

“有时ElasticSearch会输”

是的，我写的。再一次，ElasticSearch有了改进。很多。但是，我仍然认为这是在高写吞吐量条件下发生的。当集群被设计为一定的吞吐量，并且应用程序超过了这些允许，导致一个节点被写反压力所淹没时，写就会丢失。

卡桑德拉也不能幸免于这个问题。它只是对它有更高的容忍度。如果要将两者结合使用，架构Kafka之类的东西来“节流”每个人的写吞吐量将是一种很好的方法。

• 多数据中心高可用性

具有定义逻辑数据中心和可用性区域(架)的能力，Cassandra一直擅长在多个区域上复制数据集。这对于ElasticSearch来说是个问题，因为它没有逻辑数据中心的概念，并且它的“主”节点不是活动/活动的。

• 对等节点与基于角色的节点

作为我的MDHA点的后续，ElasticSearch现在允许在集群中指定具有“角色”的节点。您可以指定多个节点作为“主”角色，负责添加和更新索引。任何节点都可以将搜索流量定向到在“数据”角色下工作的节点。实际上，提高写入吞吐量(我的第一个谈话点)的一种方法是指定一个或两个具有“摄取”角色的节点，这可以防止读写通信量相互干扰。

这偏离了Cassandra的方法，即每个节点都是对等节点，并且可以处理读和写。能够对所有节点进行相同的处理，简化维护和管理。“不”，尽管普遍存在误解，但“种子”节点并没有什么特别之处。

• 查询与搜索

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

通过匹配一个或多个列/属性上的模式来检索数据是搜索。此外，通过搜索，结果的数量更多的是一个未知的事先。当然，Cassandra在过去几年中增加了一些特性，以便基于LIKE查询进行模式匹配(我不建议使用它)。但是，当需要“搜索”数据集的能力时，卡桑德拉无法与ElasticSearch竞争。

通过在特定键(列)上提供特定值来检索数据是查询。通过查询，对于要返回的结果的数量也更容易有准确的预期。如果我正在构建一个应用程序，并且我知道我只需要使用一个静态的、预定义的查询来检索数据，每次我都会选择Cassandra。

有了Cassandra，我还可以调优查询一致性，需要从或多或少的副本中获得操作确认。同样，我也可以根据应用程序的位置将这些操作定向到特定的地理区域。

...when与Elasticsearch一起使用？

他们互相恭维很好。卡桑德拉擅长于一些ElasicSearch不擅长的东西(上面详细介绍)(反之亦然.说了很多)。应用程序的需求可能需要搜索和查询。有时候你有一个应用程序需要高速键查找“哦，我们也想要搜索。”

摘要，tl;dr;

所以，虽然我在这里写了很多，但我要继续讲的重点是为这项工作选择合适的工具。当我需要搜索时，我会选择ElasticSearch。当我需要在高度可用的地理感知场景中查询时，我将选择Cassandra。我仍然看到应用程序同时使用这两种应用程序，因此两者都有各自的优点。