弹性赛vs卡桑德拉vs卡桑德拉弹力赛 [英] Elasticsearch vs Cassandra vs Elasticsearch with Cassandra
问题描述
- 我需要以更快的速度存储数据并读取数据。
- 完全故障安全，易于扩展。
- 能够搜索Google Analytics（分析）的数据。
我最后找到了一个简短的列表： Cassandra和Elasticsearch
我所理解的是Cassandra是一个完美的NoSQL存储解决方案，因为我可以使用索引编写数据和读取数据。在Google Analytics（分析）上失败或失败的地方。在将来，如果我想从 from_date到to_date 或更多的方式获取数据以进行分析，如果我不正确地设计数据模型或保持长时间
虽然弹性搜索最适合于索引（支持）通过Lucene），并且可以通过抛出一些随机文本随机搜索数据。但是，即使我想要将数据 from_date检索到to_date （我希望可能是），它的工作原理相同。但真正的问题是，它是一个搜索引擎，还是完美的NoSQL数据存储如Cassandra？如果是的话，为什么还需要Cassandra？
如果这两个都在不同的世界，请说明一下！我们如何组合它们来获得更有效的解决方案？
我们的一个应用程序使用存储在Cassandra和ElasticSearch。我们使用Cassandra可以随时访问这些记录，并将数据复制到专门用于遵守特定应用程序请求的查询表中。为了比我们的查询表更容易搜索，ElasticSearch可以很好地执行这个功能。
我们已经提出了同样的问题（我们自己）我们只是从ElasticSearch获取所有内容？
答案是ElasticSearch被设计为搜索引擎，而不是持久性数据存储。有时ElasticSearch失去了写作。在弹性搜索中，难以实现模式更改，而不会破坏所有的内容并重新加载。为此，我已经编写了旨在使ElasticSearch与Cassandra群集同步的作业。还有一个最近有关Quora的讨论关于这个主题，这产生了类似的观点。
据说，ElasticSearch作为一个搜索引擎可以很好的。而Cassandra作为一个可扩展的高性能数据存储区，将优秀但是，查询数据与搜索不同。有时候，我们需要一个或另一个，两个工作的组合对我们的应用程序很好。它可能（或可能不）对您的工作很好。
对于分析，我在使用Cassandra Spark连接器方面取得了一些成功，可以提供更复杂的OLAP查询。希望有帮助。
I am learning NoSQL and looking at different options for one of my client's requirements. I have gone through various resources before putting up this question (a person with little knowledge in NoSQL)
- I need to store data at faster rate and read data.
- Fully fail-safe and easily scalable.
- Able to search through data for Analytics.
I ended up with a short list of: Cassandra and Elasticsearch
What I do understand is Cassandra is a perfect NoSQL storage solution for me, as I can write data and read data using indexes. Where it fails or it could fail is on Analytics. In the future, if I want to get data from from_date to to_date, or more ways to get data for analytics, if I don't design the Data model properly or keeping long term sight, which might be quite hard in ever changing world.
While Elastic Search is best at indexing (backed by Lucene), and can search the data randomly by throwing some random text. But does it work the same for even if I want to retrieve data from_date to to_date (I expect it might be). But the real question is, is it a Search Engine, or perfect NoSQL data storage like Cassandra? If yes, why do we still need Cassandra?
If both of these are in different world, please explain that! How do we combine them to get a more effective solution?
One of our applications uses data that is stored into both Cassandra and ElasticSearch. We use Cassandra to access those records whenever we can, and have data duplicated into query tables designed to adhere to specific application-side requests. For a more liberal search than our query tables can allow, ElasticSearch performs that functionality nicely.
We have asked that same question (of ourselves)..."Why don't we just get everything from ElastsicSearch?"
The answer is that ElasticSearch was designed to be a search engine, and not a persistent data store. Sometimes ElasticSearch loses writes. Schema changes are difficult to do in ElasticSearch without blowing everything away and reloading. For that purpose, I have written jobs that are designed to keep ElasticSearch in-sync with our Cassandra cluster. There was also a fairly recent discussion on Quora about this topic, that yielded similar points.
That being said, ElasticSearch works great as a search engine. And Cassandra works great as a scalable, high-performance datastore. But querying data is different from searching for data. There are times that we need one or the other, and a combination of the two works well for our application. It may (or it may not) work well for yours.
As for analytics, I have had some success in using the Cassandra Spark connector, to serve more complex OLAP queries. Hope that helps.
这篇关于弹性赛vs卡桑德拉vs卡桑德拉弹力赛的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
