最近也在搭建实时的log分析系统，es很好用，感觉你看的文章有点过时了，建议仔细阅读elastic的官网 https://www.elastic.co/products/elasticsearch

默认为每一个字段创建索引

其实是没有必要的，哪个字段创建索引根据业务来定。例如像直接靠数据库的索引能解决了的就没必要，但是像中文名，文本类的模糊匹配这类在mysql检索速度很慢的字段，就可以将这种字段与他的主键id一起在es创建索引。

会存储文档的所有字段，直接从ES中返回查询结果，而不需要去关联查询db

这个问题属于第一个的引申，应用将文本查询的检索执行后，得到该条记录在数据库的主键id，再用id去数据库里查相关信息。如果涉及到A表x字段和B表y字段的联合模糊检索，那么创建索引的时候将这两个表的x与y字段在es中同一个Type里创建索引。检索后可以得到结果在A表和B表各自的主键id，再根据自身业务去数据库里取相应记录即可。

关于数据的一致性问题，大概有三个方案
1，应用上自己控制，增删改的时候相应的去维护索引信息。一致性的维护就靠程序实现，比较麻烦，但是比较灵活。

2，通过bin-log去自动创建索引， https://github.com/siddontang/go-mysql-elasticsearch github上有这个项目，自己配置好数据源就自动创建索引了。靠binlog同步一致性能做到最好，但是不太灵活，完全根据数据库表结构创建所有字段的索引，并且联表查询也比较麻烦。

3，通过river去自定义创建索引， https://github.com/jprante/elasticsearch-jdbc github上也有这个项目，是es的一个插件，通过jdbc将自定义好的sql语句从mysql中同步过来。通过sql可自定义需要索引的字段，另外表结构里需要有一个update_time的字段供sql去查找新增或者更新的数据，以保证索引的一致性，删除数据的一致性需要在程序里控制。这个方法虽然也不完美，但是也算结合了1和2方式的优缺点把。

文档相对少，核心开发人员只有一个，没有经历过时间上的洗礼（太年轻）

看看官网上的USE CASES就可以不用担心这个问题了

如果使用在整个项目的搜索场景，我个人是有些犹豫的。大家又是怎么看的呢？

搜索还是看场景，能够通过数据库搜索的就靠数据库，预期数据库解决不了的再切换到es上。
全放在es上，效率和数据的安全性肯定不如db与es结合的高。