假如現在要查http code為404的所有日誌，es可以查，分散式資料庫也能查的出來啊，相比於分散式資料庫，elasticsearch在這方面有什麼不可替代的優勢嗎？望大佬們賜教～～

這麼簡單的需求用 grep 甚至都能查出來，不具備代表性。

ES 靠的是全文索引，而 MySQL 是關係型資料庫，沒什麼好比的。日誌數據是典型的 unstructured data，而關係型資料庫從模型上就是 structured 的。

1.elasticsearch 出名的就是全文檢索，利用分詞和倒排索引能夠很好地解析你想要查詢和文檔的內容，並做匹配，就是達到了日誌系統的需求。

2. 比如我想要搜尋一個帶有NullPointException的ERROR日誌，只需要搜索這兩個詞，它便能快速地進行定位。這個就是和他的倒排索引和分詞的特點做到的。

3. 優點：支持大量、離散、關鍵詞式的查詢，遷移、擴容很簡單，符合日誌系統的需求。

4. 換一個分散式資料庫來說，那麼首先MySQL單節點百萬或者1千萬的數據量就比較力不從心了，再談到分散式資料庫，它能夠很好的解決單節點的弊端，但是分散式數據需要自定義分庫分表的規則，一段日誌的記錄肯定會存在一個欄位中，那麼MySQL對於like這類的模糊查詢力不從心。

5. 缺點：分散式數據的搭建和分配規則的使用難度都比較高，數據的遷移和持久化更是比較麻煩，對於like類的檢索力不從心，可以說MySQL可以有辦法達到日誌系統的需求，但並不適合日誌系統的需求。

6. 就目前你所言的404，如果你單獨一個欄位去存儲，自然是沒有問題，兩個做都能做，如果混雜在一條的日誌裏，es從性能上肯定是會更好，但是還是需要考慮好是否適合、難度和未來effort如何？畢竟日誌系統只是輔助性的開發，如果不是拿它賣產品，還是要衡量好投入的人力。

謝謝！

如果你的日誌系統只有http日誌要存，查詢又都是code為404這種固定欄位查詢，不用es挺正常的。挺多企業現在在改用clickhouse來應對這種情況，更節約成本。

但是，世上還有很多很多其他類型的日誌，他們的查詢需求是全文檢索，以及基於檢索前提下的統計分析。統計維度也不那麼固定。這時候，es是更加合適的選擇。

此外：最重要的：ELK Stack入門門檻夠低啊，是人是鬼都能搞起來一套，太方便了……

日誌其實一般情況下都是檢索關鍵字，並不一定要檢索具體欄位和條件，所以這種全文搜索引擎就非常適合做這類需求，你說的只是某一個比較抽象的需求，當你需要真正檢索大量雜亂的日誌時，關鍵字搜索就派上用場了，而且並不是每個系統的日誌輸出都遵循同一套規則，結構分散，序列化不同

主要看三點，也是我個人選擇資料庫落地的依據

1、數據特性

日誌的特性就是無結構、不定長

2、使用場景

日誌的使用場景寫多改少、查詢時效性強、點查詢多、查詢維度不定

3、數據體量

日誌量體量很難規劃，需要存儲支持靈活地橫向擴展

基於以上三點，es類包括solr基本是最合適的資料庫了

問這個問題，感覺你就根本不懂es啊，數據量大了，es的全文檢索效率就體現出來了，而且，它上手簡單啊，

日誌是寫多讀少的場景，而mysql是讀多寫少的場景

優勢應該是太多人用ELK分析日誌了吧。

MySQL直覺來講就劣在非分散式，存儲容量有限吧。日誌數據量不多時候，MySQL還勝在SQL用戶量大呢。

分散式存儲就很多，也有很多作為日誌存儲的實例。ambari metrics用得hbase作為存儲；HDFS就不用說，很常見的日誌分析；延伸下去，整個大數據體系就是為分析「日誌」而生的。

ES確實有強悍且舒服的地方。我覺得是綜合成本與查詢能力下，依然能有較好的實時性吧。有錢可以搞多幾臺IOE小型機分析呀。

任何一個框架適合不適合，看用戶多不多，社區強不強大社區不活躍，再花裏胡哨的框架也不適合

ELK是趨勢

推薦閱讀：
相關文章