话题 (elasticsearch 2.1) 已与当前话题合并
elasticsearch

elasticsearch

elasticsearch-analysis-pinyin可以用于繁体字吗?谢谢

回复

Elasticsearchweizhuang 发起了问题 • 2 人关注 • 0 个回复 • 44 次浏览 • 1 天前 • 来自相关话题

elasticsearch 分词后,还可以保留大写吗

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

关于拼音搜索,像我们这种情况怎样设计比较合理?

回复

Elasticsearchweizhuang 发起了问题 • 2 人关注 • 0 个回复 • 49 次浏览 • 1 天前 • 来自相关话题

elasticsearch之管道聚合

回复

Elasticsearchredhat 发起了问题 • 1 人关注 • 0 个回复 • 47 次浏览 • 2 天前 • 来自相关话题

Elasticsearch 之 Term Vectors

回复

Elasticsearchredhat 发起了问题 • 1 人关注 • 0 个回复 • 56 次浏览 • 2 天前 • 来自相关话题

elasticsearch升级带来的问题java api使用的问题,请牛人指教

回复

Elasticsearchgaojun1212 发起了问题 • 1 人关注 • 0 个回复 • 65 次浏览 • 2 天前 • 来自相关话题

ElasticSearch 联想词问题

ElasticsearchJinyang Zhou 回复了问题 • 8 人关注 • 4 个回复 • 2354 次浏览 • 3 天前 • 来自相关话题

elasticsearch索引数据存放在本地的哪个文件中?

默认分类strglee 回复了问题 • 2 人关注 • 1 个回复 • 38 次浏览 • 3 天前 • 来自相关话题

用curator删除定时删除索引,删除后集群不知为何又重建创建了这个索?

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

elastic search 查询问题

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

elasticsearch更新,排序

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

业务数据量与ES集群规模及配置的对应关系大致是怎样?

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

spring-data-elasticsearch 如何让es自动生成_id

回复

Elasticsearchredhat 发起了问题 • 1 人关注 • 0 个回复 • 85 次浏览 • 5 天前 • 来自相关话题

Nested 存储对象型数组,怎么筛选满足多个key对应多个value

Elasticsearchstrglee 回复了问题 • 3 人关注 • 1 个回复 • 87 次浏览 • 6 天前 • 来自相关话题

es报错Unexpected exception in the selector loop

回复

Elasticsearchccsy 发起了问题 • 2 人关注 • 0 个回复 • 82 次浏览 • 2018-06-11 15:54 • 来自相关话题

【线下活动】2018-06-30 南京Elastic Meetup日程安排

活动swordsmanli 发表了文章 • 12 个评论 • 1970 次浏览 • 2018-05-31 15:33 • 来自相关话题

Elastic Meetup 南京

主办方

Elastic中文社区、趋势科技

meetup_logo.jpg

协办方

IT 大咖说、阿里云、开源中国

itdks.jpeg
aliyun.jpg
osc.jpg

时间地点

  • 活动时间:2018年6月30日 13:00 - 18:00 

  • 活动地点:雨花区软件大道48号苏豪国际广场B座 趋势科技中国研发中心(靠花神庙地铁站)

 

 报名地址

http://elasticsearch.mikecrm.com/fUqiv0T

qr.php_.png

   名额有限,速速报名!

直播地址

IMG_2154.JPG

 

主题

分享一:Elastic 探秘之遗落的珍珠

标签:elastic stack 讲师简介:

medcl.jpg
 

曾勇(Medcl) Elastic 中国首席布道师 Elasticsearch爱好者,2015年加入Elastic,Elastic 中文社区的发起人,Elastic在中国的首位员工。

主题简介: Elastic Stack 功能越来越丰富了,有很多功能可能你只听说过名字,有很多功能也许没有机会尝试过,其实你可能错过了很多宝贝,所以让我们来探究探究,本次分享主要介绍 Elastic Stack 技术栈里面,一些可能看起来不太起眼但却非常有意思的功能,定义为非干货,尽量轻拍,不过相信对于刚接触 Elastic 的同学来说,也会有所收获。  

分享二:基于ELK的大数据分析平台实践

标签:运维、DevOps 讲师简介:

tuhaibo.jpg
 

涂海波 南京云利来有限公司 曾在亚信联创电信事业部从事计费产品工作多年,2年前加入南京云利来。

主题简介: 主题围绕Elasticsearch在集群搭建和运维过程中的使用经验,分享工作期间主要遇到的问题和解决思路,希望能够帮助大家在elasticsearch使用过程中少走一些弯路  

分享三:ElasticLog with ES in CloudEdge

标签:Ops、AWS、Log

讲师简介:

bruce_zhao.jpg

  赵伟,趋势科技CloudEdge Team 负责大数据研发,个人技术兴趣广泛,擅长系统设计与服务调优,目前专注于大数据领域。 主题简介: 作为趋势科技下一代应用安全网关产品,CloudEdge的用户规模不断增长。面对每日数亿级数据,如何实现快速处理与查询?本次演讲,主要分享CloudEdge的大数据架构,介绍如何在AWS云上构建大数据系统,如何利用Elasticsearch实现热数据查询,以及在Elasticsearch方面的诸多实践经验  

分享四:华泰证券Elasticsearch应用实践

标签:金融IT、大数据、DevOps、日志

讲师简介: 李文强,华泰证券数据平台架构师 负责Hadoop平台和Elasticsearch集群的管理、架构和部分项目管理,目前正积极研究基于k8s的人工智能平台落地方案。

主题简介: 经过几年的发展,Elasticsearch已经在华泰证券内部生根发芽,已经有不少业务都使用了Elasticsearch,其中一个非常重要的应用是日志搜索和分析系统,该系统统一收集和分析各个系统的日志,既提升运维效率,又提高运营质量。在这些实践中,我们也不断地对Elasticsearch进行调优,使其能够长期稳定运行,保障业务稳定。    

分享五:es在苏宁的实践

标签:实践,大数据,平台化

讲师简介:

韩君宝.png

  韩宝君,苏宁大数据平台  ES平台组负责人 2015年从事大数据研究工作,目前负责Elasticsearch的源码研究工作和定制化开发,对苏宁使用Elasticsearch的业务提供技术支持和解决方案。

主题简介: 本次分享大纲如下:

  1. 苏宁ES平台总体介绍,典型使用场景和规模;
  2. ES平台化之路-演进路线以及过程中我们的思考;
  3. 实战经验:遇到的问题及对应的解决方案;  

elasticsearch-analysis-pinyin可以用于繁体字吗?谢谢

回复

Elasticsearchweizhuang 发起了问题 • 2 人关注 • 0 个回复 • 44 次浏览 • 1 天前 • 来自相关话题

elasticsearch 分词后,还可以保留大写吗

回复

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

关于拼音搜索,像我们这种情况怎样设计比较合理?

回复

Elasticsearchweizhuang 发起了问题 • 2 人关注 • 0 个回复 • 49 次浏览 • 1 天前 • 来自相关话题

elasticsearch之管道聚合

回复

Elasticsearchredhat 发起了问题 • 1 人关注 • 0 个回复 • 47 次浏览 • 2 天前 • 来自相关话题

Elasticsearch 之 Term Vectors

回复

Elasticsearchredhat 发起了问题 • 1 人关注 • 0 个回复 • 56 次浏览 • 2 天前 • 来自相关话题

elasticsearch升级带来的问题java api使用的问题,请牛人指教

回复

Elasticsearchgaojun1212 发起了问题 • 1 人关注 • 0 个回复 • 65 次浏览 • 2 天前 • 来自相关话题

