elaseticsearch

elaseticsearch

es添加ik分词后没有用

ElasticsearchLX123123 回复了问题 • 3 人关注 • 3 个回复 • 83 次浏览 • 2 天前 • 来自相关话题

ES segment合并频繁 求问 各位大佬 怎么限制segment合并

Elasticsearchyayg2008 回复了问题 • 3 人关注 • 3 个回复 • 80 次浏览 • 2 天前 • 来自相关话题

请问各位 非SSD 批量插入一亿条数据 大概4个G大小的文件 到ES中大概要多久

Elasticsearchyayg2008 回复了问题 • 4 人关注 • 4 个回复 • 118 次浏览 • 4 天前 • 来自相关话题

有大神用过elastalert么,救助!!!!!

回复

Elasticsearchjerrymouse 回复了问题 • 1 人关注 • 1 个回复 • 59 次浏览 • 4 天前 • 来自相关话题

es 分片均匀,但只有其中一个节点负载特别高,bulk也堆积非常多

Elasticsearchzqc0512 回复了问题 • 6 人关注 • 4 个回复 • 99 次浏览 • 4 天前 • 来自相关话题

使用Spark在cdh上执行ES插入,报错java.lang.NoSuchFieldError: INSTANCE

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 52 次浏览 • 4 天前 • 来自相关话题

kibana6.4.2版本managment下没有watcher按钮是因为付费原因么

Elasticsearchmedcl 回复了问题 • 3 人关注 • 2 个回复 • 55 次浏览 • 5 天前 • 来自相关话题

elasticsearch能否手动设置某个索引为只读状态

Elasticsearchlaoyang360 回复了问题 • 3 人关注 • 2 个回复 • 50 次浏览 • 5 天前 • 来自相关话题

对子聚合结果进行统计

Kibanazqc0512 回复了问题 • 3 人关注 • 3 个回复 • 81 次浏览 • 5 天前 • 来自相关话题

es 搜索 使用highlight 后查询效率相当慢的问题

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 118 次浏览 • 2018-10-12 14:22 • 来自相关话题

kibana升级后如何不丢失仪表盘等信息

Elasticsearchzqc0512 回复了问题 • 3 人关注 • 2 个回复 • 84 次浏览 • 2018-10-11 08:32 • 来自相关话题

ElasticSearch 可以在update_by_query中使用doc修改部分文档吗

Elasticsearchrochy 回复了问题 • 2 人关注 • 2 个回复 • 68 次浏览 • 2018-10-10 11:09 • 来自相关话题

字段类型意外的从keyword变成了text

Elasticsearchkaizhang 回复了问题 • 3 人关注 • 2 个回复 • 189 次浏览 • 2018-09-29 11:56 • 来自相关话题

如何将对象放于数组中

回复

ElasticsearchVeelur 发起了问题 • 1 人关注 • 0 个回复 • 85 次浏览 • 2018-09-27 12:04 • 来自相关话题

计算日志的时间差

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 125 次浏览 • 2018-09-26 20:26 • 来自相关话题

es添加ik分词后没有用

回复

ElasticsearchLX123123 回复了问题 • 3 人关注 • 3 个回复 • 83 次浏览 • 2 天前 • 来自相关话题

ES segment合并频繁 求问 各位大佬 怎么限制segment合并

回复

Elasticsearchyayg2008 回复了问题 • 3 人关注 • 3 个回复 • 80 次浏览 • 2 天前 • 来自相关话题

请问各位 非SSD 批量插入一亿条数据 大概4个G大小的文件 到ES中大概要多久

回复

Elasticsearchyayg2008 回复了问题 • 4 人关注 • 4 个回复 • 118 次浏览 • 4 天前 • 来自相关话题

有大神用过elastalert么,救助!!!!!

回复

Elasticsearchjerrymouse 回复了问题 • 1 人关注 • 1 个回复 • 59 次浏览 • 4 天前 • 来自相关话题

es 分片均匀,但只有其中一个节点负载特别高,bulk也堆积非常多

回复

Elasticsearchzqc0512 回复了问题 • 6 人关注 • 4 个回复 • 99 次浏览 • 4 天前 • 来自相关话题

使用Spark在cdh上执行ES插入,报错java.lang.NoSuchFieldError: INSTANCE

