最近在调研ElasticSearch(简称ES)，从官方文档中了解到了一些ES的设计原理，不过也产生了几个疑问，和大家讨论讨论~
默认为每一个字段创建索引
该做法是否会影响数据的插入、删除、更新的速度？
会存储文档的所有字段，直接从ES中返回查询结果，而不需要去关联查询db
该做法增加了磁盘资源的使用（如果你还不得不在db中存储一份数据的话），当然，可以只在ES中存储那些需要检索的数据字段，但这就会和其他搜索引擎一样（速度上），并且同样会造成数据一致性问题，大家平时都是怎么权衡的？
文档相对少，核心开发人员只有一个，没有经历过时间上的洗礼（太年轻）
关于这个观点，大家又是如何理解？
其实是因为ELK才认识到ES的存在的，在处理日志数据的时候，感觉ES的设计理念还是很贴近场景的，但是如果使用在整个项目的搜索场景，我个人是有些犹豫的。大家又是怎么看的呢？
最后附上一个对比链接：this
默认为每一个字段创建索引
其实是没有必要的，哪个字段创建索引根据业务来定。例如像直接靠数据库的索引能解决了的就没必要，但是像中文名，文本类的模糊匹配这类在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结合的高。
最近也在搭建实时的log分析系统，es很好用，感觉你看的文章有点过时了，建议仔细阅读elastic的官网https://www.elastic.co/products/elasticsearch