要不要也来分享分享一下啊

Day 17 - 关于日志型数据管理策略的思考

kennywu76 发表了文章 • 7 个评论 • 5564 次浏览 • 2018-12-17 11:19 • 来自相关话题

近两年随着Elastic Stack的愈发火热,其近乎成为构建实时日志应用的工业标准。在小型数据应用场景,最新的6.5版本已经可以做到开箱即用,无需过多考虑架构上的设计工作。 然而一旦应用规模扩大到数百TB甚至PB的数据量级,整个系统的架构和后期维护工作则显得非常重要。借着2018 Elastic Advent写文的机会,结合过去几年架构和运维公司日志集群的实践经验,对于大规模日志型数据的管理策略,在此做一个总结性的思考。 文中抛出的观点,有些已经在我们的集群中有所应用并取得比较好的效果,有些则还待实践的检验。抛砖引玉,不尽成熟的地方,还请社区各位专家指正。

对于日志系统,最终用户通常有以下几个基本要求:

  1. 数据从产生到可检索的实时性要求高,可接受的延迟通常要求控制在数秒,至多不超过数十秒
  2. 新鲜数据(当天至过去几天)的查询和统计频率高,返回速度要快(毫秒级,至多几秒)
  3. 历史数据保留得越久越好。

    针对这些需求,加上对成本控制的必要性,大家通常想到的第一个架构设计就是冷热数据分离。

    冷热数据分离

    冷热分离的概念比较好理解,热结点做数据的写入,保存近期热数据,冷数据定期迁移到冷数据结点,就这么简单。不过实际操作起来可能还是碰到一些具体需要考虑的细节问题。

  4. 冷热结点集群配置的JVM heap配置要差异化。热结点无需存放太多数据,对于heap的要求通常不是太高,在够用的情况下尽量配置小一点。可以配置在26GB左右甚至更小,而不是大多数人知道的经验值31GB。原因在于这个size的heap,可以启用zero based Compressed Oops,JVM运行效率是最高的, 参考: [heap-size](https://www.elastic.co/guide/e ... e.html)。而冷结点存在的目的是尽量放更多的数据,性能不是首要的,因此heap可以配置在31GB。
  5. 数据迁移过程有一定资源消耗,为避免对数据写入产生显著影响,通常定时在业务低峰期,日志产出量比较低的时候进行,比如半夜。
  6. 索引是否应该启用压缩,如何启用?最初我们对于热结点上的索引是不启用压缩的,为了节省CPU消耗。只在冷结点配置里,增加了索引压缩选项。这样索引迁移到冷结点后,执行force merge操作的时候,ES会自动将结点上配置的索引压缩属性套用到merge过后新生成的segment,这样就实现了热结点不压缩,冷结点merge过后压缩的功能。极大节省了冷结点的磁盘空间。后来随着硬件的升级,我们发现服务器的cpu基本都是过剩的,磁盘IO通常先到瓶颈。 因此尝试在热结点上一开始创建索引的时候,就启用压缩选项。实际对比测试并没有发现显著的索引吞吐量下降,并且因为索引压缩后磁盘文件size的大幅减少,每天夜间的数据迁移工作可以节省大量的时间。至此我们的日志集群索引默认就是压缩的。
  7. 冷结点上留做系统缓存的内存一般不多,加上数据量非常巨大。索引默认的mmapfs读取方式,很容易因为系统缓存不够,导致数据在内存和磁盘之间频繁换入换出。严重的情况下,整个结点甚至会因为io持续在100%无法响应。 实践中我们发现对冷结点使用niofs效果会更好。

    实现了冷热结点分离以后,集群的资源利用率提升了不少,可管理性也要好很多了. 但是随着接入日志的类型越来越多(我们生产上有差不多400种类型的日志),各种日志的速率差异又很大,让ES自己管理shard的分布很容易产生写入热点问题。 针对这个问题,可以采用对集群结点进行分组管理的策略来解决。

    热结点分组管理

    所谓分组管理,就是通过在结点的配置文件中增加自定义的标签属性,将服务器区分到不同的组别中。然后通过设置索引的index.routing.allocation.include属性,控制改索引分布在哪个组别。同时配合设置index.routing.allocation.total_shards_per_node,可以做到某个索引的shard在某个group的结点之间绝对均匀分布。

    比如一个分组有10台机器,对一个5 primary ,1 replica的索引,让该索引分布在该分组的同时,设置total_shards_per_node为1,让每个节点上只能有一个分片,这样就避免了写入热点问题。 该方案的缺陷也显而易见,一旦有结点挂掉,不会自动recovery,某个shard将一直处于unassigned状态,集群状态变成yellow。 但我认为,热数据的恢复开销是非常高的,与其立即在其他结点开始复制,之后再重新rebalance,不如就让集群暂时处于yellow状态。 通过监控报警的手段,及时通知运维人员解决结点故障。 待故障解决之后,直接从恢复后的结点开始数据复制,开销要低得多。

    在我们的生产环境主要有两种类型的结点分组,分别是10台机器一个分组,和2台机器一个分组。10台机器的分组用于应对速率非常高,shard划分比较多的索引,2台机器的分组用于速率很低,一个shard(加一个复制片)就可以应对的索引。

    这种分组策略在我们的生产环境中经过验证,非常好的解决了写入热点问题。那么冷数据怎么管理? 冷数据不做写入,不存在写入热点问题,查询频率也比较低,业务需求方面对查询响应要求也不那么严苛,所以查询热点问题也不是那么突出。因此为了简化管理,冷结点我们是不做shard分布的精细控制,所有数据迁移到冷数据结点之后,由ES默认的shard分布则略去控制数据的分布。

    不过如果想进一步提高冷数据结点服务器资源的利用率,还是可以有进一步挖掘的的空间。我们知道ES默认的shard分布策略,只是保证一个索引的shard尽量分布在不同的结点,同时保证每个节点上shard数量差不多。但是如果采用默认按天创建索引的策略,由于索引速率差异很大,不同索引之间shard的大小差异可能是1-2个数量级的。如果每个shard的size差异不大就好了,那么默认的分布策略,基本上可以保证冷结点之间数据量分布的大致均匀。 能实现类似功能的是ES的rollover特性。

    索引的Rollover

    Rollover api可以让索引根据预先定义的时间跨度,或者索引大小来自动切分出新索引,从而将索引的大小控制在计划的范围内。合理的应用rollver api可以保证集群shard大小差别不会太大。 只是集群索引类别比较多的时候,rollover全部手动管理负担比较大,需要借助额外的管理工具和监控工具。我们出于管理简便的考虑,暂时没有应用到这个特性。

    索引的Rollup

    我们发现生产有些用户写入的“日志”,实际上是多维的metrcis数据,使用的时候不是为了查询日志的详情,仅仅是为了做各种维度组合的过滤和聚合。对于这种类型的数据,保留历史数据过多一来浪费存储空间,二来每次聚合都要在裸数据上跑,非常浪费资源。 ES从6.3开始,在x-pack里推出了rollup api,通过定期对裸数据做预先聚合,大大缩减了保存在磁盘上的数据量。对于不需要查询裸日志的应用场景,合理应用该特性,可以将历史数据的磁盘消耗降低几个数量级,同时rollup search也可以大大提升聚合速度。不过rollup也有其局限性,即他的实现是通过定期任务,对间隔期数据跑聚合完成的,有一定的计算开销。 如果数据写入速率非常高,集群压力很大,rollup可能无法跟上写入速率,而不具有实用性。 所以实际环境中,还是需要根据应用场景和资源使用情况,进行灵活的取舍。

    多集群的便利性

    数据量大到一定程度以后,单集群由于master node单点的限制,会遇到各种集群状态数据更新时得性能问题。 由此现在一些大规模的应用已经开始利用到多集群互联和cross cluster search的特性。 这种结构除了解决单集群数据容量限制问题以外,我们还发现在做容量均衡方面还有比较好的便利性。应用日志写入量通常随着业务变化也会剧烈变化,好不容易规划好的容量,不久就被业务的增长给打破,数倍或者数10倍的流量增长很可能就让一组结点过载出现写入延迟。 如果只有一个集群,在结点之间重新平衡shard比较费力,涉及到数据的迁移,可能非常缓慢,还会影响写入。 但如果有多集群互联,切换就可以做到非常的快速和简单。 原理上只需要在新集群中加入对应的索引配置模版,然后更新写入程序的配置,写入目标指向新集群,重启写入程序即可。并且,可以进一步将整个流程工具化,在GUI上完成一键切换。

es没有写入,监控发现有bulk的任务?

fanmo3yuan 回复了问题 • 3 人关注 • 2 个回复 • 1859 次浏览 • 2018-12-17 11:03 • 来自相关话题

请问一下大家,elasticsqech 在进行大数据聚合时直接报错,请问怎么请理,跪谢

God_lockin 回复了问题 • 3 人关注 • 1 个回复 • 1749 次浏览 • 2018-12-16 21:09 • 来自相关话题

es每次get都把内存吃爆了。。。

huigy 回复了问题 • 7 人关注 • 7 个回复 • 3731 次浏览 • 2018-12-15 15:05 • 来自相关话题

用go-mysql-elasticsearch同步mysql数据到es5.5.0的时候,字符串怎么转日期

bellengao 回复了问题 • 2 人关注 • 1 个回复 • 2473 次浏览 • 2018-12-15 11:05 • 来自相关话题

怎么设置es的单个字段的长度,最大可以设置为多长

bellengao 回复了问题 • 2 人关注 • 1 个回复 • 4362 次浏览 • 2018-12-15 10:53 • 来自相关话题

status 503

bellengao 回复了问题 • 2 人关注 • 1 个回复 • 2199 次浏览 • 2018-12-15 10:43 • 来自相关话题

Day 15 - 基于海量公司分词ES中文分词插件

novia 发表了文章 • 0 个评论 • 6830 次浏览 • 2018-12-15 10:35 • 来自相关话题

介绍


本次想和大家分享一款Elasticsearch分词插件,该插件是基于天津海量信息股份有限公司的中文分词核心开发的。海量分词针对大数据检索场景专门做了定制和优化,更贴近搜索需求,整体分词的性能也是非常高效。

本文章有广告成分。但希望将公司研究成果分享出来,给大家实际工作中多一种选择...

海量分词检索优化点


  • 地名方面海量分词5.0可以识别并检索出关于地名后缀的结果

    可以通过搜索“河南”得到“河南省”的结果,搜索“天津”得到“天津市”的搜索结果,而不是简单河南、天津的识别。

  • 著名人物的人名识别更精准,如刘翔、傅莹等

    部分分词器处理中文分词只有两种方式:一种是单字(unigrams)形式,即简单粗暴的将中文的每一个汉字作为一个词(token)分开;另一种是两字(bigrams)的,也就是任意相邻的两个汉字作为一个词分开。这种简单粗暴的切分方式无法实现时效性较新的人名识别,如刘翔、傅莹等会被识别为单字切开。

  • 外国人名识别方面海量可以将人名识别智能识别

    “玛利亚 凯利”、“乔治·史密斯”、“玛丽·戴维斯”将完整的外国人名识别出姓氏和名,如“乔治·史密斯”可以被识别为“乔治”和 “史密斯”。

  • 常见词的品牌名称识别方面,海量分词5.0识别的结果中包含实际意义的品牌名称

    如“乐高”,“吉米作为简单的词,可以被识别,但是词放在文档语境中有其品牌的属性,海量分词识别的结果中可以准确搜索出品牌的结果。

  • 机构名识别方面

    海量分词5.0可以识别完整的机构名称,如“天津海量信息技术股份有限公司”,可以完整的识别出全称。

    海量分词性能评测


    评测用例


    本次评测选取的语料一共三个。一个是2MB的海量测试语料,一个是4MB的北大语料(新版旧版各2MB),一个是9.4GB海量的线上实际数据

    评测指标


    本次评测是在开源评测程序上修改而来,评测指标有分词速度、行数完美率、字数完美率(该指标仅供参考)、内存消耗

    评测结果


    2MB海量测试语料


    | 分词器 | 分词模式 | 分词速度(字符/毫秒) | 行数完美率 | 字数完美率 | 占用内存(MB) |
    | -------- | -------- | ----------- | ------ | ------ | -------- |
    | 海量 | / | 1049.0212 | 74.11% | 65.97% | 85 |
    | ltp | / | 33.748833 | 55.68% | 45.23% | 201 |
    | IctClass | 普通分词 | 208.69612 | 48.77% | 37.10% | 51 |
    | IctClass | 细粒度分词 | 691.5951 | 38.33% | 27.95% | 51 |
    | Jieba | SEARCH分词 | 592.697 | 47.64% | 36.25% | 236 |
    | FudanNLP | / | 121.7537 | 42.99% | 31.59% | 99 |
    | HanLP | 标准分词 | 212.74121 | 45.30% | 34.00% | 63 |
    | HanLP | NLP分词 | 378.23676 | 44.09% | 32.55% | 71 |
    | HanLP | N-最短路径分词 | 189.29959 | 44.19% | 32.22% | 60 |
    | HanLP | 最短路径分词 | 415.63605 | 43.19% | 31.28% | 59 |
    | HanLP | 极速词典分词 | 6735.1934 | 36.78% | 25.10% | 18 |
    | THULAC | / | 0.20857348 | 54.49% | 43.79% | 110 |
    | Stanford | CTB | 0.13520464 | 44.43% | 33.25% | 1101 |
    | Stanford | PKU | 0.12508623 | 45.15% | 34.01% | 1065 |

    可以看到海量分词的行数完美率是最高的,而且速度十分优异;仅有的一个比海量分词速度快的算法是一个追求极限性能舍弃准确率的算法

    4MB北大语料


    | 词器 | 分词模式 | 分词速度(字符/毫秒) | 行数完美率 | 字数完美率 | 占用内存(MB) |
    | -------- | -------- | ----------- | ------ | ------ | -------- |
    | 海量 | / | 1121.7269 | 85.94% | 48.28% | 85 |
    | ltp | / | 35.81329 | 87.37% | 49.37% | 201 |
    | IctClass | 普通分词 | 226.11554 | 78.55% | 42.04% | 51 |
    | IctClass | 细粒度分词 | 756.5135 | 59.06% | 30.61% | 51 |
    | Jieba | SEARCH分词 | 957.52826 | 47.07% | 20.01% | 236 |
    | FudanNLP | / | 126.09879 | 58.54% | 27.78% | 99 |
    | HanLP | 标准分词 | 369.66 | 65.46% | 35.04% | 63 |
    | HanLP | NLP分词 | 439.75632 | 61.93% | 31.37% | 71 |
    | HanLP | N-最短路径分词 | 223.30482 | 69.20% | 35.07% | 60 |
    | HanLP | 最短路径分词 | 440.72244 | 67.74% | 33.83% | 59 |
    | HanLP | 极速词典分词 | 7522.581 | 58.09% | 27.82% | 18 |

    (注:THULAC和stanford由于速度问题,不纳入评测)

    可以看到海量的速度和行数完美率都很优异而且达到了兼顾,行数完美率只落后更高的ltp算法1.4个百分点,速度却是它的三十多倍

    9.4GB线上数据


    | 分词器 | 分词模式 | 分词速度(字符/毫秒) |
    | -------- | -------- | ----------- |
    | ltp | / | 33.592 |
    | 海量 | / | 960.611 |
    | IctClass | 普通分词 | 198.094 |
    | HanLP | N-最短路径分词 | 201.735 |
    | HanLP | 最短路径分词 | 425.482 |
    | HanLP | 标准分词 | 473.400 |
    | HanLP | NLP分词 | 361.842 |
    | IctClass | 细粒度分词 | 689.183 |
    | FudanNLP | / | 120.860 |
    | HanLP | 极速词典分词 | 6238.916 |
    | Jieba | SEARCH分词 | 568.262 |

    (注:THULAC和stanford由于速度问题,不纳入评测)

    本表格中分词顺序按(4MB北大语料的)行数完美率进行排序,越靠前的(4MB北大语料的)行数完美率越高

    可以看出海量的分词速度十分优秀,分词速度拉开了大多数分词数倍,相比于行数完美率小幅领先的ltp要快几十倍

    海量分词插件使用方法


    安装使用


  • 下载安装 - 地址: https://github.com/HylandaOpen ... eases

    <br /> unzip plugin to folder `your-es-root/plugins/`<br />

  • 使用 elasticsearch-plugin 安装

    <br /> ./bin/elasticsearch-plugin install <a href="https://github.com/HylandaOpen/elasticsearch-analysis-hlseg/releases/download/v6.4.2/elasticsearch-analysis-hlseg-6.4.2.zip" rel="nofollow" target="_blank">https://github.com/HylandaOpen ... 2.zip</a><br />

  • 重启es集群

    实例(借用github-ik分词插件的实例)


    1.创建index

    bash<br /> curl -XPUT <a href="http://localhost:9200/hylanda_seg" rel="nofollow" target="_blank">http://localhost:9200/hylanda_seg</a><br />

    2.配置mapping

    bash<br /> curl -XPOST <a href="http://localhost:9200/hylanda_seg/data/_mapping" rel="nofollow" target="_blank">http://localhost:9200/hylanda_seg/data/_mapping</a> -H 'Content-Type:application/json' -d'<br /> {<br /> "properties": {<br /> "msg": {<br /> "type": "text",<br /> "analyzer": "hlseg_search"<br /> }<br /> }<br /> }'<br />

    3.插入测试数据

    bash<br /> curl -XPOST <a href="http://localhost:9200/hylanda_seg/data/1" rel="nofollow" target="_blank">http://localhost:9200/hylanda_seg/data/1</a> -H 'Content-Type:application/json' -d'<br /> {"content":"美国留给伊拉克的是个烂摊子吗"}<br /> '<br />

    bash<br /> curl -XPOST <a href="http://localhost:9200/hylanda_seg/data/2" rel="nofollow" target="_blank">http://localhost:9200/hylanda_seg/data/2</a> -H 'Content-Type:application/json' -d'<br /> {"content":"公安部:各地校车将享最高路权"}<br /> '<br />

    bash<br /> curl -XPOST <a href="http://localhost:9200/hylanda_seg/data/3" rel="nofollow" target="_blank">http://localhost:9200/hylanda_seg/data/3</a> -H 'Content-Type:application/json' -d'<br /> {"content":"中韩渔警冲突调查:韩警平均每天扣1艘中国渔船"}<br /> '<br />

    bash<br /> curl -XPOST <a href="http://localhost:9200/hylanda_seg/data/4" rel="nofollow" target="_blank">http://localhost:9200/hylanda_seg/data/4</a> -H 'Content-Type:application/json' -d'<br /> {"content":"中国驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首"}<br /> '<br />

    4.查询

    bash<br /> curl -XPOST <a href="http://localhost:9200/hylanda_seg/data/_search" rel="nofollow" target="_blank">http://localhost:9200/hylanda_seg/data/_search</a> -H 'Content-Type:application/json' -d'<br /> {<br /> "query": {<br /> "match": {<br /> "content": "中国"<br /> }<br /> },<br /> "highlight": {<br /> "fields": {<br /> "content": {}<br /> }<br /> }<br /> }<br /> '<br />

    返回结果

    json<br /> {<br /> "took" : 11,<br /> "timed_out" : false,<br /> "_shards" : {<br /> "total" : 5,<br /> "successful" : 5,<br /> "skipped" : 0,<br /> "failed" : 0<br /> },<br /> "hits" : {<br /> "total" : 2,<br /> "max_score" : 0.5754429,<br /> "hits" : [<br /> {<br /> "_index" : "hylanda_seg",<br /> "_type" : "data",<br /> "_id" : "4",<br /> "_score" : 0.5754429,<br /> "_source" : {<br /> "content" : "中韩渔警冲突调查:韩警平均每天扣1艘中国渔船"<br /> },<br /> "highlight" : {<br /> "content" : [<br /> "中韩渔警冲突调查:韩警平均每天扣1艘<em>中国</em>渔船"<br /> ]<br /> }<br /> },<br /> {<br /> "_index" : "hylanda_seg",<br /> "_type" : "data",<br /> "_id" : "5",<br /> "_score" : 0.2876821,<br /> "_source" : {<br /> "content" : "中国驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首"<br /> },<br /> "highlight" : {<br /> "content" : [<br /> "<em>中国</em>驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首"<br /> ]<br /> }<br /> }<br /> ]<br /> }<br /> }<br />

    字典配置


    <br /> 海量分词分为基础词词典CoreDict.dat和自定义词典userDict_utf8.txt。基础词词典在dictionary目录下,需要将CoreDict.zip解压后放在config目录下,可以通过修改config下的userDict_utf8.txt来更新自定义词典<br />

    自定义词典格式如下

    ---

    <br /> 1.用户自定义词典采用文本格式,utf-8编码,每行一个词<br /> <br /> 2.每个词包含三列属性,分别是词串、词的属性以及idf值的加权等级,并以Tab作为分隔,其中除了词串必填外,其他列可以不填,不填写则系统采用默认值<br /> <br /> 3.“#”表示注释,会在加载时被忽略<br /> <br /> 4.词的属性以西文逗号分隔,可以是词性、停止词标志或者自定义属性<br /> <br /> 5.词性标记参考北大标准,用于词性标注时参考,该项不填则默认为名词<br /> <br /> 6.停止词标志为:stopword,由SegOption.outputStopWord来控制是否输出停止词<br /> <br /> 7.自定义属性不参与分词过程,分词结果中若Token.userTag不为空,则可以获取到该词的自定义属性。<br /> <br /> 8.idf值的加权分5级,从低到高的定义是idf-lv1 — idf-lv5,等级越高则该词在关键词计算时的权重会越大,若不填写该值则系统默认是idf-lv3(中等权重)<br />

ES5.6.4中数值类型的term查询类型应该是TermQuery还是PointRangeQuery

回复

zhangg7723 发起了问题 • 3 人关注 • 0 个回复 • 3558 次浏览 • 2018-12-14 17:43 • 来自相关话题

Day 14 - 订单中心基于elasticsearch 的解决方案

blogsit 发表了文章 • 3 个评论 • 13493 次浏览 • 2018-12-14 15:24 • 来自相关话题

       ElasticSearch分布式搜索储存集群的引入,主要是为了解决订单数据的存储与搜索的问题。

项目背景:
      15年去哪儿网酒店日均订单量达到30w+,随着多平台订单的聚合日均订单能达到100w左右。原来采用的热表分库方式,即将最近6个月的订单的放置在一张表中,将历史订单放在在history表中。history表存储全量的数据,当用户查询的下单时间跨度超过6个月即查询历史订单表,此分表方式热表的数据量为4000w左右,当时能解决的问题。但是显然不能满足携程艺龙订单接入的需求。如果继续按照热表方式,数据量将超过1亿条。全量数据表保存2年的可能就超过4亿的数据量。所以寻找有效途径解决此问题迫在眉睫。由于对这预计4亿的数据量还需按照预定日期、入住日期、离店日期、订单号、联系人姓名、电话、酒店名称、订单状态……等多个条件查询。所以简单按照某一个维度进行分表操作没有意义。ElasticSearch分布式搜索储存集群的引入,就是为了解决订单数据的存储与搜索的问题。

具体解决方案:

1、系统性能
        对订单模型进行抽象和分类,将常用搜索字段和基础属性字段剥离DB做分库分表。存储订单详情,ElasticSearch存储搜素字段。订单复杂查询直接走ElasticSearch。如下图:

elasticsearch1.png

       通用数据存储模型

elasticsearch2.png


关键字段
    ■ 业务核心字段,用于查询过滤
系统字段
    ■ version 避免高并发操作导致数据覆盖
大字段
    ■ order_data订单详情数据(JSON)
    ■ 可灵活需要索引的字段返回的字段

 
 
2、系统可用性
     系统可用性保障:双机房高可用如下图。

       
elasticsearch3.png

     数据可用性保障:
            一、异步多写保证数据一致性。

                
二、数据补充机制:
  1、每天凌晨task扫描数据库热表数据与es数据版本进行比较。
  2、将第三方推送过来数据中的,订单号即时插入订单同步队列表中。如果数据模型解析转换、持久化成功。删除队列中订单号。同时设置1分钟一次的task 扫描队列表。
  3、推送第三方的数据也采用同样的方式。保证给第三方数据的准确性。


elasticsearch4.png


3、系统伸缩性
      elasticSearch中索引设置了8个分片,目前Es单个索引的文档达到到1.4亿,合计达到2亿条数据占磁盘大小64G,集群机器磁盘容量240G。

 
 
 

es查询性能问题

rochy 回复了问题 • 3 人关注 • 1 个回复 • 2336 次浏览 • 2018-12-14 13:07 • 来自相关话题

elasticsearch id

rochy 回复了问题 • 2 人关注 • 1 个回复 • 4136 次浏览 • 2018-12-14 13:02 • 来自相关话题

spring-data-elasticsearch 查询部分指定字段

CatCoder 回复了问题 • 2 人关注 • 2 个回复 • 5563 次浏览 • 2018-12-14 10:16 • 来自相关话题

elasticsearch单值桶

回复

hnj1575565068 发起了问题 • 1 人关注 • 0 个回复 • 1144 次浏览 • 2018-12-14 09:46 • 来自相关话题

spring boot 2.0可以整合elasticsearch 5.4.0吗

qqq1234567 回复了问题 • 2 人关注 • 2 个回复 • 1115 次浏览 • 2018-12-13 18:20 • 来自相关话题