2014-11-05 60 views
2

我正在構建可從ElasticSearch中受益匪淺的應用程序。在我目前的版本中,我使用1個單一索引:只有1種類型的「消息」:「消息」。爲相同數據彈性搜索一個索引或多個索引

消息由以下格式(平均10KB)的:

messages 
- id 
- subject (string) 
- date (date) (format: dateOptionalTime) 
- account_id (integer) 
- body (string) 
- receivers (nested) 
    properties: 
     name (string) 
     email (string) 
- files (nested) 
    properties: 
     content_type (string) 
     filename (string) 
     size (long) 

搜索當前的ACCOUNT_ID基礎上(添加過濾器,以每個查詢)。在我的mySQL數據庫中,每個賬戶都有一個company_id(一個公司可以有多個賬戶)。將來,我可能願意允許用戶在公司範圍內進行搜索,而不是在一個帳戶中進行搜索。我的數據集是一個很大(> 50米的文件)。

我的問題是什麼是最好的,只是使用單一類型(消息)這個單一的索引(消息),或者做一個公司範圍內的索引,我會爲每個公司創建一個新的索引像messages_%company_id%)。

我的數據集每月增長1 - 5M個文檔,文檔幾乎不需要刪除。舊數據在這裏可以像新插入的文檔一樣有價值。

回答

1

我會堅持使用單一索引和單一類型。

ES「索引」類似於SQL「數據庫」。 ES「類型」類似於SQL「表」。你會爲單獨的公司創建單獨的數據庫還是單獨的表格?可能不會。

ES非常好地縮放,並且可以很容易地通過任何類型的內容進行搜索。只要給ES提供必要的硬件,50M文檔就不會有問題。

另外一個注意事項:如果有什麼誘惑讓ES成爲您的唯一數據存儲,我會抵制它。我認爲它還沒有到位。保持MySQL數據庫爲「權威」存儲引擎,並使用ES進行搜索。

+0

目前我是mySQL作爲我的主數據存儲,S3文檔的一些(重要的)元數據位於其中,其餘的位於S3的原始文件中。所以ES確實爲我提供了搜索功能,但我總是能夠通過mySQL和S3完全重建/恢復。 – Floris 2014-11-06 07:27:25

+0

是的,只要你能夠從MySQL + S3重建,你應該沒問題! – yahermann 2014-11-06 15:35:15

+0

所以我不能獲得更好的性能或更少的資源,如果我創建像多個索引和/或類型。 – Floris 2014-11-06 17:58:41