回复

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 52 次浏览 • 4 天前 • 来自相关话题

kibana6.4.2版本managment下没有watcher按钮是因为付费原因么

回复

Elasticsearchmedcl 回复了问题 • 3 人关注 • 2 个回复 • 55 次浏览 • 5 天前 • 来自相关话题

elasticsearch能否手动设置某个索引为只读状态

回复

Elasticsearchlaoyang360 回复了问题 • 3 人关注 • 2 个回复 • 50 次浏览 • 5 天前 • 来自相关话题

对子聚合结果进行统计

回复

Kibanazqc0512 回复了问题 • 3 人关注 • 3 个回复 • 81 次浏览 • 5 天前 • 来自相关话题

es 搜索 使用highlight 后查询效率相当慢的问题

回复

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 118 次浏览 • 2018-10-12 14:22 • 来自相关话题

kibana升级后如何不丢失仪表盘等信息

回复

Elasticsearchzqc0512 回复了问题 • 3 人关注 • 2 个回复 • 84 次浏览 • 2018-10-11 08:32 • 来自相关话题

ElasticSearch 可以在update_by_query中使用doc修改部分文档吗

回复

Elasticsearchrochy 回复了问题 • 2 人关注 • 2 个回复 • 68 次浏览 • 2018-10-10 11:09 • 来自相关话题

字段类型意外的从keyword变成了text

回复

Elasticsearchkaizhang 回复了问题 • 3 人关注 • 2 个回复 • 189 次浏览 • 2018-09-29 11:56 • 来自相关话题

如何将对象放于数组中

回复

ElasticsearchVeelur 发起了问题 • 1 人关注 • 0 个回复 • 85 次浏览 • 2018-09-27 12:04 • 来自相关话题

计算日志的时间差

回复

Elasticsearchrochy 回复了问题 • 2 人关注 • 1 个回复 • 125 次浏览 • 2018-09-26 20:26 • 来自相关话题

ES内存分配规划

Elasticsearchyayg2008 发表了文章 • 2 个评论 • 490 次浏览 • 2018-07-04 15:15 • 来自相关话题

阅读本文前,请先阅读ES内存分析。 ES默认配置下,heap是存在超卖情况的。

类目 默认占比 是否常驻 淘汰策略(在控制大小情况下) 控制参数
query cache 10% LRU indices.queries.cache.size
request cache 1% LRU indices.requests.cache.size
fielddata cache 无限制 LRU indices.fielddata.cache.size
segment memory 无限制 不能通过参数控制
common space 70% GC 通过熔断器 indices.breaker.total.limit 限制

common space(可GC)

子类目 默认占比 控制参数
indexing buffer 10% indices.memory.index_buffer_size
request agg data 60% indices.breaker.request.limit
in-flight data 100% network.breaker.inflight_requests.limit

通过上表可知,segment memory是非常重要,而且是不可通过参数干预的内存空间,而cache部分则可以提升性能,可以被清除。common space 是运行时的动态空间,可以被GC。

综上所述,需要保证segment memory+cache+common space不超过100%。由于熔断器是按整个heap大小来计算的,所以如果segment memory 过大,仍然可能会导致OOM。为了减少这种情况的发生,需要预留足够空间给segment。 优化

  1. 限制fielddata大小,fielddata是针对text类型进行排序、聚合才用到。正常应该避免这种情况发生。
  2. 限制request agg data大小,这个参数会影响聚合使用的内存,如果触发熔断,业务需要进行优化。

内存分配

                                                                                                                                                                                                                                                                                         
         
segment memory

       

         
预留10%
       
         
       
         
fielddata cache
       
         
限制在20%
       
         
       
         
query cache
       
         
限制10%
       
         
       
         
request cache
       
         
限制1%
       
         
       
         
indexing buffer
       
         
限制10%
       
         
       
         
request agg data
       
         
限制1%
       
         
父熔断器配置30%,扣除fielddata,agg剩余的就是in-flight
       
         
in-flight data
       
         
限制9%
       

参数设置

indices.fielddata.cache.size:1%--需要重启节点

PUT _cluster/settings
{
  "persistent": {
    "indices.breaker.fielddata.limit":"20%",
    "indices.breaker.request.limit":"1%",
    "indices.breaker.total.limit":"70%"

  }
}