ElasticSearch 联想词问题

回复

ElasticsearchJinyang Zhou 回复了问题 • 8 人关注 • 4 个回复 • 2354 次浏览 • 3 天前 • 来自相关话题

elasticsearch索引数据存放在本地的哪个文件中?

回复

默认分类strglee 回复了问题 • 2 人关注 • 1 个回复 • 38 次浏览 • 3 天前 • 来自相关话题

用curator删除定时删除索引,删除后集群不知为何又重建创建了这个索?

回复

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

elastic search 查询问题

回复

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

elasticsearch更新,排序

回复

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

业务数据量与ES集群规模及配置的对应关系大致是怎样?

回复

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

spring-data-elasticsearch 如何让es自动生成_id

回复

Elasticsearchredhat 发起了问题 • 1 人关注 • 0 个回复 • 85 次浏览 • 5 天前 • 来自相关话题

Nested 存储对象型数组,怎么筛选满足多个key对应多个value

回复

Elasticsearchstrglee 回复了问题 • 3 人关注 • 1 个回复 • 87 次浏览 • 6 天前 • 来自相关话题

es报错Unexpected exception in the selector loop

回复

Elasticsearchccsy 发起了问题 • 2 人关注 • 0 个回复 • 82 次浏览 • 2018-06-11 15:54 • 来自相关话题

Elasticsearch snapshot 备份的使用方法

Elasticsearchrockybean 发表了文章 • 1 个评论 • 272 次浏览 • 2018-05-31 23:23 • 来自相关话题

常见的数据库都会提供备份的机制,以解决在数据库无法使用的情况下,可以开启新的实例,然后通过备份来恢复数据减少损失。虽然 Elasticsearch 有良好的容灾性,但由于以下原因,其依然需要备份机制。

  1. 数据灾备。在整个集群无法正常工作时,可以及时从备份中恢复数据。
  2. 归档数据。随着数据的积累,比如日志类的数据,集群的存储压力会越来越大,不管是内存还是磁盘都要承担数据增多带来的压力,此时我们往往会选择只保留最近一段时间的数据,比如1个月,而将1个月之前的数据删除。如果你不想删除这些数据,以备后续有查看的需求,那么你就可以将这些数据以备份的形式归档。
  3. 迁移数据。当你需要将数据从一个集群迁移到另一个集群时,也可以用备份的方式来实现。

Elasticsearch 做备份有两种方式,一是将数据导出成文本文件,比如通过 elasticdumpesm 等工具将存储在 Elasticsearch 中的数据导出到文件中。二是以备份 elasticsearch data 目录中文件的形式来做快照,也就是 Elasticsearch 中 snapshot 接口实现的功能。第一种方式相对简单,在数据量小的时候比较实用,当应对大数据量场景效率就大打折扣。我们今天就着重讲解下第二种备份的方式,即 snapshot api 的使用。

备份要解决备份到哪里、如何备份、何时备份和如何恢复的问题,那么我们接下来一个个解决。

1. 备份到哪里

在 Elasticsearch 中通过 repository 定义备份存储类型和位置,存储类型有共享文件系统、AWS 的 S3存储、HDFS、微软 Azure的存储、Google Cloud 的存储等,当然你也可以自己写代码实现国内阿里云的存储。我们这里以最简单的共享文件系统为例,你也可以在本地做实验。

首先,你要在 elasticsearch.yml 的配置文件中注明可以用作备份路径 path.repo ,如下所示:

path.repo: ["/mount/backups", "/mount/longterm_backups"]

配置好后,就可以使用 snapshot api 来创建一个 repository 了,如下我们创建一个名为 my_backup 的 repository。

PUT /_snapshot/my_backup
{
  "type": "fs",
  "settings": {
    "location": "/mount/backups/my_backup"
  }
}

之后我们就可以在这个 repository 中来备份数据了。

2. 如何备份

有了 repostiroy 后,我们就可以做备份了,也叫快照,也就是记录当下数据的状态。如下所示我们创建一个名为 snapshot_1 的快照。

PUT /_snapshot/my_backup/snapshot_1?wait_for_completion=true

wait_for_completion 为 true 是指该 api 在备份执行完毕后再返回结果,否则默认是异步执行的,我们这里为了立刻看到效果,所以设置了该参数,线上执行时不用设置该参数,让其在后台异步执行即可。

执行成功后会返回如下结果,用于说明备份的情况:

{
  "snapshots": [
    {
      "snapshot": "snapshot_1",
      "uuid": "52Lr4aFuQYGjMEv5ZFeFEg",
      "version_id": 6030099,
      "version": "6.3.0",
      "indices": [
        ".monitoring-kibana-6-2018.05.30",
        ".monitoring-es-6-2018.05.28",
        ".watcher-history-7-2018.05.30",
        ".monitoring-beats-6-2018.05.29",
        "metricbeat-6.2.4-2018.05.28",
        ".monitoring-alerts-6",
        "metricbeat-6.2.4-2018.05.30"
      ],
      "include_global_state": true,
      "state": "SUCCESS",
      "start_time": "2018-05-31T12:45:57.492Z",
      "start_time_in_millis": 1527770757492,
      "end_time": "2018-05-31T12:46:15.214Z",
      "end_time_in_millis": 1527770775214,
      "duration_in_millis": 17722,
      "failures": [],
      "shards": {
        "total": 28,
        "failed": 0,
        "successful": 28
      }
    }
  ]
}

返回结果的参数意义都是比较直观的,比如 indices 指明此次备份涉及到的索引名称,由于我们没有指定需要备份的索引,这里备份了所有索引;state 指明状态;duration_in_millis 指明备份任务执行时长等。

我们可以通过 GET _snapshot/my_backup/snapshot_1获取 snapshot_1 的执行状态。

此时如果去 /mount/backups/my_backup 查看,会发现里面多了很多文件,这些文件其实都是基于 elasticsearch data 目录中的文件生成的压缩存储的备份文件。大家可以通过 du -sh . 命令看一下该目录的大小,方便后续做对比。

3. 何时备份

通过上面的步骤我们成功创建了一个备份,但随着数据的新增,我们需要对新增的数据也做备份,那么我们如何做呢?方法很简单,只要再创建一个快照 snapshot_2 就可以了。

PUT /_snapshot/my_backup/snapshot_2?wait_for_completion=true

当执行完毕后,你会发现 /mount/backups/my_backup 体积变大了。这说明新数据备份进来了。要说明的一点是,当你在同一个 repository 中做多次 snapshot 时,elasticsearch 会检查要备份的数据 segment 文件是否有变化,如果没有变化则不处理,否则只会把发生变化的 segment file 备份下来。这其实就实现了增量备份。

elasticsearch 的资深用户应该了解 force merge 功能,即可以强行将一个索引的 segment file 合并成指定数目,这里要注意的是如果你主动调用 force merge api,那么 snapshot 功能的增量备份功能就失效了,因为 api 调用完毕后,数据目录中的所有 segment file 都发生变化了。

另一个就是备份时机的问题,虽然 snapshot 不会占用太多的 cpu、磁盘和网络资源,但还是建议大家尽量在闲时做备份。

4. 如何恢复

所谓“养兵千日,用兵一时”,我们该演练下备份的成果,将其恢复出来。通过调用如下 api 即可快速实现恢复功能。

POST /_snapshot/my_backup/snapshot_1/_restore?wait_for_completion=true
{
  "indices": "index_1",
  "rename_replacement": "restored_index_1"
}

