elasticsearch现在除了在日志分析中使用外，是否有别的应用场景呢？

严格的说，ES不是一个数据库，而是一个搜索引擎，ES的方方面面也都是围绕搜索设计的。ES支持全文搜索，这里简单解释下什么是全文搜索：对于“我在北京的一家互联网公司工作”这样的数据，如果你搜索“北京”、“互联网”、“工作”这些关键词都能命中这条数据的话，这就是全文搜索，你每天都在用的百度、Google都属于全文搜索。值得一提的是，ES的全文搜索对中文也有很好的支持（单是中文分词器就有很多种），绝对能够满足国内大多数人的全文搜索需求。ES通过建立倒排索引实现全文搜索。具体来说，ES会建立一个覆盖表中所有文档、所有字段的庞大的倒排索引，以实现对存入ES中的所有数据进行快速检索。因此只要是存入ES的数据，无论再复杂的聚合查询也可以得到不错的性能，而且你再也不用为如何建立各种复杂索引而头痛了。
说了这么多ES的优点，你是不是觉得ES简直万能了？可惜不是的， ES也有很多的短处，最明显的就是字段类型无法修改、写入性能较低和高硬件资源消耗 。前边讲到ES会自动的替你建立索引，尽管这能给全文搜索以及聚合查询带来很多好处还能替你省了建索引这一麻烦事，但是这个特性也会带来一堆问题。ES需要在创建字段前要预先建立Mapping，Mapping中包含每个字段的类型信息，ES需要根据Mapping为字段建立合适的索引。由于这个Mapping的存在，ES中的字段一但建立就不能再修改类型了。（例如，你建的数据表的某个字段忘了加全文搜索，你想临时加上，但是表已经建好并且已经有很多数据了，这时候该怎么办呢？不好意思，你只能把整个数据表删了再重建一遍！）因此，ES在数据结构灵活度上高于MySQL但远不如MongoDB。ES的缺点还不止这些，自动建立索引使得ES的写入性能也收到了影响，要明显低于MongoDB，并且ES的写入还有一个更要命的问题，那就是默认1S的写入延迟，也就是说你的数据在写入后要至少等1S才能被查询到。对于同样的数据ES占用的存储空间也要明显大于MongoDB（建那么复杂的索引能不占空间吗？），对硬件资源的消耗也是非常厉害，大数据量下64G内存+SSD基本是标配，算得上是数据库中的贵族服务了，因此如果你的老板很小气，对于ES的选用可要慎重喽！
ES的全文搜索特性使它成为构建搜索引擎的利器。除此之外，ES很好的支持了复杂聚合查询这一特点还使得ES非常适合拿来作数据分析使用。 其实，ES还专门做了与自己配套的ELK套装，给你提供从日志收集到数据可视化分析的一条龙服务，绝对是构建高大上数据分析平台的利器。但是，ES的高成本和低写入性能这些缺点也注定了它不适合用在那些数据价值不高、对写入性能有要求、数据量大而成本受限的场景中。