我们的一个应用程序使用了同时存储在Cassandra和ElasticSearch中的数据。我们使用Cassandra在任何可能的时候访问这些记录，并将数据复制到查询表中，以满足特定应用程序端的请求。对于比我们的查询表所能允许的更自由的搜索，ElasticSearch很好地执行了该功能。
我们也问过同样的问题......“为什么我们不直接从ElastsicSearch获取所有信息呢？”
答案是，ElasticSearch被设计成一个搜索引擎，而不是一个持久的数据存储。有时ElasticSearch会丢失写操作。在ElasticSearch中进行模式更改时，很难不删除所有内容并重新加载。为此，我编写了一些作业，旨在使ElasticSearch与Cassandra集群保持同步。还有一个fairly recent discussion on Quora about this topic，也得到了类似的结果。
也就是说，ElasticSearch作为搜索引擎非常出色。Cassandra作为可伸缩的高性能数据存储也非常出色。但是，查询数据和搜索数据是不同的。有时候我们需要两者之一，而两者的结合对我们的应用程序来说很好。它可能（也可能不）对你的应用程序来说很好。
至于分析，我已经在使用Cassandra Spark连接器方面取得了一些成功，以服务于更复杂的OLAP查询。希望这能有所帮助。

编辑20200421

对于类似的问题，我写了一个更新的答案：
ElasticSearch vs. ElasticSearch+Cassandra

Cassandra + Lucene是一个很好的选择。对于这个问题有不同的倡议，例如：

• 易易工作室-各种在线工具，站长网志，以及多个应用项目。（https://github.com/Stratio/cassandra-lucene-index）
• Stratio Cassandra，这是一个与Apache Lucene的原生集成，非常有趣。（https://github.com/Stratio/stratio-cassandra）-这个项目已经停止，在有利于Stratio的Cassandra Lucene索引
• Tuplejump Calliope，它就像斯特拉蒂奥·Cassandra，但它不太活跃。（https://github.com/tuplejump/stargate-core）
• Datastax的DSE搜索。它允许使用Cassandra和Apache Solr，但这是一个专有选项。（http://www.datastax.com/what-we-offer/products-services/datastax-enterprise）

在解决了这个问题之后，我意识到当你想确保你的数据模式保持可靠的写操作，而不想利用elasticsearch提供的索引操作时，像casandra这样的NoSQL数据库是很好的。如果你想保留一些索引数据，那么elasticsearch是很好的，如果你信任你的模式，只想做更多的读操作而不是写操作。
我的案例是数据分析。所以我在ElasticSearch中保留了很多Latices，因为后来我想遍历很多数据，看看我的下一步应该是什么。如果我想在我的分析管线中的数据模式中有很多变化，我会使用casandra。
也有很多很好的表示工具，如kibana，你可以用它来表示你的数据与一些良好的图形。也许我是懒惰的，但他们是非常好看，他们帮助了我。

将数据存储在Cassandra和ElasticSearch的组合中可以提供最多的功能。它允许您查找键-值表，还允许您在索引中搜索数据。
这种组合为您提供了很大的灵活性，非常适合您的应用。

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

我们开发了一个应用程序，使用了Elasticsearch和Cassandra，类似的数据被存储在Cassandra中，并被编入Elasticsearch的索引中。
我们的应用程序的用户界面具有搜索、聚合、数据导出等功能。后端微服务不断获取大量数据（关于Kafka主题）并将其存储到Cassandra中。一旦数据存储到Cassandra中，服务将确保数据被索引到Elasticsearch中。
Cassandra是Elasticsearch的“真理之源”。在需要重新索引ES索引的情况下，我们查询Cassandra，并将数据重新索引到ES中。
这个解决方案帮助了我们，因为它非常容易扩展，搜索和聚合速度也快得多。

Cassandra非常擅长按ID检索数据。我对二级索引的性能了解不多，但我怀疑它是否能像Elasticsearch一样快。当然，Elasticsearch在全文搜索功能方面胜出（text analysis、relevancy scoring等）。
Cassandra在更新性能方面也是如此。Elasticsearch支持更新，但更新实际上是原子操作中的重索引+软删除。

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

Elasticsearch还提供聚合功能，用于实时分析。由于搜索速度非常快，对数据子集的分析也会非常快。

如果其中一个能够很好地满足您的需求（就像这里ES看起来会很好地工作），我就只使用其中一个。如果您同时有两个世界的需求，那么您可以选择：

• 使用其中的一种并解决其缺点。2例如，你可以用Elasticsearch处理很多更新，但是需要更多的碎片和硬件
• 使用两者并确保它们同步

• 因为elasticsearch是建立在Lucene索引上的，如果你想在elasticsearch中存储索引，它在检索数据方面比Cassandra本身的索引性能更好。
• 如果您的需求与实时检索无关，那么您也可以使用ElasticSearch作为NoSQL数据库，有人认为ElasticSearch会丢失写入，并且模式更改很困难，但是如果你的数据量不是太大的话，你可以很容易地把ElasticSearch作为一个搜索引擎，沿着拥有最好的索引和NoSQL数据库。我已经在ElasticSearch模式的变化，如果你的数据结构是一致的，那么它将创建任何问题。
• 作为ElasticSearch或Solr的支持者，我在这两个搜索引擎上都工作过，我的经验是，如果你正确配置这两个搜索引擎，它们都可以流畅地使用。
• 我能想到的唯一的缺点是，如果你的目标是真实的结果，不能在你的响应中容忍毫秒级的延迟，那么最好求助于其他的NoSQL数据库，比如cassandra或者couchbase。
• Cassandra使用solr，比Cassandra使用elasticSearch效果更好。