通过上面的 api,我们可以将 index_1 索引恢复到 restored_index_1 中。这个恢复过程完全是基于文件的,因此效率会比较高。

虽然我们这里演示的是在同一个集群做备份与恢复,你也可以在另一个集群上连接该 repository 做恢复。我们这里就不做说明了。

5. 其他

由于 Elasticsearch 版本更新比较快,因此大家在做备份与恢复的时候,要注意版本问题,同一个大版本之间的备份与恢复是没有问题的,比如都是 5.1 和 5.6 之间可以互相备份恢复。但你不能把一个高版本的备份在低版本恢复,比如将 6.x 的备份在 5.x 中恢复。而低版本备份在高版本恢复有一定要求:

1) 5.x 可以在 6.x 恢复

2) 2.x 可以在 5.x 恢复

3) 1.x 可以在 2.x 恢复

其他跨大版本的升级都是不可用的,比如1.x 的无法在 5.x 恢复。这里主要原因还是 Lucene 版本问题导致的,每一次 ES 的大版本升级都会伴随 Lucene 的大版本,而 Lucene 的版本是尽量保证向前兼容,即新版可以读旧版的文件,但版本跨越太多,无法实现兼容的情况也在所难免了。

6. 继续学习

本文只是简单对 snapshot 功能做了一个演示,希望这足够引起你的兴趣。如果你想进一步深入的了解该功能,比如备份的时候如何指定部分索引、如何查询备份和还原的进度、如何跨集群恢复数据、如何备份到 HDFS 等,可以详细阅读官方手册https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html,如果在使用的过程中遇到了问题,欢迎留言讨论。

【线下活动】2018-06-30 南京Elastic Meetup日程安排

活动swordsmanli 发表了文章 • 12 个评论 • 1970 次浏览 • 2018-05-31 15:33 • 来自相关话题

Elastic Meetup 南京

主办方

Elastic中文社区、趋势科技

meetup_logo.jpg

协办方

IT 大咖说、阿里云、开源中国

itdks.jpeg
aliyun.jpg
osc.jpg

时间地点

  • 活动时间:2018年6月30日 13:00 - 18:00 

  • 活动地点:雨花区软件大道48号苏豪国际广场B座 趋势科技中国研发中心(靠花神庙地铁站)

 

 报名地址

http://elasticsearch.mikecrm.com/fUqiv0T

qr.php_.png

   名额有限,速速报名!

直播地址

IMG_2154.JPG

 

主题

分享一:Elastic 探秘之遗落的珍珠

标签:elastic stack 讲师简介:

medcl.jpg
 

曾勇(Medcl) Elastic 中国首席布道师 Elasticsearch爱好者,2015年加入Elastic,Elastic 中文社区的发起人,Elastic在中国的首位员工。

主题简介: Elastic Stack 功能越来越丰富了,有很多功能可能你只听说过名字,有很多功能也许没有机会尝试过,其实你可能错过了很多宝贝,所以让我们来探究探究,本次分享主要介绍 Elastic Stack 技术栈里面,一些可能看起来不太起眼但却非常有意思的功能,定义为非干货,尽量轻拍,不过相信对于刚接触 Elastic 的同学来说,也会有所收获。  

分享二:基于ELK的大数据分析平台实践

标签:运维、DevOps 讲师简介:

tuhaibo.jpg
 

涂海波 南京云利来有限公司 曾在亚信联创电信事业部从事计费产品工作多年,2年前加入南京云利来。

主题简介: 主题围绕Elasticsearch在集群搭建和运维过程中的使用经验,分享工作期间主要遇到的问题和解决思路,希望能够帮助大家在elasticsearch使用过程中少走一些弯路  

分享三:ElasticLog with ES in CloudEdge

标签:Ops、AWS、Log

讲师简介:

bruce_zhao.jpg

  赵伟,趋势科技CloudEdge Team 负责大数据研发,个人技术兴趣广泛,擅长系统设计与服务调优,目前专注于大数据领域。 主题简介: 作为趋势科技下一代应用安全网关产品,CloudEdge的用户规模不断增长。面对每日数亿级数据,如何实现快速处理与查询?本次演讲,主要分享CloudEdge的大数据架构,介绍如何在AWS云上构建大数据系统,如何利用Elasticsearch实现热数据查询,以及在Elasticsearch方面的诸多实践经验  

分享四:华泰证券Elasticsearch应用实践

标签:金融IT、大数据、DevOps、日志

讲师简介: 李文强,华泰证券数据平台架构师 负责Hadoop平台和Elasticsearch集群的管理、架构和部分项目管理,目前正积极研究基于k8s的人工智能平台落地方案。

主题简介: 经过几年的发展,Elasticsearch已经在华泰证券内部生根发芽,已经有不少业务都使用了Elasticsearch,其中一个非常重要的应用是日志搜索和分析系统,该系统统一收集和分析各个系统的日志,既提升运维效率,又提高运营质量。在这些实践中,我们也不断地对Elasticsearch进行调优,使其能够长期稳定运行,保障业务稳定。    

分享五:es在苏宁的实践

标签:实践,大数据,平台化

讲师简介:

韩君宝.png

  韩宝君,苏宁大数据平台  ES平台组负责人 2015年从事大数据研究工作,目前负责Elasticsearch的源码研究工作和定制化开发,对苏宁使用Elasticsearch的业务提供技术支持和解决方案。

主题简介: 本次分享大纲如下:

  1. 苏宁ES平台总体介绍,典型使用场景和规模;
  2. ES平台化之路-演进路线以及过程中我们的思考;
  3. 实战经验:遇到的问题及对应的解决方案;  

logstash-filter-elasticsearch的简易安装

Logstashziyou 发表了文章 • 0 个评论 • 130 次浏览 • 2018-05-29 09:38 • 来自相关话题

不同版本的logstash集成的插件不一样,在5.6版本就未集成logstash-filter-elasticsearch插件,所以需要自己安装。 官方提供的方法因为需要联网,并且需要调整插件管理源,比较麻烦,针对logstash-filter-elasticsearch插件,使用下面这种方式安装。 logstash-filter-elasticsearch插件安装 1、在git上下载logstash-filter-elasticsearch压缩包,logstash-filter-elasticsearch.zip, 2、在logstash的目录下新建plugins目录,解压logstash-filter-elasticsearch.zip到此目录下。 3、在logstash目录下的Gemfile中添加一行:
gem "logstash-filter-elasticsearch", :path => "./plugins/logstash-filter-elasticsearch"
4、重启logstash即可。   此方法适用logstash-filter-elasticsearch,但不适用全部logstash插件。

转载一篇关于shard数量设计的文章,很赞

Elasticsearchlz8086 发表了文章 • 2 个评论 • 167 次浏览 • 2018-05-28 18:34 • 来自相关话题

