我正在学习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查询方面取得了一些成功。希望能有所帮助。