我正在学习NoSQL，并正在为客户的需求之一寻找不同的选择。在提出这个问题之前，我已经遍历了各种资源（对NoSQL不太了解的人）
最后我列出了以下内容： Cassandra and Elasticsearch
Cassandra and Elasticsearch
我所了解的是，Cassandra对我来说是一个完美的NoSQL存储解决方案，因为我可以使用索引写入数据和读取数据。它失败或可能失败的地方在Google Analytics（分析）上。将来，如果我想从中获取数据from_date to to_date，或者想以更多方式获取数据进行分析，如果我没有适当地设计数据模型或保持长期的眼光，那么在不断变化的世界中这可能很难。
from_date to to_date
While Elastic Search最擅长建立索引（由Lucene支持），并且可以通过抛出一些随机文本来随机搜索数据。但是即使我想检索数据，它是否也一样工作from_date to to_date（我希望是这样）。但是真正的问题是，它是搜索引擎还是像Cassandra这样的完美NoSQL数据存储？如果是，为什么我们仍然需要Cassandra？
Elastic Search
如果两者都在不同的世界，请解释一下！我们如何将它们结合起来以获得更有效的解决方案？
我们的应用程序之一使用存储在Cassandra和ElasticSearch中的数据。我们会尽可能地使用Cassandra访问这些记录，并将数据复制到查询表中，这些查询表旨在遵守特定的应用程序端请求。为了提供比我们的查询表所允许的更为宽松的搜索，ElasticSearch可以很好地执行该功能。
我们（我们自己）也曾问过同样的问题……“为什么我们不从ElastsicSearch中得到一切？”
答案是ElasticSearch被设计为搜索引擎，而不是持久性数据存储。有时ElasticSearch丢失写入。如果不浪费一切并重新加载，则在ElasticSearch中很难进行模式更改。为此，我编写了旨在使ElasticSearch与我们的Cassandra集群保持同步的作业。最近在Quora上有关该主题的讨论也很相似。
话虽如此，ElasticSearch可以 很好地 用作搜索引擎。而且Cassandra可以 很好地 用作可扩展的高性能数据存储。但是 查询 数据不同于 搜索 数据。有时我们需要一个或另一个，并且两者的结合对于我们的应用程序非常有效。它可能（或可能不）适合您的产品。
至于分析，我在使用Cassandra Spark连接器来服务更复杂的OLAP查询方面取得了一些成功。希望能有所帮助。