How many shards should I have in my Elasticsearch cluster?   Elasticsearch is a very versatile platform, that supports a variety of use cases, and provides great flexibility around data organisation and replication strategies. This flexibility can however sometimes make it hard to determine up-front how to best organize your data into indices and shards, especially if you are new to the Elastic Stack. While suboptimal choices  will not necessarily cause problems when first starting out, they have the potential to cause performance problems as data volumes grow over time. The more data the cluster holds, the more difficult it also becomes to correct the problem, as reindexing of large amounts of data can sometimes be required. When we come across users that are experiencing performance problems, it is not uncommon that this can be traced back to issues around how data is indexed and number of shards in the cluster. This is especially true for use-cases involving multi-tenancy and/or use of time-based indices. When discussing this with users, either in person at events or meetings or via our forum, some of the most common questions are “How many shards should I have?” and “How large should my shards be?”. This blog post aims to help you answer these questions and provide practical guidelines for use cases that involve the use of time-based indices, e.g. logging or security analytics, in a single place. What is a shard? Before we start, we need to establish some facts and terminology that we will need in later sections. Data in Elasticsearch is organized into indices. Each index is made up of one or more shards. Each shard is an instance of a Lucene index, which you can think of as a self-contained search engine that indexes and handles queries for a subset of the data in an Elasticsearch cluster. As data is written to a shard, it is periodically published into new immutable Lucene segments on disk, and it is at this time it becomes available for querying. This is referred to as a refresh. How this works is described in greater detail in Elasticsearch: the Definitive Guide. As the number of segments grow, these are periodically consolidated into larger segments. This process is referred to as merging. As all segments are immutable, this means that the disk space used will typically fluctuate during indexing, as new, merged segments need to be created before the ones they replace can be deleted. Merging can be quite resource intensive, especially with respect to disk I/O. The shard is the unit at which Elasticsearch distributes data around the cluster. The speed at which Elasticsearch can move shards around when rebalancing data, e.g. following a failure, will depend on the size and number of shards as well as network and disk performance. TIP: Avoid having very large shards as this can negatively affect the cluster's ability to recover from failure. There is no fixed limit on how large shards can be, but a shard size of 50GB is often quoted as a limit that has been seen to work for a variety of use-cases. Index by retention period As segments are immutable, updating a document requires Elasticsearch to first find the existing document, then mark it as deleted and add the updated version. Deleting a document also requires the document to be found and marked as deleted. For this reason, deleted documents will continue to tie up disk space and some system resources until they are merged out, which can consume a lot of system resources. Elasticsearch allows complete indices to be deleted very efficiently directly from the file system, without explicitly having to delete all records individually. This is by far the most efficient way to delete data from Elasticsearch. TIP: Try to use time-based indices for managing data retention whenever possible. Group data into indices based on the retention period. Time-based indices also make it easy to vary the number of primary shards and replicas over time, as this can be changed for the next index to be generated. This simplifies adapting to changing data volumes and requirements. Are indices and shards not free? For each Elasticsearch index, information about mappings and state is stored in the cluster state. This is kept in memory for fast access. Having a large number of indices in a cluster can therefore result in a large cluster state, especially if mappings are large. This can become slow to update as all updates need to be done through a single thread in order to guarantee consistency before the changes are distributed across the cluster. TIP: In order to reduce the number of indices and avoid large and sprawling mappings, consider storing data with similar structure in the same index rather than splitting into separate indices based on where the data comes from. It is important to find a good balance between the number of indices and the mapping size for each individual index. Each shard has data that need to be kept in memory and use heap space. This includes data structures holding information at the shard level, but also at the segment level in order to define where data reside on disk. The size of these data structures is not fixed and will vary depending on the use-case. One important characteristic of the segment related overhead is however that it is not strictly proportional to the size of the segment. This means that larger segments have less overhead per data volume compared to smaller segments. The difference can be substantial. In order to be able to store as much data as possible per node, it becomes important to manage heap usage and reduce the amount of overhead as much as possible. The more heap space a node has, the more data and shards it can handle. Indices and shards are therefore not free from a cluster perspective, as there is some level of resource overhead for each index and shard. TIP: Small shards result in small segments, which increases overhead. Aim to keep the average shard size between a few GB and a few tens of GB. For use-cases with time-based data, it is common to see shards between 20GB and 40GB in size. TIP: As the overhead per shard depends on the segment count and size, forcing smaller segments to merge into larger ones through a forcemerge operation can reduce overhead and improve query performance. This should ideally be done once no more data is written to the index. Be aware that this is an expensive operation that should ideally be performed during off-peak hours. TIP: The number of shards you can hold on a node will be proportional to the amount of heap you have available, but there is no fixed limit enforced by Elasticsearch. A good rule-of-thumb is to ensure you keep the number of shards per node below 20 to 25 per GB heap it has configured. A node with a 30GB heap should therefore have a maximum of 600-750 shards, but the further below this limit you can keep it the better. This will generally help the cluster stay in good health. How does shard size affect performance? In Elasticsearch, each query is executed in a single thread per shard. Multiple shards can however be processed in parallel, as can multiple queries and aggregations against the same shard. This means that the minimum query latency, when no caching is involved, will depend on the data, the type of query, as well as the size of the shard. Querying lots of small shards will make the processing per shard faster, but as many more tasks need to be queued up and processed in sequence, it is not necessarily going to be faster than querying a smaller number of larger shards. Having lots of small shards can also reduce the query throughput if there are multiple concurrent queries. TIP: The best way to determine the maximum shard size from a query performance perspective is to benchmark using realistic data and queries. Always benchmark with a query and indexing load representative of what the node would need to handle in production, as optimizing for a single query might give misleading results. How do I manage shard size? When using time-based indices, each index has traditionally been associated with a fixed time period. Daily indices are very common, and often used for holding data with short retention period or large daily volumes. These allow retention period to be managed with good granularity and makes it easy to adjust for changing volumes on a daily basis. Data with a longer retention period, especially if the daily volumes do not warrant the use of daily indices, often use weekly or monthly induces in order to keep the shard size up. This reduces the number of indices and shards that need to be stored in the cluster over time. TIP: If using time-based indices covering a fixed period, adjust the period each index covers based on the retention period and expected data volumes in order to reach the target shard size. Time-based indices with a fixed time interval works well when data volumes are reasonably predictable and change slowly. If the indexing rate can vary quickly, it is very difficult to maintain a uniform target shard size. In order to be able to better handle this type of scenarios, the Rollover and Shrink APIs were introduced. These add a lot of flexibility to how indices and shards are managed, specifically for time-based indices. The rollover index API makes it possible to specify the number of documents and index should contain and/or the maximum period documents should be written to it. Once one of these criteria has been exceeded, Elasticsearch can trigger a new index to be created for writing without downtime. Instead of having each index cover a specific time-period, it is now possible to switch to a new index at a specific size, which makes it possible to more easily achieve an even shard size for all indices. In cases where data might be updated, there is no longer a distinct link between the timestamp of the event and the index it resides in when using this API, which may make updates significantly less efficient as each update my need to be preceded by a search. TIP: If you have time-based, immutable data where volumes can vary significantly over time, consider using the rollover index API to achieve an optimal target shard size by dynamically varying the time-period each index covers. This gives great flexibility and can help avoid having too large or too small shards when volumes are unpredictable. The shrink index API allows you to shrink an existing index into a new index with fewer primary shards. If an even spread of shards across nodes is desired during indexing, but this will result in too small shards, this API can be used to reduce the number of primary shards once the index is no longer indexed into. This will result in larger shards, better suited for longer term storage of data. TIP: If you need to have each index cover a specific time period but still want to be able to spread indexing out across a large number of nodes, consider using the shrink API to reduce the number of primary shards once the index is no longer indexed into. This API can also be used to reduce the number of shards in case you have initially configured too many shards. Conclusions This blog post has provided tips and practical guidelines around how to best manage data in Elasticsearch. If you are interested in learning more, "Elasticsearch: the definitive guide" contains a section about designing for scale, which is well worth reading even though it is a bit old. A lot of the decisions around how to best distribute your data across indices and shards will however depend on the use-case specifics, and it can sometimes be hard to determine how to best apply the advice available. For more in-depth and personal advice you can engage with us commercially through a subscription and let our Support and Consulting teams help accelerate your project. If you are happy to discuss your use-case in the open, you can also get help from our community and through our public forum.