ES内存使用分析及熔断器设置

Elasticsearchyayg2008 发表了文章 • 0 个评论 • 591 次浏览 • 2018-07-04 15:08 • 来自相关话题

内存占用

ES的JVM heap按使用场景分为可GC部分和常驻部分。 可GC部分内存会随着GC操作而被回收; 常驻部分不会被GC,通常使用LRU策略来进行淘汰; 内存占用情况如下图:

jvm.png

common space包括了indexing buffer和其他ES运行需要的class。indexing buffer由indices.memory.index_buffer_size参数控制, 默认最大占用10%,当full up后,该部分数据被刷入磁盘对应的Segments中。这部分空间是可以被回收反复利用的。

queryCache 是node级别的filter过滤器结果缓存,大小由indices.queries.cache.size 参数控制,默认10%。使用LRU淘汰策略。

requestCache是shard级别的query result缓存,通常 only requests of size 0 such as aggregations, counts and suggestions will be cached。使用LRU淘汰策略。通过indices.requests.cache.size参数控制,默认1%。设置后整个NODE都生效。

fieldDataCache,针对text字段,没有docValues属性(相当于列存储),当对text类型字段进行sort,agg时,需要将对应的字段内容全部加载到内存,这部分数据就放在fieldDataCache。通过indices.fielddata.cache.size 参数限制大小,默认不限制。这种情况下,占用内存会逐渐增多,直到触发熔断;新数据无法加载。

segmentsMemory ,缓存段信息,包括FST,Dimensional points for numeric range filters,Deleted documents bitset ,Doc values and stored fields codec formats等数据。这部分缓存是必须的,不能进行大小设置,通常跟index息息相关,close index、force merge均会释放部分空间。 可以通过命令

GET _cat/nodes?v&h=id,ip,port,r,ramPercent,ramCurrent,heapMax,heapCurrent,fielddataMemory,queryCacheMemory,requestCacheMemory,segmentsMemory

查看当前各块的使用情况。

熔断器

Elasticsearch 有一系列的断路器,它们都能保证内存不会超出限制:

  • indices.breaker.fielddata.limit fielddata 断路器默认设置堆的 60% 作为 fielddata 大小的上限。
  • indices.breaker.request.limit request 断路器估算需要完成其他请求部分的结构大小,例如创建一个聚合桶,默认限制是堆内存的 60%。它实际上是node level的一个统计值,统计的是这个结点上,各类查询聚合操作,需要申请的Bigarray的空间大小总和。 所以如果有一个聚合需要很大的空间,同时在执行的聚合可能也会被break掉。
  • indices.breaker.total.limit 父熔断,inflight、request(agg)和fielddata不会使用超过堆内存的 70%。
  • network.breaker.inflight requests.limit 限制当前通过HTTP等进来的请求使用内存不能超过Node内存的指定值。这个内存主要是限制请求内容的长度。 默认100%。
  • script.max_compilations_per_minute
  • 限制script并发执行数,默认值为15。

参考文档 https://www.elastic.co/guide/en/elasticsearch/reference/5.3/circuit-breaker.html#fielddata-circuit-breaker https://www.elastic.co/guide/cn/elasticsearch/guide/cn/_limiting_memory_usage.html http://zhengjianglong.leanote.com/post/ES%E8%AE%BE%E7%BD%AE

[杭州滨江] [PingPong 金融] 招聘 Java 高级工程师

求职招聘jeffreyji 发表了文章 • 0 个评论 • 494 次浏览 • 2018-06-26 11:49 • 来自相关话题

