Elasticsearch vs Cassandra vs Elasticsearch与Cassandra

Question

我正在学习NoSQL，并根据客户的要求查看不同的选项。在提出这个问题之前，我已经经历了各种资源（一个对NoSQL知之甚少的人）

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

我最后得到了一个简短的清单：Cassandra and Elasticsearch

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

尽管Elastic Search最适合索引（由Lucene支持），并且可以通过抛出一些随机文本来随机搜索数据。但即使我想检索数据from_date to to_date（我希望它可能是），它的工作原理是否相同。但真正的问题是，它是一个搜索引擎，还是完美的NoSQL数据存储，如Cassandra？如果是的话，为什么我们仍然需要Cassandra？

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

Answer 1

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

我们已经问了同样的问题（我们自己）......＆＃34;为什么我们不能从ElastsicSearch获得所有内容？＆＃34;

答案是ElasticSearch被设计为搜索引擎，而不是持久数据存储。有时ElasticSearch会丢失写入内容。在ElasticSearch中很难进行模式更改，而不会将所有内容都移除并重新加载。为此，我编写了旨在使ElasticSearch与我们的Cassandra集群保持同步的作业。还有一个fairly recent discussion on Quora about this topic，它产生了类似的观点。

话虽这么说，ElasticSearch将伟大的作为搜索引擎。 Cassandra将伟大的作为可扩展的高性能数据存储区。但查询数据与搜索数据不同。有时候我们需要一个或另一个，两者的组合很适合我们的应用。它可能（或可能不适用）适合你。

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

Answer 2

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）

Answer 3

在我自己解决这个问题之后，我已经意识到当你想确保使用可靠的写入操作保留数据模式时，像casandra这样的NoSQL数据库是好的，并且不想利用elasticsearch提供的索引操作。如果你想保留一些索引数据，那么如果你信任你的方案并且只做更多的读取而不是写入，那么elasticsearch是好的。

我的案例是数据分析。所以我在弹性搜索中保留了很多我的Latices，因为后来我想要遍历数据，看看下一步应该是什么。如果我想在分析线中对数据模式进行大量更改，我会使用casandra。

还有很多很好的代表工具，比如kibana，你可以使用它来展示你的数据和一些好的图形。也许我很懒，但他们很好看，他们帮助了我。

Answer 4

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

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

Answer 5

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

Answer 6

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

卡桑德拉（Cassandra）也赢得了更新性能。 Elasticsearch支持更新，但是更新实际上是原子操作中的重新索引+软删除。

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

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

如果其中之一足以满足您的要求（例如，在这里看来ES可以很好地工作），那么我只会使用其中一个。如果您有两个方面的要求，则可以：

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

Answer 7

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

Answer 8

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

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

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

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