[技术交流] Elasticsearch冉冉升起,几款开源数据引擎对比

Elasticsearchhw_cloudsearch 发表了文章 • 0 个评论 • 216 次浏览 • 2018-05-24 16:35 • 来自相关话题

2018年的数据引擎排名已经出啦,不知道各位小伙伴留意没~~~
排名.png
Elasticsearch强势进入前十,是一颗冉冉升起的新星。   一些小伙伴经常会碰到选取何种数据引擎的情况。在此,我们将把几个热门的开源数据引擎进行对比,供大家参考。
对比.png
从上表看出: MySQL:将数据保存在不同的表中,使用SQL语言进行交互,是目前非常流行的关系型数据库管理系统。如果您需要一个传统的数据库,那么MySQL是不错的选择。 MongoDB:基于分布式文件存储的NoSQL数据库,数据结构由键值对组成,具有可扩展性。如果您需要存储和查询非结构化信息,不太需要分析或全文检索,那么MongoDB是不错的选择。 Redis:高性能的键值对数据库,支持一定程度的事务性。主要应用为缓存,对读写有非常高性能要求的场景中,是不错的选择。但因为是靠全内存加速,所以数据量大的情况下,配置要求也很高。 Elasticsearch:基于Lucene的分布式搜索引擎,具有全文检索,同义词处理,相关度排名,复杂数据分析的能力。如果您想做文本类检索,及相关性排序,以及指标类分析,Elasticsearch会非常适合。它在文档全文检索(网站搜索,APP搜索)和日志分析(运营,运维)领域拥有得天独厚的优势。   此文抛砖引玉,欢迎小伙伴留言讨论不同数据引擎的适用场景~~ 另有想快速体验Elasticsearch欢迎戳下面链接~~~ 华为云搜索服务是云上的Elasticsearch,具有简单易用、无忧运维、弹性灵活、数据可靠等特点,欢迎使用~~~~  

干货 | Elasticsearch 布道者Medcl对话携程Wood大叔核心笔记

Elasticsearchlaoyang360 发表了文章 • 7 个评论 • 558 次浏览 • 2018-05-23 00:28 • 来自相关话题

Elastic Podcast 第二期来啦, 这一次我们来到了位于上海的携程旅行网,携程内部大量运用了 Elasticsearch来进行集中式的运维日志管理和为业务部门提供统一的搜索服务平台, 目前线上总共部署了多达 94 个 Elasticsearch 集群和超过 700 多个 Elasticsearch 节点,每天新增日志 1600 亿条,峰值达到 300 万每秒,存放在 Elasticsearch里面的索引文档达到 2.5 万亿,磁盘存储达到 PB 级。 想知道携程是如何应对这些海量数据下的挑战,以及最佳实践,让我们一起来收听这一期的 Podcast,跟随携程的两位技术负责人吴晓刚和胡航来一探究竟。

音频地址:http://m.ximalaya.com/111156131/sound/89571047

主持人:Elastic 技术布道师,曾勇(Medcl)。 嘉宾: 1、吴晓刚(Wood大叔),携程技术保障部系统研发总监, Elasticsearch 国内早期实践者,中文社区活跃用户。 曾在 eBay, Morgan Stanley, PPTV 等国内外公司从事系统软件研发、系统集成与技术支持工作。对于大规模 IT 系统的运维自动化、可视化、性能优化具有浓厚的兴趣。在技术方面一直抱有知其然知其所以然的态度。

2、胡航,携程旅行网高级技术经理,负责相关搜索实现、SOA服务的开发。曾供职于腾讯、盛大等公司,对新技术持有强烈的好奇心,目前关注于 Elasticsearch 的业务实现、JVM 性能优化等。

1、携程Elasticsearch使用历史

1.1 运维组Wood大叔:

2014年,ES0.9版本。 选型对比:MongoDB——数据量级大了以后,出现性能瓶颈。 调研后,选型:ELK(Elasticsearch、Logstash、Kibana)。 实现效果:实时看效果、查询、聚合。

1.2 胡航业务组:

业务场景:酒店价格。 选型依据:ES分布式、可调试性能好。 版本:ES2.3。 时间:2017年中,逐步转向ES,5.3版本。 效果:显著。专注于后端开发,业务交由业务团队自己去做。

2、携程Elasticsearch规模

2.1 运维组Wood大叔:

集群:94个。最小三个节点,最大:360+节点。 节点:700+。 每日增量:1600亿条。 峰值:300W/s。 总数据量:2.5万亿,PB数量级。 面对挑战: 1)实时写入。 2)业务流程相关,几个月-2年的历史数据。

2.2 胡航业务组:

业务场景:3集群,每集群6个节点。 单个索引:最大1000W-2000W。

关注:ES基础框架,帮业务部分实现写入、查询、DSL调优。 查询:3000-4000/s。

携程ES规模量全国数一数二,有很大挑战。

3、携程Elasticsearch淌过的坑

3.1 运维组Wood大叔:

3.1.1 痛点1:内存溢出。

原因:早期版本,对查询限制做的不充分;数据量上了规模,查询、聚合会非常耗内存。

升级版本后,ES做了很多处理,集群层面做了限制。越来越稳定。

3.1.2 痛点2:集群故障无法恢复。

3.1.3 痛点3:translog做不完。

3.1.4 痛点4:集群的平台化管理。

需要:研究底层工作机制,找到规避方法。 经验丰富后,运维效率提升。

3.2胡航业务组:

3.2.1 痛点1:ES基础不熟悉带来的问题;

3.2.2 痛点2:性能问题——最终排查是ES5.X keyword类型的原因。

4、架构

4.1运维组Wood大叔:

1、早期:ELK+redis(中间缓存)

挑战: 1)redis承受能力差。

2)redis单线程。

改善: 1)redis改为kafka(磁盘级别),数据畅通了。

2)Logstash内存消耗大。——改为:logstash forward,推荐官方Beats。

3)数据规模后,需要很多服务器,Logstash非常耗内存。

优化:用golang开发了一个gohangout (https://github.com/childe/gohangout ) ,

内存比java 版的hangout(https://github.com/childe/hangout) 内存大幅降低。

4.2 胡航搜索业务组:

1)单点集群压力瓶颈。

改为:业务数据导入ES,提供定制客户端。

2)搜索平台,接入更多业务需求。

不方便在kibana做定制开发,自己做了简单网站查询数据、监控,满足业务的贴切需求。

5、ES6.3最新特性(抢先看)

5.1 ES6.3 支持Sql接口

Wood大叔: kibana看DSL,拷贝后修改。新用户不熟悉,会不方便。

BI部分也需要,类似sql的查询。

优点:更简单,发挥更大的作用。

携程BI部门——应用场景:搜索的关键词、 统计热词,目的地等信息。

Kibana满足不了需求,就要写代码。如果有了sql,会非常快的开发。

胡航搜索业务组: 写DSL,还是稍微复杂。借助 NLPChina ElasticsearchSql插件实现。

实际应用发现插件还是有问题,期待ES官方推出Sql查询。

5.2 增加kibana丰富表现力

5.3 更快的索引速度

refresh优化:提升吞吐。

6、ELK Stack最喜欢的特性

Wood大叔: 丰富的扩展能力,用户不必关心底层的实现。通过服务器增加节点,方便大数据量查询。

胡航: ES可视化、可调试特性。 举例: 1)出现问题排查DSL是不是合适?Mapping是不是合适?

