Elasticsearch vs Cassandra vs Elasticsearch with Cassandra

我正在学习 NoSQL，并且正在为我的客户的一个需求寻找不同的选择。在提出这个问题之前，我浏览了各种资源(一个对 NoSQL 知之甚少的人)

  • 我需要以更快的速度存储数据并读取数据。
  • 完全的故障安全和易于扩展。
  • 能够通过数据搜索分析。

我得到了一个简短的列表: Cassandra and Elasticsearch

我明白的是 Cassandra 对我来说是一个完美的 NoSQL 存储解决方案，因为我可以使用索引来写数据和读数据。它失败或可能失败的地方在于分析。在未来，如果我想从 from_date to to_date中获取数据，或者更多的方法来获取数据用于分析，如果我没有正确设计数据模型或者保持长远的眼光，这在不断变化的世界中可能会很困难。

而 Elastic Search最擅长索引(由 Lucene 支持) ，可以通过抛出一些随机文本随机搜索数据。但是即使我想要检索数据 from_date to to_date(我希望它可能是) ，它的工作原理是否相同。但真正的问题是，它是一个搜索引擎，还是像 Cassandra 那样完美的 NoSQL 数据存储？如果是的话，我们为什么还需要卡珊德拉？

如果这两者是在不同的世界，请解释！我们如何将它们结合起来得到一个更有效的解决方案？

68889 次浏览
小开

