一、為什么elasticsearch很適合日志系統(tǒng)

elasticsearch 出名的就是全文檢索，利用分詞和倒排索引能夠很好地解析你想要查詢和文檔的內(nèi)容，并做匹配，就是達(dá)到了日志系統(tǒng)的需求。比如我想要搜尋一個(gè)帶有NullPointException的ERROR日志，只需要搜索這兩個(gè)詞，它便能快速地進(jìn)行定位。這個(gè)就是和他的倒排索引和分詞的特點(diǎn)做到的。

優(yōu)點(diǎn)：支持大量、離散、關(guān)鍵詞式的查詢，遷移、擴(kuò)容很簡單，符合日志系統(tǒng)的需求。

換一個(gè)分布式數(shù)據(jù)庫來說，那么首先MySQL單節(jié)點(diǎn)百萬或者1千萬的數(shù)據(jù)量就比較力不從心了，再談到分布式數(shù)據(jù)庫，它能夠很好的解決單節(jié)點(diǎn)的弊端，但是分布式數(shù)據(jù)需要自定義分庫分表的規(guī)則，一段日志的記錄肯定會(huì)存在一個(gè)字段中，那么MySQL對(duì)于like這類的模糊查詢力不從心。

缺點(diǎn)：分布式數(shù)據(jù)的搭建和分配規(guī)則的使用難度都比較高，數(shù)據(jù)的遷移和持久化更是比較麻煩，對(duì)于like類的檢索力不從心，可以說MySQL可以有辦法達(dá)到日志系統(tǒng)的需求，但并不適合日志系統(tǒng)的需求。

就目前你所言的404，如果你單獨(dú)一個(gè)字段去存儲(chǔ)，自然是沒有問題，兩個(gè)做都能做，如果混雜在一條的日志里，es從性能上肯定是會(huì)更好，但是還是需要考慮好是否適合、難度和未來effort如何？畢竟日志系統(tǒng)只是輔助性的開發(fā)，如果不是拿它賣產(chǎn)品，還是要衡量好投入的人力。

延伸閱讀：

二、MongoDB是什么

非關(guān)系型數(shù)據(jù)庫(nosql ),屬于文檔型數(shù)據(jù)庫。MongoDB采用類JSON的documents來存儲(chǔ)數(shù)據(jù)。數(shù)據(jù)結(jié)構(gòu)由鍵值(key=>value)對(duì)組成。

MongoDB采用動(dòng)態(tài)數(shù)據(jù)模型schema，這意味著不需要預(yù)先定義表的數(shù)據(jù)類型和字段名。當(dāng)MongoDB需要更新文檔documents的時(shí)候，可以輕松增加新的字段名或者刪除舊的字段。MongoDB讓數(shù)據(jù)結(jié)構(gòu)更加層級(jí)化，因而存儲(chǔ)數(shù)組等復(fù)雜數(shù)據(jù)結(jié)構(gòu)。 在同一個(gè)集合collection中，文檔document對(duì)字段也沒有強(qiáng)約束，因此更容易設(shè)計(jì)差異化的數(shù)據(jù)結(jié)構(gòu)。