为什么elasticsearch很适合日志系统

elasticsearch 出名的就是全文检索，利用分词和倒排索引能够很好地解析你想要查询和文档的内容，并做匹配，就是达到了日志系统的需求。比如我想要搜寻一个带有NullPointException的ERROR日志，只需要搜索这两个词，它便能快速地进行定位。

一、为什么elasticsearch很适合日志系统

elasticsearch 出名的就是全文检索，利用分词和倒排索引能够很好地解析你想要查询和文档的内容，并做匹配，就是达到了日志系统的需求。比如我想要搜寻一个带有NullPointException的ERROR日志，只需要搜索这两个词，它便能快速地进行定位。这个就是和他的倒排索引和分词的特点做到的。

优点：支持大量、离散、关键词式的查询，迁移、扩容很简单，符合日志系统的需求。

换一个分布式数据库来说，那么首先MySQL单节点百万或者1千万的数据量就比较力不从心了，再谈到分布式数据库，它能够很好的解决单节点的弊端，但是分布式数据需要自定义分库分表的规则，一段日志的记录肯定会存在一个字段中，那么MySQL对于like这类的模糊查询力不从心。

缺点：分布式数据的搭建和分配规则的使用难度都比较高，数据的迁移和持久化更是比较麻烦，对于like类的检索力不从心，可以说MySQL可以有办法达到日志系统的需求，但并不适合日志系统的需求。

就目前你所言的404，如果你单独一个字段去存储，自然是没有问题，两个做都能做，如果混杂在一条的日志里，es从性能上肯定是会更好，但是还是需要考虑好是否适合、难度和未来effort如何？毕竟日志系统只是辅助性的开发，如果不是拿它卖产品，还是要衡量好投入的人力。

延伸阅读：

二、MongoDB是什么

非关系型数据库(nosql ),属于文档型数据库。MongoDB采用类JSON的documents来存储数据。数据结构由键值(key=>value)对组成。

MongoDB采用动态数据模型schema，这意味着不需要预先定义表的数据类型和字段名。当MongoDB需要更新文档documents的时候，可以轻松增加新的字段名或者删除旧的字段。MongoDB让数据结构更加层级化，因而存储数组等复杂数据结构。 在同一个集合collection中，文档document对字段也没有强约束，因此更容易设计差异化的数据结构。