Elasticsearch与Cassandra对比Elasticsearch与Cassandra

我正在学习NoSQL，并正在为客户的需求之一寻找不同的选择。在提出这个问题之前，我已经遍历了各种资源（对NoSQL不太了解的人）

• 我需要以更快的速度存储数据并读取数据。
• 完全故障安全且易于扩展。
• 能够搜索数据以获取Google Analytics（分析）。

最后我列出了以下内容： Cassandra and Elasticsearch

我所了解的是，Cassandra对我来说是一个完美的NoSQL存储解决方案，因为我可以使用索引写入数据和读取数据。它失败或可能失败的地方在Analytics（分析）上。将来，如果我想从中获取数据from_date to to_date，或者想以更多方式获取数据进行分析，那么如果我没有正确设计数据模型或保持长期的眼光，那么在不断变化的世界中，这可能会很难。

While Elastic Search最擅长建立索引（由Lucene支持），并且可以通过抛出一些随机文本来随机搜索数据。但是，即使我要检索数据，它是否也一样工作from_date to to_date（我希望是这样）。但是真正的问题是，它是搜索引擎还是像Cassandra这样的完美NoSQL数据存储？如果是，为什么我们仍然需要Cassandra？

如果两者都在不同的世界，请解释一下！我们如何结合它们以获得更有效的解决方案？

我们的应用程序之一使用存储在Cassandra和ElasticSearch中的数据。我们尽可能使用Cassandra访问这些记录，并将数据复制到查询表中，这些查询表旨在遵守特定的应用程序端请求。对于比我们的查询表所允许的更为宽松的搜索，ElasticSearch可以很好地执行该功能。

我们（我们自己）也曾问过同样的问题……“为什么我们不从ElastsicSearch中得到一切？”

答案是，ElasticSearch被设计为搜索引擎，而不是持久性数据存储。有时ElasticSearch丢失写入。如果不浪费一切并重新加载，则在ElasticSearch中很难进行模式更改。为此，我编写了旨在使ElasticSearch与我们的Cassandra集群保持同步的作业。最近在Quora上有关该主题的讨论也很相似。

话虽如此，ElasticSearch可以很好地用作搜索引擎。而且Cassandra可以很好地用作可扩展的高性能数据存储。但是查询数据不同于搜索数据。有时候，我们需要一个或另一个，而将两者结合起来对我们的应用程序则很好。它可能（或可能不）适合您的产品。

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

编辑20200421

我为类似的问题写了新的答案：

ElasticSearch与ElasticSearch + Cassandra

Cassandra + Lucene是一个不错的选择。有针对此问题的不同举措，例如：

• Stratio的Cassandra Lucene索引-源自Stratio Cassandra，是Apache Cassandra的插件，扩展了其索引功能。（https://github.com/Stratio/cassandra-lucene-index）
• Stratio Cassandra，它是与Apache Lucene的本机集成，非常有趣。（https://github.com/Stratio/stratio-cassandra）-该项目因Stratio的Cassandra Lucene索引而被终止
• Tuplejump Calliope，就像Stratio Cassandra一样，但是不太活跃。（https://github.com/tuplejump/stargate-core）
• DSE按Datastax搜索。它允许将Cassandra与Apache Solr一起使用，但这是一个专有选项。（http://www.datastax.com/what-we-offer/products-services/datastax-enterprise）

在自己解决了这个问题之后，我意识到，想要确保使用可靠的写操作来保存数据架构，并且不想利用elasticsearch提供的索引操作，像casandra这样的NoSQL数据库是不错的选择。如果您想保留一些索引数据，那么在您信任自己的方案并且只进行比写入更多的读取时，elasticsearch会很有用。

我的案例是数据分析。因此，我在弹性搜索中保留了很多Latices，因为以后我想遍历大量数据以查看下一步应该做什么。如果我想在分析桩线上的数据架构中进行很多更改，我会使用casandra。

另外，还有许多不错的表示工具，例如kibana，可用于以一些良好的图形表示数据。也许我很懒，但是他们看上去很好，他们帮助了我。

结合使用Cassandra和ElasticSearch来存储数据可为您提供大多数功能。它允许您查找键值表，还可以搜索索引中的数据。

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

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

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

我们应用程序的UI具有搜索，聚合，数据导出等功能。后端微服务不断获取大量数据（关于Kafka主题）并将其存储到Cassandra中。一旦将数据存储到Cassandra中，服务将确保将数据索引到Elasticsearch中。

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

该解决方案为我们提供了帮助，因为它非常易于扩展，并且搜索和汇总速度更快。

• 由于Elasticsearch是基于Lucene索引构建的，因此，如果要在Elasticsearch中存储索引，则与Cassandra本身中的索引进行检索相比，其性能最佳。
• 如果您的需求与实时检索无关，那么您也可以将elasticsearch用作NoSQL数据库，人们认为ElasticSearch丢失写操作和更改架构很困难，但是如果您的数据量不是太大。您可以轻松地将elasticsearch作为具有最佳索引的搜索引擎，并将elasticsearch作为aNoSQL数据库。有几种预防方法。我已经研究过Elasticsearch中的模式更改，如果您的数据结构一致，那么它将产生任何问题。
• 成为ElasticSearch或SOlr的支持者。我已经在两个搜索引擎上工作，并且我发现，如果正确配置它们，则可以流畅使用两个搜索引擎。
• 只有缺点，我能想到的，如果您的目标是实时结果并且不能延迟响应时间的毫秒级。然后最好利用其他NoSQL数据库（例如cassandra或couchbase）的帮助。
• 带有solr的Cassandra，比带有elasticSearch的Cassandra更好。

Cassandra擅长通过ID检索数据。我对二级索引的性能了解不多，但是我怀疑它是否与Elasticsearch一样快。在全文搜索功能（文本分析，相关性评分）上，Elasticsearch当然可以胜出等）方面。

Cassandra的更新性能也很出色。Elasticsearch支持更新，但是更新实际上是原子操作中的重新索引+软删除。

Cassandra有一个非常好的复制模型（如果您需要额外的故障保护功能）。Elasticsearch也可以，我并不是在说ES特别不可靠（有时像所有软件一样会出现问题）。

Elasticsearch还具有用于实时分析的聚合。而且由于搜索是如此之快，因此对数据子集的分析将很快。

如果其中之一满足您的需求（就像这里的ES似乎可以正常工作），我将只使用其中一个。如果您有两个方面的要求，则可以：

• 使用其中之一并解决不利因素。例如，您也许可以使用Elasticsearch处理许多更新，但使用更多的碎片和更多的硬件
• 同时使用并确保它们同步