PingPong 金融是家极其低调又极具实力的独角兽公司,作为中国第一家获得欧洲支付牌照的民营公司,目前在跨境收款这个风口处于领先地位,公司继去年的 B 轮之后,现在又敲定 C 轮融资了。 我司已经自建 IDC 搭建大数据中心,微服务上线如火如荼,Spark, Hadoop, HBase, MongoDB, Dubbo, RocketMQ, Elasticsearch 等大公司用的技术,我们全部都有用,我们完全拥抱开源,18 年我们已经准备自研一些开源的 framework,也愿意为开源贡献力量。 我们招聘技术大牛了,先贴下公司福利: 最新版 MacBook Pro 或 Surface 随你挑 每天下午水果 + 晚上免费晚餐 每年 15 天年假 + 每月 2k 加班费 + 3 个月以上的年终 生日礼品 + 每月团建费 + 节日聚餐 + 买书报销 继续贴 JD: ============================================================ 高级 Java 工程师职位描述(薪资 25-40K): 岗位职责 1.带领团队完成产品开发,承担技术 leader 和项目经理角色; 2.负责系统后端核心 API 的编写; 3.负责公司各平台的对接工作; 4.根据业务需求合理设计和扩展; 岗位要求 1.Java 基础扎实,精通多线程、并发、集合、网络、IO 等基础知识,熟悉 Http、TCP/IP 等协议; 2.熟练使用 SpringBoot、Mybatis 等常用的框架并了解其工作原理; 3.熟悉 RocketMQ、Dubbo、Zookeeper 等开源技术的使用以及工作原理; 4.熟悉 MySql、HBase、Elasticsearch、Redis 等的运用以及原理,优秀的 SQL 编写能力以及调优能力; 5.思维清晰,能独立分析并解决遇到的问题,丰富的系统设计能力以及服务化设计能力; 6.具备良好的表达能力,善于团队合作、具备非常良好的责任心以及 Owner 意识,具备独立解决问题能力; 有意向的请发简历到邮箱: jiwg#pingpongx.com, 最后感谢各位的阅读.

关于同义词检索方案的一点实践经验

ElasticsearchJinyang Zhou 发表了文章 • 0 个评论 • 580 次浏览 • 2018-06-15 13:36 • 来自相关话题

最近一直在搞同义词搜索的问题,踩了一些坑,总结了一些经验,尤其是刚刚接触搜索和 ES,所以如果有不对的,或者不完备的地方也希望大家能提出改进意见。。。

下面是自己留下的文档记录:


需求

同义词检索也是搜索引擎必备的功能之一,例如,我们希望用户在搜索广东话的同时,也能找出和粤语有关的信息;用户在搜索苹果手机的同时,包含iPhone的内容也能被检索并呈现。

在现实生活中,相同语义的表述词汇往往有很多,而用户在检索的时候很难在一条 query 中将它们全部体现,所以识别和提供同义词检索显然可以获得更高的召回率。

需求剖析

在思考解决方案之前,我们不妨再来看看刚才提到的两个例子:

  1. 苹果手机iPhone
  2. 广东话粤语

我们先来看第一个,苹果手机iPhone

显然,这两个词是等价的,因为苹果公司发布的所有手机产品都叫 iPhone,而 iPhone 这个名字也没有被其他公司使用过。

于是,当用户搜索“苹果手机购买”的时候,我们也就有理由将它拆分成“苹果手机购买”和“iPhone购买”,分别进行检索,再将结果合并返回。


语言学中对这样的词组,称为是同义词中的相对同义词,或是等义词等义同义词。它们表达意思完全一致,在绝大多数语境中都可以相互替换,同时对上下文也不会产生影响。

这样的词组还有很多,例如:猫熊熊猫柚子文旦等等,这些等义词大抵来说有这样几种来源:

  1. 音节减缩形成:机枪机关枪坦克坦克车电扇电风扇
  2. 音译和音译形成:出租车的士维生素维他命
  3. 地域叫法不同,或新旧叫法:单车自行车脚踏车西红柿番茄马铃薯洋芋土豆黄瓜胡瓜
  4. 昵称代称:周杰伦周董
  5. 描述角度不同,学名方言差异:电脑计算机曲别针回形针

这些词组多以名词呈现,数量比较少,词组规模也较小,同时变化也很小。


接下来我们再来看第二组词:广东话粤语

广东话粤语这两个词代表的意思是相同的吗?它们也是可以相互替换的吗?

答案显然是否定的。

广东话从语义本身来说是一个比较粗糙的概念,它不仅指广东省内的粤语,还涵盖了潮汕话,客家话,雷州话等其他方言。而粤语却是一个非常严肃的概念,对语音语调都有非常详细的规定,不仅通用于广东省大部分地区,还包括广西、香港、澳门等地,甚至东南亚和北美。它们联系在于,大部分广东地区的人说的是粤语。

