关于elasticsearch需要注意的几点

1.es cluster的部署：

       es集群每个节点既可以是master节点也可以是data节点，建议master节点专门负责路由寻址等不起data节点存数据的功能，data节点专门负责存储数据；避免单个节点io过于频繁es进程卡死，es集群部署和配置都很简单，需要注意的就是上面提到的这一点；

另外，你可以为es cluster安装一个可视化的kibana界面，需要使用kibana的语言去操作索引的crud，查看各节点最近的IO状况、各索引的健康状态等信息；很多人使用logstash获取es产生的日志并分析；

2.关于es的查询：

       说起查询就必须要先提到分词器，es默认的分词器是standard，另外你可以为你的es安装ik_smart支持中文分词的插件；如果你的字段含有中文并且字段长度比较长，那么建议使用ik_smart分词器；当然如果你最多使用的查询方式是match_phrase，并且slop参数为0，那么字段就算是中文用standard分词器也没关系，只是分词后比较占空间；（standard默认是一个汉字一个汉字简单的拆分开来分词，ik_smart会把常用词组分到一起，比如 “中国人”，如果是standard分词会分成 中、国、人，ik_smart会分成 中国、人），说一下slop参数：将目标字符串调换其中的字符slop次可以匹配源字符串。比如：字段值是“编辑器”，我们想：match_phrase “辑器编”，slop=3 就是把编字后移3位得到 辑器编 匹配成功，slop如果设的大match_phrase就失去了保持相对位置的意义，所以慎用。 

     另外数字在es里不分词，比如 19942320，分词过后还是19942320；

      es和传统数据库的结构并不一样，每一个索引/类型下的ID都对应的是一个json文档，你存在json文档里的字段也并不是像oracle，mysql中保存成一条一条的，而是用json键值对的方式保存起来，此时如果你使用的不是嵌套模式，会保存成这样：key:[value1,value2,...]，尽管你写入es的文档结构是： key:value1;key:value2。这样会造成查询的时候会出现问题；

解决方法： es和oracle的区别还在于，oracle你要先建好表空间表结构什么的，es会根据你入的文档字段自动生成mapping,熟悉nosql的人应该清楚。但是如果你想指明某些字段的type为嵌套，必须自己声明该索引的mapping，并且指明field 类型为nested；

如果你的查询中用到了nestedQuery，可以使用innerHits区别于普通的response.getHits().getHits（）这样，innerHits是专门用来返回命中的nested查询的，返回的数据也是一条一条的；

如果你感到用api 拼接es的query吃力，可以先快速学习一下kibana里 dev tool的查询语言；

关系型数据库表与表之间主外键连接的方式查询非常快捷方便，在es里并不是这样，你也可以自己写索引间外键连接的代码后台实现；

如果es要查询的数据量过多可以用scrollId的方式查询，其他常用的还有match等方式，网上有很多帖子，不再多说；

暂时就想到这么多，如果使用es个人觉得需要先考虑清楚是可以接受一个索引数据量很大，还是分成几个索引，自己做好外键关联。