2)相信ES的社区,不必关心底层,更多的时间做业务(解放双手)。

3)ES中做好数据模型,实现业务需求。

7、ELK Stack最需要完善的

Wood大叔: 1)集群的保护待更进一步完善 数据丢失后的处理?

节点损毁后的处理?

目的:减轻运维的负担;

2)甄别坏查询,Slow log存在缺陷。 很难判定真正故障是哪个慢查询。

集群发下故障的时候,有API实时分析会更好(比单纯查slow log)。

胡航: 1)ES坑还很多,比较耗费时间。

2)期待社区对常见问题整理。

3)期待官方总结完善的向导,类似:Cookbook。

初级上手的话可以参考借鉴(大家缺乏经验)

8、初学者的建议

1)初学者必读——《Elasticsearch: 权威指南》(英文、中文) WOOD大叔至少看了3遍。

2)不断的实践。

3)带着问题,再去找文档,构建知识体系。

4)多参与社区,尝试理解和解决社区问题,不断学习,以提升自己。 互帮互助,共同成长!

5)中文社区的小建议:问题精华版收集——新手通读,学习前人经验。

9、如何看待Elasticsearch在国内的发展?

1)参与和贡献,国内做的不足;

2)中文分词插件等,如:分词质量要求高,专业语义搜索支持(提高搜索相关性等)、情感标注、NLP等。

3)在中文应用场景应用更加丰富。

4)社区问题比较分散,社区需要意见领袖,加强某领域讨论、深入交流等。

5)medcl:ElasticTips成立,大家都去参与,以图片形式分享。

6) 社区还会做更多的事情,大家多分享、互相交流。

10、小结

非常震惊,wood大叔看了3遍《Elasticsearch: 权威指南》,我们没有理由不努力。

共勉,加油!

_validate/query?explain解释

Elasticsearchhnj1575565068 发表了文章 • 0 个评论 • 130 次浏览 • 2018-04-24 10:33 • 来自相关话题

使用_validate/query?explain API得到的结果如下,Synonym是什么意思啊?同义词吗?求解释{   "valid": true,   "_shards": {     "total": 1,     "successful": 1,     "failed": 0   },   "explanations": [     {       "index": "country",       "valid": true,       "explanation": "name:z Synonym(name:g name:zg)"     }   ] }
使用_validate/query?explain API得到的结果如下,Synonym是什么意思啊?同义词吗?求解释{   "valid": true,   "_shards": {     "total": 1,     "successful": 1,     "failed": 0   },   "explanations": [     {       "index": "country",       "valid": true,       "explanation": "name:z Synonym(name:g name:zg)"     }   ] }

看到一个词语提取小工具,分享给有标签、词库需求的TX们

Elasticsearchtc 发表了文章 • 1 个评论 • 199 次浏览 • 2018-04-23 13:44 • 来自相关话题

【东家·守艺人】ElasticSearch (ELK) 资深开发工程师(杭州)

求职招聘惜朝 发表了文章 • 0 个评论 • 400 次浏览 • 2018-04-19 20:13 • 来自相关话题

职位描述

  1. 构建基于ElasticSearch(ES)的实时数据分析平台;
  2. 负责个性化搜索、个性化推荐系统的架构和服务;

岗位要求

  1. 熟悉Java开发,包括常用中间件:Dubbo、Zookeeper、MySQL、Redis、MongoDB等;
  2. 熟悉ElasticSearch(ES)/Solr/Lucence原理;
  3. 有ElasticSearch(ES)/Solr/Lucence 工程应用经验丰富;
  4. 有搜索相关功能性能调优优先;

工作地址

杭州 - 西湖区 - 文一西路崇义路口公元里13幢2楼

联系我

职位描述

  1. 构建基于ElasticSearch(ES)的实时数据分析平台;
  2. 负责个性化搜索、个性化推荐系统的架构和服务;

岗位要求

  1. 熟悉Java开发,包括常用中间件:Dubbo、Zookeeper、MySQL、Redis、MongoDB等;
  2. 熟悉ElasticSearch(ES)/Solr/Lucence原理;
  3. 有ElasticSearch(ES)/Solr/Lucence 工程应用经验丰富;
  4. 有搜索相关功能性能调优优先;

工作地址

杭州 - 西湖区 - 文一西路崇义路口公元里13幢2楼

联系我

《死磕 Elasticsearch 方法论》:普通程序员高效精进的 10 大狠招!(完整版)

Elasticsearchlaoyang360 发表了文章 • 0 个评论 • 4532 次浏览 • 2018-04-05 00:01 • 来自相关话题

0、授人以渔,少走半年弯路!

死磕 Elasticsearch 方法论:普通程序员高效精进的 10 大狠招!

一、Elasitcsearch基础篇

1.1 Elasitcsearch基础认知

1、Elasticsearch学习,请先看这一篇!
2、Elasticsearch增、删、改、查操作深入详解
3、Elasticsearch 索引存储深入详解

1.2 Elasticsearch集群部署

4、Elasticsearch安装与测试验证详解
5、Elasticsearch windows下一键安装实现深入详解
6、Elasticsearch集群部署详解
7、Elasticsearch5.4.0(head/kibana/logstash)安装部署深入详解

1.3 Elasticsearch 插件安装

8、Elasticsearch插件一——-head插件安装详解
9、Elasticsearch插件二—— kibana插件安装详解
10、Elasticsearch插件三—— Marvel插件安装详解
11、Elasticsearch插件四—— logstash插件安装详解
12、Elasticsearch插件五—— graph插件安装详解
13、Elasticsearch插件六—— 分词 IK analyzer插件安装详解
14、Elasticsearch5.4.0 IK分词插件安装详解

1.4 Elasticsearch小试牛刀

15、ES技术团队划重点 | ES5.X,你必须知道的API和相关技巧
16、Elasticsearch检索分类深入详解—基础篇
17、上线必备 | 高性能ES5.X部署配置清单
18、 Elasticsearch究竟要设置多少分片数?
19、深究|Elasticsearch单字段支持的最大字符数?
20、Elasticsearch6.X 新类型Join深入详解

二、Elasticsearch进阶篇

2.1 Elasitcsearch数据同步

2.1.1 ES与关系型数据库同步
21、logstash-input-jdbc实现mysql 与elasticsearch实时同步深入详解
22、elasticsearch-jdbc实现MySQL同步到ElasticSearch深入详解
23、go-mysql-elasticsearch实现mysql 与elasticsearch实时同步深入详解
24、mysql 与elasticsearch实时同步常用插件及优缺点对比
25、logstash-input-jdbc 同步原理及相关问题解读
26、 logstash-input-jdbc实现oracle 与elasticsearch实时同步详解
27、logstash一次同步Mysql多张表到ES深入详解
2.1.2 ES与非关系型数据库同步
28、 logstash_output_mongodb插件用途及安装详解
29、 logstash-output-mongodb实现Mysql到Mongodb数据同步
30、logstash-out-mongodb实现elasticsearch到Mongodb的数据同步
31、mongo-connector实现MongoDB与elasticsearch实时同步深入详解
2.1.3 ES与Kafka同步
32、kafka数据同步Elasticsearch深入详解
2.1.4 ES文件同步
33、 Elasticsearch批量导入本地Json文件Java实现
34、logstash实现日志文件同步到elasticsearch深入详解
2.1.5 ES同步小结
35、如何将不同类型数据导入Elaticsearch中?
36、一张图理清楚关系型/非关系型数据库与Elasticsearch同步

2.2 Elasticsearch检索进阶

