ElasticSearch或Couchbase或其他東西

Question

背景： 我有一個巨大的數據流 - 每小時獲得1000000條記錄，ttl是3個小時......每個「文檔」包含大約20個屬性，我需要搜索最多同時使用「==」，「IN」和「BETWEEN」比較15個屬性。

由於大多數情況下不存在不可搜索的屬性，因此沒有理由將文檔存儲兩次（在Couchbase AND中的ElasticSearch索引中），所以我認爲將其存儲在ElasticSearch中是一個好主意。我是對的？

或者，也許有人可以推薦我更好的數據庫這樣的任務？我需要在今後的容易橫向擴展（MySQL的自定義分片不是一個選項）... 這個數據是某種形式的緩存，以便最終一致性和耐久性差是OK ...

根據CAP定理我需要主要是A和P ...

Answer 1

關於性能，只要您使用適當大小的硬件，就不應該每小時編制索引1M文檔的問題。我已經運行Elasticsearch遠遠高於沒有問題。有一個詳細的書面記錄在這裏，你可能會發現有用的有關基準和大小大Elasticsearch集羣：

ElasticSearch setup for a large cluster with heavy aggregations

對於一個短暫的緩存系統只有3個小時的TTL我同意這將是存儲浪費數據存儲在多個存儲庫中。您可以將數據存儲在Couchbase中並實時或近實時地將其複製到Elasticsearch中，但爲什麼要這麼做呢？不確定從兩個地方獲取數據會帶來哪些好處。

對於與您的特定用例有關的性能問題，我強烈建議進行基準測試。我發現的Elasticsearch（和Solr）的一個優勢是他們（對我而言）在多個非文本字段上搜索時出人意料的強大性能。您傾向於將ES用於文本搜索目的（它的優點在哪裏），但它也是一個體面的通用數據庫。我發現，與其他一些NoSQL解決方案相比，它在搜索多個參數時具有很強的性能。

個人來說，當在這個用例中對ES進行基準測試時，我會看到許多不同的索引選項。ES支持TTL的文檔，以便自動清除緩存很簡單：

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-ttl-field.html

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html

然而，你可能想玩弄具有每個每小時不同的指標 - 一件事ES（因它使用下面的Lucene索引和文件存儲）是刪除工作不同於大多數數據庫。文檔被標記爲已刪除但未刪除，然後定期將下面的文件（稱爲分段）合併，屆時將創建新的分段而不刪除已刪除的文檔。這可能會導致大量磁盤活動在單個索引中的大容量刪除大量用例中。解決方法是爲每個小時創建一個新索引，然後在其中的數據超過3個小時後刪除索引。

您可能會發現關於TTL在Elasticsearch有用此之前的討論與時間序列指標：Performance issues using Elasticsearch as a time window storage

最後，關於容易橫向擴展Elasticsearch是相當不錯的位置 - 你添加一個新的節點與正確的羣集名稱和ES照顧剩下的部分，自動將碎片遷移到新節點。在您的用例中，您可能需要使用複製因子，因爲更多節點中的更多副本是提高查詢性能的簡單方法。

Answer 2

對於緩存（類似緩存的系統）的用例，我認爲Elasticsearch只會在未來給你帶來問題。我假設你根本不需要索引，因爲你並不是在尋找像功能一樣的搜索。

我還沒有使用Couchbase，但我聽說過它的好東西。我聽說過像使用Couchbase進行更多類似用途的用例，以及用於更多搜索類目的Elasticsearch（以及Couchbase無法執行的操作）的用例。

就可擴展性而言，據我所知，這兩者在非常高的視點上看起來都很相似。當集羣中的某個節點出現故障時，它們都支持容易的分片和複製，並且可以將分片重新平衡，輔助副本升級爲主分區。具體細節可能會有所不同。

但是，誠實地說，您必須自己嘗試一下，並像流量一樣測試生產。我曾與Elasticsearch合作，並且我知道你不能總是僅僅說出它是否是你的用例的正確選擇，因爲它在生產中的應用程序的行爲方式可能與其在性能方面的行爲不同。

但我認爲你是在正確的軌道上。