招兼职Cassandra培训讲师
企业培训公司面向单位员工培训，长期招Cassandra兼职老师，一般三天左右的短周期培训，周末为主，有2人左右的小辅导，也有30人左右的培训大班，待遇优，北京，上海，成都，广州，深圳等，如您想挣点外块，积累资源，充实生活，请联系我。
要求：
相关技术专业，本科及以上学历；
三年以上实际项目经验；
认真，热情，耐心，乐于助人，不保守，表达能力较好。具体再议。
感兴趣的可以联系：QQ 2355811930 ；QQ1489302364，微信15501239699，简历接收邮箱：admin@info-soft.cn
企业培训公司面向单位员工培训，长期招Cassandra兼职老师，一般三天左右的短周期培训，周末为主，有2人左右的小辅导，也有30人左右的培训大班，待遇优，北京，上海，成都，广州，深圳等，如您想挣点外块，积累资源，充实生活，请联系我。
要求：
相关技术专业，本科及以上学历；
三年以上实际项目经验；
认真，热情，耐心，乐于助人，不保守，表达能力较好。具体再议。
感兴趣的可以联系：QQ 2355811930 ；QQ1489302364，微信15501239699，简历接收邮箱：admin@info-soft.cn
收起阅读 »
nini 发表于 : 2017-06-29 17:16
评论 (1)
智慧芽诚聘高级搜索工程师20-30K（C轮互联网Saas）
职位描述【工作职责】：
1、负责搜索系统分布式架构设计、搭建、维护和优化；
2、负责分词，索引和查询的算法优化，提高查全率和搜索性能；
3、负责搜索服务端的开发工作，融合大数据平台实现个性化搜索，完成各种垂直搜索应用的开发；
4、负责内容的数据挖掘，分析与挖掘各种潜在关联，分析特征，建议模型，优化现有的排序结果；
5、搜索服务的线上部署和维护，监控搜索服务的运行状态；
【岗位要求】：
1. 熟悉搜索引擎原理和机制，熟练撑握搜索引擎技术，有丰富的搜索引擎相关的研发经验，对算法设计、数据结构有深刻的理解；
2. 熟悉Solr、Elasticsearch等开源搜索技术及mysql、redis等数据库，能够胜任搜索引擎应用技术的研究与开发、设计与架构能力；
3. 熟悉LINUX操作命令及Python、SHELL脚本编写；
4、对数据敏感，具备优秀的逻辑思维，对解决挑战性问题充满热情，善于独立解决问题和分析问题；
5. 在用户行为挖掘上有相关研究和专业积累；有较好的创新能力；
6. 良好的团队合作精神，较强的沟通能力；
7. 实践过自然语言处理、数据挖掘、机器学习者优先；
8. 有信息提取和大型搜索索引建立、排序算法、query优化经验者优先；
有意者请发简历至 yuezhitao@patsnap.com
【加入我们，你可以得到什么？】
你可以得到国际化的视野，可以和国外的同事和客户进行交流沟通
你可以跟随公司快速成长，从“前台”到“总裁”的华丽变身不再是梦想
你可以学习和应用最新最酷的技术，我们鼓励学习创新，而不是重复使用过时效率差的技术
你不需要定时打卡，不用担心迟到扣钱，因为我们是弹性工作制
你不需要担心五险一金，因为我们完全按照规定缴纳，员工还可以享受年假、病假、婚假、丧假、产假等带薪休假，另外我们还有补充商业保险
【为什么选择我们？】
1. 公司前景：整个大环境对知识产权的重视，除了现有业务增长迅猛，还在新兴业务上积极布局
2. 办公地点：坐落于上海静安区黄金地段，CBD中的CBD
3. 交通方便：地铁五线环绕（1，3，4，12，13），步行10分钟之内可到，数十多路公交车近在咫尺
4. 工作环境：开放，明亮。无限量供应的饮料和零食，可以让你迅速成为胖纸！ Mac Pro, Surface Pro, 大屏显示器各种标配。
【我们是谁？】
或许现在你对专利市场还感到陌生，或许你还并不了解知识产权的重要性，但互联网时代，“IP”这个热词你一定有所听说，且耳熟能详。看看身边高精尖的技术产品，被百姓津津乐道的新能源汽车，到酷炫的无人驾驶，还有风靡持久的日本电饭煲……无不持续着、保护着、更迭着他们的IP技术。
崛起的IP界应证着这样一句话：
21世纪一定是知识经济的时代，科技创新更是知识经济时代的灵魂——
而PatSnap智慧芽，正立旨于为科技创新指路。
PatSnap是全球领先的专利分析与管理平台，公司致力于让全球更多组织机构了解并使用专利。PatSnap通过提供强大又易用的专利工具，帮助客户从专利中获取有价值的资讯，从而促进客户的商业化过程，加速研发进度，确定重要技术发展方向，最终提高客户在行业内的核心竞争力。
PatSnap通过位于新加坡，中国苏州，英国伦敦的三家分公司，业务辐射全球上千家企业，客户中不乏 IBM ，美国国立卫生研究院，美国国防部，MIT（麻省理工学院）以及新加坡国立大学等知名企业及团体。
目前我们已经获得C轮融资，在近期的在德勤亚太区高科技高成长500强企业中获得第44位的优质排名。德勤高科技高成长500强是亚太区内享负盛名的高科技企业评选活动。本次评选基于过去三年企业的收入增长百分比而定，智慧芽在这段时期内增长了1078%！
有意者请发简历至 yuezhitao@patsnap.com
继续阅读 »
1、负责搜索系统分布式架构设计、搭建、维护和优化；
2、负责分词，索引和查询的算法优化，提高查全率和搜索性能；
3、负责搜索服务端的开发工作，融合大数据平台实现个性化搜索，完成各种垂直搜索应用的开发；
4、负责内容的数据挖掘，分析与挖掘各种潜在关联，分析特征，建议模型，优化现有的排序结果；
5、搜索服务的线上部署和维护，监控搜索服务的运行状态；
【岗位要求】：
1. 熟悉搜索引擎原理和机制，熟练撑握搜索引擎技术，有丰富的搜索引擎相关的研发经验，对算法设计、数据结构有深刻的理解；
2. 熟悉Solr、Elasticsearch等开源搜索技术及mysql、redis等数据库，能够胜任搜索引擎应用技术的研究与开发、设计与架构能力；
3. 熟悉LINUX操作命令及Python、SHELL脚本编写；
4、对数据敏感，具备优秀的逻辑思维，对解决挑战性问题充满热情，善于独立解决问题和分析问题；
5. 在用户行为挖掘上有相关研究和专业积累；有较好的创新能力；
6. 良好的团队合作精神，较强的沟通能力；
7. 实践过自然语言处理、数据挖掘、机器学习者优先；
8. 有信息提取和大型搜索索引建立、排序算法、query优化经验者优先；
有意者请发简历至 yuezhitao@patsnap.com
【加入我们，你可以得到什么？】
你可以得到国际化的视野，可以和国外的同事和客户进行交流沟通
你可以跟随公司快速成长，从“前台”到“总裁”的华丽变身不再是梦想
你可以学习和应用最新最酷的技术，我们鼓励学习创新，而不是重复使用过时效率差的技术
你不需要定时打卡，不用担心迟到扣钱，因为我们是弹性工作制
你不需要担心五险一金，因为我们完全按照规定缴纳，员工还可以享受年假、病假、婚假、丧假、产假等带薪休假，另外我们还有补充商业保险
【为什么选择我们？】
1. 公司前景：整个大环境对知识产权的重视，除了现有业务增长迅猛，还在新兴业务上积极布局
2. 办公地点：坐落于上海静安区黄金地段，CBD中的CBD
3. 交通方便：地铁五线环绕（1，3，4，12，13），步行10分钟之内可到，数十多路公交车近在咫尺
4. 工作环境：开放，明亮。无限量供应的饮料和零食，可以让你迅速成为胖纸！ Mac Pro, Surface Pro, 大屏显示器各种标配。
【我们是谁？】
或许现在你对专利市场还感到陌生，或许你还并不了解知识产权的重要性，但互联网时代，“IP”这个热词你一定有所听说，且耳熟能详。看看身边高精尖的技术产品，被百姓津津乐道的新能源汽车，到酷炫的无人驾驶，还有风靡持久的日本电饭煲……无不持续着、保护着、更迭着他们的IP技术。
崛起的IP界应证着这样一句话：
21世纪一定是知识经济的时代，科技创新更是知识经济时代的灵魂——
而PatSnap智慧芽，正立旨于为科技创新指路。
PatSnap是全球领先的专利分析与管理平台，公司致力于让全球更多组织机构了解并使用专利。PatSnap通过提供强大又易用的专利工具，帮助客户从专利中获取有价值的资讯，从而促进客户的商业化过程，加速研发进度，确定重要技术发展方向，最终提高客户在行业内的核心竞争力。
PatSnap通过位于新加坡，中国苏州，英国伦敦的三家分公司，业务辐射全球上千家企业，客户中不乏 IBM ，美国国立卫生研究院，美国国防部，MIT（麻省理工学院）以及新加坡国立大学等知名企业及团体。
目前我们已经获得C轮融资，在近期的在德勤亚太区高科技高成长500强企业中获得第44位的优质排名。德勤高科技高成长500强是亚太区内享负盛名的高科技企业评选活动。本次评选基于过去三年企业的收入增长百分比而定，智慧芽在这段时期内增长了1078%！
有意者请发简历至 yuezhitao@patsnap.com
职位描述【工作职责】：
1、负责搜索系统分布式架构设计、搭建、维护和优化；
2、负责分词，索引和查询的算法优化，提高查全率和搜索性能；
3、负责搜索服务端的开发工作，融合大数据平台实现个性化搜索，完成各种垂直搜索应用的开发；
4、负责内容的数据挖掘，分析与挖掘各种潜在关联，分析特征，建议模型，优化现有的排序结果；
5、搜索服务的线上部署和维护，监控搜索服务的运行状态；
【岗位要求】：
1. 熟悉搜索引擎原理和机制，熟练撑握搜索引擎技术，有丰富的搜索引擎相关的研发经验，对算法设计、数据结构有深刻的理解；
2. 熟悉Solr、Elasticsearch等开源搜索技术及mysql、redis等数据库，能够胜任搜索引擎应用技术的研究与开发、设计与架构能力；
3. 熟悉LINUX操作命令及Python、SHELL脚本编写；
4、对数据敏感，具备优秀的逻辑思维，对解决挑战性问题充满热情，善于独立解决问题和分析问题；
5. 在用户行为挖掘上有相关研究和专业积累；有较好的创新能力；
6. 良好的团队合作精神，较强的沟通能力；
7. 实践过自然语言处理、数据挖掘、机器学习者优先；
8. 有信息提取和大型搜索索引建立、排序算法、query优化经验者优先；
有意者请发简历至 yuezhitao@patsnap.com
【加入我们，你可以得到什么？】
你可以得到国际化的视野，可以和国外的同事和客户进行交流沟通
你可以跟随公司快速成长，从“前台”到“总裁”的华丽变身不再是梦想
你可以学习和应用最新最酷的技术，我们鼓励学习创新，而不是重复使用过时效率差的技术
你不需要定时打卡，不用担心迟到扣钱，因为我们是弹性工作制
你不需要担心五险一金，因为我们完全按照规定缴纳，员工还可以享受年假、病假、婚假、丧假、产假等带薪休假，另外我们还有补充商业保险
【为什么选择我们？】
1. 公司前景：整个大环境对知识产权的重视，除了现有业务增长迅猛，还在新兴业务上积极布局
2. 办公地点：坐落于上海静安区黄金地段，CBD中的CBD
3. 交通方便：地铁五线环绕（1，3，4，12，13），步行10分钟之内可到，数十多路公交车近在咫尺
4. 工作环境：开放，明亮。无限量供应的饮料和零食，可以让你迅速成为胖纸！ Mac Pro, Surface Pro, 大屏显示器各种标配。
【我们是谁？】
或许现在你对专利市场还感到陌生，或许你还并不了解知识产权的重要性，但互联网时代，“IP”这个热词你一定有所听说，且耳熟能详。看看身边高精尖的技术产品，被百姓津津乐道的新能源汽车，到酷炫的无人驾驶，还有风靡持久的日本电饭煲……无不持续着、保护着、更迭着他们的IP技术。
崛起的IP界应证着这样一句话：
21世纪一定是知识经济的时代，科技创新更是知识经济时代的灵魂——
而PatSnap智慧芽，正立旨于为科技创新指路。
PatSnap是全球领先的专利分析与管理平台，公司致力于让全球更多组织机构了解并使用专利。PatSnap通过提供强大又易用的专利工具，帮助客户从专利中获取有价值的资讯，从而促进客户的商业化过程，加速研发进度，确定重要技术发展方向，最终提高客户在行业内的核心竞争力。
PatSnap通过位于新加坡，中国苏州，英国伦敦的三家分公司，业务辐射全球上千家企业，客户中不乏 IBM ，美国国立卫生研究院，美国国防部，MIT（麻省理工学院）以及新加坡国立大学等知名企业及团体。
目前我们已经获得C轮融资，在近期的在德勤亚太区高科技高成长500强企业中获得第44位的优质排名。德勤高科技高成长500强是亚太区内享负盛名的高科技企业评选活动。本次评选基于过去三年企业的收入增长百分比而定，智慧芽在这段时期内增长了1078%！
有意者请发简历至 yuezhitao@patsnap.com 收起阅读 »
1、负责搜索系统分布式架构设计、搭建、维护和优化；
2、负责分词，索引和查询的算法优化，提高查全率和搜索性能；
3、负责搜索服务端的开发工作，融合大数据平台实现个性化搜索，完成各种垂直搜索应用的开发；
4、负责内容的数据挖掘，分析与挖掘各种潜在关联，分析特征，建议模型，优化现有的排序结果；
5、搜索服务的线上部署和维护，监控搜索服务的运行状态；
【岗位要求】：
1. 熟悉搜索引擎原理和机制，熟练撑握搜索引擎技术，有丰富的搜索引擎相关的研发经验，对算法设计、数据结构有深刻的理解；
2. 熟悉Solr、Elasticsearch等开源搜索技术及mysql、redis等数据库，能够胜任搜索引擎应用技术的研究与开发、设计与架构能力；
3. 熟悉LINUX操作命令及Python、SHELL脚本编写；
4、对数据敏感，具备优秀的逻辑思维，对解决挑战性问题充满热情，善于独立解决问题和分析问题；
5. 在用户行为挖掘上有相关研究和专业积累；有较好的创新能力；
6. 良好的团队合作精神，较强的沟通能力；
7. 实践过自然语言处理、数据挖掘、机器学习者优先；
8. 有信息提取和大型搜索索引建立、排序算法、query优化经验者优先；
有意者请发简历至 yuezhitao@patsnap.com
【加入我们，你可以得到什么？】
你可以得到国际化的视野，可以和国外的同事和客户进行交流沟通
你可以跟随公司快速成长，从“前台”到“总裁”的华丽变身不再是梦想
你可以学习和应用最新最酷的技术，我们鼓励学习创新，而不是重复使用过时效率差的技术
你不需要定时打卡，不用担心迟到扣钱，因为我们是弹性工作制
你不需要担心五险一金，因为我们完全按照规定缴纳，员工还可以享受年假、病假、婚假、丧假、产假等带薪休假，另外我们还有补充商业保险
【为什么选择我们？】
1. 公司前景：整个大环境对知识产权的重视，除了现有业务增长迅猛，还在新兴业务上积极布局
2. 办公地点：坐落于上海静安区黄金地段，CBD中的CBD
3. 交通方便：地铁五线环绕（1，3，4，12，13），步行10分钟之内可到，数十多路公交车近在咫尺
4. 工作环境：开放，明亮。无限量供应的饮料和零食，可以让你迅速成为胖纸！ Mac Pro, Surface Pro, 大屏显示器各种标配。
【我们是谁？】
或许现在你对专利市场还感到陌生，或许你还并不了解知识产权的重要性，但互联网时代，“IP”这个热词你一定有所听说，且耳熟能详。看看身边高精尖的技术产品，被百姓津津乐道的新能源汽车，到酷炫的无人驾驶，还有风靡持久的日本电饭煲……无不持续着、保护着、更迭着他们的IP技术。
崛起的IP界应证着这样一句话：
21世纪一定是知识经济的时代，科技创新更是知识经济时代的灵魂——
而PatSnap智慧芽，正立旨于为科技创新指路。
PatSnap是全球领先的专利分析与管理平台，公司致力于让全球更多组织机构了解并使用专利。PatSnap通过提供强大又易用的专利工具，帮助客户从专利中获取有价值的资讯，从而促进客户的商业化过程，加速研发进度，确定重要技术发展方向，最终提高客户在行业内的核心竞争力。
PatSnap通过位于新加坡，中国苏州，英国伦敦的三家分公司，业务辐射全球上千家企业，客户中不乏 IBM ，美国国立卫生研究院，美国国防部，MIT（麻省理工学院）以及新加坡国立大学等知名企业及团体。
目前我们已经获得C轮融资，在近期的在德勤亚太区高科技高成长500强企业中获得第44位的优质排名。德勤高科技高成长500强是亚太区内享负盛名的高科技企业评选活动。本次评选基于过去三年企业的收入增长百分比而定，智慧芽在这段时期内增长了1078%！
有意者请发简历至 yuezhitao@patsnap.com 收起阅读 »
关于Elasticsearch性能优化的几点问题
本次分享主要包含两个方面的实战经验：索引性能和查询性能。
一. 索引性能（Index Performance）
首先要考虑的是，索引性能是否有必要做优化？
索引速度提高与否？主要是看瓶颈在什么地方，若是 Read DB（产生DOC）的速度比较慢，那瓶颈不在 ElasticSearch 时，优化就没那么大的动力。实际上 Elasticsearch 的索引速度还是非常快的。
我们有一次遇到 Elasticsearch 升级后索引速度很慢，查下来是新版 IK 分词的问题，修改分词插件后得到解决。
如果需要优化，应该如何优化？
SSD 是经济压力能承受情况下的不二选择。减少碎片也可以提高索引速度，每天进行优化还是很有必要的。在初次索引的时候，把 replica 设置为 0，也能提高索引速度。
bulk 是不是一定需要呢？
若是 Elasticsearch 普通索引已经导致高企的 LA，IO 压力已经见顶，这时候 bulk 也无法提供帮助，SSD 应该是很好的选择。
在 create doc 速度能跟上的时候，bulk 是可以提高速度的。
记得 threadpool.index.queue_size ++，不然会出现索引时队列不够用的情况。
indices.memory.index_buffer_size:10% 这个参数可以进行适当调整。
调整如下参数也可以提高索引速度：index.translog.flush_threshold_ops:50000 和 refresh_interval。
二. 查询性能（Query Perofrmance）
王道是什么？routing，routing，还是 routing。
我们为了提高查询速度，减少慢查询，结合自己的业务实践，使用多个集群，每个集群使用不同的 routing。比如，用户是一个routing维度。
在实践中，这个routing 非常重要。
我们碰到一种情况，想把此维度的查询（即用户查询）引到非用户routing 的集群，结果集群完全顶不住！
在大型的本地分类网站中，城市、类目也是一个不错的维度。我们使用这种维度进行各种搭配。然后在前端分析查询，把各个不同查询分别引入合适的集群。这样做以后，每个集群只需要很少的机器，而且保持很小的 CPU Usage 和 LA。从而查询速度够快，慢查询几乎消灭。
分合？
分别（索引和routing）查询和合并（索引和routing）查询，即此分合的意思。
索引越来越大，单个 shard 也很巨大，查询速度也越来越慢。这时候，是选择分索引还是更多的shards？
在实践过程中，更多的 shards 会带来额外的索引压力，即 IO 压力。
我们选择了分索引。比如按照每个大分类一个索引，或者主要的大城市一个索引。然后将他们进行合并查询。如：http://cluster1:9200/shanghai,beijing/_search?routing=fang，自动将查询中城市属性且值为上海或北京的查询，且是房类目的，引入集群 cluster1，并且routing等于fang。
http://cluster1:9200/other/_search?routing=jinan,linyi。小城市的索引，我们使用城市做 routing，如本例中同时查询济南和临沂城市。
http://cluster1:9200/_all/_search，全部城市查询。
再如： http://cluster2:9200/fang,che/_search?routing=shanghai_qiche,shanghai_zufang,beijing_qiche,beijing_zufang。查询上海和北京在小分类汽车、整租的信息，那我们进行如上合并查询。并将其引入集群 cluster2。
使用更多的 shards？
除了有 IO 压力，而且不能进行全部城市或全部类目查询，因为完全顶不住。
Elastic 官方文档建议：一个 Node 最好不要多于三个 shards。
若是 "more shards”，除了增加更多的机器，是没办法做到这一点的。
分索引，虽然一个 Node 总的shards 还是挺多的，但是一个索引可以保持3个以内的shards。
我们使用分索引时，全量查询是可以顶住的，虽然压力有点儿高。
索引越来越大，资源使用也越来越多。若是要进行更细的集群分配，大索引使用的资源成倍增加。
有什么办法能减小索引？显然，创建 doc 时，把不需要的 field 去掉是一个办法；但是，这需要对业务非常熟悉。
有啥立竿见影的办法？
根据我们信息的特点，内容（field:description）占了索引的一大半，那我们就不把 description 索引进 ES，doc 小了一倍，集群也小了一倍，所用的资源（Memory, HD or SSD, Host, snapshot存储，还有时间）大大节省，查询速度自然也更快。
那要查 description 怎么办？
上面的实例中，我们可以把查询引入不同集群，自然我们也可以把 description 查询引入一个非实时（也可以实时）集群，这主要是我们业务特点决定的，因为description查询所占比例非常小，使得我们可以这样做。
被哪些查询搞过？第一位是 Range 查询，这货的性能真不敢恭维。在最热的查询中，若是有这货，肯定是非常痛苦的，网页变慢，查询速度变慢，集群 LA 高企，严重的时候会导致集群 shard 自动下线。所以，建议在最热的查询中避免使用 Range 查询。
Facet 查询，在后续版本这个被 aggregations 替代，我们大多数时候让它在后端进行运算。
三. 其他
1)线程池
线程池我们默认使用 fixed，使用 cached 有可能控制不好。主要是比较大的分片 relocation时，会导致分片自动下线，集群可能处于危险状态。在集群高压时，若是 cached ，分片也可能自动下线。自 1.4 版本后，我们就一直 fixed，至于新版是否还存在这个问题，就没再试验了。
两个原因：一是 routing王道带来的改善，使得集群一直低压运行；二是使用fixed 后，已经极少遇到自动下线shard了。
我们前面说过，user 是一个非常好的维度。这个维度很重要，routing 效果非常明显。其他维度，需要根据业务特点，进行组合。
所以我们的集群一直是低压运行，就很少再去关注新版本的 使用 cached 配置问题。
hreadpool.search.queue_size 这个配置是很重要的，一般默认是够用了，可以尝试提高。
2）优化
每天优化是有好处的，可以大大改善查询性能。max_num_segments 建议配置为1。虽然优化时间会变长，但是在高峰期前能完成的话，会对查询性能有很大好处。
3) JVM GC的选择：选择 G1还是 CMS？
应该大多数人还是选择了 CMS，我们使用的经验是 G1 和 CMS 比较接近；但和 CMS 相比，还是有一点距离，至少在我们使用经验中是如此。
JVM 32G 现象？
128G内存的机器配置一个 JVM，然后是巨大的 heapsize （如64G）？
还是配多个 JVM instance，较小的 heapsize（如32G）？
我的建议是后者。实际使用中，后者也能帮助我们节省不少资源，并提供不错的性能。具体请参阅 “Don’t Cross 32 GB!" （https://www.elastic.co/guide/e ... _oops）
跨 32G 时，有一个现象，使用更多的内存，比如 40G，效果还不如31G！
这篇文档值得大家仔细阅读。
JVM 还有一个配置 bootstrap.mlockall: true，比较重要。这是让 JVM 启动的时候就 锁定 heap 内存。
有没有用过 较小的 heapsize，加上SSD？我听说有人使用过，效果还不错，当然，我们自己还没试过。
4）插件工具
推荐 kopf，是一个挺不错的工具，更新及时，功能完备，可以让你忘掉很多 API :)。
上面是 kopf 的图片。管理Elasticsearch 集群真心方便。以前那些 API ，慢慢要忘光了:)
索引，查询，和一些重要的配置，是今天分享的重点。
Q&A
Q1：您建议生产环境JVM采用什么样的参数设置？FULL GC频率和时间如何？
CMS 标准配置。
ES_HEAP_NEWSIZE=?G
JAVA_OPTS="$JAVA_OPTS -XX:+UseCondCardMark"
JAVA_OPTS="$JAVA_OPTS -XX:CMSWaitDuration=250"
JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"
JAVA_OPTS="$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75"
JAVA_OPTS="$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly"
Full GC 很少去care 它了。我们使用 Elasticsearch 在JVM上花的时间很少。
Q2：生产环境服务器如何配置性价比较高？单机CPU核数、主频？内存容量？磁盘容量？
内存大一些，CPU 多核是必要的，JVM 和 Elasticsearch 会充分使用内存和多核的。 关于内存容量的问题，很多是 JVM Tunning 的问题。 磁盘容量没啥要求。
Q3： 分组统计(Facet 查询或 aggregations )大多数时候让它在后端进行运算，怎么实现？应用如果需要实时进行统计而且并发量较大，如何优化？
因为我们是网站系统，所以对于 Facet 请求，引导到后端慢慢计算，前端初始的时候可能没数据，但是此后就会有了。
如果是精确要求的话，那就只能从 提高 facet 查询性能去下手，比如 routing、filter、cache、更多的内存...
Q4：存进Elasticsearch的数据，timestamp是UTC时间，Elasticsearch集群会在UTC 0点，也就是北京时间早上8点自动执行优化？如何改参数设置这个时间？
我们没有使用Elasticsearch的自动优化设置。自己控制优化时间。
Q5：我的Java程序，log4j2 Flume appender，然后机器上的Flume agent ，直接Elasticsearch 的sink avro到 es节点上，多少个agent 连在单个Elasticsearch节点比较合适 ？
ElasticSearch本身是一个分布式计算集群，所以，请求平均分配到每个 node 即可。
Q6：我代码里直接用 Java API 生成Flume appender 格式，Flume agent 里interceptor去拆分几个字段，这样是不是太累了？比较推荐的做法是不是还是各业务点自己控制字段，调用Elasticsearch API 生成索引内容？
业务点自己控制生成的文档吧？如果需要产生不同routing，并且分了索引，这些其实是业务相关的。routing和不同索引，都是根据业务情况哪些查询比较集中而进行处理的。
Q7：您见过或管理过的生产环境的Elasticsearch数据量多大？
我们使用 Elasticsearch 进行某些业务处理，数据量过亿。
Q8：SSD性能提升多少？
SSD 对索引帮助非常大，效果当当的，提高几十倍应该是没问题。不过，我们没有试过完全使用SSD顶查询，而是使用内存，内存性价比还是不错的。
Q9：我们现在有256个shard，用uid做routing，所有查询都是走routing。每个shard有30多G，每次扩容很慢，有什么建议？
可以考虑使用分合查询吗？ 或者使用更多的维度？ 256个 shard 确实比较难以控制。但是如果是分索引和查询，比more shards(256) 效果应该会好不少。
Q10：Elasticsearch排序等聚合类的操作需要用到fielddata，查询时很慢。新版本中doc values聚合查询操作性能提升很大，你们有没有用过？
Facet 查询需要更大的内存，更多的 CPU 资源。可以考虑routing、filter、cache等多种方式提高性能。
Aggs 将来是要替换 Facet，建议尽快替换原来的facet API。
Q11：Elasticsearch配置bootstrap.mlockall，我们在使用中发现会导致启动很慢，因为Elasticsearch要获取到足够的内存才开始启动。
启动慢是可以接受的，启动慢的原因也许是内存没有有效释放过，比如文件 cached了。 内存充足的情况下，启动速度还是蛮快的，可以接受。 JVM 和 Lucene 都需要内存，一般是JVM 50%, 剩下的50% 文件cached 为Lucene 使用。
Q12：优化是一个开销比较大的操作，每天优化的时候是否会导致查询不可用？如何优化这块？
优化是开销很大的。不会导致查询不可用。优化是值得的，大量的碎片会导致查询性能大大降低。 如果非常 care 查询，可以考虑多个集群。在优化时，查询 skip 这个集群就可以。
Q13：Elasticsearch适合做到10亿级数据查询，每天千万级的数据实时写入或更新吗？
10亿是可以做到的，如果文档轻量，10亿所占的资源还不是很多。
ELK 使用 Elasticsearch ，进行日志处理每天千万是小case吧？
不过我们除了使用 ELK 进行日志处理，还进行业务处理，10亿级快速查询是可以做到，不过，需要做一些工作，比如索引和shards的分分合合：）
Q14：Elasticsearch相比Solr有什么优势吗？
我们当年使用 Solr 的时候，Elasticsearch 刚出来。他们都是基于 Lucene的。 Elasticsearch 相对于 solr ，省事是一个优点。而且现在 Elasticsearch 相关的应用软件也越来越多。Solr 和 Lucene 集成度很高，更新版本是和Lucene一起的，这是个优点。
很多年没用 Solr了，毕竟那时候数据量还不大，所以折腾的就少了，主要还是折腾 JVM。所以，就不再过多的比较了。
Q15：分词用的什么组件？Elasticsearch自带的吗？
我们使用 IK 分词，不过其他分词也不错。IK分词更新还是很及时的。而且它可以远程更新词典。：）
Q16： reindex有没有好的方法？
reindex 这个和 Lucene 有关，它的 update 就是 delete+ add。
Q17：以上面的两个例子为例 ： 是存储多份同样的数据么？
是两个集群。第一个集群使用大城市分索引，不过，还有大部分小城市合并一个索引。大城市还是用类目进行routing，小城市合并的索引就使用城市进行routing 。
第二个集群，大类分得索引，比如fang、che，房屋和车辆和其他类目在一个集群上，他们使用 city+二级类目做routing。
Q18：集群部署有没有使用 Docker ？ 我们使用的时候 ，同一个服务器 节点之间的互相发现没有问题 ，但是跨机器的时候需要强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群互相发现问题。
我们使用puppet进行部署。暂没使用 Docker。 强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群，跨IP段的时候是有这个需要。
Q19：您建议采用什么样的数据总线架构来保证业务数据按routing写入多个Elasticsearch集群，怎么保证多集群Elasticsearch中的数据与数据库中数据的一致性？
我们以前使用 php在web代码中进行索引和分析 query，然后引导到不同集群。 现在我们开发了一套go rest系统——4sea，使用 redis + elastic 以综合提高性能。
索引时，更新db的同时，提交一个文档 ID 通知4sea 进行更新，然后根据配置更新到不同集群。
数据提交到查询时，就是分析 query 并引导到不同集群。
这套 4sea 系统，有机会的可以考虑开源，不算很复杂的。
Q20： 能介绍一下Elasticsearch的集群rebanlance、段合并相关的原理和经验吗？
“段”合并？，我们是根据业务特点，产生几个不一样的集群，主要还是 routing 不一样。
shards 比较平均很重要的，所以选择routing 维度是难点，选择城市的话，大城市所在分片会非常大，此时可以考虑 分索引，几个大城市几个索引，然后小城市合并一个索引。
如果 shards 大小分布平均的话，就不关心如何 allocation 了。
Q21：关于集群rebalance，其实就是cluster.routing.allocation配置下的那些rebalance相关的设置，比如allow_rebalance／cluster_concurrent_rebalance／node_initial_primaries_recoveries，推荐怎么配置？
分片多的情况下，这个才是需要的吧。
分片比较少时，allow_rebalance disable，然后手动也可以接受的。
分片多，一般情况会自动平衡。我们对主从不太关心。只是如果一台机器多个 JVM instance （多个 Elasticsearch node）的话，我们写了个脚本来避免同一shard 在一台机器上。
cluster_concurrent_rebalance 在恢复的时候根据情况修改。正常情况下，再改成默认就好了。
node_initial_primaries_recoveries，在保证集群低压的情况下，不怎么care。
kopf 上面有好多这种配置，你可以多试试。
Q22：合并查询是异步请求还是同步请求？做缓存吗？
合并查询是 Elasticsearch 自带 API。
Q23：用http url connection请求的时候，会发现返回请求很耗时，一般怎么处理？
尽可能减少慢查询吧？我们很多工作就是想办法如何减少慢查询，routing和分分合合，就是这个目的。
Q24：生产环境单个节点存储多少G数据？
有大的，有小的。小的也几十G了。不过根据我们自己的业务特点，某些集群就去掉了全文索引。唯一的全文索引，使用基本的routing（比较平衡的routing，比如user。城市的话，就做不到平衡了，因为大城市数据很多），然后做了 快照，反正是增量快照，1小时甚至更短时间都可以考虑！！！去掉全文索引的其他业务集群，就小多了。
继续阅读 »
一. 索引性能（Index Performance）
首先要考虑的是，索引性能是否有必要做优化？
索引速度提高与否？主要是看瓶颈在什么地方，若是 Read DB（产生DOC）的速度比较慢，那瓶颈不在 ElasticSearch 时，优化就没那么大的动力。实际上 Elasticsearch 的索引速度还是非常快的。
我们有一次遇到 Elasticsearch 升级后索引速度很慢，查下来是新版 IK 分词的问题，修改分词插件后得到解决。
如果需要优化，应该如何优化？
SSD 是经济压力能承受情况下的不二选择。减少碎片也可以提高索引速度，每天进行优化还是很有必要的。在初次索引的时候，把 replica 设置为 0，也能提高索引速度。
bulk 是不是一定需要呢？
若是 Elasticsearch 普通索引已经导致高企的 LA，IO 压力已经见顶，这时候 bulk 也无法提供帮助，SSD 应该是很好的选择。
在 create doc 速度能跟上的时候，bulk 是可以提高速度的。
记得 threadpool.index.queue_size ++，不然会出现索引时队列不够用的情况。
indices.memory.index_buffer_size:10% 这个参数可以进行适当调整。
调整如下参数也可以提高索引速度：index.translog.flush_threshold_ops:50000 和 refresh_interval。
二. 查询性能（Query Perofrmance）
王道是什么？routing，routing，还是 routing。
我们为了提高查询速度，减少慢查询，结合自己的业务实践，使用多个集群，每个集群使用不同的 routing。比如，用户是一个routing维度。
在实践中，这个routing 非常重要。
我们碰到一种情况，想把此维度的查询（即用户查询）引到非用户routing 的集群，结果集群完全顶不住！
在大型的本地分类网站中，城市、类目也是一个不错的维度。我们使用这种维度进行各种搭配。然后在前端分析查询，把各个不同查询分别引入合适的集群。这样做以后，每个集群只需要很少的机器，而且保持很小的 CPU Usage 和 LA。从而查询速度够快，慢查询几乎消灭。
分合？
分别（索引和routing）查询和合并（索引和routing）查询，即此分合的意思。
索引越来越大，单个 shard 也很巨大，查询速度也越来越慢。这时候，是选择分索引还是更多的shards？
在实践过程中，更多的 shards 会带来额外的索引压力，即 IO 压力。
我们选择了分索引。比如按照每个大分类一个索引，或者主要的大城市一个索引。然后将他们进行合并查询。如：http://cluster1:9200/shanghai,beijing/_search?routing=fang，自动将查询中城市属性且值为上海或北京的查询，且是房类目的，引入集群 cluster1，并且routing等于fang。
http://cluster1:9200/other/_search?routing=jinan,linyi。小城市的索引，我们使用城市做 routing，如本例中同时查询济南和临沂城市。
http://cluster1:9200/_all/_search，全部城市查询。
再如： http://cluster2:9200/fang,che/_search?routing=shanghai_qiche,shanghai_zufang,beijing_qiche,beijing_zufang。查询上海和北京在小分类汽车、整租的信息，那我们进行如上合并查询。并将其引入集群 cluster2。
使用更多的 shards？
除了有 IO 压力，而且不能进行全部城市或全部类目查询，因为完全顶不住。
Elastic 官方文档建议：一个 Node 最好不要多于三个 shards。
若是 "more shards”，除了增加更多的机器，是没办法做到这一点的。
分索引，虽然一个 Node 总的shards 还是挺多的，但是一个索引可以保持3个以内的shards。
我们使用分索引时，全量查询是可以顶住的，虽然压力有点儿高。
索引越来越大，资源使用也越来越多。若是要进行更细的集群分配，大索引使用的资源成倍增加。
有什么办法能减小索引？显然，创建 doc 时，把不需要的 field 去掉是一个办法；但是，这需要对业务非常熟悉。
有啥立竿见影的办法？
根据我们信息的特点，内容（field:description）占了索引的一大半，那我们就不把 description 索引进 ES，doc 小了一倍，集群也小了一倍，所用的资源（Memory, HD or SSD, Host, snapshot存储，还有时间）大大节省，查询速度自然也更快。
那要查 description 怎么办？
上面的实例中，我们可以把查询引入不同集群，自然我们也可以把 description 查询引入一个非实时（也可以实时）集群，这主要是我们业务特点决定的，因为description查询所占比例非常小，使得我们可以这样做。
被哪些查询搞过？第一位是 Range 查询，这货的性能真不敢恭维。在最热的查询中，若是有这货，肯定是非常痛苦的，网页变慢，查询速度变慢，集群 LA 高企，严重的时候会导致集群 shard 自动下线。所以，建议在最热的查询中避免使用 Range 查询。
Facet 查询，在后续版本这个被 aggregations 替代，我们大多数时候让它在后端进行运算。
三. 其他
1)线程池
线程池我们默认使用 fixed，使用 cached 有可能控制不好。主要是比较大的分片 relocation时，会导致分片自动下线，集群可能处于危险状态。在集群高压时，若是 cached ，分片也可能自动下线。自 1.4 版本后，我们就一直 fixed，至于新版是否还存在这个问题，就没再试验了。
两个原因：一是 routing王道带来的改善，使得集群一直低压运行；二是使用fixed 后，已经极少遇到自动下线shard了。
我们前面说过，user 是一个非常好的维度。这个维度很重要，routing 效果非常明显。其他维度，需要根据业务特点，进行组合。
所以我们的集群一直是低压运行，就很少再去关注新版本的 使用 cached 配置问题。
hreadpool.search.queue_size 这个配置是很重要的，一般默认是够用了，可以尝试提高。
2）优化
每天优化是有好处的，可以大大改善查询性能。max_num_segments 建议配置为1。虽然优化时间会变长，但是在高峰期前能完成的话，会对查询性能有很大好处。
3) JVM GC的选择：选择 G1还是 CMS？
应该大多数人还是选择了 CMS，我们使用的经验是 G1 和 CMS 比较接近；但和 CMS 相比，还是有一点距离，至少在我们使用经验中是如此。
JVM 32G 现象？
128G内存的机器配置一个 JVM，然后是巨大的 heapsize （如64G）？
还是配多个 JVM instance，较小的 heapsize（如32G）？
我的建议是后者。实际使用中，后者也能帮助我们节省不少资源，并提供不错的性能。具体请参阅 “Don’t Cross 32 GB!" （https://www.elastic.co/guide/e ... _oops）
跨 32G 时，有一个现象，使用更多的内存，比如 40G，效果还不如31G！
这篇文档值得大家仔细阅读。
JVM 还有一个配置 bootstrap.mlockall: true，比较重要。这是让 JVM 启动的时候就 锁定 heap 内存。
有没有用过 较小的 heapsize，加上SSD？我听说有人使用过，效果还不错，当然，我们自己还没试过。
4）插件工具
推荐 kopf，是一个挺不错的工具，更新及时，功能完备，可以让你忘掉很多 API :)。
上面是 kopf 的图片。管理Elasticsearch 集群真心方便。以前那些 API ，慢慢要忘光了:)
索引，查询，和一些重要的配置，是今天分享的重点。
Q&A
Q1：您建议生产环境JVM采用什么样的参数设置？FULL GC频率和时间如何？
CMS 标准配置。
ES_HEAP_NEWSIZE=?G
JAVA_OPTS="$JAVA_OPTS -XX:+UseCondCardMark"
JAVA_OPTS="$JAVA_OPTS -XX:CMSWaitDuration=250"
JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"
JAVA_OPTS="$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75"
JAVA_OPTS="$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly"
Full GC 很少去care 它了。我们使用 Elasticsearch 在JVM上花的时间很少。
Q2：生产环境服务器如何配置性价比较高？单机CPU核数、主频？内存容量？磁盘容量？
内存大一些，CPU 多核是必要的，JVM 和 Elasticsearch 会充分使用内存和多核的。 关于内存容量的问题，很多是 JVM Tunning 的问题。 磁盘容量没啥要求。
Q3： 分组统计(Facet 查询或 aggregations )大多数时候让它在后端进行运算，怎么实现？应用如果需要实时进行统计而且并发量较大，如何优化？
因为我们是网站系统，所以对于 Facet 请求，引导到后端慢慢计算，前端初始的时候可能没数据，但是此后就会有了。
如果是精确要求的话，那就只能从 提高 facet 查询性能去下手，比如 routing、filter、cache、更多的内存...
Q4：存进Elasticsearch的数据，timestamp是UTC时间，Elasticsearch集群会在UTC 0点，也就是北京时间早上8点自动执行优化？如何改参数设置这个时间？
我们没有使用Elasticsearch的自动优化设置。自己控制优化时间。
Q5：我的Java程序，log4j2 Flume appender，然后机器上的Flume agent ，直接Elasticsearch 的sink avro到 es节点上，多少个agent 连在单个Elasticsearch节点比较合适 ？
ElasticSearch本身是一个分布式计算集群，所以，请求平均分配到每个 node 即可。
Q6：我代码里直接用 Java API 生成Flume appender 格式，Flume agent 里interceptor去拆分几个字段，这样是不是太累了？比较推荐的做法是不是还是各业务点自己控制字段，调用Elasticsearch API 生成索引内容？
业务点自己控制生成的文档吧？如果需要产生不同routing，并且分了索引，这些其实是业务相关的。routing和不同索引，都是根据业务情况哪些查询比较集中而进行处理的。
Q7：您见过或管理过的生产环境的Elasticsearch数据量多大？
我们使用 Elasticsearch 进行某些业务处理，数据量过亿。
Q8：SSD性能提升多少？
SSD 对索引帮助非常大，效果当当的，提高几十倍应该是没问题。不过，我们没有试过完全使用SSD顶查询，而是使用内存，内存性价比还是不错的。
Q9：我们现在有256个shard，用uid做routing，所有查询都是走routing。每个shard有30多G，每次扩容很慢，有什么建议？
可以考虑使用分合查询吗？ 或者使用更多的维度？ 256个 shard 确实比较难以控制。但是如果是分索引和查询，比more shards(256) 效果应该会好不少。
Q10：Elasticsearch排序等聚合类的操作需要用到fielddata，查询时很慢。新版本中doc values聚合查询操作性能提升很大，你们有没有用过？
Facet 查询需要更大的内存，更多的 CPU 资源。可以考虑routing、filter、cache等多种方式提高性能。
Aggs 将来是要替换 Facet，建议尽快替换原来的facet API。
Q11：Elasticsearch配置bootstrap.mlockall，我们在使用中发现会导致启动很慢，因为Elasticsearch要获取到足够的内存才开始启动。
启动慢是可以接受的，启动慢的原因也许是内存没有有效释放过，比如文件 cached了。 内存充足的情况下，启动速度还是蛮快的，可以接受。 JVM 和 Lucene 都需要内存，一般是JVM 50%, 剩下的50% 文件cached 为Lucene 使用。
Q12：优化是一个开销比较大的操作，每天优化的时候是否会导致查询不可用？如何优化这块？
优化是开销很大的。不会导致查询不可用。优化是值得的，大量的碎片会导致查询性能大大降低。 如果非常 care 查询，可以考虑多个集群。在优化时，查询 skip 这个集群就可以。
Q13：Elasticsearch适合做到10亿级数据查询，每天千万级的数据实时写入或更新吗？
10亿是可以做到的，如果文档轻量，10亿所占的资源还不是很多。
ELK 使用 Elasticsearch ，进行日志处理每天千万是小case吧？
不过我们除了使用 ELK 进行日志处理，还进行业务处理，10亿级快速查询是可以做到，不过，需要做一些工作，比如索引和shards的分分合合：）
Q14：Elasticsearch相比Solr有什么优势吗？
我们当年使用 Solr 的时候，Elasticsearch 刚出来。他们都是基于 Lucene的。 Elasticsearch 相对于 solr ，省事是一个优点。而且现在 Elasticsearch 相关的应用软件也越来越多。Solr 和 Lucene 集成度很高，更新版本是和Lucene一起的，这是个优点。
很多年没用 Solr了，毕竟那时候数据量还不大，所以折腾的就少了，主要还是折腾 JVM。所以，就不再过多的比较了。
Q15：分词用的什么组件？Elasticsearch自带的吗？
我们使用 IK 分词，不过其他分词也不错。IK分词更新还是很及时的。而且它可以远程更新词典。：）
Q16： reindex有没有好的方法？
reindex 这个和 Lucene 有关，它的 update 就是 delete+ add。
Q17：以上面的两个例子为例 ： 是存储多份同样的数据么？
是两个集群。第一个集群使用大城市分索引，不过，还有大部分小城市合并一个索引。大城市还是用类目进行routing，小城市合并的索引就使用城市进行routing 。
第二个集群，大类分得索引，比如fang、che，房屋和车辆和其他类目在一个集群上，他们使用 city+二级类目做routing。
Q18：集群部署有没有使用 Docker ？ 我们使用的时候 ，同一个服务器 节点之间的互相发现没有问题 ，但是跨机器的时候需要强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群互相发现问题。
我们使用puppet进行部署。暂没使用 Docker。 强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群，跨IP段的时候是有这个需要。
Q19：您建议采用什么样的数据总线架构来保证业务数据按routing写入多个Elasticsearch集群，怎么保证多集群Elasticsearch中的数据与数据库中数据的一致性？
我们以前使用 php在web代码中进行索引和分析 query，然后引导到不同集群。 现在我们开发了一套go rest系统——4sea，使用 redis + elastic 以综合提高性能。
索引时，更新db的同时，提交一个文档 ID 通知4sea 进行更新，然后根据配置更新到不同集群。
数据提交到查询时，就是分析 query 并引导到不同集群。
这套 4sea 系统，有机会的可以考虑开源，不算很复杂的。
Q20： 能介绍一下Elasticsearch的集群rebanlance、段合并相关的原理和经验吗？
“段”合并？，我们是根据业务特点，产生几个不一样的集群，主要还是 routing 不一样。
shards 比较平均很重要的，所以选择routing 维度是难点，选择城市的话，大城市所在分片会非常大，此时可以考虑 分索引，几个大城市几个索引，然后小城市合并一个索引。
如果 shards 大小分布平均的话，就不关心如何 allocation 了。
Q21：关于集群rebalance，其实就是cluster.routing.allocation配置下的那些rebalance相关的设置，比如allow_rebalance／cluster_concurrent_rebalance／node_initial_primaries_recoveries，推荐怎么配置？
分片多的情况下，这个才是需要的吧。
分片比较少时，allow_rebalance disable，然后手动也可以接受的。
分片多，一般情况会自动平衡。我们对主从不太关心。只是如果一台机器多个 JVM instance （多个 Elasticsearch node）的话，我们写了个脚本来避免同一shard 在一台机器上。
cluster_concurrent_rebalance 在恢复的时候根据情况修改。正常情况下，再改成默认就好了。
node_initial_primaries_recoveries，在保证集群低压的情况下，不怎么care。
kopf 上面有好多这种配置，你可以多试试。
Q22：合并查询是异步请求还是同步请求？做缓存吗？
合并查询是 Elasticsearch 自带 API。
Q23：用http url connection请求的时候，会发现返回请求很耗时，一般怎么处理？
尽可能减少慢查询吧？我们很多工作就是想办法如何减少慢查询，routing和分分合合，就是这个目的。
Q24：生产环境单个节点存储多少G数据？
有大的，有小的。小的也几十G了。不过根据我们自己的业务特点，某些集群就去掉了全文索引。唯一的全文索引，使用基本的routing（比较平衡的routing，比如user。城市的话，就做不到平衡了，因为大城市数据很多），然后做了 快照，反正是增量快照，1小时甚至更短时间都可以考虑！！！去掉全文索引的其他业务集群，就小多了。
本次分享主要包含两个方面的实战经验：索引性能和查询性能。
一. 索引性能（Index Performance）
首先要考虑的是，索引性能是否有必要做优化？
索引速度提高与否？主要是看瓶颈在什么地方，若是 Read DB（产生DOC）的速度比较慢，那瓶颈不在 ElasticSearch 时，优化就没那么大的动力。实际上 Elasticsearch 的索引速度还是非常快的。
我们有一次遇到 Elasticsearch 升级后索引速度很慢，查下来是新版 IK 分词的问题，修改分词插件后得到解决。
如果需要优化，应该如何优化？
SSD 是经济压力能承受情况下的不二选择。减少碎片也可以提高索引速度，每天进行优化还是很有必要的。在初次索引的时候，把 replica 设置为 0，也能提高索引速度。
bulk 是不是一定需要呢？
若是 Elasticsearch 普通索引已经导致高企的 LA，IO 压力已经见顶，这时候 bulk 也无法提供帮助，SSD 应该是很好的选择。
在 create doc 速度能跟上的时候，bulk 是可以提高速度的。
记得 threadpool.index.queue_size ++，不然会出现索引时队列不够用的情况。
indices.memory.index_buffer_size:10% 这个参数可以进行适当调整。
调整如下参数也可以提高索引速度：index.translog.flush_threshold_ops:50000 和 refresh_interval。
二. 查询性能（Query Perofrmance）
王道是什么？routing，routing，还是 routing。
我们为了提高查询速度，减少慢查询，结合自己的业务实践，使用多个集群，每个集群使用不同的 routing。比如，用户是一个routing维度。
在实践中，这个routing 非常重要。
我们碰到一种情况，想把此维度的查询（即用户查询）引到非用户routing 的集群，结果集群完全顶不住！
在大型的本地分类网站中，城市、类目也是一个不错的维度。我们使用这种维度进行各种搭配。然后在前端分析查询，把各个不同查询分别引入合适的集群。这样做以后，每个集群只需要很少的机器，而且保持很小的 CPU Usage 和 LA。从而查询速度够快，慢查询几乎消灭。
分合？
分别（索引和routing）查询和合并（索引和routing）查询，即此分合的意思。
索引越来越大，单个 shard 也很巨大，查询速度也越来越慢。这时候，是选择分索引还是更多的shards？
在实践过程中，更多的 shards 会带来额外的索引压力，即 IO 压力。
我们选择了分索引。比如按照每个大分类一个索引，或者主要的大城市一个索引。然后将他们进行合并查询。如：http://cluster1:9200/shanghai,beijing/_search?routing=fang，自动将查询中城市属性且值为上海或北京的查询，且是房类目的，引入集群 cluster1，并且routing等于fang。
http://cluster1:9200/other/_search?routing=jinan,linyi。小城市的索引，我们使用城市做 routing，如本例中同时查询济南和临沂城市。
http://cluster1:9200/_all/_search，全部城市查询。
再如： http://cluster2:9200/fang,che/_search?routing=shanghai_qiche,shanghai_zufang,beijing_qiche,beijing_zufang。查询上海和北京在小分类汽车、整租的信息，那我们进行如上合并查询。并将其引入集群 cluster2。
使用更多的 shards？
除了有 IO 压力，而且不能进行全部城市或全部类目查询，因为完全顶不住。
Elastic 官方文档建议：一个 Node 最好不要多于三个 shards。
若是 "more shards”，除了增加更多的机器，是没办法做到这一点的。
分索引，虽然一个 Node 总的shards 还是挺多的，但是一个索引可以保持3个以内的shards。
我们使用分索引时，全量查询是可以顶住的，虽然压力有点儿高。
索引越来越大，资源使用也越来越多。若是要进行更细的集群分配，大索引使用的资源成倍增加。
有什么办法能减小索引？显然，创建 doc 时，把不需要的 field 去掉是一个办法；但是，这需要对业务非常熟悉。
有啥立竿见影的办法？
根据我们信息的特点，内容（field:description）占了索引的一大半，那我们就不把 description 索引进 ES，doc 小了一倍，集群也小了一倍，所用的资源（Memory, HD or SSD, Host, snapshot存储，还有时间）大大节省，查询速度自然也更快。
那要查 description 怎么办？
上面的实例中，我们可以把查询引入不同集群，自然我们也可以把 description 查询引入一个非实时（也可以实时）集群，这主要是我们业务特点决定的，因为description查询所占比例非常小，使得我们可以这样做。
被哪些查询搞过？第一位是 Range 查询，这货的性能真不敢恭维。在最热的查询中，若是有这货，肯定是非常痛苦的，网页变慢，查询速度变慢，集群 LA 高企，严重的时候会导致集群 shard 自动下线。所以，建议在最热的查询中避免使用 Range 查询。
Facet 查询，在后续版本这个被 aggregations 替代，我们大多数时候让它在后端进行运算。
三. 其他
1)线程池
线程池我们默认使用 fixed，使用 cached 有可能控制不好。主要是比较大的分片 relocation时，会导致分片自动下线，集群可能处于危险状态。在集群高压时，若是 cached ，分片也可能自动下线。自 1.4 版本后，我们就一直 fixed，至于新版是否还存在这个问题，就没再试验了。
两个原因：一是 routing王道带来的改善，使得集群一直低压运行；二是使用fixed 后，已经极少遇到自动下线shard了。
我们前面说过，user 是一个非常好的维度。这个维度很重要，routing 效果非常明显。其他维度，需要根据业务特点，进行组合。
所以我们的集群一直是低压运行，就很少再去关注新版本的 使用 cached 配置问题。
hreadpool.search.queue_size 这个配置是很重要的，一般默认是够用了，可以尝试提高。
2）优化
每天优化是有好处的，可以大大改善查询性能。max_num_segments 建议配置为1。虽然优化时间会变长，但是在高峰期前能完成的话，会对查询性能有很大好处。
3) JVM GC的选择：选择 G1还是 CMS？
应该大多数人还是选择了 CMS，我们使用的经验是 G1 和 CMS 比较接近；但和 CMS 相比，还是有一点距离，至少在我们使用经验中是如此。
JVM 32G 现象？
128G内存的机器配置一个 JVM，然后是巨大的 heapsize （如64G）？
还是配多个 JVM instance，较小的 heapsize（如32G）？
我的建议是后者。实际使用中，后者也能帮助我们节省不少资源，并提供不错的性能。具体请参阅 “Don’t Cross 32 GB!" （https://www.elastic.co/guide/e ... _oops）
跨 32G 时，有一个现象，使用更多的内存，比如 40G，效果还不如31G！
这篇文档值得大家仔细阅读。
JVM 还有一个配置 bootstrap.mlockall: true，比较重要。这是让 JVM 启动的时候就 锁定 heap 内存。
有没有用过 较小的 heapsize，加上SSD？我听说有人使用过，效果还不错，当然，我们自己还没试过。
4）插件工具
推荐 kopf，是一个挺不错的工具，更新及时，功能完备，可以让你忘掉很多 API :)。
上面是 kopf 的图片。管理Elasticsearch 集群真心方便。以前那些 API ，慢慢要忘光了:)
索引，查询，和一些重要的配置，是今天分享的重点。
Q&A
Q1：您建议生产环境JVM采用什么样的参数设置？FULL GC频率和时间如何？
CMS 标准配置。
ES_HEAP_NEWSIZE=?G
JAVA_OPTS="$JAVA_OPTS -XX:+UseCondCardMark"
JAVA_OPTS="$JAVA_OPTS -XX:CMSWaitDuration=250"
JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"
JAVA_OPTS="$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75"
JAVA_OPTS="$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly"
Full GC 很少去care 它了。我们使用 Elasticsearch 在JVM上花的时间很少。
Q2：生产环境服务器如何配置性价比较高？单机CPU核数、主频？内存容量？磁盘容量？
内存大一些，CPU 多核是必要的，JVM 和 Elasticsearch 会充分使用内存和多核的。 关于内存容量的问题，很多是 JVM Tunning 的问题。 磁盘容量没啥要求。
Q3： 分组统计(Facet 查询或 aggregations )大多数时候让它在后端进行运算，怎么实现？应用如果需要实时进行统计而且并发量较大，如何优化？
因为我们是网站系统，所以对于 Facet 请求，引导到后端慢慢计算，前端初始的时候可能没数据，但是此后就会有了。
如果是精确要求的话，那就只能从 提高 facet 查询性能去下手，比如 routing、filter、cache、更多的内存...
Q4：存进Elasticsearch的数据，timestamp是UTC时间，Elasticsearch集群会在UTC 0点，也就是北京时间早上8点自动执行优化？如何改参数设置这个时间？
我们没有使用Elasticsearch的自动优化设置。自己控制优化时间。
Q5：我的Java程序，log4j2 Flume appender，然后机器上的Flume agent ，直接Elasticsearch 的sink avro到 es节点上，多少个agent 连在单个Elasticsearch节点比较合适 ？
ElasticSearch本身是一个分布式计算集群，所以，请求平均分配到每个 node 即可。
Q6：我代码里直接用 Java API 生成Flume appender 格式，Flume agent 里interceptor去拆分几个字段，这样是不是太累了？比较推荐的做法是不是还是各业务点自己控制字段，调用Elasticsearch API 生成索引内容？
业务点自己控制生成的文档吧？如果需要产生不同routing，并且分了索引，这些其实是业务相关的。routing和不同索引，都是根据业务情况哪些查询比较集中而进行处理的。
Q7：您见过或管理过的生产环境的Elasticsearch数据量多大？
我们使用 Elasticsearch 进行某些业务处理，数据量过亿。
Q8：SSD性能提升多少？
SSD 对索引帮助非常大，效果当当的，提高几十倍应该是没问题。不过，我们没有试过完全使用SSD顶查询，而是使用内存，内存性价比还是不错的。
Q9：我们现在有256个shard，用uid做routing，所有查询都是走routing。每个shard有30多G，每次扩容很慢，有什么建议？
可以考虑使用分合查询吗？ 或者使用更多的维度？ 256个 shard 确实比较难以控制。但是如果是分索引和查询，比more shards(256) 效果应该会好不少。
Q10：Elasticsearch排序等聚合类的操作需要用到fielddata，查询时很慢。新版本中doc values聚合查询操作性能提升很大，你们有没有用过？
Facet 查询需要更大的内存，更多的 CPU 资源。可以考虑routing、filter、cache等多种方式提高性能。
Aggs 将来是要替换 Facet，建议尽快替换原来的facet API。
Q11：Elasticsearch配置bootstrap.mlockall，我们在使用中发现会导致启动很慢，因为Elasticsearch要获取到足够的内存才开始启动。
启动慢是可以接受的，启动慢的原因也许是内存没有有效释放过，比如文件 cached了。 内存充足的情况下，启动速度还是蛮快的，可以接受。 JVM 和 Lucene 都需要内存，一般是JVM 50%, 剩下的50% 文件cached 为Lucene 使用。
Q12：优化是一个开销比较大的操作，每天优化的时候是否会导致查询不可用？如何优化这块？
优化是开销很大的。不会导致查询不可用。优化是值得的，大量的碎片会导致查询性能大大降低。 如果非常 care 查询，可以考虑多个集群。在优化时，查询 skip 这个集群就可以。
Q13：Elasticsearch适合做到10亿级数据查询，每天千万级的数据实时写入或更新吗？
10亿是可以做到的，如果文档轻量，10亿所占的资源还不是很多。
ELK 使用 Elasticsearch ，进行日志处理每天千万是小case吧？
不过我们除了使用 ELK 进行日志处理，还进行业务处理，10亿级快速查询是可以做到，不过，需要做一些工作，比如索引和shards的分分合合：）
Q14：Elasticsearch相比Solr有什么优势吗？
我们当年使用 Solr 的时候，Elasticsearch 刚出来。他们都是基于 Lucene的。 Elasticsearch 相对于 solr ，省事是一个优点。而且现在 Elasticsearch 相关的应用软件也越来越多。Solr 和 Lucene 集成度很高，更新版本是和Lucene一起的，这是个优点。
很多年没用 Solr了，毕竟那时候数据量还不大，所以折腾的就少了，主要还是折腾 JVM。所以，就不再过多的比较了。
Q15：分词用的什么组件？Elasticsearch自带的吗？
我们使用 IK 分词，不过其他分词也不错。IK分词更新还是很及时的。而且它可以远程更新词典。：）
Q16： reindex有没有好的方法？
reindex 这个和 Lucene 有关，它的 update 就是 delete+ add。
Q17：以上面的两个例子为例 ： 是存储多份同样的数据么？
是两个集群。第一个集群使用大城市分索引，不过，还有大部分小城市合并一个索引。大城市还是用类目进行routing，小城市合并的索引就使用城市进行routing 。
第二个集群，大类分得索引，比如fang、che，房屋和车辆和其他类目在一个集群上，他们使用 city+二级类目做routing。
Q18：集群部署有没有使用 Docker ？ 我们使用的时候 ，同一个服务器 节点之间的互相发现没有问题 ，但是跨机器的时候需要强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群互相发现问题。
我们使用puppet进行部署。暂没使用 Docker。 强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群，跨IP段的时候是有这个需要。
Q19：您建议采用什么样的数据总线架构来保证业务数据按routing写入多个Elasticsearch集群，怎么保证多集群Elasticsearch中的数据与数据库中数据的一致性？
我们以前使用 php在web代码中进行索引和分析 query，然后引导到不同集群。 现在我们开发了一套go rest系统——4sea，使用 redis + elastic 以综合提高性能。
索引时，更新db的同时，提交一个文档 ID 通知4sea 进行更新，然后根据配置更新到不同集群。
数据提交到查询时，就是分析 query 并引导到不同集群。
这套 4sea 系统，有机会的可以考虑开源，不算很复杂的。
Q20： 能介绍一下Elasticsearch的集群rebanlance、段合并相关的原理和经验吗？
“段”合并？，我们是根据业务特点，产生几个不一样的集群，主要还是 routing 不一样。
shards 比较平均很重要的，所以选择routing 维度是难点，选择城市的话，大城市所在分片会非常大，此时可以考虑 分索引，几个大城市几个索引，然后小城市合并一个索引。
如果 shards 大小分布平均的话，就不关心如何 allocation 了。
Q21：关于集群rebalance，其实就是cluster.routing.allocation配置下的那些rebalance相关的设置，比如allow_rebalance／cluster_concurrent_rebalance／node_initial_primaries_recoveries，推荐怎么配置？
分片多的情况下，这个才是需要的吧。
分片比较少时，allow_rebalance disable，然后手动也可以接受的。
分片多，一般情况会自动平衡。我们对主从不太关心。只是如果一台机器多个 JVM instance （多个 Elasticsearch node）的话，我们写了个脚本来避免同一shard 在一台机器上。
cluster_concurrent_rebalance 在恢复的时候根据情况修改。正常情况下，再改成默认就好了。
node_initial_primaries_recoveries，在保证集群低压的情况下，不怎么care。
kopf 上面有好多这种配置，你可以多试试。
Q22：合并查询是异步请求还是同步请求？做缓存吗？
合并查询是 Elasticsearch 自带 API。
Q23：用http url connection请求的时候，会发现返回请求很耗时，一般怎么处理？
尽可能减少慢查询吧？我们很多工作就是想办法如何减少慢查询，routing和分分合合，就是这个目的。
Q24：生产环境单个节点存储多少G数据？
有大的，有小的。小的也几十G了。不过根据我们自己的业务特点，某些集群就去掉了全文索引。唯一的全文索引，使用基本的routing（比较平衡的routing，比如user。城市的话，就做不到平衡了，因为大城市数据很多），然后做了 快照，反正是增量快照，1小时甚至更短时间都可以考虑！！！去掉全文索引的其他业务集群，就小多了。
收起阅读 »
一. 索引性能（Index Performance）
首先要考虑的是，索引性能是否有必要做优化？
索引速度提高与否？主要是看瓶颈在什么地方，若是 Read DB（产生DOC）的速度比较慢，那瓶颈不在 ElasticSearch 时，优化就没那么大的动力。实际上 Elasticsearch 的索引速度还是非常快的。
我们有一次遇到 Elasticsearch 升级后索引速度很慢，查下来是新版 IK 分词的问题，修改分词插件后得到解决。
如果需要优化，应该如何优化？
SSD 是经济压力能承受情况下的不二选择。减少碎片也可以提高索引速度，每天进行优化还是很有必要的。在初次索引的时候，把 replica 设置为 0，也能提高索引速度。
bulk 是不是一定需要呢？
若是 Elasticsearch 普通索引已经导致高企的 LA，IO 压力已经见顶，这时候 bulk 也无法提供帮助，SSD 应该是很好的选择。
在 create doc 速度能跟上的时候，bulk 是可以提高速度的。
记得 threadpool.index.queue_size ++，不然会出现索引时队列不够用的情况。
indices.memory.index_buffer_size:10% 这个参数可以进行适当调整。
调整如下参数也可以提高索引速度：index.translog.flush_threshold_ops:50000 和 refresh_interval。
二. 查询性能（Query Perofrmance）
王道是什么？routing，routing，还是 routing。
我们为了提高查询速度，减少慢查询，结合自己的业务实践，使用多个集群，每个集群使用不同的 routing。比如，用户是一个routing维度。
在实践中，这个routing 非常重要。
我们碰到一种情况，想把此维度的查询（即用户查询）引到非用户routing 的集群，结果集群完全顶不住！
在大型的本地分类网站中，城市、类目也是一个不错的维度。我们使用这种维度进行各种搭配。然后在前端分析查询，把各个不同查询分别引入合适的集群。这样做以后，每个集群只需要很少的机器，而且保持很小的 CPU Usage 和 LA。从而查询速度够快，慢查询几乎消灭。
分合？
分别（索引和routing）查询和合并（索引和routing）查询，即此分合的意思。
索引越来越大，单个 shard 也很巨大，查询速度也越来越慢。这时候，是选择分索引还是更多的shards？
在实践过程中，更多的 shards 会带来额外的索引压力，即 IO 压力。
我们选择了分索引。比如按照每个大分类一个索引，或者主要的大城市一个索引。然后将他们进行合并查询。如：http://cluster1:9200/shanghai,beijing/_search?routing=fang，自动将查询中城市属性且值为上海或北京的查询，且是房类目的，引入集群 cluster1，并且routing等于fang。
http://cluster1:9200/other/_search?routing=jinan,linyi。小城市的索引，我们使用城市做 routing，如本例中同时查询济南和临沂城市。
http://cluster1:9200/_all/_search，全部城市查询。
再如： http://cluster2:9200/fang,che/_search?routing=shanghai_qiche,shanghai_zufang,beijing_qiche,beijing_zufang。查询上海和北京在小分类汽车、整租的信息，那我们进行如上合并查询。并将其引入集群 cluster2。
使用更多的 shards？
除了有 IO 压力，而且不能进行全部城市或全部类目查询，因为完全顶不住。
Elastic 官方文档建议：一个 Node 最好不要多于三个 shards。
若是 "more shards”，除了增加更多的机器，是没办法做到这一点的。
分索引，虽然一个 Node 总的shards 还是挺多的，但是一个索引可以保持3个以内的shards。
我们使用分索引时，全量查询是可以顶住的，虽然压力有点儿高。
索引越来越大，资源使用也越来越多。若是要进行更细的集群分配，大索引使用的资源成倍增加。
有什么办法能减小索引？显然，创建 doc 时，把不需要的 field 去掉是一个办法；但是，这需要对业务非常熟悉。
有啥立竿见影的办法？
根据我们信息的特点，内容（field:description）占了索引的一大半，那我们就不把 description 索引进 ES，doc 小了一倍，集群也小了一倍，所用的资源（Memory, HD or SSD, Host, snapshot存储，还有时间）大大节省，查询速度自然也更快。
那要查 description 怎么办？
上面的实例中，我们可以把查询引入不同集群，自然我们也可以把 description 查询引入一个非实时（也可以实时）集群，这主要是我们业务特点决定的，因为description查询所占比例非常小，使得我们可以这样做。
被哪些查询搞过？第一位是 Range 查询，这货的性能真不敢恭维。在最热的查询中，若是有这货，肯定是非常痛苦的，网页变慢，查询速度变慢，集群 LA 高企，严重的时候会导致集群 shard 自动下线。所以，建议在最热的查询中避免使用 Range 查询。
Facet 查询，在后续版本这个被 aggregations 替代，我们大多数时候让它在后端进行运算。
三. 其他
1)线程池
线程池我们默认使用 fixed，使用 cached 有可能控制不好。主要是比较大的分片 relocation时，会导致分片自动下线，集群可能处于危险状态。在集群高压时，若是 cached ，分片也可能自动下线。自 1.4 版本后，我们就一直 fixed，至于新版是否还存在这个问题，就没再试验了。
两个原因：一是 routing王道带来的改善，使得集群一直低压运行；二是使用fixed 后，已经极少遇到自动下线shard了。
我们前面说过，user 是一个非常好的维度。这个维度很重要，routing 效果非常明显。其他维度，需要根据业务特点，进行组合。
所以我们的集群一直是低压运行，就很少再去关注新版本的 使用 cached 配置问题。
hreadpool.search.queue_size 这个配置是很重要的，一般默认是够用了，可以尝试提高。
2）优化
每天优化是有好处的，可以大大改善查询性能。max_num_segments 建议配置为1。虽然优化时间会变长，但是在高峰期前能完成的话，会对查询性能有很大好处。
3) JVM GC的选择：选择 G1还是 CMS？
应该大多数人还是选择了 CMS，我们使用的经验是 G1 和 CMS 比较接近；但和 CMS 相比，还是有一点距离，至少在我们使用经验中是如此。
JVM 32G 现象？
128G内存的机器配置一个 JVM，然后是巨大的 heapsize （如64G）？
还是配多个 JVM instance，较小的 heapsize（如32G）？
我的建议是后者。实际使用中，后者也能帮助我们节省不少资源，并提供不错的性能。具体请参阅 “Don’t Cross 32 GB!" （https://www.elastic.co/guide/e ... _oops）
跨 32G 时，有一个现象，使用更多的内存，比如 40G，效果还不如31G！
这篇文档值得大家仔细阅读。
JVM 还有一个配置 bootstrap.mlockall: true，比较重要。这是让 JVM 启动的时候就 锁定 heap 内存。
有没有用过 较小的 heapsize，加上SSD？我听说有人使用过，效果还不错，当然，我们自己还没试过。
4）插件工具
推荐 kopf，是一个挺不错的工具，更新及时，功能完备，可以让你忘掉很多 API :)。
上面是 kopf 的图片。管理Elasticsearch 集群真心方便。以前那些 API ，慢慢要忘光了:)
索引，查询，和一些重要的配置，是今天分享的重点。
Q&A
Q1：您建议生产环境JVM采用什么样的参数设置？FULL GC频率和时间如何？
CMS 标准配置。
ES_HEAP_NEWSIZE=?G
JAVA_OPTS="$JAVA_OPTS -XX:+UseCondCardMark"
JAVA_OPTS="$JAVA_OPTS -XX:CMSWaitDuration=250"
JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"
JAVA_OPTS="$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75"
JAVA_OPTS="$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly"
Full GC 很少去care 它了。我们使用 Elasticsearch 在JVM上花的时间很少。
Q2：生产环境服务器如何配置性价比较高？单机CPU核数、主频？内存容量？磁盘容量？
内存大一些，CPU 多核是必要的，JVM 和 Elasticsearch 会充分使用内存和多核的。 关于内存容量的问题，很多是 JVM Tunning 的问题。 磁盘容量没啥要求。
Q3： 分组统计(Facet 查询或 aggregations )大多数时候让它在后端进行运算，怎么实现？应用如果需要实时进行统计而且并发量较大，如何优化？
因为我们是网站系统，所以对于 Facet 请求，引导到后端慢慢计算，前端初始的时候可能没数据，但是此后就会有了。
如果是精确要求的话，那就只能从 提高 facet 查询性能去下手，比如 routing、filter、cache、更多的内存...
Q4：存进Elasticsearch的数据，timestamp是UTC时间，Elasticsearch集群会在UTC 0点，也就是北京时间早上8点自动执行优化？如何改参数设置这个时间？
我们没有使用Elasticsearch的自动优化设置。自己控制优化时间。
Q5：我的Java程序，log4j2 Flume appender，然后机器上的Flume agent ，直接Elasticsearch 的sink avro到 es节点上，多少个agent 连在单个Elasticsearch节点比较合适 ？
ElasticSearch本身是一个分布式计算集群，所以，请求平均分配到每个 node 即可。
Q6：我代码里直接用 Java API 生成Flume appender 格式，Flume agent 里interceptor去拆分几个字段，这样是不是太累了？比较推荐的做法是不是还是各业务点自己控制字段，调用Elasticsearch API 生成索引内容？
业务点自己控制生成的文档吧？如果需要产生不同routing，并且分了索引，这些其实是业务相关的。routing和不同索引，都是根据业务情况哪些查询比较集中而进行处理的。
Q7：您见过或管理过的生产环境的Elasticsearch数据量多大？
我们使用 Elasticsearch 进行某些业务处理，数据量过亿。
Q8：SSD性能提升多少？
SSD 对索引帮助非常大，效果当当的，提高几十倍应该是没问题。不过，我们没有试过完全使用SSD顶查询，而是使用内存，内存性价比还是不错的。
Q9：我们现在有256个shard，用uid做routing，所有查询都是走routing。每个shard有30多G，每次扩容很慢，有什么建议？
可以考虑使用分合查询吗？ 或者使用更多的维度？ 256个 shard 确实比较难以控制。但是如果是分索引和查询，比more shards(256) 效果应该会好不少。
Q10：Elasticsearch排序等聚合类的操作需要用到fielddata，查询时很慢。新版本中doc values聚合查询操作性能提升很大，你们有没有用过？
Facet 查询需要更大的内存，更多的 CPU 资源。可以考虑routing、filter、cache等多种方式提高性能。
Aggs 将来是要替换 Facet，建议尽快替换原来的facet API。
Q11：Elasticsearch配置bootstrap.mlockall，我们在使用中发现会导致启动很慢，因为Elasticsearch要获取到足够的内存才开始启动。
启动慢是可以接受的，启动慢的原因也许是内存没有有效释放过，比如文件 cached了。 内存充足的情况下，启动速度还是蛮快的，可以接受。 JVM 和 Lucene 都需要内存，一般是JVM 50%, 剩下的50% 文件cached 为Lucene 使用。
Q12：优化是一个开销比较大的操作，每天优化的时候是否会导致查询不可用？如何优化这块？
优化是开销很大的。不会导致查询不可用。优化是值得的，大量的碎片会导致查询性能大大降低。 如果非常 care 查询，可以考虑多个集群。在优化时，查询 skip 这个集群就可以。
Q13：Elasticsearch适合做到10亿级数据查询，每天千万级的数据实时写入或更新吗？
10亿是可以做到的，如果文档轻量，10亿所占的资源还不是很多。
ELK 使用 Elasticsearch ，进行日志处理每天千万是小case吧？
不过我们除了使用 ELK 进行日志处理，还进行业务处理，10亿级快速查询是可以做到，不过，需要做一些工作，比如索引和shards的分分合合：）
Q14：Elasticsearch相比Solr有什么优势吗？
我们当年使用 Solr 的时候，Elasticsearch 刚出来。他们都是基于 Lucene的。 Elasticsearch 相对于 solr ，省事是一个优点。而且现在 Elasticsearch 相关的应用软件也越来越多。Solr 和 Lucene 集成度很高，更新版本是和Lucene一起的，这是个优点。
很多年没用 Solr了，毕竟那时候数据量还不大，所以折腾的就少了，主要还是折腾 JVM。所以，就不再过多的比较了。
Q15：分词用的什么组件？Elasticsearch自带的吗？
我们使用 IK 分词，不过其他分词也不错。IK分词更新还是很及时的。而且它可以远程更新词典。：）
Q16： reindex有没有好的方法？
reindex 这个和 Lucene 有关，它的 update 就是 delete+ add。
Q17：以上面的两个例子为例 ： 是存储多份同样的数据么？
是两个集群。第一个集群使用大城市分索引，不过，还有大部分小城市合并一个索引。大城市还是用类目进行routing，小城市合并的索引就使用城市进行routing 。
第二个集群，大类分得索引，比如fang、che，房屋和车辆和其他类目在一个集群上，他们使用 city+二级类目做routing。
Q18：集群部署有没有使用 Docker ？ 我们使用的时候 ，同一个服务器 节点之间的互相发现没有问题 ，但是跨机器的时候需要强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群互相发现问题。
我们使用puppet进行部署。暂没使用 Docker。 强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群，跨IP段的时候是有这个需要。
Q19：您建议采用什么样的数据总线架构来保证业务数据按routing写入多个Elasticsearch集群，怎么保证多集群Elasticsearch中的数据与数据库中数据的一致性？
我们以前使用 php在web代码中进行索引和分析 query，然后引导到不同集群。 现在我们开发了一套go rest系统——4sea，使用 redis + elastic 以综合提高性能。
索引时，更新db的同时，提交一个文档 ID 通知4sea 进行更新，然后根据配置更新到不同集群。
数据提交到查询时，就是分析 query 并引导到不同集群。
这套 4sea 系统，有机会的可以考虑开源，不算很复杂的。
Q20： 能介绍一下Elasticsearch的集群rebanlance、段合并相关的原理和经验吗？
“段”合并？，我们是根据业务特点，产生几个不一样的集群，主要还是 routing 不一样。
shards 比较平均很重要的，所以选择routing 维度是难点，选择城市的话，大城市所在分片会非常大，此时可以考虑 分索引，几个大城市几个索引，然后小城市合并一个索引。
如果 shards 大小分布平均的话，就不关心如何 allocation 了。
Q21：关于集群rebalance，其实就是cluster.routing.allocation配置下的那些rebalance相关的设置，比如allow_rebalance／cluster_concurrent_rebalance／node_initial_primaries_recoveries，推荐怎么配置？
分片多的情况下，这个才是需要的吧。
分片比较少时，allow_rebalance disable，然后手动也可以接受的。
分片多，一般情况会自动平衡。我们对主从不太关心。只是如果一台机器多个 JVM instance （多个 Elasticsearch node）的话，我们写了个脚本来避免同一shard 在一台机器上。
cluster_concurrent_rebalance 在恢复的时候根据情况修改。正常情况下，再改成默认就好了。
node_initial_primaries_recoveries，在保证集群低压的情况下，不怎么care。
kopf 上面有好多这种配置，你可以多试试。
Q22：合并查询是异步请求还是同步请求？做缓存吗？
合并查询是 Elasticsearch 自带 API。
Q23：用http url connection请求的时候，会发现返回请求很耗时，一般怎么处理？
尽可能减少慢查询吧？我们很多工作就是想办法如何减少慢查询，routing和分分合合，就是这个目的。
Q24：生产环境单个节点存储多少G数据？
有大的，有小的。小的也几十G了。不过根据我们自己的业务特点，某些集群就去掉了全文索引。唯一的全文索引，使用基本的routing（比较平衡的routing，比如user。城市的话，就做不到平衡了，因为大城市数据很多），然后做了 快照，反正是增量快照，1小时甚至更短时间都可以考虑！！！去掉全文索引的其他业务集群，就小多了。
收起阅读 »
Elastic 收购 Opbeat，进入 APM 领域
https://www.elastic.co/blog/we ... amily
https://techcrunch.com/2017/06 ... tion/
Today, at Elastic’s customer event in London, the company announced it has acquired Opbeat, a SaaS-application performance management vendor for an undisclosed amount. All 15 employees have already joined the Elastic team.
Opbeat focuses on monitoring applications written in Javascript. What’s more, it maps production application issues directly to the relevant developer source code, making it easier to fix the problem without having to hunt in the code to find the problem area.
Elastic is probably best known for its search product, Elasticsearch, an open source search tool that runs on some of the world’s biggest properties including Wikipedia, Yelp and eBay. In recent years, the company has moved beyond straight search and into analytics, particularly focusing on log data that puts them squarely in competition with companies like Splunk. Last year, it pulled all of the products together into a platform play they called Elastic Stack.
Elastic CEO Shay Banon sees today’s acquisition through a strategic lens, giving his company a leg up on the competition by offering not only a way to search log data, but also giving insights into the applications that are generating the data and why they may be performing poorly.
Rasmus Makwarth, who was CEO at Opbeat says joining Elastic allows the company to speed up the product roadmap and take advantage of the breadth of the Elastic platform. “We’ve been running a SaaS platform for some time now, giving application insights to developers, but haven’t been able to give customers insight into the entire application,” he explained. Joining Elastic lets his company take advantage of the search tool, as well as analytics, logging and data visualization available on the Elastic platform to greatly expand the vision.
Opbeat’s employees have already joined Elastic and are working with the Elastic team to build an on-prem application to go with the existing SaaS piece. Banon said that the company hopes to take advantage of Opbeat’s cloud background to expand its cloud offerings.
Taking a cloud-native application and engineering it to be on-prem is no simple task, but the two companies hope to have an on-prem version ready in several month. It’s worth noting that Opbeat was using Elasticsearch in its product, but as Banon pointed out using a product and making it part of the stack are two different matters, and it will take a significant engineering effort to incorporate the new company into the fold as both a cloud and on-prem product.
You may recall that Cisco bought APM vendor AppDynamics earlier this year for $3.7 billion right before the company was about to IPO. While Banon wouldn’t reveal today’s purchase price, he joked that it was substantially less than that.
Given that Opbeat was founded in 2013 in Copenhagen, Denmark and has raised approximately $2.8 million, that’s a fair bet. The company will remain in Denmark.
https://www.elastic.co/blog/we ... amily
https://techcrunch.com/2017/06 ... tion/
Today, at Elastic’s customer event in London, the company announced it has acquired Opbeat, a SaaS-application performance management vendor for an undisclosed amount. All 15 employees have already joined the Elastic team.
Opbeat focuses on monitoring applications written in Javascript. What’s more, it maps production application issues directly to the relevant developer source code, making it easier to fix the problem without having to hunt in the code to find the problem area.
Elastic is probably best known for its search product, Elasticsearch, an open source search tool that runs on some of the world’s biggest properties including Wikipedia, Yelp and eBay. In recent years, the company has moved beyond straight search and into analytics, particularly focusing on log data that puts them squarely in competition with companies like Splunk. Last year, it pulled all of the products together into a platform play they called Elastic Stack.
Elastic CEO Shay Banon sees today’s acquisition through a strategic lens, giving his company a leg up on the competition by offering not only a way to search log data, but also giving insights into the applications that are generating the data and why they may be performing poorly.
Rasmus Makwarth, who was CEO at Opbeat says joining Elastic allows the company to speed up the product roadmap and take advantage of the breadth of the Elastic platform. “We’ve been running a SaaS platform for some time now, giving application insights to developers, but haven’t been able to give customers insight into the entire application,” he explained. Joining Elastic lets his company take advantage of the search tool, as well as analytics, logging and data visualization available on the Elastic platform to greatly expand the vision.
Opbeat’s employees have already joined Elastic and are working with the Elastic team to build an on-prem application to go with the existing SaaS piece. Banon said that the company hopes to take advantage of Opbeat’s cloud background to expand its cloud offerings.
Taking a cloud-native application and engineering it to be on-prem is no simple task, but the two companies hope to have an on-prem version ready in several month. It’s worth noting that Opbeat was using Elasticsearch in its product, but as Banon pointed out using a product and making it part of the stack are two different matters, and it will take a significant engineering effort to incorporate the new company into the fold as both a cloud and on-prem product.
You may recall that Cisco bought APM vendor AppDynamics earlier this year for $3.7 billion right before the company was about to IPO. While Banon wouldn’t reveal today’s purchase price, he joked that it was substantially less than that.
Given that Opbeat was founded in 2013 in Copenhagen, Denmark and has raised approximately $2.8 million, that’s a fair bet. The company will remain in Denmark. 收起阅读 »
ELK使用不完全记录
ELK入门搭建参考文章
ELK入门搭建参考文章
【线下活动】2017-06-25 杭州 Elastic Meetup日程安排
报名链接：http://elasticsearch.mikecrm.com/O6o0yq3
1.举办方
主办：Elastic 中文社区
协办：魔蝎科技
独家直播：
IT大咖说
2. 时间地点
活动时间：2017年6月25日 13:30 - 18:00
活动地点：杭州市西湖区文一西路767号西溪国际商务中心E座1楼会议室
3. 主题
分享一：基于ElasticSearch构建搜索云服务
演讲者简介：
陈超，七牛云技术总监，Spark Summit China 出品人， 专注于大规模分布式计算与机器学习领域。
主题简介：
介绍七牛基于 Elasticsearch 如何构建大规模搜索云服务的经验和思考。
分享二：采用Elasticsearch构建大规模通用搜索平台的经验分享
演讲者简介：
马华标 - 城破 蚂蚁金服中间件搜索负责人， 12年加入阿里巴巴任职于B2B中文站架构部、数据仓库架构组组长，14年加入蚂蚁金服担任中间件搜索负责人， 从事搜索方面的团队建设与产品研发工作。
主题简介：
介绍蚂蚁金服采用Elasticsearch构建大规模通用搜索平台的经验分享。
分享三：垂直搜索引擎系统架构
演讲者简介：
吴英昊 花名：丰坚
蚂蚁金服数据中间件技术专家，曾任职于当当网，担任搜索架构师（兼开发经理）职位，负责当当网的搜索后台的技术架构和技术团队的管理，包括搜索引擎架构，搜索排序和 Query 分析，后在一创业公司负责推荐和广告系统架构和算法相关工作。 目前在蚂蚁金服数据中间件搜索组技术专家。
主题简介：
主题 “垂直搜索引擎系统架构”，介绍如何采用 Elasticsearch 构建大规模通用搜索平台。会穿插一些关于ES在垂直搜索中的应用和优化方向。
分享四：Metricbeat 在容器监控方面的应用
演讲者简介：
曾勇（Medcl） Elastic 工程师与布道师
Elasticsearch 爱好者，2015年加入 Elastic，Elastic 中文社区的发起人，Elastic 公司在中国的首位员工。
主题简介：
使用 Docker 或者其他的容器方案来进行部署已经成为热门，今天的分享将介绍如何使用 Metricbeat 来收集和监控您的容器化部署环境，结合 Elasticsearch 和 Kibana 对容器的性能进行全方位的了解。
继续阅读 »
1.举办方
主办：Elastic 中文社区
协办：魔蝎科技
独家直播：
IT大咖说
2. 时间地点
活动时间：2017年6月25日 13:30 - 18:00
活动地点：杭州市西湖区文一西路767号西溪国际商务中心E座1楼会议室
3. 主题
分享一：基于ElasticSearch构建搜索云服务
演讲者简介：
陈超，七牛云技术总监，Spark Summit China 出品人， 专注于大规模分布式计算与机器学习领域。
主题简介：
介绍七牛基于 Elasticsearch 如何构建大规模搜索云服务的经验和思考。
分享二：采用Elasticsearch构建大规模通用搜索平台的经验分享
演讲者简介：
马华标 - 城破 蚂蚁金服中间件搜索负责人， 12年加入阿里巴巴任职于B2B中文站架构部、数据仓库架构组组长，14年加入蚂蚁金服担任中间件搜索负责人， 从事搜索方面的团队建设与产品研发工作。
主题简介：
介绍蚂蚁金服采用Elasticsearch构建大规模通用搜索平台的经验分享。
分享三：垂直搜索引擎系统架构
演讲者简介：
吴英昊 花名：丰坚
蚂蚁金服数据中间件技术专家，曾任职于当当网，担任搜索架构师（兼开发经理）职位，负责当当网的搜索后台的技术架构和技术团队的管理，包括搜索引擎架构，搜索排序和 Query 分析，后在一创业公司负责推荐和广告系统架构和算法相关工作。 目前在蚂蚁金服数据中间件搜索组技术专家。
主题简介：
主题 “垂直搜索引擎系统架构”，介绍如何采用 Elasticsearch 构建大规模通用搜索平台。会穿插一些关于ES在垂直搜索中的应用和优化方向。
分享四：Metricbeat 在容器监控方面的应用
演讲者简介：
曾勇（Medcl） Elastic 工程师与布道师
Elasticsearch 爱好者，2015年加入 Elastic，Elastic 中文社区的发起人，Elastic 公司在中国的首位员工。
主题简介：
使用 Docker 或者其他的容器方案来进行部署已经成为热门，今天的分享将介绍如何使用 Metricbeat 来收集和监控您的容器化部署环境，结合 Elasticsearch 和 Kibana 对容器的性能进行全方位的了解。
报名链接：http://elasticsearch.mikecrm.com/O6o0yq3
1.举办方
主办：Elastic 中文社区
协办：魔蝎科技
独家直播：
IT大咖说
2. 时间地点
活动时间：2017年6月25日 13:30 - 18:00
活动地点：杭州市西湖区文一西路767号西溪国际商务中心E座1楼会议室
3. 主题
分享一：基于ElasticSearch构建搜索云服务
演讲者简介：
陈超，七牛云技术总监，Spark Summit China 出品人， 专注于大规模分布式计算与机器学习领域。
主题简介：
介绍七牛基于 Elasticsearch 如何构建大规模搜索云服务的经验和思考。
分享二：采用Elasticsearch构建大规模通用搜索平台的经验分享
演讲者简介：
马华标 - 城破 蚂蚁金服中间件搜索负责人， 12年加入阿里巴巴任职于B2B中文站架构部、数据仓库架构组组长，14年加入蚂蚁金服担任中间件搜索负责人， 从事搜索方面的团队建设与产品研发工作。
主题简介：
介绍蚂蚁金服采用Elasticsearch构建大规模通用搜索平台的经验分享。
分享三：垂直搜索引擎系统架构
演讲者简介：
吴英昊 花名：丰坚
蚂蚁金服数据中间件技术专家，曾任职于当当网，担任搜索架构师（兼开发经理）职位，负责当当网的搜索后台的技术架构和技术团队的管理，包括搜索引擎架构，搜索排序和 Query 分析，后在一创业公司负责推荐和广告系统架构和算法相关工作。 目前在蚂蚁金服数据中间件搜索组技术专家。
主题简介：
主题 “垂直搜索引擎系统架构”，介绍如何采用 Elasticsearch 构建大规模通用搜索平台。会穿插一些关于ES在垂直搜索中的应用和优化方向。
分享四：Metricbeat 在容器监控方面的应用
演讲者简介：
曾勇（Medcl） Elastic 工程师与布道师
Elasticsearch 爱好者，2015年加入 Elastic，Elastic 中文社区的发起人，Elastic 公司在中国的首位员工。
主题简介：
使用 Docker 或者其他的容器方案来进行部署已经成为热门，今天的分享将介绍如何使用 Metricbeat 来收集和监控您的容器化部署环境，结合 Elasticsearch 和 Kibana 对容器的性能进行全方位的了解。 收起阅读 »
1.举办方
主办：Elastic 中文社区
协办：魔蝎科技
独家直播：
IT大咖说
2. 时间地点
活动时间：2017年6月25日 13:30 - 18:00
活动地点：杭州市西湖区文一西路767号西溪国际商务中心E座1楼会议室
3. 主题
分享一：基于ElasticSearch构建搜索云服务
演讲者简介：
陈超，七牛云技术总监，Spark Summit China 出品人， 专注于大规模分布式计算与机器学习领域。
主题简介：
介绍七牛基于 Elasticsearch 如何构建大规模搜索云服务的经验和思考。
分享二：采用Elasticsearch构建大规模通用搜索平台的经验分享
演讲者简介：
马华标 - 城破 蚂蚁金服中间件搜索负责人， 12年加入阿里巴巴任职于B2B中文站架构部、数据仓库架构组组长，14年加入蚂蚁金服担任中间件搜索负责人， 从事搜索方面的团队建设与产品研发工作。
主题简介：
介绍蚂蚁金服采用Elasticsearch构建大规模通用搜索平台的经验分享。
分享三：垂直搜索引擎系统架构
演讲者简介：
吴英昊 花名：丰坚
蚂蚁金服数据中间件技术专家，曾任职于当当网，担任搜索架构师（兼开发经理）职位，负责当当网的搜索后台的技术架构和技术团队的管理，包括搜索引擎架构，搜索排序和 Query 分析，后在一创业公司负责推荐和广告系统架构和算法相关工作。 目前在蚂蚁金服数据中间件搜索组技术专家。
主题简介：
主题 “垂直搜索引擎系统架构”，介绍如何采用 Elasticsearch 构建大规模通用搜索平台。会穿插一些关于ES在垂直搜索中的应用和优化方向。
分享四：Metricbeat 在容器监控方面的应用
演讲者简介：
曾勇（Medcl） Elastic 工程师与布道师
Elasticsearch 爱好者，2015年加入 Elastic，Elastic 中文社区的发起人，Elastic 公司在中国的首位员工。
主题简介：
使用 Docker 或者其他的容器方案来进行部署已经成为热门，今天的分享将介绍如何使用 Metricbeat 来收集和监控您的容器化部署环境，结合 Elasticsearch 和 Kibana 对容器的性能进行全方位的了解。 收起阅读 »
模糊查询导致Elasticsearch服务宕机
之前我在社区里写过 《ElasticSearch集群故障案例分析: 警惕通配符查询》一文，讲的是关于通配符查询可能引起ES集群负载过高的问题。 当时提到wildcard query构造的non-deterministic automaton要经历一个determinize的过程，其间如果生成的状态数量过高，可能引起集群负载彪高，影响对外服务。 但因为determinize的过程中，Lucene对生成的状态数量做了限制，因此在问题查询过去以后，集群还是可以恢复常态。
然而近期我们线上的另外一起故障，使我意识到，Prefix/Regex/Fuzzy一类的模糊查询可能直接让整个集群直接挂掉。
问题出现时，ES服务端日志有如下报错:
调查后发现，Prefix/Regex/Fuzzy一类的Query，是直接构造的deterministic automaton，如果查询字符串过长，或者pattern本身过于复杂，构造出来的状态过多，之后一个isFinite的Lucene方法调用可能产生堆栈溢出。
一个可以复现问题的regex query如下:
对于我们这次特定的问题，是因为prefix Query里没有限制用户输入的长度。 看ES的源码，PrefixQuery继承自Lucene的AutomatonQuery，在实例化的时候，maxDeterminizedStates传的是Integer.MAX_VALUE, 并且生成automaton之前，prefix的长度也没有做限制。 个人认为这里可能应该限制一下大小，避免产生过多的状态:
org.apache.lucene.util.automaton.Operations.isFinite，
可以看到这段代码里用了递归，递归的深度取决于状态转移的数量。根据注释的说明，这是一段待完善的代码，因为使用了递归，可能导致堆栈溢出:
由此可见，在项目里使用了模糊查询的同学，一定一定要注意限制用户输入长度，否则可能导致集群负载过高或者整个挂掉。
虽然Lucene/Elasticsearch应该在代码层面做一些限制，确保有问题的query不会导致stack overflow，但是当用到这类查询的时候，程序员的思维方式还局限在RDBMS开发的时代。 我们应该多在数据索引阶段下功夫，确保尽量用最高效的term query来完成绝大多数的查询。
继续阅读 »
然而近期我们线上的另外一起故障，使我意识到，Prefix/Regex/Fuzzy一类的模糊查询可能直接让整个集群直接挂掉。
问题出现时，ES服务端日志有如下报错:
[2017-06-14T21:06:39,330][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [xx.xx.xx.xx] fatal error in thread [elasticsearch[xx.xx.xx.xx][search][T#29]], exiting
java.lang.StackOverflowError
at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
调查后发现，Prefix/Regex/Fuzzy一类的Query，是直接构造的deterministic automaton，如果查询字符串过长，或者pattern本身过于复杂，构造出来的状态过多，之后一个isFinite的Lucene方法调用可能产生堆栈溢出。
一个可以复现问题的regex query如下:
POST /test/_search
{
"query": {
"regexp": {
"test": "t{1,9500}"
}
}
}对于我们这次特定的问题，是因为prefix Query里没有限制用户输入的长度。 看ES的源码，PrefixQuery继承自Lucene的AutomatonQuery，在实例化的时候，maxDeterminizedStates传的是Integer.MAX_VALUE, 并且生成automaton之前，prefix的长度也没有做限制。 个人认为这里可能应该限制一下大小，避免产生过多的状态:
public class PrefixQuery extends AutomatonQuery {
/** Constructs a query for terms starting with <code>prefix</code>. */
public PrefixQuery(Term prefix) {
// It's OK to pass unlimited maxDeterminizedStates: the automaton is born small and determinized:
super(prefix, toAutomaton(prefix.bytes()), Integer.MAX_VALUE, true);
if (prefix == null) {
throw new NullPointerException("prefix must not be null");
}
org.apache.lucene.util.automaton.Operations.isFinite，
可以看到这段代码里用了递归，递归的深度取决于状态转移的数量。根据注释的说明，这是一段待完善的代码，因为使用了递归，可能导致堆栈溢出:
// TODO: not great that this is recursive... in theory a
// large automata could exceed java's stack
private static boolean isFinite(Transition scratch, Automaton a, int state, BitSet path, BitSet visited) {
path.set(state);
int numTransitions = a.initTransition(state, scratch);
for(int t=0;t<numTransitions;t++) {
a.getTransition(state, t, scratch);
if (path.get(scratch.dest) || (!visited.get(scratch.dest) && !isFinite(scratch, a, scratch.dest, path, visited))) {
return false;
}
}
path.clear(state);
visited.set(state);
return true;
}由此可见，在项目里使用了模糊查询的同学，一定一定要注意限制用户输入长度，否则可能导致集群负载过高或者整个挂掉。
虽然Lucene/Elasticsearch应该在代码层面做一些限制，确保有问题的query不会导致stack overflow，但是当用到这类查询的时候，程序员的思维方式还局限在RDBMS开发的时代。 我们应该多在数据索引阶段下功夫，确保尽量用最高效的term query来完成绝大多数的查询。
之前我在社区里写过 《ElasticSearch集群故障案例分析: 警惕通配符查询》一文，讲的是关于通配符查询可能引起ES集群负载过高的问题。 当时提到wildcard query构造的non-deterministic automaton要经历一个determinize的过程，其间如果生成的状态数量过高，可能引起集群负载彪高，影响对外服务。 但因为determinize的过程中，Lucene对生成的状态数量做了限制，因此在问题查询过去以后，集群还是可以恢复常态。
然而近期我们线上的另外一起故障，使我意识到，Prefix/Regex/Fuzzy一类的模糊查询可能直接让整个集群直接挂掉。
问题出现时，ES服务端日志有如下报错:
调查后发现，Prefix/Regex/Fuzzy一类的Query，是直接构造的deterministic automaton，如果查询字符串过长，或者pattern本身过于复杂，构造出来的状态过多，之后一个isFinite的Lucene方法调用可能产生堆栈溢出。
一个可以复现问题的regex query如下:
对于我们这次特定的问题，是因为prefix Query里没有限制用户输入的长度。 看ES的源码，PrefixQuery继承自Lucene的AutomatonQuery，在实例化的时候，maxDeterminizedStates传的是Integer.MAX_VALUE, 并且生成automaton之前，prefix的长度也没有做限制。 个人认为这里可能应该限制一下大小，避免产生过多的状态:
org.apache.lucene.util.automaton.Operations.isFinite，
可以看到这段代码里用了递归，递归的深度取决于状态转移的数量。根据注释的说明，这是一段待完善的代码，因为使用了递归，可能导致堆栈溢出:
由此可见，在项目里使用了模糊查询的同学，一定一定要注意限制用户输入长度，否则可能导致集群负载过高或者整个挂掉。
虽然Lucene/Elasticsearch应该在代码层面做一些限制，确保有问题的query不会导致stack overflow，但是当用到这类查询的时候，程序员的思维方式还局限在RDBMS开发的时代。 我们应该多在数据索引阶段下功夫，确保尽量用最高效的term query来完成绝大多数的查询。 收起阅读 »
然而近期我们线上的另外一起故障，使我意识到，Prefix/Regex/Fuzzy一类的模糊查询可能直接让整个集群直接挂掉。
问题出现时，ES服务端日志有如下报错:
[2017-06-14T21:06:39,330][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [xx.xx.xx.xx] fatal error in thread [elasticsearch[xx.xx.xx.xx][search][T#29]], exiting
java.lang.StackOverflowError
at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
调查后发现，Prefix/Regex/Fuzzy一类的Query，是直接构造的deterministic automaton，如果查询字符串过长，或者pattern本身过于复杂，构造出来的状态过多，之后一个isFinite的Lucene方法调用可能产生堆栈溢出。
一个可以复现问题的regex query如下:
POST /test/_search
{
"query": {
"regexp": {
"test": "t{1,9500}"
}
}
}对于我们这次特定的问题，是因为prefix Query里没有限制用户输入的长度。 看ES的源码，PrefixQuery继承自Lucene的AutomatonQuery，在实例化的时候，maxDeterminizedStates传的是Integer.MAX_VALUE, 并且生成automaton之前，prefix的长度也没有做限制。 个人认为这里可能应该限制一下大小，避免产生过多的状态:
public class PrefixQuery extends AutomatonQuery {
/** Constructs a query for terms starting with <code>prefix</code>. */
public PrefixQuery(Term prefix) {
// It's OK to pass unlimited maxDeterminizedStates: the automaton is born small and determinized:
super(prefix, toAutomaton(prefix.bytes()), Integer.MAX_VALUE, true);
if (prefix == null) {
throw new NullPointerException("prefix must not be null");
}
org.apache.lucene.util.automaton.Operations.isFinite，
可以看到这段代码里用了递归，递归的深度取决于状态转移的数量。根据注释的说明，这是一段待完善的代码，因为使用了递归，可能导致堆栈溢出:
// TODO: not great that this is recursive... in theory a
// large automata could exceed java's stack
private static boolean isFinite(Transition scratch, Automaton a, int state, BitSet path, BitSet visited) {
path.set(state);
int numTransitions = a.initTransition(state, scratch);
for(int t=0;t<numTransitions;t++) {
a.getTransition(state, t, scratch);
if (path.get(scratch.dest) || (!visited.get(scratch.dest) && !isFinite(scratch, a, scratch.dest, path, visited))) {
return false;
}
}
path.clear(state);
visited.set(state);
return true;
}由此可见，在项目里使用了模糊查询的同学，一定一定要注意限制用户输入长度，否则可能导致集群负载过高或者整个挂掉。
虽然Lucene/Elasticsearch应该在代码层面做一些限制，确保有问题的query不会导致stack overflow，但是当用到这类查询的时候，程序员的思维方式还局限在RDBMS开发的时代。 我们应该多在数据索引阶段下功夫，确保尽量用最高效的term query来完成绝大多数的查询。 收起阅读 »
ElasticHD: ElasticSearch Dashboard Application
ElasticHD 是一款 ElasticSearch的可视化应用。不依赖ES的插件安装，更便捷；导航栏直接填写对应的ES IP和端口就可以操作Es了。目前支持如下功能：
- ES Real time data search
- ES Dashboard data visualization
- ES Index Template (在线修改、查看、上传）
- ES Indices Index deletion and search
- SQL Converts to Elasticsearch DSL
- ES 基本查询文档
Install elasticHD
Precompiled binaries for supported operating systems are available.
Basic Usage
- linux and MacOs use ElasticHD
- 下载对应的elasticHD版本，unzip xxx_elasticHd_xxx.zip
- 修改权限 chmod 0777 ElasticHD
- 可指定ip端口运行elastichd ./ElasticHD -p 127.0.0.1:9800 默认 ip和端口也是这个
- windows use ElasticHD
- 直接下载对应windows版本,解压，双击运行。当然想指定端口的话同linux
Application Info
ElasticHD 是一款 ElasticSearch的可视化应用。不依赖ES的插件安装，更便捷；导航栏直接填写对应的ES IP和端口就可以操作Es了。目前支持如下功能：
- ES Real time data search
- ES Dashboard data visualization
- ES Index Template (在线修改、查看、上传）
- ES Indices Index deletion and search
- SQL Converts to Elasticsearch DSL
- ES 基本查询文档
Install elasticHD
Precompiled binaries for supported operating systems are available.
Basic Usage
- linux and MacOs use ElasticHD
- 下载对应的elasticHD版本，unzip xxx_elasticHd_xxx.zip
- 修改权限 chmod 0777 ElasticHD
- 可指定ip端口运行elastichd ./ElasticHD -p 127.0.0.1:9800 默认 ip和端口也是这个
- windows use ElasticHD
- 直接下载对应windows版本,解压，双击运行。当然想指定端口的话同linux
Application Info
收起阅读 »
farmerx 发表于 : 2017-06-06 14:55
评论 (27)
Elasticsearch 5.4.1 和 5.3.3 发布
昨日 Elastic 正式发布针对 5.4 Bug 的修复版本 Elasticsearch 5.4.1（基于 Lucene6.5.1 ），以及基于 Lucene6.4.2的 Elasticsearch 5.3.3。 Elasticsearch 5.4.1 是目前最新的稳定版本，在官方的 Elastic Cloud 上已可以直接部署和升级。此次发布包括两个安全补丁-- 所有 X-Pack Security 用户都应该升级。
5.4.x 相关链接：
Elasticsearch 5.4.1 下载地址
Elasticsearch 5.4.1 发行说明
Elasticsearch 5.4 重要改变
X-Pack 5.4.1 发行说明
5.3.x 相关链接:
Elasticsearch 5.3.3 下载地址
Elasticsearch 5.3.3 发行说明
Elasticsearch 5.3.3 重要改变
X-Pack 5.3.3 发行说明
你可以通过阅读上面的详细的发行说明来了解具体的发布内容，下面是一些重点摘要：
X-Pack Document Level Security and Aliases (ESA-2017-09)
X-Pack 安全组件在版本 5.4.1 和 5.3.3 之前对于索引别名的文档层面的安全设置存在漏洞，这个 bug 允许单个用户在特定的操作下能通过别名查看未经允许的数据。
影响版本
X-Pack Security 从 5.0.0 到 5.4.0 都受影响。
解决方案
所有 X-Pack 安全组件的用户升级到 5.3.3 或者 5.4.1。如果不能升级，通过禁用索引层面的 request cache 可以临时解决这个问题。
CVE ID: CVE-2017-8441
X-Pack Privilege Escalation (ESA-2017-06)
修复 run_as 功能存在的一个特权扩大的bug。正常情况下，当使用run_as执行某些操作会以特定的身份来执行，这个bug 让用户无法正常转换为 run_as 指定的用户身份，从而导致查询失败和结果异常。
如果你不使用 run_as 功能或 _user 属性，则不受此bug影响。
影响版本
X-Pack Security 从 5.0.0 到 5.4.0 都受影响。
解决方案
建议升级 Elastic Stack 到 5.4.1，如果不能升级，请移除模板里面的 {{_user.username}} 占位符并确保 run_as 设置不会被不可信用户修改。
CVE ID: CVE-2017-8438
其它重要变化:
最后，请下载和试用最新的 Elasticsearch 5.4.1，欢迎前往GitHub issue反馈任何遇到的问题。
继续阅读 »
5.4.x 相关链接：
Elasticsearch 5.4.1 下载地址
Elasticsearch 5.4.1 发行说明
Elasticsearch 5.4 重要改变
X-Pack 5.4.1 发行说明
5.3.x 相关链接:
Elasticsearch 5.3.3 下载地址
Elasticsearch 5.3.3 发行说明
Elasticsearch 5.3.3 重要改变
X-Pack 5.3.3 发行说明
你可以通过阅读上面的详细的发行说明来了解具体的发布内容，下面是一些重点摘要：
X-Pack Document Level Security and Aliases (ESA-2017-09)
X-Pack 安全组件在版本 5.4.1 和 5.3.3 之前对于索引别名的文档层面的安全设置存在漏洞，这个 bug 允许单个用户在特定的操作下能通过别名查看未经允许的数据。
影响版本
X-Pack Security 从 5.0.0 到 5.4.0 都受影响。
解决方案
所有 X-Pack 安全组件的用户升级到 5.3.3 或者 5.4.1。如果不能升级，通过禁用索引层面的 request cache 可以临时解决这个问题。
CVE ID: CVE-2017-8441
X-Pack Privilege Escalation (ESA-2017-06)
修复 run_as 功能存在的一个特权扩大的bug。正常情况下，当使用run_as执行某些操作会以特定的身份来执行，这个bug 让用户无法正常转换为 run_as 指定的用户身份，从而导致查询失败和结果异常。
如果你不使用 run_as 功能或 _user 属性，则不受此bug影响。
影响版本
X-Pack Security 从 5.0.0 到 5.4.0 都受影响。
解决方案
建议升级 Elastic Stack 到 5.4.1，如果不能升级，请移除模板里面的 {{_user.username}} 占位符并确保 run_as 设置不会被不可信用户修改。
CVE ID: CVE-2017-8438
其它重要变化:
- 修复 bug，单分片进行 scroll 操作可能引起 X-Pack Security 造成节点僵死及 OOM。
- Elasticsearch 5.4.0 启用 TLS 不能对 5.3.x 和之前的节点进行认证。
- LDAP 认证用户在撤销认证之后后可能任然驻留在缓存。
- 现在，Netty在处理线程池、缓冲池和其他资源时，尊重处理器的设置，而不是在其他容器上运行时，可能会对这些资源进行过度的调整。
- 对关闭的索引进行 Index setting 修改将进行验证，保护因为错误的配置造成索引无法打开的问题。
- 修复 TransportClient 关于嗅探可能造成客户端挂起的异常。
- 修复在KERBEROS安全模式，HDFS repository 插件与 Java Security Manager 发生的冲突。
- 修复 Snapshot/restore 在 Elasticsearch 5.2.x 及之前的版本在取回所有快照时异常缓慢的问题。
最后，请下载和试用最新的 Elasticsearch 5.4.1，欢迎前往GitHub issue反馈任何遇到的问题。
昨日 Elastic 正式发布针对 5.4 Bug 的修复版本 Elasticsearch 5.4.1（基于 Lucene6.5.1 ），以及基于 Lucene6.4.2的 Elasticsearch 5.3.3。 Elasticsearch 5.4.1 是目前最新的稳定版本，在官方的 Elastic Cloud 上已可以直接部署和升级。此次发布包括两个安全补丁-- 所有 X-Pack Security 用户都应该升级。
5.4.x 相关链接：
Elasticsearch 5.4.1 下载地址
Elasticsearch 5.4.1 发行说明
Elasticsearch 5.4 重要改变
X-Pack 5.4.1 发行说明
5.3.x 相关链接:
Elasticsearch 5.3.3 下载地址
Elasticsearch 5.3.3 发行说明
Elasticsearch 5.3.3 重要改变
X-Pack 5.3.3 发行说明
你可以通过阅读上面的详细的发行说明来了解具体的发布内容，下面是一些重点摘要：
X-Pack Document Level Security and Aliases (ESA-2017-09)
X-Pack 安全组件在版本 5.4.1 和 5.3.3 之前对于索引别名的文档层面的安全设置存在漏洞，这个 bug 允许单个用户在特定的操作下能通过别名查看未经允许的数据。
影响版本
X-Pack Security 从 5.0.0 到 5.4.0 都受影响。
解决方案
所有 X-Pack 安全组件的用户升级到 5.3.3 或者 5.4.1。如果不能升级，通过禁用索引层面的 request cache 可以临时解决这个问题。
CVE ID: CVE-2017-8441
X-Pack Privilege Escalation (ESA-2017-06)
修复 run_as 功能存在的一个特权扩大的bug。正常情况下，当使用run_as执行某些操作会以特定的身份来执行，这个bug 让用户无法正常转换为 run_as 指定的用户身份，从而导致查询失败和结果异常。
如果你不使用 run_as 功能或 _user 属性，则不受此bug影响。
影响版本
X-Pack Security 从 5.0.0 到 5.4.0 都受影响。
解决方案
建议升级 Elastic Stack 到 5.4.1，如果不能升级，请移除模板里面的 {{_user.username}} 占位符并确保 run_as 设置不会被不可信用户修改。
CVE ID: CVE-2017-8438
其它重要变化:
最后，请下载和试用最新的 Elasticsearch 5.4.1，欢迎前往GitHub issue反馈任何遇到的问题。 收起阅读 »
5.4.x 相关链接：
Elasticsearch 5.4.1 下载地址
Elasticsearch 5.4.1 发行说明
Elasticsearch 5.4 重要改变
X-Pack 5.4.1 发行说明
5.3.x 相关链接:
Elasticsearch 5.3.3 下载地址
Elasticsearch 5.3.3 发行说明
Elasticsearch 5.3.3 重要改变
X-Pack 5.3.3 发行说明
你可以通过阅读上面的详细的发行说明来了解具体的发布内容，下面是一些重点摘要：
X-Pack Document Level Security and Aliases (ESA-2017-09)
X-Pack 安全组件在版本 5.4.1 和 5.3.3 之前对于索引别名的文档层面的安全设置存在漏洞，这个 bug 允许单个用户在特定的操作下能通过别名查看未经允许的数据。
影响版本
X-Pack Security 从 5.0.0 到 5.4.0 都受影响。
解决方案
所有 X-Pack 安全组件的用户升级到 5.3.3 或者 5.4.1。如果不能升级，通过禁用索引层面的 request cache 可以临时解决这个问题。
CVE ID: CVE-2017-8441
X-Pack Privilege Escalation (ESA-2017-06)
修复 run_as 功能存在的一个特权扩大的bug。正常情况下，当使用run_as执行某些操作会以特定的身份来执行，这个bug 让用户无法正常转换为 run_as 指定的用户身份，从而导致查询失败和结果异常。
如果你不使用 run_as 功能或 _user 属性，则不受此bug影响。
影响版本
X-Pack Security 从 5.0.0 到 5.4.0 都受影响。
解决方案
建议升级 Elastic Stack 到 5.4.1，如果不能升级，请移除模板里面的 {{_user.username}} 占位符并确保 run_as 设置不会被不可信用户修改。
CVE ID: CVE-2017-8438
其它重要变化:
- 修复 bug，单分片进行 scroll 操作可能引起 X-Pack Security 造成节点僵死及 OOM。
- Elasticsearch 5.4.0 启用 TLS 不能对 5.3.x 和之前的节点进行认证。
- LDAP 认证用户在撤销认证之后后可能任然驻留在缓存。
- 现在，Netty在处理线程池、缓冲池和其他资源时，尊重处理器的设置，而不是在其他容器上运行时，可能会对这些资源进行过度的调整。
- 对关闭的索引进行 Index setting 修改将进行验证，保护因为错误的配置造成索引无法打开的问题。
- 修复 TransportClient 关于嗅探可能造成客户端挂起的异常。
- 修复在KERBEROS安全模式，HDFS repository 插件与 Java Security Manager 发生的冲突。
- 修复 Snapshot/restore 在 Elasticsearch 5.2.x 及之前的版本在取回所有快照时异常缓慢的问题。
最后，请下载和试用最新的 Elasticsearch 5.4.1，欢迎前往GitHub issue反馈任何遇到的问题。 收起阅读 »
《Elasticsearch权威指南》中文版背后的故事
去年我们社区一起翻译了一本书《Elasticsearch权威指南》，并且已经在官方上线了，链接：
https://www.elastic.co/guide/cn/index.html
撒花~ ???????????????????
我想给大家分享一些这本书后面的故事：
大家在浏览到前言章节里面有一节“鸣谢”，里面可以看到很多熟悉的名字：
薛杰，骆朗，彭秋源，魏喆，饶琛琳， 风虎，路小磊，michealzh，nodexy，sdlyjzh，落英流离， sunyonggang，Singham，烧碱，龙翔，陈思，陈华， 追风侃侃，Geolem，卷发，kfypmqqw，袁伟强，yichao， 小彬，leo，tangmisi，Alex，baifan，Evan，fanyer， wwb，瑞星，刘碧琴，walker，songgl， 吕兵，东，杜宁，秦东亮，biyuhao，刘刚， yumo，王秀文，zcola，gitqh，blackoon，David，韩炳辰， 韩陆，echolihao，Xargin，abel-sun，卞顺强， bsll，冬狼，王琦，Medcl。
是的，这些就是我们权威指南的核心的译者了，虽然只是列了一个名字，但是其实背后付出了很多，有一些同学是在此之前就已经做过部分翻译的同学，如：路小磊，有一些是早就出版了多本书的资深作家了，如：饶琛琳，还有很多是社区里面一直就非常活跃的同学，各种线上线下活动都能看到你们的身影，感谢你们。
记得去年刚刚开始这个翻译的计划的时候，短短几天时间就收到了很多同学的报名，一下子累积人数多达80人，
正所谓人多就是力量，不过任务的分配和管理也就成了一个问题，要知道权威指南纸质版有650多页，
很厚的一本书，内容也真是非常多。我记得项目应该是3月份启动，到了5月份还没什么大的进展，大家都在摸索怎么去翻译，大家都无从下手，我也着急啊??，这个时候要感谢社区的热心成员：龙翔，?，他把他老婆Claire拉到我们翻译计划里面来了，?，这个翻译的事情总算有了转机，Claire在翻译项目的管理这块很专业?，提出了很多建设性意见，✍️，我们成立了一个翻译小组委员会，?，然后形成了5个翻译小组，?，每个小组由一个小组长来负责（大家积极踊跃）：
A组：薛杰；
B组：骆朗；
C组：彭秋源；
D组：饶琛琳；
E组：魏喆；
这样，几十个翻译志愿者分别分到了不同的翻译小组，然后以翻译小组为单位进行翻译计划的分配和认领，任务也比较具体，小组成员再内部进行协调，有问题大家一起讨论，小组内部内也可以讨论，然后翻译就开始顺利的进行了！?
所以在这里要特别感谢龙翔两口子和几位翻译小组的小组长，当然还有各组的小组成员，如果没有你们，翻译工作估计要到进行到猴年马月啦，?，大家官网上面现在也看不到这些中文的资料啦！?
顺便值得一提的是，同时期还有另外一个开源社区也在翻译权威指南（韩文），并且比我们早开始，然后我们在去年12月份的时候就完成了，赶在Elastic{ON}DevChina大会之前完成的，而现在我们的已经上线了，也不知道他们的完成了没有，?。
权威指南的原作者Clinton和Zachary听说了我们的翻译的事情，都很兴奋，本来打算要来中国参加Elastic{ON}DevChina大会的，不过很遗憾，因为种种原因都没能过来，不过他们很支持我们，帮忙解决了后面上线的很多技术细节。
相信很多人想了解具体是怎么做的，我再给大家具体介绍一下，任务的管理和分配，我们使用GoogleDocs来进行协助，大家都有修改权限，常见的术语和FAQ也都会放在里面。
链接：[url=https://docs.google.com/spreadsheets/d/1vzPqcYJfz6ouY053E6WUdvS9WR8XqcHPyB7_U-72b_Q/edit?pref=2&pli=1#gid=1600884528]https://docs.google.com/spread ... 84528[/url]
另外关于本书翻译的项目管理，我们直接使用的是GitHub（https://github.com/elasticsear ... guide ），以asciidoc源文件为最小提交单元，每翻译完成一个文件，提交一个PR，每个PR单独Review，每个PR正常需要两个同学Review确认，正常的GitHub操作流程，和提交代码一样（文档其实本来也是和代码一样），翻译完成一篇之后，提交一个PR，打上标签“to be review”，表示翻译完了可以被Review了，Reviewer如果认可了就留言"LGTM", 然后打上标签“To be merged”，如果有不同意见，可以在PR上面留言讨论，PR提交人可以结合意见探讨或者修改，有些PR可以要讨论和修改很多次，比如这个：[url=https://github.com/elasticsearch-cn/elasticsearch-definitive-guide/pull/4]https://github.com/elasticsear ... ull/4[/url]，真的是不厌其烦，截止目前为止，总共提交了470多个翻译相关的PR。
为什么要以Asciidoc源文件作为翻译的基础，而不是gitdoc、wiki、markdown等等呢，因为我们可以保证后续的样式和官网一致，翻译审核完成之后就能够直接的放到官网上面，以提供给更多的人去访问和学习，同时官方的docs工具链也很完善，也支持编译输出成各种格式，如PDF等。另外文档和英文格式保持一致且也是托管在GitHub上面，方便后续的更新和维护，现在权威指南英文版正在更新到最新，到时候我们可以很方便的检测变化然后同步更新，文档即源码，文档是开源重要的一部分，参与开源的方式其实也有很多种，贡献代码和贡献文档都是同等重要的啦。可持续性更新也很重要。
是不是权威指南翻译完了之后就结束了呢，答案是：NO！
文档和代码一样，也有Bug，也要不断完善，虽然我们在提交翻译和Review的过程中有反复进行过修改和进行过多轮的Review，（先是小组内部进行第一轮Review，打上标签“To be final review”，然后再由另外一个组的同学进行Review，然后在打上“To be merge”），但是由于大家水平有限，难免会出现各种翻译不准确、格式、表达等问题，所有希望大家能够继续帮忙改进，可以继续提交PR来完善修改，如果说嫌麻烦，可以发Issue说明哪里有问题或者觉得可以再讨论的地方，提供建设性意见。
后续也会有新的翻译，也希望大家踊跃参加，为Elastic中文的社区贡献力量。
一直想写这篇文章，今天终于完成啦！
最后来一张上次来参加Elastic{ON}DevChina的译者合影！
继续阅读 »
https://www.elastic.co/guide/cn/index.html
撒花~ ???????????????????
我想给大家分享一些这本书后面的故事：
大家在浏览到前言章节里面有一节“鸣谢”，里面可以看到很多熟悉的名字：
薛杰，骆朗，彭秋源，魏喆，饶琛琳， 风虎，路小磊，michealzh，nodexy，sdlyjzh，落英流离， sunyonggang，Singham，烧碱，龙翔，陈思，陈华， 追风侃侃，Geolem，卷发，kfypmqqw，袁伟强，yichao， 小彬，leo，tangmisi，Alex，baifan，Evan，fanyer， wwb，瑞星，刘碧琴，walker，songgl， 吕兵，东，杜宁，秦东亮，biyuhao，刘刚， yumo，王秀文，zcola，gitqh，blackoon，David，韩炳辰， 韩陆，echolihao，Xargin，abel-sun，卞顺强， bsll，冬狼，王琦，Medcl。
是的，这些就是我们权威指南的核心的译者了，虽然只是列了一个名字，但是其实背后付出了很多，有一些同学是在此之前就已经做过部分翻译的同学，如：路小磊，有一些是早就出版了多本书的资深作家了，如：饶琛琳，还有很多是社区里面一直就非常活跃的同学，各种线上线下活动都能看到你们的身影，感谢你们。
记得去年刚刚开始这个翻译的计划的时候，短短几天时间就收到了很多同学的报名，一下子累积人数多达80人，
正所谓人多就是力量，不过任务的分配和管理也就成了一个问题，要知道权威指南纸质版有650多页，
很厚的一本书，内容也真是非常多。我记得项目应该是3月份启动，到了5月份还没什么大的进展，大家都在摸索怎么去翻译，大家都无从下手，我也着急啊??，这个时候要感谢社区的热心成员：龙翔，?，他把他老婆Claire拉到我们翻译计划里面来了，?，这个翻译的事情总算有了转机，Claire在翻译项目的管理这块很专业?，提出了很多建设性意见，✍️，我们成立了一个翻译小组委员会，?，然后形成了5个翻译小组，?，每个小组由一个小组长来负责（大家积极踊跃）：
A组：薛杰；
B组：骆朗；
C组：彭秋源；
D组：饶琛琳；
E组：魏喆；
这样，几十个翻译志愿者分别分到了不同的翻译小组，然后以翻译小组为单位进行翻译计划的分配和认领，任务也比较具体，小组成员再内部进行协调，有问题大家一起讨论，小组内部内也可以讨论，然后翻译就开始顺利的进行了！?
所以在这里要特别感谢龙翔两口子和几位翻译小组的小组长，当然还有各组的小组成员，如果没有你们，翻译工作估计要到进行到猴年马月啦，?，大家官网上面现在也看不到这些中文的资料啦！?
顺便值得一提的是，同时期还有另外一个开源社区也在翻译权威指南（韩文），并且比我们早开始，然后我们在去年12月份的时候就完成了，赶在Elastic{ON}DevChina大会之前完成的，而现在我们的已经上线了，也不知道他们的完成了没有，?。
权威指南的原作者Clinton和Zachary听说了我们的翻译的事情，都很兴奋，本来打算要来中国参加Elastic{ON}DevChina大会的，不过很遗憾，因为种种原因都没能过来，不过他们很支持我们，帮忙解决了后面上线的很多技术细节。
相信很多人想了解具体是怎么做的，我再给大家具体介绍一下，任务的管理和分配，我们使用GoogleDocs来进行协助，大家都有修改权限，常见的术语和FAQ也都会放在里面。
链接：[url=https://docs.google.com/spreadsheets/d/1vzPqcYJfz6ouY053E6WUdvS9WR8XqcHPyB7_U-72b_Q/edit?pref=2&pli=1#gid=1600884528]https://docs.google.com/spread ... 84528[/url]
另外关于本书翻译的项目管理，我们直接使用的是GitHub（https://github.com/elasticsear ... guide ），以asciidoc源文件为最小提交单元，每翻译完成一个文件，提交一个PR，每个PR单独Review，每个PR正常需要两个同学Review确认，正常的GitHub操作流程，和提交代码一样（文档其实本来也是和代码一样），翻译完成一篇之后，提交一个PR，打上标签“to be review”，表示翻译完了可以被Review了，Reviewer如果认可了就留言"LGTM", 然后打上标签“To be merged”，如果有不同意见，可以在PR上面留言讨论，PR提交人可以结合意见探讨或者修改，有些PR可以要讨论和修改很多次，比如这个：[url=https://github.com/elasticsearch-cn/elasticsearch-definitive-guide/pull/4]https://github.com/elasticsear ... ull/4[/url]，真的是不厌其烦，截止目前为止，总共提交了470多个翻译相关的PR。
为什么要以Asciidoc源文件作为翻译的基础，而不是gitdoc、wiki、markdown等等呢，因为我们可以保证后续的样式和官网一致，翻译审核完成之后就能够直接的放到官网上面，以提供给更多的人去访问和学习，同时官方的docs工具链也很完善，也支持编译输出成各种格式，如PDF等。另外文档和英文格式保持一致且也是托管在GitHub上面，方便后续的更新和维护，现在权威指南英文版正在更新到最新，到时候我们可以很方便的检测变化然后同步更新，文档即源码，文档是开源重要的一部分，参与开源的方式其实也有很多种，贡献代码和贡献文档都是同等重要的啦。可持续性更新也很重要。
是不是权威指南翻译完了之后就结束了呢，答案是：NO！
文档和代码一样，也有Bug，也要不断完善，虽然我们在提交翻译和Review的过程中有反复进行过修改和进行过多轮的Review，（先是小组内部进行第一轮Review，打上标签“To be final review”，然后再由另外一个组的同学进行Review，然后在打上“To be merge”），但是由于大家水平有限，难免会出现各种翻译不准确、格式、表达等问题，所有希望大家能够继续帮忙改进，可以继续提交PR来完善修改，如果说嫌麻烦，可以发Issue说明哪里有问题或者觉得可以再讨论的地方，提供建设性意见。
后续也会有新的翻译，也希望大家踊跃参加，为Elastic中文的社区贡献力量。
一直想写这篇文章，今天终于完成啦！
最后来一张上次来参加Elastic{ON}DevChina的译者合影！
去年我们社区一起翻译了一本书《Elasticsearch权威指南》，并且已经在官方上线了，链接：
https://www.elastic.co/guide/cn/index.html
撒花~ ???????????????????
我想给大家分享一些这本书后面的故事：
大家在浏览到前言章节里面有一节“鸣谢”，里面可以看到很多熟悉的名字：
薛杰，骆朗，彭秋源，魏喆，饶琛琳， 风虎，路小磊，michealzh，nodexy，sdlyjzh，落英流离， sunyonggang，Singham，烧碱，龙翔，陈思，陈华， 追风侃侃，Geolem，卷发，kfypmqqw，袁伟强，yichao， 小彬，leo，tangmisi，Alex，baifan，Evan，fanyer， wwb，瑞星，刘碧琴，walker，songgl， 吕兵，东，杜宁，秦东亮，biyuhao，刘刚， yumo，王秀文，zcola，gitqh，blackoon，David，韩炳辰， 韩陆，echolihao，Xargin，abel-sun，卞顺强， bsll，冬狼，王琦，Medcl。
是的，这些就是我们权威指南的核心的译者了，虽然只是列了一个名字，但是其实背后付出了很多，有一些同学是在此之前就已经做过部分翻译的同学，如：路小磊，有一些是早就出版了多本书的资深作家了，如：饶琛琳，还有很多是社区里面一直就非常活跃的同学，各种线上线下活动都能看到你们的身影，感谢你们。
记得去年刚刚开始这个翻译的计划的时候，短短几天时间就收到了很多同学的报名，一下子累积人数多达80人，
正所谓人多就是力量，不过任务的分配和管理也就成了一个问题，要知道权威指南纸质版有650多页，
很厚的一本书，内容也真是非常多。我记得项目应该是3月份启动，到了5月份还没什么大的进展，大家都在摸索怎么去翻译，大家都无从下手，我也着急啊??，这个时候要感谢社区的热心成员：龙翔，?，他把他老婆Claire拉到我们翻译计划里面来了，?，这个翻译的事情总算有了转机，Claire在翻译项目的管理这块很专业?，提出了很多建设性意见，✍️，我们成立了一个翻译小组委员会，?，然后形成了5个翻译小组，?，每个小组由一个小组长来负责（大家积极踊跃）：
A组：薛杰；
B组：骆朗；
C组：彭秋源；
D组：饶琛琳；
E组：魏喆；
这样，几十个翻译志愿者分别分到了不同的翻译小组，然后以翻译小组为单位进行翻译计划的分配和认领，任务也比较具体，小组成员再内部进行协调，有问题大家一起讨论，小组内部内也可以讨论，然后翻译就开始顺利的进行了！?
所以在这里要特别感谢龙翔两口子和几位翻译小组的小组长，当然还有各组的小组成员，如果没有你们，翻译工作估计要到进行到猴年马月啦，?，大家官网上面现在也看不到这些中文的资料啦！?
顺便值得一提的是，同时期还有另外一个开源社区也在翻译权威指南（韩文），并且比我们早开始，然后我们在去年12月份的时候就完成了，赶在Elastic{ON}DevChina大会之前完成的，而现在我们的已经上线了，也不知道他们的完成了没有，?。
权威指南的原作者Clinton和Zachary听说了我们的翻译的事情，都很兴奋，本来打算要来中国参加Elastic{ON}DevChina大会的，不过很遗憾，因为种种原因都没能过来，不过他们很支持我们，帮忙解决了后面上线的很多技术细节。
相信很多人想了解具体是怎么做的，我再给大家具体介绍一下，任务的管理和分配，我们使用GoogleDocs来进行协助，大家都有修改权限，常见的术语和FAQ也都会放在里面。
链接：[url=https://docs.google.com/spreadsheets/d/1vzPqcYJfz6ouY053E6WUdvS9WR8XqcHPyB7_U-72b_Q/edit?pref=2&pli=1#gid=1600884528]https://docs.google.com/spread ... 84528[/url]
另外关于本书翻译的项目管理，我们直接使用的是GitHub（https://github.com/elasticsear ... guide ），以asciidoc源文件为最小提交单元，每翻译完成一个文件，提交一个PR，每个PR单独Review，每个PR正常需要两个同学Review确认，正常的GitHub操作流程，和提交代码一样（文档其实本来也是和代码一样），翻译完成一篇之后，提交一个PR，打上标签“to be review”，表示翻译完了可以被Review了，Reviewer如果认可了就留言"LGTM", 然后打上标签“To be merged”，如果有不同意见，可以在PR上面留言讨论，PR提交人可以结合意见探讨或者修改，有些PR可以要讨论和修改很多次，比如这个：[url=https://github.com/elasticsearch-cn/elasticsearch-definitive-guide/pull/4]https://github.com/elasticsear ... ull/4[/url]，真的是不厌其烦，截止目前为止，总共提交了470多个翻译相关的PR。
为什么要以Asciidoc源文件作为翻译的基础，而不是gitdoc、wiki、markdown等等呢，因为我们可以保证后续的样式和官网一致，翻译审核完成之后就能够直接的放到官网上面，以提供给更多的人去访问和学习，同时官方的docs工具链也很完善，也支持编译输出成各种格式，如PDF等。另外文档和英文格式保持一致且也是托管在GitHub上面，方便后续的更新和维护，现在权威指南英文版正在更新到最新，到时候我们可以很方便的检测变化然后同步更新，文档即源码，文档是开源重要的一部分，参与开源的方式其实也有很多种，贡献代码和贡献文档都是同等重要的啦。可持续性更新也很重要。
是不是权威指南翻译完了之后就结束了呢，答案是：NO！
文档和代码一样，也有Bug，也要不断完善，虽然我们在提交翻译和Review的过程中有反复进行过修改和进行过多轮的Review，（先是小组内部进行第一轮Review，打上标签“To be final review”，然后再由另外一个组的同学进行Review，然后在打上“To be merge”），但是由于大家水平有限，难免会出现各种翻译不准确、格式、表达等问题，所有希望大家能够继续帮忙改进，可以继续提交PR来完善修改，如果说嫌麻烦，可以发Issue说明哪里有问题或者觉得可以再讨论的地方，提供建设性意见。
后续也会有新的翻译，也希望大家踊跃参加，为Elastic中文的社区贡献力量。
一直想写这篇文章，今天终于完成啦！
最后来一张上次来参加Elastic{ON}DevChina的译者合影！
收起阅读 »
https://www.elastic.co/guide/cn/index.html
撒花~ ???????????????????
我想给大家分享一些这本书后面的故事：
大家在浏览到前言章节里面有一节“鸣谢”，里面可以看到很多熟悉的名字：
薛杰，骆朗，彭秋源，魏喆，饶琛琳， 风虎，路小磊，michealzh，nodexy，sdlyjzh，落英流离， sunyonggang，Singham，烧碱，龙翔，陈思，陈华， 追风侃侃，Geolem，卷发，kfypmqqw，袁伟强，yichao， 小彬，leo，tangmisi，Alex，baifan，Evan，fanyer， wwb，瑞星，刘碧琴，walker，songgl， 吕兵，东，杜宁，秦东亮，biyuhao，刘刚， yumo，王秀文，zcola，gitqh，blackoon，David，韩炳辰， 韩陆，echolihao，Xargin，abel-sun，卞顺强， bsll，冬狼，王琦，Medcl。
是的，这些就是我们权威指南的核心的译者了，虽然只是列了一个名字，但是其实背后付出了很多，有一些同学是在此之前就已经做过部分翻译的同学，如：路小磊，有一些是早就出版了多本书的资深作家了，如：饶琛琳，还有很多是社区里面一直就非常活跃的同学，各种线上线下活动都能看到你们的身影，感谢你们。
记得去年刚刚开始这个翻译的计划的时候，短短几天时间就收到了很多同学的报名，一下子累积人数多达80人，
正所谓人多就是力量，不过任务的分配和管理也就成了一个问题，要知道权威指南纸质版有650多页，
很厚的一本书，内容也真是非常多。我记得项目应该是3月份启动，到了5月份还没什么大的进展，大家都在摸索怎么去翻译，大家都无从下手，我也着急啊??，这个时候要感谢社区的热心成员：龙翔，?，他把他老婆Claire拉到我们翻译计划里面来了，?，这个翻译的事情总算有了转机，Claire在翻译项目的管理这块很专业?，提出了很多建设性意见，✍️，我们成立了一个翻译小组委员会，?，然后形成了5个翻译小组，?，每个小组由一个小组长来负责（大家积极踊跃）：
A组：薛杰；
B组：骆朗；
C组：彭秋源；
D组：饶琛琳；
E组：魏喆；
这样，几十个翻译志愿者分别分到了不同的翻译小组，然后以翻译小组为单位进行翻译计划的分配和认领，任务也比较具体，小组成员再内部进行协调，有问题大家一起讨论，小组内部内也可以讨论，然后翻译就开始顺利的进行了！?
所以在这里要特别感谢龙翔两口子和几位翻译小组的小组长，当然还有各组的小组成员，如果没有你们，翻译工作估计要到进行到猴年马月啦，?，大家官网上面现在也看不到这些中文的资料啦！?
顺便值得一提的是，同时期还有另外一个开源社区也在翻译权威指南（韩文），并且比我们早开始，然后我们在去年12月份的时候就完成了，赶在Elastic{ON}DevChina大会之前完成的，而现在我们的已经上线了，也不知道他们的完成了没有，?。
权威指南的原作者Clinton和Zachary听说了我们的翻译的事情，都很兴奋，本来打算要来中国参加Elastic{ON}DevChina大会的，不过很遗憾，因为种种原因都没能过来，不过他们很支持我们，帮忙解决了后面上线的很多技术细节。
相信很多人想了解具体是怎么做的，我再给大家具体介绍一下，任务的管理和分配，我们使用GoogleDocs来进行协助，大家都有修改权限，常见的术语和FAQ也都会放在里面。
链接：[url=https://docs.google.com/spreadsheets/d/1vzPqcYJfz6ouY053E6WUdvS9WR8XqcHPyB7_U-72b_Q/edit?pref=2&pli=1#gid=1600884528]https://docs.google.com/spread ... 84528[/url]
另外关于本书翻译的项目管理，我们直接使用的是GitHub（https://github.com/elasticsear ... guide ），以asciidoc源文件为最小提交单元，每翻译完成一个文件，提交一个PR，每个PR单独Review，每个PR正常需要两个同学Review确认，正常的GitHub操作流程，和提交代码一样（文档其实本来也是和代码一样），翻译完成一篇之后，提交一个PR，打上标签“to be review”，表示翻译完了可以被Review了，Reviewer如果认可了就留言"LGTM", 然后打上标签“To be merged”，如果有不同意见，可以在PR上面留言讨论，PR提交人可以结合意见探讨或者修改，有些PR可以要讨论和修改很多次，比如这个：[url=https://github.com/elasticsearch-cn/elasticsearch-definitive-guide/pull/4]https://github.com/elasticsear ... ull/4[/url]，真的是不厌其烦，截止目前为止，总共提交了470多个翻译相关的PR。
为什么要以Asciidoc源文件作为翻译的基础，而不是gitdoc、wiki、markdown等等呢，因为我们可以保证后续的样式和官网一致，翻译审核完成之后就能够直接的放到官网上面，以提供给更多的人去访问和学习，同时官方的docs工具链也很完善，也支持编译输出成各种格式，如PDF等。另外文档和英文格式保持一致且也是托管在GitHub上面，方便后续的更新和维护，现在权威指南英文版正在更新到最新，到时候我们可以很方便的检测变化然后同步更新，文档即源码，文档是开源重要的一部分，参与开源的方式其实也有很多种，贡献代码和贡献文档都是同等重要的啦。可持续性更新也很重要。
是不是权威指南翻译完了之后就结束了呢，答案是：NO！
文档和代码一样，也有Bug，也要不断完善，虽然我们在提交翻译和Review的过程中有反复进行过修改和进行过多轮的Review，（先是小组内部进行第一轮Review，打上标签“To be final review”，然后再由另外一个组的同学进行Review，然后在打上“To be merge”），但是由于大家水平有限，难免会出现各种翻译不准确、格式、表达等问题，所有希望大家能够继续帮忙改进，可以继续提交PR来完善修改，如果说嫌麻烦，可以发Issue说明哪里有问题或者觉得可以再讨论的地方，提供建设性意见。
后续也会有新的翻译，也希望大家踊跃参加，为Elastic中文的社区贡献力量。
一直想写这篇文章，今天终于完成啦！
最后来一张上次来参加Elastic{ON}DevChina的译者合影！
收起阅读 »
写了个深入详解Elasticsearch专栏，欢迎大家品鉴！
1、深入详解Elasticearch：http://blog.csdn.net/column/de ... .html
2、这个专栏，起初主要用来研究关系型数据mysql/oracle非关系型数据库mongo与Elaticsearch的实时同步问题，随着延伸和项目需要，还会路线拓展ES java开发等问题；
3、之前的研究都是基于Elasticsearch2.3.4版本。基础原理想通。 5.X，6.X版本后续也会跟进。
欢迎大家品鉴，多提不足！
终生学习者：铭毅天下，博客地址：http://blog.csdn.net/laoyang360
1、深入详解Elasticearch：http://blog.csdn.net/column/de ... .html
2、这个专栏，起初主要用来研究关系型数据mysql/oracle非关系型数据库mongo与Elaticsearch的实时同步问题，随着延伸和项目需要，还会路线拓展ES java开发等问题；
3、之前的研究都是基于Elasticsearch2.3.4版本。基础原理想通。 5.X，6.X版本后续也会跟进。
欢迎大家品鉴，多提不足！
终生学习者：铭毅天下，博客地址：http://blog.csdn.net/laoyang360 收起阅读 »
laoyang360 发表于 : 2017-05-28 14:19
评论 (2)
java招聘
职位描述：
岗位描述：
1、负责商城网站的设计、开发工作，制定和落实解决方案。
2、 保证平台的稳定性，并不断提升平台性能，协助解决系统中的问题和技术难题。
任职资格：
1、对高并发、多线程、缓存等技术和业务场景有实际操作经验；
2、JAVA基础扎实，对于中间件、SOA框架等原理有一定理解；
3、熟悉Linux下的常用操作，熟悉MySQL、Redis、MongoDB、elasticsearch、等开源数据库；
4、熟悉互联网产品架构，有大型分布式、高并发、高负载、高可用性系统设计开发经验者优先。
5、强烈的责任心与主动性，对所负责工作有owner意识，并能自我驱动成长；
在这里：
有最前沿技术的最佳实践场景：golang，nginx+lua，java，redis，docker，hadoop，storm，机器学习、elasticsearch。
有高并发，分布式，大数据挖掘的业务场景。
我们将为你提供跟身边大牛接触学习的机会。
我们将为你提供一个开放的技术环境，一个自由高效的团队，和一个改变现有技术的机会。
分享、自由、协作是我们的处事法则。
福利：
弹性工作时间，巨大的发展空间。
年假，双休，法定节假日。
六险一金，补充商业保险，丰厚的餐补，全面保障。
绝对竞争力的薪资及年终奖金，股票激励机制。
伴随公司发展的升职机会，及每年两次的调薪机会。
继续阅读 »
岗位描述：
1、负责商城网站的设计、开发工作，制定和落实解决方案。
2、 保证平台的稳定性，并不断提升平台性能，协助解决系统中的问题和技术难题。
任职资格：
1、对高并发、多线程、缓存等技术和业务场景有实际操作经验；
2、JAVA基础扎实，对于中间件、SOA框架等原理有一定理解；
3、熟悉Linux下的常用操作，熟悉MySQL、Redis、MongoDB、elasticsearch、等开源数据库；
4、熟悉互联网产品架构，有大型分布式、高并发、高负载、高可用性系统设计开发经验者优先。
5、强烈的责任心与主动性，对所负责工作有owner意识，并能自我驱动成长；
在这里：
有最前沿技术的最佳实践场景：golang，nginx+lua，java，redis，docker，hadoop，storm，机器学习、elasticsearch。
有高并发，分布式，大数据挖掘的业务场景。
我们将为你提供跟身边大牛接触学习的机会。
我们将为你提供一个开放的技术环境，一个自由高效的团队，和一个改变现有技术的机会。
分享、自由、协作是我们的处事法则。
福利：
弹性工作时间，巨大的发展空间。
年假，双休，法定节假日。
六险一金，补充商业保险，丰厚的餐补，全面保障。
绝对竞争力的薪资及年终奖金，股票激励机制。
伴随公司发展的升职机会，及每年两次的调薪机会。
职位描述：
岗位描述：
1、负责商城网站的设计、开发工作，制定和落实解决方案。
2、 保证平台的稳定性，并不断提升平台性能，协助解决系统中的问题和技术难题。
任职资格：
1、对高并发、多线程、缓存等技术和业务场景有实际操作经验；
2、JAVA基础扎实，对于中间件、SOA框架等原理有一定理解；
3、熟悉Linux下的常用操作，熟悉MySQL、Redis、MongoDB、elasticsearch、等开源数据库；
4、熟悉互联网产品架构，有大型分布式、高并发、高负载、高可用性系统设计开发经验者优先。
5、强烈的责任心与主动性，对所负责工作有owner意识，并能自我驱动成长；
在这里：
有最前沿技术的最佳实践场景：golang，nginx+lua，java，redis，docker，hadoop，storm，机器学习、elasticsearch。
有高并发，分布式，大数据挖掘的业务场景。
我们将为你提供跟身边大牛接触学习的机会。
我们将为你提供一个开放的技术环境，一个自由高效的团队，和一个改变现有技术的机会。
分享、自由、协作是我们的处事法则。
福利：
弹性工作时间，巨大的发展空间。
年假，双休，法定节假日。
六险一金，补充商业保险，丰厚的餐补，全面保障。
绝对竞争力的薪资及年终奖金，股票激励机制。
伴随公司发展的升职机会，及每年两次的调薪机会。 收起阅读 »
岗位描述：
1、负责商城网站的设计、开发工作，制定和落实解决方案。
2、 保证平台的稳定性，并不断提升平台性能，协助解决系统中的问题和技术难题。
任职资格：
1、对高并发、多线程、缓存等技术和业务场景有实际操作经验；
2、JAVA基础扎实，对于中间件、SOA框架等原理有一定理解；
3、熟悉Linux下的常用操作，熟悉MySQL、Redis、MongoDB、elasticsearch、等开源数据库；
4、熟悉互联网产品架构，有大型分布式、高并发、高负载、高可用性系统设计开发经验者优先。
5、强烈的责任心与主动性，对所负责工作有owner意识，并能自我驱动成长；
在这里：
有最前沿技术的最佳实践场景：golang，nginx+lua，java，redis，docker，hadoop，storm，机器学习、elasticsearch。
有高并发，分布式，大数据挖掘的业务场景。
我们将为你提供跟身边大牛接触学习的机会。
我们将为你提供一个开放的技术环境，一个自由高效的团队，和一个改变现有技术的机会。
分享、自由、协作是我们的处事法则。
福利：
弹性工作时间，巨大的发展空间。
年假，双休，法定节假日。
六险一金，补充商业保险，丰厚的餐补，全面保障。
绝对竞争力的薪资及年终奖金，股票激励机制。
伴随公司发展的升职机会，及每年两次的调薪机会。 收起阅读 »
Grok Debugger 国内镜像
Grok 是一个常用的对日志进行结构化的一个工具，
可以通过在线工具进行调试：
http://grokdebug.herokuapp.com
http://grokconstructor.appspot.com
不过有时候比较慢，甚至不能访问，所以现在为大家搭好了一个国内的镜像，方便使用：
http://grok.elasticsearch.cn/
目前还是英文，源码fork至：https://github.com/elasticsear ... uctor
欢迎提交PR来进行翻译。
PS:
1. Kibana后续将提供Grok Debug的功能；
2.如果你的日志每一行都遵循固定格式，你可以考虑使用 dissect filter，性能更强更简单。
继续阅读 »
可以通过在线工具进行调试：
http://grokdebug.herokuapp.com
http://grokconstructor.appspot.com
不过有时候比较慢，甚至不能访问，所以现在为大家搭好了一个国内的镜像，方便使用：
http://grok.elasticsearch.cn/
目前还是英文，源码fork至：https://github.com/elasticsear ... uctor
欢迎提交PR来进行翻译。
PS:
1. Kibana后续将提供Grok Debug的功能；
2.如果你的日志每一行都遵循固定格式，你可以考虑使用 dissect filter，性能更强更简单。
Grok 是一个常用的对日志进行结构化的一个工具，
可以通过在线工具进行调试：
http://grokdebug.herokuapp.com
http://grokconstructor.appspot.com
不过有时候比较慢，甚至不能访问，所以现在为大家搭好了一个国内的镜像，方便使用：
http://grok.elasticsearch.cn/
目前还是英文，源码fork至：https://github.com/elasticsear ... uctor
欢迎提交PR来进行翻译。
PS:
1. Kibana后续将提供Grok Debug的功能；
2.如果你的日志每一行都遵循固定格式，你可以考虑使用 dissect filter，性能更强更简单。 收起阅读 »
可以通过在线工具进行调试：
http://grokdebug.herokuapp.com
http://grokconstructor.appspot.com
不过有时候比较慢，甚至不能访问，所以现在为大家搭好了一个国内的镜像，方便使用：
http://grok.elasticsearch.cn/
目前还是英文，源码fork至：https://github.com/elasticsear ... uctor
欢迎提交PR来进行翻译。
PS:
1. Kibana后续将提供Grok Debug的功能；
2.如果你的日志每一行都遵循固定格式，你可以考虑使用 dissect filter，性能更强更简单。 收起阅读 »
GZIP造成JAVA Native Memory泄漏案例
[携程旅行网 吴晓刚]
近期公司某个线上JAVA应用出现内存泄漏问题，整个排查过程颇费周折，前后耗费了近2周才定位到问题根源并予以修复。排查问题过程中在网上翻查了大量的资料，发现国内几乎没有文章能对同类问题做透彻的分析和找到问题真正根源的。即使国外的各类博客和文章，也少有正确的分析。因此感觉有必要对问题根源和相关案例做一个总结，希望能为国内开发者避免踩上同类陷阱提供一些帮助。
开门见山，先列一下收集到的同类问题案例集：
这些案例涉及到的不乏一些流行的开源软件如Lucene, Elasticsearch, Kafka，并且某些Bug版本在大量公司有线上部署。这些案例的问题根源都惊人的一致，即在JAVA里使用GZIP库进行数据流的压缩/解压之后，忘记调用流的close()方法，从而造成native memory的泄漏。
关于这类问题的分析方法和工具，上面收集的案例集里有非常详尽的描述，这里就不再班门弄斧一一赘述了。只结合我们自己的案例，做一个比较简短的介绍和总结。
我们公司这个案例的排查之所以花了近2个礼拜，其中一个重要原因是这个应用是通过Docker部署的。应用上线运行一段时间后，会被Docker的OOM killer给Kill掉，查看JVM监控数据却发现Heap使用得很少，甚至都没有old GC发生过，top里看这个JAVA进程的RSS内存占用远高于分配的Heap大小。很自然的，研发人员第一反应是底层系统的问题，注意力被转移到研究各种Docker内存相关的参数上。 而我知道ElasticCloud曾经也被某些版本的linux内核bug困扰，docker可能会误杀JVM (参见 Memory Issues We'll Remember)，bug的内核版本和docker版本和我们线上部署的又很接近，因此这个内核bug也被加入到了怀疑列表中。 事后证明这个方向是错误的，浪费了一些时间。
在一段时间排查无果后，为了缩小排查范围，我们决定将这个应用部署到VM上做对比测试。结果内存泄漏问题依然存在，因而排除掉了Linux内核和docker本身的问题。
同期也参考过一篇关于DirectByteByffer造成堆外内存泄漏问题的分析博客，JVM源码分析之堆外内存完全解读 ，考虑到问题现象和我们类似，我们的应用也有用到netty，DBB泄漏也被列为怀疑对象。然而在JVM启动里参数里对MaxDirectMemorySize做了限制后，经过一段时间对外服务，JAVA进程的RSS仍然会远超过HEAP + MDM设置的大小。
这期间我们也使用过NMT 工具分析HEAP内存占用情况，然而这个工具报告出来的内存远小于RSS，也就是说这多出来的内存并没有被JVM本身用到，泄漏的是native memory。 JAVA应用产生native memory泄漏通常是在使用某些native库时造成的，因此注意力转移到JNI。
最终帮助我们找到正确方向的是开头列的 Debugging Java Native Memory Leaks 这篇由Twitter工程师写的博客。 博客里介绍了如何使用jemalloc来替换glibc的malloc，通过拦截和追踪JVM对native memory的分配申请，从而可以分析出HEAP以外的内存分配由哪些方法调用产生的。博客里提到产生泄漏的原因是忘记关闭GZIPOutputStream，巧合的是我们线上应用也使用了gzip压缩服务请求数据，于是查看了一下相关的代码，果然发现有忘记关闭的stream。 找到根源后，解决问题就简单了，一行代码修复。
对于ElasticSearch用户，要注意的是某些版本存在这个泄漏问题，对于小内存机器上运行的ES服务可能会有较大的影响。 可是官方没有明确列出所有受影响的版本，只在博客里提到5.2.1修复了这些问题。 因此如果你有顾虑的话，可以用top命令看一下ES JAVA进程的RSS消耗，如果大大于分配的HEAP，有可能就是中招啦。
继续阅读 »
近期公司某个线上JAVA应用出现内存泄漏问题，整个排查过程颇费周折，前后耗费了近2周才定位到问题根源并予以修复。排查问题过程中在网上翻查了大量的资料，发现国内几乎没有文章能对同类问题做透彻的分析和找到问题真正根源的。即使国外的各类博客和文章，也少有正确的分析。因此感觉有必要对问题根源和相关案例做一个总结，希望能为国内开发者避免踩上同类陷阱提供一些帮助。
开门见山，先列一下收集到的同类问题案例集：
- Debugging Java Native Memory Leaks
- Tracking Down Native Memory Leaks in Elasticsearch
- CompressingStoredFieldsFormat should reclaim memory more aggressively
- Close InputStream when receiving cluster state in PublishClusterStateAction
- Kafka OOM During Log Recovery Due to Leaked Native Memory
这些案例涉及到的不乏一些流行的开源软件如Lucene, Elasticsearch, Kafka，并且某些Bug版本在大量公司有线上部署。这些案例的问题根源都惊人的一致，即在JAVA里使用GZIP库进行数据流的压缩/解压之后，忘记调用流的close()方法，从而造成native memory的泄漏。
关于这类问题的分析方法和工具，上面收集的案例集里有非常详尽的描述，这里就不再班门弄斧一一赘述了。只结合我们自己的案例，做一个比较简短的介绍和总结。
我们公司这个案例的排查之所以花了近2个礼拜，其中一个重要原因是这个应用是通过Docker部署的。应用上线运行一段时间后，会被Docker的OOM killer给Kill掉，查看JVM监控数据却发现Heap使用得很少，甚至都没有old GC发生过，top里看这个JAVA进程的RSS内存占用远高于分配的Heap大小。很自然的，研发人员第一反应是底层系统的问题，注意力被转移到研究各种Docker内存相关的参数上。 而我知道ElasticCloud曾经也被某些版本的linux内核bug困扰，docker可能会误杀JVM (参见 Memory Issues We'll Remember)，bug的内核版本和docker版本和我们线上部署的又很接近，因此这个内核bug也被加入到了怀疑列表中。 事后证明这个方向是错误的，浪费了一些时间。
在一段时间排查无果后，为了缩小排查范围，我们决定将这个应用部署到VM上做对比测试。结果内存泄漏问题依然存在，因而排除掉了Linux内核和docker本身的问题。
同期也参考过一篇关于DirectByteByffer造成堆外内存泄漏问题的分析博客，JVM源码分析之堆外内存完全解读 ，考虑到问题现象和我们类似，我们的应用也有用到netty，DBB泄漏也被列为怀疑对象。然而在JVM启动里参数里对MaxDirectMemorySize做了限制后，经过一段时间对外服务，JAVA进程的RSS仍然会远超过HEAP + MDM设置的大小。
这期间我们也使用过NMT 工具分析HEAP内存占用情况，然而这个工具报告出来的内存远小于RSS，也就是说这多出来的内存并没有被JVM本身用到，泄漏的是native memory。 JAVA应用产生native memory泄漏通常是在使用某些native库时造成的，因此注意力转移到JNI。
最终帮助我们找到正确方向的是开头列的 Debugging Java Native Memory Leaks 这篇由Twitter工程师写的博客。 博客里介绍了如何使用jemalloc来替换glibc的malloc，通过拦截和追踪JVM对native memory的分配申请，从而可以分析出HEAP以外的内存分配由哪些方法调用产生的。博客里提到产生泄漏的原因是忘记关闭GZIPOutputStream，巧合的是我们线上应用也使用了gzip压缩服务请求数据，于是查看了一下相关的代码，果然发现有忘记关闭的stream。 找到根源后，解决问题就简单了，一行代码修复。
对于ElasticSearch用户，要注意的是某些版本存在这个泄漏问题，对于小内存机器上运行的ES服务可能会有较大的影响。 可是官方没有明确列出所有受影响的版本，只在博客里提到5.2.1修复了这些问题。 因此如果你有顾虑的话，可以用top命令看一下ES JAVA进程的RSS消耗，如果大大于分配的HEAP，有可能就是中招啦。
[携程旅行网 吴晓刚]
近期公司某个线上JAVA应用出现内存泄漏问题，整个排查过程颇费周折，前后耗费了近2周才定位到问题根源并予以修复。排查问题过程中在网上翻查了大量的资料，发现国内几乎没有文章能对同类问题做透彻的分析和找到问题真正根源的。即使国外的各类博客和文章，也少有正确的分析。因此感觉有必要对问题根源和相关案例做一个总结，希望能为国内开发者避免踩上同类陷阱提供一些帮助。
开门见山，先列一下收集到的同类问题案例集：
这些案例涉及到的不乏一些流行的开源软件如Lucene, Elasticsearch, Kafka，并且某些Bug版本在大量公司有线上部署。这些案例的问题根源都惊人的一致，即在JAVA里使用GZIP库进行数据流的压缩/解压之后，忘记调用流的close()方法，从而造成native memory的泄漏。
关于这类问题的分析方法和工具，上面收集的案例集里有非常详尽的描述，这里就不再班门弄斧一一赘述了。只结合我们自己的案例，做一个比较简短的介绍和总结。
我们公司这个案例的排查之所以花了近2个礼拜，其中一个重要原因是这个应用是通过Docker部署的。应用上线运行一段时间后，会被Docker的OOM killer给Kill掉，查看JVM监控数据却发现Heap使用得很少，甚至都没有old GC发生过，top里看这个JAVA进程的RSS内存占用远高于分配的Heap大小。很自然的，研发人员第一反应是底层系统的问题，注意力被转移到研究各种Docker内存相关的参数上。 而我知道ElasticCloud曾经也被某些版本的linux内核bug困扰，docker可能会误杀JVM (参见 Memory Issues We'll Remember)，bug的内核版本和docker版本和我们线上部署的又很接近，因此这个内核bug也被加入到了怀疑列表中。 事后证明这个方向是错误的，浪费了一些时间。
在一段时间排查无果后，为了缩小排查范围，我们决定将这个应用部署到VM上做对比测试。结果内存泄漏问题依然存在，因而排除掉了Linux内核和docker本身的问题。
同期也参考过一篇关于DirectByteByffer造成堆外内存泄漏问题的分析博客，JVM源码分析之堆外内存完全解读 ，考虑到问题现象和我们类似，我们的应用也有用到netty，DBB泄漏也被列为怀疑对象。然而在JVM启动里参数里对MaxDirectMemorySize做了限制后，经过一段时间对外服务，JAVA进程的RSS仍然会远超过HEAP + MDM设置的大小。
这期间我们也使用过NMT 工具分析HEAP内存占用情况，然而这个工具报告出来的内存远小于RSS，也就是说这多出来的内存并没有被JVM本身用到，泄漏的是native memory。 JAVA应用产生native memory泄漏通常是在使用某些native库时造成的，因此注意力转移到JNI。
最终帮助我们找到正确方向的是开头列的 Debugging Java Native Memory Leaks 这篇由Twitter工程师写的博客。 博客里介绍了如何使用jemalloc来替换glibc的malloc，通过拦截和追踪JVM对native memory的分配申请，从而可以分析出HEAP以外的内存分配由哪些方法调用产生的。博客里提到产生泄漏的原因是忘记关闭GZIPOutputStream，巧合的是我们线上应用也使用了gzip压缩服务请求数据，于是查看了一下相关的代码，果然发现有忘记关闭的stream。 找到根源后，解决问题就简单了，一行代码修复。
对于ElasticSearch用户，要注意的是某些版本存在这个泄漏问题，对于小内存机器上运行的ES服务可能会有较大的影响。 可是官方没有明确列出所有受影响的版本，只在博客里提到5.2.1修复了这些问题。 因此如果你有顾虑的话，可以用top命令看一下ES JAVA进程的RSS消耗，如果大大于分配的HEAP，有可能就是中招啦。 收起阅读 »
近期公司某个线上JAVA应用出现内存泄漏问题，整个排查过程颇费周折，前后耗费了近2周才定位到问题根源并予以修复。排查问题过程中在网上翻查了大量的资料，发现国内几乎没有文章能对同类问题做透彻的分析和找到问题真正根源的。即使国外的各类博客和文章，也少有正确的分析。因此感觉有必要对问题根源和相关案例做一个总结，希望能为国内开发者避免踩上同类陷阱提供一些帮助。
开门见山，先列一下收集到的同类问题案例集：
- Debugging Java Native Memory Leaks
- Tracking Down Native Memory Leaks in Elasticsearch
- CompressingStoredFieldsFormat should reclaim memory more aggressively
- Close InputStream when receiving cluster state in PublishClusterStateAction
- Kafka OOM During Log Recovery Due to Leaked Native Memory
这些案例涉及到的不乏一些流行的开源软件如Lucene, Elasticsearch, Kafka，并且某些Bug版本在大量公司有线上部署。这些案例的问题根源都惊人的一致，即在JAVA里使用GZIP库进行数据流的压缩/解压之后，忘记调用流的close()方法，从而造成native memory的泄漏。
关于这类问题的分析方法和工具，上面收集的案例集里有非常详尽的描述，这里就不再班门弄斧一一赘述了。只结合我们自己的案例，做一个比较简短的介绍和总结。
我们公司这个案例的排查之所以花了近2个礼拜，其中一个重要原因是这个应用是通过Docker部署的。应用上线运行一段时间后，会被Docker的OOM killer给Kill掉，查看JVM监控数据却发现Heap使用得很少，甚至都没有old GC发生过，top里看这个JAVA进程的RSS内存占用远高于分配的Heap大小。很自然的，研发人员第一反应是底层系统的问题，注意力被转移到研究各种Docker内存相关的参数上。 而我知道ElasticCloud曾经也被某些版本的linux内核bug困扰，docker可能会误杀JVM (参见 Memory Issues We'll Remember)，bug的内核版本和docker版本和我们线上部署的又很接近，因此这个内核bug也被加入到了怀疑列表中。 事后证明这个方向是错误的，浪费了一些时间。
在一段时间排查无果后，为了缩小排查范围，我们决定将这个应用部署到VM上做对比测试。结果内存泄漏问题依然存在，因而排除掉了Linux内核和docker本身的问题。
同期也参考过一篇关于DirectByteByffer造成堆外内存泄漏问题的分析博客，JVM源码分析之堆外内存完全解读 ，考虑到问题现象和我们类似，我们的应用也有用到netty，DBB泄漏也被列为怀疑对象。然而在JVM启动里参数里对MaxDirectMemorySize做了限制后，经过一段时间对外服务，JAVA进程的RSS仍然会远超过HEAP + MDM设置的大小。
这期间我们也使用过NMT 工具分析HEAP内存占用情况，然而这个工具报告出来的内存远小于RSS，也就是说这多出来的内存并没有被JVM本身用到，泄漏的是native memory。 JAVA应用产生native memory泄漏通常是在使用某些native库时造成的，因此注意力转移到JNI。
最终帮助我们找到正确方向的是开头列的 Debugging Java Native Memory Leaks 这篇由Twitter工程师写的博客。 博客里介绍了如何使用jemalloc来替换glibc的malloc，通过拦截和追踪JVM对native memory的分配申请，从而可以分析出HEAP以外的内存分配由哪些方法调用产生的。博客里提到产生泄漏的原因是忘记关闭GZIPOutputStream，巧合的是我们线上应用也使用了gzip压缩服务请求数据，于是查看了一下相关的代码，果然发现有忘记关闭的stream。 找到根源后，解决问题就简单了，一行代码修复。
对于ElasticSearch用户，要注意的是某些版本存在这个泄漏问题，对于小内存机器上运行的ES服务可能会有较大的影响。 可是官方没有明确列出所有受影响的版本，只在博客里提到5.2.1修复了这些问题。 因此如果你有顾虑的话，可以用top命令看一下ES JAVA进程的RSS消耗，如果大大于分配的HEAP，有可能就是中招啦。 收起阅读 »
kennywu76 发表于 : 2017-05-24 12:33
评论 (10)
招聘 Elastic search 培训师/项目经理 20k +
Elastic search 服务供应商需要招聘培训师/项目经理
薪酬： 月工资20k +
工作地点：北京/上海/深圳 愿意出差，因工作情况会全国飞
任职要求：
1、计算机相关专业，本科以上学历，具有3年以上搜索引擎及相关开发经验；
2、较强的java编程基础，熟悉Git代码管理，有多分支并行开发经验；
3、熟练使用开源搜索工具Logstash，ElasticSearch，熟悉其原理和源代码，能熟练的修改开源工具以适合业务场景的需求；
4、熟悉Lucene以及Kibana，有实际的产品使用经历；
5、具有良好的沟通能力和责任心。
继续阅读 »
薪酬： 月工资20k +
工作地点：北京/上海/深圳 愿意出差，因工作情况会全国飞
任职要求：
1、计算机相关专业，本科以上学历，具有3年以上搜索引擎及相关开发经验；
2、较强的java编程基础，熟悉Git代码管理，有多分支并行开发经验；
3、熟练使用开源搜索工具Logstash，ElasticSearch，熟悉其原理和源代码，能熟练的修改开源工具以适合业务场景的需求；
4、熟悉Lucene以及Kibana，有实际的产品使用经历；
5、具有良好的沟通能力和责任心。
Elastic search 服务供应商需要招聘培训师/项目经理
薪酬： 月工资20k +
工作地点：北京/上海/深圳 愿意出差，因工作情况会全国飞
任职要求：
1、计算机相关专业，本科以上学历，具有3年以上搜索引擎及相关开发经验；
2、较强的java编程基础，熟悉Git代码管理，有多分支并行开发经验；
3、熟练使用开源搜索工具Logstash，ElasticSearch，熟悉其原理和源代码，能熟练的修改开源工具以适合业务场景的需求；
4、熟悉Lucene以及Kibana，有实际的产品使用经历；
5、具有良好的沟通能力和责任心。
收起阅读 »
薪酬： 月工资20k +
工作地点：北京/上海/深圳 愿意出差，因工作情况会全国飞
任职要求：
1、计算机相关专业，本科以上学历，具有3年以上搜索引擎及相关开发经验；
2、较强的java编程基础，熟悉Git代码管理，有多分支并行开发经验；
3、熟练使用开源搜索工具Logstash，ElasticSearch，熟悉其原理和源代码，能熟练的修改开源工具以适合业务场景的需求；
4、熟悉Lucene以及Kibana，有实际的产品使用经历；
5、具有良好的沟通能力和责任心。
收起阅读 »
oniza 发表于 : 2017-05-19 11:52
评论 (0)