37、你必须知道的23个最有用的Elasticseaerch检索技巧
38、Elasticsearch实战 | match_phrase搜不出来,怎么办?

2.3 Elasitcsearch聚合进阶

39、 Elasticsearch聚合深入详解——对比Mysql实现
40、Elasticsearch聚合后分页深入详解
41、Elasticsearch聚合优化 | 聚合速度提升5倍

2.4 Elasticsearch Java API 详解

42、 Elasticsearch Java API深入详解
43、Elasticsearch Jest实战深入详解

2.5 Elasitcsearch数据迁移

44、Elasticsearch索引迁移的四种方式

2.6 Elasticsearch性能测试

45、 Elasticsearch自定义脚本完成性能测试
46、Elasticsearch性能测试工具rally深入详解
47、esrally性能分析结果图形化展示深入详解
48、esrally性能测试原理

2.7 Elasitcsearch安全监控

49、Elasticsearch6.2.2 X-Pack部署及使用详解

三、Elasticsearch实战篇

3.1 Elasticsearch应用场景

50、Elasticsearch的使用场景深入详解
51、 Elasticsearch全文检索实战小结

3.2 Elasticsearch架构设计

52、 Elasticsearch实战——全文检索架构设计
53、干货 |《深入理解Elasticsearch》读书笔记

3.3 Elasticsearch项目实战

54、Elasticsearch全文检索系统实现深入详解
55、 Elasticsearch大文件检索性能提升20倍实践(干货)
56、刨根问底 | Elasticsearch 5.X集群多节点角色配置深入详解
57、干货 | Elasticsearch5.X Mapping万能模板
58、干货 | Elasticsearch 集群健康值红色终极解决方案
59、 实战 | Elasticsearch打造知识库检索系统
60、Elasticsearch实战 | 必要的时候,还得空间换时间!
61、 Elasticsearch全量数据增量遍历实现原理
62、 Elasticsearch索引增量统计及定时邮件实现

更多干货,持续更新中..... 更新地址:http://t.cn/Rmwzx9t

和你一起,死磕ELK Stack!

ES数据备份和清理-快照

Elasticsearchziyou 发表了文章 • 3 个评论 • 240 次浏览 • 2018-04-04 17:41 • 来自相关话题

        这两天在看ES数据备份方面的事情,因为我们ES集群的存储空间有限,需要定时对ES的数据进行备份和清理,把备份的数据存储到其他地方去,然后在ES集群中释放掉。         看大家好多是主要考虑数据的安全性才做的数据的备份,我们就比较low了,我们就是因硬盘不够,要删数据。上个项目是因为日志数据重要程度一般般,就保留了一个月的量,然后也没有做数据的备份转储。这次上线的项目要求就高点了,需要删除的数据存储到其他地方,但是硬盘的容量更低了。所以就需要做ES数据备份和转储,转储完了就清掉。         这里是用ES官方推荐的数据快照方案,这个方案可以完全通过ES API进行操作,比价方便、快捷,在数据恢复方面也是方便的。 先上ES官方的链接,大家看看:https://www.elastic.co/guide/e ... .html         然后就是步骤了: 执行过程分为两部分: 一、准备过程 1、添加ES备份存储目录 在集群的每台机器上进行目录创建 mkdir /home/esdata 2、挂载共享文件存储目录 在集群的每台机器上目录挂载 mount -t nfs 10.70.61.80:/home/apmtest /home/esdata 3、修改ES集群配置 在ES集群的每台机器上都添加path.repo属性 path.repo: ["/home/esdata"] 4、重启ES集群 ES集群重启必须是关闭所有机器后,再启动。 5、建立备份仓库 PUT /_snapshot/my_backup    {      "type": "fs",        "settings": {          "location": "/home/esdata"        }  } 二、备份数据快照 1、通过API执行备份 PUT /_snapshot/my_backup/snapshot_2018.03.01?wait_for_completion=true  {      "indices": "filebeat-2018.03.01"  }           快照仓库需要注意的地方就是需要在整个集群的每一台机器上挂载相同的共享文件存储目录,保证在集群里做的操作是输出到相同的地方的。   下面来一份shell脚本,可以定时执行,是做ES数据的定时转储和清理的,大家可以借鉴一下
#!/bin/bash
ESIP=127.0.0.1
DATE=`date -d '-2 days' +'%Y.%m.%d'`
INDEX='{ "indices": "'$DATE'" }'
echo "begin to backup ES LOG..."
 
curl -XPUT "http://$ESIP:9200/_snapshot/my_backup/snapshot_$DATE?wait_for_completion=true" -d $INDEX
 
echo "----------------------------------------------------------------------------"
 
echo "begin to clean ES LOG..."
 
URL1="http://$ESIP:9200/filebeat-$DATE"
 
curl -XDELETE $URL1

 
echo "TRANSFER AND CLEAN ES LOG END!"

php的操作类库,通过写sql来转化dsl来查询elasticsearch

Elasticsearchqieangel2013 发表了文章 • 1 个评论 • 746 次浏览 • 2018-03-21 15:44 • 来自相关话题

EsParser

php的操作类库,通过写sql来转化dsl来查询elasticsearch

composer使用

{
    "require": {
        "qieangel2013/esparser": "dev-master"
    }
}
composer install
require __DIR__.'/vendor/autoload.php';
$sql = 'select * from alp_dish_sales_saas where sid in(994,290) limit 1,10';
//$sql='update alp_dish_sales_saas set mid=3  where adsid=15125110';
//$sql='delete from alp_dish_sales_saas where adsid=15546509';
$es_config=array(
    'index' =>"alp_dish_sales_saas",
    'type'  =>"alp_dish_sales_saas",
    'url'   =>"http://127.0.0.1:9200",
    'version' =>"5.x" //1.x 2.x 5.x 6.x,可以不配置,系统会请求获取版本,这样会多一次请求,建议配置一下
 );
$parser = new EsParser($sql, true,$es_config);//第三个参数是es的配置参数,一定要配置
print_r($parser->result);//打印结果
//print_r($parser->explain());//打印dsl

普通调用

require_once dirname(__FILE__) . '/src/library/EsParser.php';
$sql = 'select * from alp_dish_sales_saas where sid in(994,290) limit 1,10';
//$sql='update alp_dish_sales_saas set mid=3  where adsid=15125110';
//$sql='delete from alp_dish_sales_saas where adsid=15546509';
$es_config=array(
        'index' =>"alp_dish_sales_saas",
        'type'  =>"alp_dish_sales_saas",
        'url'   =>"http://127.0.0.1:9200",
        'version' =>"5.x" //1.x 2.x 5.x 6.x,可以不配置,系统会请求获取版本,这样会多一次请求,建议配置一下
    );
$parser = new EsParser($sql, true,$es_config);//第三个参数是es的配置参数,一定要配置
print_r($parser->result);//打印结果
//print_r($parser->explain()); //打印dsl

目前支持的sql函数

*  SQL Select
*  SQL Delete
*  SQL Update
*  SQL Where
*  SQL Order By
*  SQL Group By
*  SQL AND & OR 
*  SQL Like
*  SQL COUNT distinct
*  SQL In
*  SQL avg()
*  SQL count()
*  SQL max()
*  SQL min()
*  SQL sum()
*  SQL Between
*  SQL Aliases

使用注意事项

请在配置项填写es的版本,这样系统不会请求获取版本,这样不会多一次请求,建议配置一下

交流使用

qq群:578276199

项目地址

github:https://github.com/qieangel2013/EsParser
oschina:https://gitee.com/qieangel2013/EsParser

