Spark-Cassandra VS Spark-Elasticsearch

我一直在使用Elasticsearch已經有一段時間了，現在使用Cassandra的經驗並不多。Spark-Cassandra VS Spark-Elasticsearch

現在，我有一個項目，我們想使用spark來處理數據，但我需要決定是否應該使用Cassandra或Elasticsearch作爲數據存儲來加載我的數據。

就連接器而言，Cassandra和Elasticsearch現在都有一個很好的連接器來加載數據，所以不會成爲決定性因素。

決定勝利的因素將是我能夠在Spark中加載數據的速度。我的數據差不多是20TB。

我知道我可以使用JMeter運行一些測試並自己查看結果，但我想問任何熟悉這兩個系統的人。

感謝

來源

2015-08-28 Adetiloye Philip Kehinde

問題是什麼？ – eliasah

是的，這取決於數據檢索工作量。 Cassandra非常擅長通過鍵檢索部分數據，從spark可以只下推主鍵和集羣鍵上的過濾器，否則對於全表掃描（select * from table）不太好。詳細描述你的用例，因爲cassandra和elasticsearch都非常「垂直」DBMS –

我的用例非常簡單，我需要使用Spark每天爲不同用戶（1M +）生成報告。現在，我需要將所有用戶的數據從Cassandra或Elasticsearch加載到Spark，並且沒有必要同時運行Cassandra和Elasticsearch。 –

簡短確切的答案是「看情況」，主要是簇大小=）

我不會選擇Elastisearch作爲數據的主要來源，因爲它擅長搜索。搜索是一個非常具體的任務，它需要一個非常具體的方法，在這種情況下使用倒排索引來存儲實際數據。每個領域基本上都進入單獨的索引，並且因爲索引非常緊湊。儘管可以存儲到索引完整對象中，但這樣的索引很難獲得任何壓縮效益。這需要更多的磁盤空間來存儲索引和更多的cpu時鐘，並使用磁盤來處理它們。

卡桑德拉另一方面是非常擅長存儲和檢索數據。如果沒有更多或更少的特定需求，我會說Cassandra擅長作爲主存儲（並提供非常簡單的搜索場景），ES擅長於搜索。

來源

2015-08-28 21:35:41 evgenii

我會反駁Evgenii關於ES如何善於搜索的答案。是的ES超過了文字搜索，但它並不意味着它不能做數據。

實際上，您可以將它看作是「Mongo」風格的文檔並對其執行「過濾」查詢以獲得快速獲取結果。但現在問題變成：你需要多快的讀/寫，你需要任何發行版嗎？ ES缺乏的是分配。是的，ES可以進行分片，但它在執行多區域分佈和複製數據的可靠性方面存在問題。

如果您需要數據的靈活性/可靠性，我會轉向Cassanda。此外，由於你正在處理結核病 - 卡桑德拉也可能是一個贏家，因爲它適合極端的數量。

如果你需要更容易的時間來運行搜索（不限於文本搜索，例如：地理空間，你也可以做），那麼ES可能更適合。（注意你正在做的剪切體積，你需要碎片以分散你的負荷）。

來源

2016-07-30 10:42:39 azngunit81

Spark-Cassandra VS Spark-Elasticsearch

回答

相關問題