Cassandra + Lucene 是一个很好的选择，在这个问题上有不同的举措，例如:

  • Stratio 的 Cassandra Lucene Index-派生自 Stratio Cassandra，是一个扩展其索引功能的 Cassandra 插件。(https://github.com/Stratio/cassandra-lucene-index)
  • Stratio Cassandra，它是 Apache Lucene 的原生集成，非常有趣。(https://github.com/Stratio/stratio-cassandra)-该项目已停止有利于 Stratio 的 Cassandra Lucene 指数
  • Tuple Calliope 就像 Stratio Cassandra 一样，只不过没那么活跃
  • 通过 Datastax 进行 DSE 搜索。它允许在 Apache Solr 中使用 Cassandra，但是它是一个专有选项
小开
最佳答案

我们的一个应用程序使用存储在 Cassandra 和 ElasticSearch 中的数据。我们使用 Cassandra 在任何可能的时候访问这些记录，并将数据复制到查询表中，这些查询表旨在遵循特定的应用程序端请求。对于比我们的查询表所允许的更自由的搜索，ElasticSearch 很好地执行了这一功能。

我们也问过(我们自己)同样的问题... ... “为什么我们不从弹性搜索中获取所有信息呢?”

答案是 ElasticSearch 被设计成一个搜索引擎，而不是一个持久的数据存储。有时 ElasticSearch 会丢失写入。在 ElasticSearch，如果不把所有东西都炸掉并重新装载，模式改变是很难做到的。为此，我编写了一些工作，旨在保持 ElasticSearch 与我们的 Cassandra 集群同步。还有一个 最近 Quora 上关于这个话题的讨论，产生了类似的点。

也就是说，ElasticSearch 作为搜索引擎使用 很好。Cassandra 使用 很好作为可伸缩的高性能数据存储。但是 有疑问的数据与 寻找的数据不同。有时候我们需要其中之一，而这两者的结合对于我们的应用程序来说非常有效。它可能(也可能不)对你有用。

至于分析，我在使用 Cassandra Spark 连接器服务更复杂的 OLAP 查询方面取得了一些成功。希望能帮上忙。

编辑20200421

对于一个类似的问题，我写了一个更新的答案:

ElasticSearch 与 ElasticSearch + Cassandra

小开

在我自己解决了这个问题之后，我意识到像 casandra 这样的 NoSQL 数据库是很好的，当你想要确保你的数据模式保持可靠的写操作，并且不想利用 elasticsearch 提供的索引操作时。如果你想保留一些索引数据，那么弹性搜索是很好的，如果你相信你的方案，只会做更多的读比写。

我的案子是数据分析。因此，我保留了很多我的 Latice 在弹性搜索，因为后来我想通过数据遍历了很多，看看应该是我的下一步。如果我想在我的分析流程中对数据的模式进行大量改变，我会使用 casandra。

此外，还有许多不错的表示工具，如 kibana，您可以使用它们以一些好的图形来显示数据。也许我很懒，但他们都很好看，他们帮助了我。

小开

将数据存储在 Cassandra 和 ElasticSearch 的组合中可以提供大部分功能。它允许您查找键值表，还允许您搜索索引中的数据。

这种组合为您提供了很大的灵活性，非常适合您的应用程序。

小开
  • 由于 elasticsearch 是建立在 Lucene 索引之上的，如果你想在 elasticsearch 中存储索引，它的性能比 Cassandra 本身的索引检索数据要好得多。
  • 如果你的需求与实时检索无关，那么你也可以使用 ElasticSearch 作为 NoSQL 数据库，有人认为 ElasticSearch 会丢失写操作和模式更改，但是如果你的数据量不是太大。您可以很容易地将 elasticsearch 作为一个搜索引擎来实现，并且使用最佳索引和 elasticsearch 作为一个 NoSQL 数据库。有几种方法可以防止这种情况的发生。我曾经在 elasticsearch 中做过模式更改，如果您的数据结构是一致的，那么它会产生任何问题。
  • 成为 ElasticSearch 或 SOlr 的支持者。我已经在两个搜索引擎和我的经验，这两个搜索引擎可以使用流利，如果你配置正确。
  • 只有缺点，我可以想到它，如果你的目标是实时的结果，不能妥协毫秒延迟您的反应。那么最好借助其他 NoSQL 数据库，如 Cassandra 或 Couchbase。
  • Cassandra 使用 solr，比 Cassandra 使用 elasticSearch 效果更好。
小开

Elassandra 是 Cassandra + Elastic Search 的组合解决方案，它使用 Elastic search 索引数据，Cassandra 作为数据存储，我不确定性能，但是根据这个 文章，它的性能很好。
如果您的应用程序需要搜索功能，那么 Elassandra 是最好的开源选择。DSE 搜索是可用的，但它的昂贵。

小开

我们开发了一个应用程序，在其中我们使用了 Elasticsearch 和 Cassandra。 类似的数据被存储到 Cassandra 中，并被索引到 Elasticsearch 中。

我们应用程序的 UI 具有搜索、聚合、数据导出等特性。 后端微服务不断获取海量数据(关于卡夫卡主题)并将其存储到 Cassandra 中。一旦数据被存储到 Cassandra，服务将确保数据被索引到 Elasticsearch。

Cassandra 是 Elasticsearch 的“真相之源”。在需要重新索引 ES 索引的情况下，我们查询 Cassandra 并将数据重新索引到 ES 中。

这个解决方案帮助了我们，因为它非常容易扩展，搜索和聚合速度也快得多。

小开

Cassandra 擅长通过 ID 检索数据。我不太了解二级索引的性能，但我怀疑它是否像 Elasticsearch 那样快。当然是 Elasticsearch 在全文搜索功能方面胜出(文本分析、 相关性评分相关性评分等)。

Cassandra 在更新性能上也赢了。Elasticsearch 支持更新，但是更新实际上是原子操作中的 reindex + soft delete。

Cassandra 有一个非常好的复制模型(如果你需要额外的故障安全)。Elasticsearch 也不错，我不认为 ES 是特别不可靠的(它有时会出问题，就像所有软件一样)。

Elasticsearch 也有用于实时分析的 聚合，而且由于搜索速度非常快，对一部分数据的分析将是快速的也是如此。

如果您的需求通过其中一个已经足够满足(就像这里似乎 ES 可以很好地工作) ，我只会使用其中一个。如果两个世界都有需求，那么您可以:

  • 利用其中的一个，克服不利因素。例如，您可以使用 Elasticsearch 处理许多更新，但是需要更多的碎片和更多的硬件
  • 同时使用两者，并确保它们是同步的

提交答案