elasticsearch分词检索的match-query匹配过程分析

Elasticsearch夏李俊 发表了文章 • 3 个评论 • 472 次浏览 • 2018-03-14 12:00 • 来自相关话题

1. 模拟字符串数据存储
localhost:9200/yigo-redist.1/_analyze?analyzer=default&text=全能片(前)---TRW-GDB7891AT刹车片自带报警线,无单独报警线号码,卡仕欧,卡仕欧,乘用车,刹车片
上面的url表示
  •     索引为`yigo-redist.1`
  •     使用了索引`yigo-redist.1`中的分词器(`analyzer`) `default`
  •     解析的字符串(`text`)为"全能片(前)---TRW-GDB7891AT刹车片自带报警线,无单独报警线号码,卡仕欧,卡仕欧,乘用车,刹车片"
如果结果为:
{
  "tokens" : [ {
    "token" : "全能",
    "start_offset" : 0,
    "end_offset" : 2,
    "type" : "CN_WORD",
    "position" : 1
  }, {
    "token" : "片",
    "start_offset" : 2,
    "end_offset" : 3,
    "type" : "CN_CHAR",
    "position" : 2
  }, {
    "token" : "前",
    "start_offset" : 4,
    "end_offset" : 5,
    "type" : "CN_CHAR",
    "position" : 3
  }, {
    "token" : "trw-gdb7891at",
    "start_offset" : 9,
    "end_offset" : 22,
    "type" : "LETTER",
    "position" : 4
  }, {
    "token" : "刹车片",
    "start_offset" : 22,
    "end_offset" : 25,
    "type" : "CN_WORD",
    "position" : 5
  }, {
    "token" : "自带",
    "start_offset" : 25,
    "end_offset" : 27,
    "type" : "CN_WORD",
    "position" : 6
  }, {
    "token" : "报警",
    "start_offset" : 27,
    "end_offset" : 29,
    "type" : "CN_WORD",
    "position" : 7
  }, {
    "token" : "线",
    "start_offset" : 29,
    "end_offset" : 30,
    "type" : "CN_CHAR",
    "position" : 8
  }, {
    "token" : "无",
    "start_offset" : 31,
    "end_offset" : 32,
    "type" : "CN_WORD",
    "position" : 9
  }, {
    "token" : "单独",
    "start_offset" : 32,
    "end_offset" : 34,
    "type" : "CN_WORD",
    "position" : 10
  }, {
    "token" : "报警",
    "start_offset" : 34,
    "end_offset" : 36,
    "type" : "CN_WORD",
    "position" : 11
  }, {
    "token" : "线",
    "start_offset" : 36,
    "end_offset" : 37,
    "type" : "CN_CHAR",
    "position" : 12
  }, {
    "token" : "号码",
    "start_offset" : 37,
    "end_offset" : 39,
    "type" : "CN_WORD",
    "position" : 13
  }, {
    "token" : "卡",
    "start_offset" : 40,
    "end_offset" : 41,
    "type" : "CN_CHAR",
    "position" : 14
  }, {
    "token" : "仕",
    "start_offset" : 41,
    "end_offset" : 42,
    "type" : "CN_WORD",
    "position" : 15
  }, {
    "token" : "欧",
    "start_offset" : 42,
    "end_offset" : 43,
    "type" : "CN_WORD",
    "position" : 16
  }, {
    "token" : "卡",
    "start_offset" : 44,
    "end_offset" : 45,
    "type" : "CN_CHAR",
    "position" : 17
  }, {
    "token" : "仕",
    "start_offset" : 45,
    "end_offset" : 46,
    "type" : "CN_WORD",
    "position" : 18
  }, {
    "token" : "欧",
    "start_offset" : 46,
    "end_offset" : 47,
    "type" : "CN_WORD",
    "position" : 19
  }, {
    "token" : "乘用车",
    "start_offset" : 48,
    "end_offset" : 51,
    "type" : "CN_WORD",
    "position" : 20
  }, {
    "token" : "刹车片",
    "start_offset" : 52,
    "end_offset" : 55,
    "type" : "CN_WORD",
    "position" : 21
  } ]
}
2. 关键词查询
localhost:9200//yigo-redist.1/_analyze?analyzer=default_search&text=gdb7891
  •     索引为`yigo-redist.1`
  •     使用了索引`yigo-redist.1`中的分词器(`analyzer`) `default_search`
  •     解析的字符串(`text`)为"gdb7891"
返回结果:
{
  "tokens" : [ {
    "token" : "gdb7891",
    "start_offset" : 0,
    "end_offset" : 7,
    "type" : "LETTER",
    "position" : 1
  } ]
}
3. 关键词使用存储的分词器查询
localhost:9200//yigo-redist.1/_analyze?analyzer=default&text=gdb7891
  •     索引为`yigo-redist.1`
  •     使用了索引`yigo-redist.1`中的分词器(`analyzer`) `default_search`
  •     解析的字符串(`text`)为"gdb7891"
返回结果:
{
  "tokens" : [ {
    "token" : "gdb7891",
    "start_offset" : 0,
    "end_offset" : 7,
    "type" : "LETTER",
    "position" : 1
  }, {
    "token" : "",
    "start_offset" : 0,
    "end_offset" : 7,
    "type" : "LETTER",
    "position" : 1
  }, {
    "token" : "gdb7891",
    "start_offset" : 0,
    "end_offset" : 7,
    "type" : "LETTER",
    "position" : 1
  }, {
    "token" : "",
    "start_offset" : 0,
    "end_offset" : 3,
    "type" : "ENGLISH",
    "position" : 2
  }, {
    "token" : "gdb",
    "start_offset" : 0,
    "end_offset" : 3,
    "type" : "ENGLISH",
    "position" : 2
  }, {
    "token" : "gdb",
    "start_offset" : 0,
    "end_offset" : 3,
    "type" : "ENGLISH",
    "position" : 2
  }, {
    "token" : "7891",
    "start_offset" : 3,
    "end_offset" : 7,
    "type" : "ARABIC",
    "position" : 3
  }, {
    "token" : "7891",
    "start_offset" : 3,
    "end_offset" : 7,
    "type" : "ARABIC",
    "position" : 3
  }, {
    "token" : "",
    "start_offset" : 3,
    "end_offset" : 7,
    "type" : "ARABIC",
    "position" : 3
  } ]
}
总结
  •     通过步骤1可以看出,存储的数据"全能片(前)---TRW-GDB7891AT刹车片自带报警线,无单独报警线号码,卡仕欧,卡仕欧,乘用车,刹车片",被拆分成了很多词组碎片,然后存储在了索引数据中
  •     通过步骤2可以看出,当关键词输入"gdb7891",这个在检索分词器(`default_search`)下,没有拆分,只一个可供查询的碎片就是"gdb7891",但是步骤1,拆分的碎片里不存在"gb7891"的词组碎片,唯一相近的就是"trw-gdb7891at",所以使用普通的match-query是无法匹配步骤1输入的索引数据
  •     通过步骤3,可以看出如果使用相同的分词器,"gdb7891"能够拆分成"gdb","7891"等等,通过这2个碎片都能找到步骤1输入的索引数据,但是因为关键词被拆分了,所以会查询到更多的匹配的数据,比如:与"gdb"匹配的,与"7891"匹配的,与"gdb7891"匹配的
  •     如果说想通过分词器(`default_search`)检索出步骤1的数据,需要使用wildcard-query,使用"*gdb7891*",就可以匹配
      {      "query": {          "wildcard" : { "description" : "*gdb7891*" }      }  }