如此说来,给广东话粤语这样非常相似却又并不完全一致的词直接划上等号是有失偏颇的。当然,其实仔细考虑也不难发现,和广东话有相似之处却又不完全相同的词还有很多,例如:客家话广州话广府话等等。


语言学中把这样的词汇,称作是相对同义词,或是近义词。它们在意义上有一些相似之处,只能在特定的语境中进行替换。

它们的差别可能包括:

  1. 语义上:毁坏损坏(前者更严重),介绍说明(前者可以对人施加作用)
  2. 色彩上:团结勾结

对于这类相似却又不完全相同的近义词,在搜索的时候提供关联搜索是一个不错的方案。例如用户搜索“毁坏公物如何处罚”的时候,查询结果可以由90%的“损坏公物如何处罚”和10%的“毁坏公物如何处罚”查询结果合并后返回,从而获得更多的召回。

这些近义词以动词为主,不仅数量多,词组的规模也大,例如靠近的近义词可以是:靠拢逼近接近迫近等等。

解决思路

可替换的等义词问题中,我们可以直接使用 Elasticsearch 原生的 synonyms 功能来完成。虽说原生 synonyms 功能不支持热更新,而且需要将词典事先放进制定目录,不过好在这类等义词数量并不多,变化也并不大,尚且属于一劳永逸的任务。

对于不可直接替换的近义词问题,如果直接套用原生的 Synonyms 虽然可能会带来更多召回,但是查准率却骤降。

对于这类问题,我们期待的场景是,一旦发现用户 query 中的某个词有近义词,我们就将它拆分替换,成为多个 query 进行联合搜索。就像前面的例子:用户搜索“损坏公物如何处罚”的时候,查询结果可以由90%的“损坏公物如何处罚”和10%的“毁坏公物如何处罚”查询结果合并后返回。如此说来,使用 Elasticsearch 提供的 boosting_query 就成为了一个自然而然的想法。

不过稍加思考也不难发现,boosting_query 中 weight 的获得并不容易,也就是前面例子中的90%10%这组数字应该怎么设定,这也是近义词联合搜索中的重点。

先回到我们刚才的例子:当用户搜索“损坏公物如何处罚”的时候,我们本能地觉得用90%损坏10%毁坏合并在一起是“合理的”,这样的本能其实是来自于:我们主观地认为在检索“搞坏公物”这个事实的时候,90%的用户会使用毁坏来描述,10%的用户会使用损坏来描述。

简而言之,这组数字可以理解为用户群体描述同一个问题时,对词组选择的组成比例。再换个说法,也就是在当前这条 query 中,原词和近义词之间的可替换程度

再举一例,在“广东话入门”这条 query 中,从“表达学习语言”的语义上来看,广东话粤语差别并不大,这条 query 自然可以拆分成“广东话入门”和“粤语入门”,进行联合搜索,而且它们的 weight 甚至可以设置为 1:1 来获得更多合理的召回。

反过来,在“粤语歌曲推荐”这条 query 中,广东话的 weight 就需要慎重考虑,一方面是因为本身就没有“广东话歌曲”这种说法,另一方面也因为在广泛的语料中,歌曲广东话这两个词极少同时被提及。所以几遍是“粤语歌曲推荐”的拆分成分中有“广东话歌曲推荐”,weight 也需要被设置地非常低(倘若真的没有“粤语歌曲”相关的内容,推荐“广东话”的内容作为替补)。

说到这里,其实已经很明白了,语言模型是可以在这里被使用的,而语言模型的困惑度也与前面提到的 weight 一脉相承。

所以大致计算流程可以是:获得用户的query之后进行分词,在词组中寻找所有可能的同义词替换,将所有替换后的 query 分别放进语言模型中获得困惑度(或其他 metrics),依据它们来作为 boosting query 中的 weight。

graph TD;
广东话入门-->'广东话','入门';
'广东话','入门'-->_'广东话','入门'_;
'广东话','入门'-->_'粤语','入门'_;
_'广东话','入门'_-->语言模型;
_'粤语','入门'_-->语言模型;
语言模型-->PPL:0.65;
语言模型-->PPL:0.35;

对于这里语言模型的选择,可以使用传统的ngram,也可以使用双向的LSTM这样一些成熟的方案从语料中训练,也可以使用一些现成的方案:http://ai.baidu.com/tech/nlp/dnnlm_cn