因为总是看到很多同学在说elasticsearch性能不够好，集群不够稳定，询问关于elasticsearch的调优，但是每次都是一个个点的单独讲，很多时候都是case by case的解答，今天简单梳理下日常的elasticsearch使用调优，以下仅为自己日常经验之谈，如有疏漏，还请大家帮忙指正。

一、配置文件调优

elasticsearch.yml

内存锁定

bootstrap.memory_lock：true 允许 JVM 锁住内存，禁止操作系统交换出去。

zen.discovery

Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。组播发现应该永远不被使用在生产环境了，否则你得到的结果就是一个节点意外的加入到了你的生产环境，仅仅是因为他们收到了一个错误的组播信号。
ES是一个P2P类型的分布式系统，使用gossip协议，集群的任意请求都可以发送到集群的任一节点，然后es内部会找到需要转发的节点，并且与之进行通信。
在es1.x的版本，es默认是开启组播，启动es之后，可以快速将局域网内集群名称，默认端口的相同实例加入到一个大的集群，后续再es2.x之后，都调整成了单播，避免安全问题和网络风暴；
单播discovery.zen.ping.unicast.hosts，建议写入集群内所有的节点及端口，如果新实例加入集群，新实例只需要写入当前集群的实例，即可自动加入到当前集群，之后再处理原实例的配置即可，新实例加入集群，不需要重启原有实例；
节点zen相关配置：
discovery.zen.ping_timeout：判断master选举过程中，发现其他node存活的超时设置，主要影响选举的耗时，参数仅在加入或者选举 master 主节点的时候才起作用
discovery.zen.join_timeout：节点确定加入到集群中，向主节点发送加入请求的超时时间，默认为3s
discovery.zen.minimum_master_nodes：参与master选举的最小节点数，当集群能够被选为master的节点数量小于最小数量时，集群将无法正常选举。

故障检测（ fault detection ）

两种情况下回进行故障检测，第一种是由master向集群的所有其他节点发起ping，验证节点是否处于活动状态；第二种是：集群每个节点向master发起ping，判断master是否存活，是否需要发起选举。
故障检测需要配置以下设置使用
形如：
discovery.zen.fd.ping_interval 节点被ping的频率，默认为1s。
discovery.zen.fd.ping_timeout 等待ping响应的时间，默认为 30s，运行的集群中，master 检测所有节点，以及节点检测 master 是否正常。
discovery.zen.fd.ping_retries ping失败/超时多少导致节点被视为失败，默认为3。

https://www.elastic.co/guide/e ... .html

队列数量

不建议盲目加大es的队列数量，如果是偶发的因为数据突增，导致队列阻塞，加大队列size可以使用内存来缓存数据，如果是持续性的数据阻塞在队列，加大队列size除了加大内存占用，并不能有效提高数据写入速率，反而可能加大es宕机时候，在内存中可能丢失的上数据量。
哪些情况下，加大队列size呢？GET /_cat/thread_pool，观察api中返回的queue和rejected，如果确实存在队列拒绝或者是持续的queue，可以酌情调整队列size。

https://www.elastic.co/guide/e ... .html

内存使用

设置indices的内存熔断相关参数，根据实际情况进行调整，防止写入或查询压力过高导致OOM，
indices.breaker.total.limit: 50%，集群级别的断路器，默认为jvm堆的70%；
indices.breaker.request.limit: 10%，单个request的断路器限制，默认为jvm堆的60%；
indices.breaker.fielddata.limit: 10%，fielddata breaker限制，默认为jvm堆的60%。

https://www.elastic.co/guide/e ... .html

根据实际情况调整查询占用cache，避免查询cache占用过多的jvm内存，参数为静态的，需要在每个数据节点配置。
indices.queries.cache.size: 5%，控制过滤器缓存的内存大小，默认为10%。接受百分比值，5%或者精确值，例如512mb。

https://www.elastic.co/guide/e ... .html

创建shard

如果集群规模较大，可以阻止新建shard时扫描集群内全部shard的元数据，提升shard分配速度。
cluster.routing.allocation.disk.include_relocations: false，默认为true。

https://www.elastic.co/guide/e ... .html

二、系统层面调优

jdk版本

当前根据官方建议，选择匹配的jdk版本；

jdk内存配置

首先，-Xms和-Xmx设置为相同的值，避免在运行过程中再进行内存分配，同时，如果系统内存小于64G，建议设置略小于机器内存的一半，剩余留给系统使用。
同时，jvm heap建议不要超过32G（不同jdk版本具体的值会略有不同），否则jvm会因为内存指针压缩导致内存浪费，详见：
https://www.elastic.co/guide/c ... .html

交换分区

关闭交换分区，防止内存发生交换导致性能下降（部分情况下，宁死勿慢）
swapoff -a

文件句柄

Lucene 使用了 大量的 文件。 同时，Elasticsearch 在节点和 HTTP 客户端之间进行通信也使用了大量的套接字，所有这一切都需要足够的文件描述符，默认情况下，linux默认运行单个进程打开1024个文件句柄，这显然是不够的，故需要加大文件句柄数
ulimit -n 65536

https://www.elastic.co/guide/e ... .html

mmap

Elasticsearch 对各种文件混合使用了 NioFs（ 注：非阻塞文件系统）和 MMapFs （ 注：内存映射文件系统）。请确保你配置的最大映射数量，以便有足够的虚拟内存可用于 mmapped 文件。这可以暂时设置：
sysctl -w vm.max_map_count=262144
或者你可以在 /etc/sysctl.conf 通过修改 vm.max_map_count 永久设置它。

https://www.elastic.co/guide/c ... .html

磁盘

如果你正在使用 SSDs，确保你的系统 I/O 调度程序是配置正确的。 当你向硬盘写数据，I/O 调度程序决定何时把数据实际发送到硬盘。 大多数默认 nix 发行版下的调度程序都叫做 cfq（完全公平队列）。但它是为旋转介质优化的： 机械硬盘的固有特性意味着它写入数据到基于物理布局的硬盘会更高效。
这对 SSD 来说是低效的，尽管这里没有涉及到机械硬盘。但是，deadline 或者 noop 应该被使用。deadline 调度程序基于写入等待时间进行优化， noop 只是一个简单的 FIFO 队列。
echo noop > /sys/block/sd/queue/scheduler

磁盘挂载

mount -o noatime,data=writeback,barrier=0,nobh /dev/sd* /esdata*
其中，noatime，禁止记录访问时间戳；data=writeback，不记录journal；barrier=0，因为关闭了journal，所以同步关闭barrier；
nobh，关闭buffer_head，防止内核影响数据IO

磁盘其他注意事项

使用 RAID 0。条带化 RAID 会提高磁盘I/O，代价显然就是当一块硬盘故障时整个就故障了，不要使用镜像或者奇偶校验 RAID 因为副本已经提供了这个功能。
另外，使用多块硬盘，并允许 Elasticsearch 通过多个 path.data 目录配置把数据条带化分配到它们上面。
不要使用远程挂载的存储，比如 NFS 或者 SMB/CIFS。这个引入的延迟对性能来说完全是背道而驰的。

三、elasticsearch使用方式调优

当elasticsearch本身的配置没有明显的问题之后，发现es使用还是非常慢，这个时候，就需要我们去定位es本身的问题了，首先祭出定位问题的第一个命令：

hot_threads

GET /_nodes/hot_threads&interval=30s

抓取30s的节点上占用资源的热线程，并通过排查占用资源最多的TOP线程来判断对应的资源消耗是否正常，一般情况下，bulk，search类的线程占用资源都可能是业务造成的，但是如果是merge线程占用了大量的资源，就应该考虑是不是创建index或者刷磁盘间隔太小，批量写入size太小造成的。

https://www.elastic.co/guide/e ... .html

pending_tasks

GET /_cluster/pending_tasks

有一些任务只能由主节点去处理，比如创建一个新的 索引或者在集群中移动分片，由于一个集群中只能有一个主节点，所以只有这一master节点可以处理集群级别的元数据变动。在99.9999%的时间里，这不会有什么问题，元数据变动的队列基本上保持为零。在一些罕见的集群里，元数据变动的次数比主节点能处理的还快，这会导致等待中的操作会累积成队列。这个时候可以通过pending_tasks api分析当前什么操作阻塞了es的队列，比如，集群异常时，会有大量的shard在recovery，如果集群在大量创建新字段，会出现大量的put_mappings的操作，所以正常情况下，需要禁用动态mapping。

https://www.elastic.co/guide/e ... .html

字段存储

当前es主要有doc_values，fielddata，storefield三种类型，大部分情况下，并不需要三种类型都存储，可根据实际场景进行调整：
当前用得最多的就是doc_values，列存储，对于不需要进行分词的字段，都可以开启doc_values来进行存储（且只保留keyword字段），节约内存，当然，开启doc_values会对查询性能有一定的影响，但是，这个性能损耗是比较小的，而且是值得的；

fielddata构建和管理 100% 在内存中，常驻于 JVM 内存堆，所以可用于快速查询，但是这也意味着它本质上是不可扩展的，有很多边缘情况下要提防，如果对于字段没有分析需求，可以关闭fielddata；

storefield主要用于_source字段，默认情况下，数据在写入es的时候，es会将doc数据存储为_source字段，查询时可以通过_source字段快速获取doc的原始结构，如果没有update，reindex等需求，可以将_source字段disable；

_all，ES在6.x以前的版本，默认将写入的字段拼接成一个大的字符串，并对该字段进行分词，用于支持整个doc的全文检索，在知道doc字段名称的情况下，建议关闭掉该字段，节约存储空间，也避免不带字段key的全文检索；

norms：搜索时进行评分，日志场景一般不需要评分，建议关闭；

tranlog

Elasticsearch 2.0之后为了保证不丢数据，每次 index、bulk、delete、update 完成的时候，一定触发刷新 translog 到磁盘上，才给请求返回 200 OK。这个改变在提高数据安全性的同时当然也降低了一点性能。
如果你不在意这点可能性，还是希望性能优先，可以在 index template 里设置如下参数：
<br /> {<br /> "index.translog.durability": "async"<br /> }<br />

index.translog.sync_interval：对于一些大容量的偶尔丢失几秒数据问题也并不严重的集群，使用异步的 fsync 还是比较有益的。比如，写入的数据被缓存到内存中，再每5秒执行一次 fsync ，默认为5s。小于的值100ms是不允许的。
index.translog.flush_threshold_size：translog存储尚未安全保存在Lucene中的所有操作。虽然这些操作可用于读取，但如果要关闭并且必须恢复，则需要重新编制索引。此设置控制这些操作的最大总大小，以防止恢复时间过长。达到设置的最大size后，将发生刷新，生成新的Lucene提交点，默认为512mb。

refresh_interval

执行刷新操作的频率，这会使索引的最近更改对搜索可见，默认为1s，可以设置-1为禁用刷新，对于写入速率要求较高的场景，可以适当的加大对应的时长，减小磁盘io和segment的生成；

禁止动态mapping

动态mapping的坏处：
1.造成集群元数据一直变更，导致集群不稳定；
2.可能造成数据类型与实际类型不一致；
3.对于一些异常字段或者是扫描类的字段，也会频繁的修改mapping，导致业务不可控。
动态mapping配置的可选值及含义如下：
true：支持动态扩展，新增数据有新的字段属性时，自动添加对于的mapping，数据写入成功
false：不支持动态扩展，新增数据有新的字段属性时，直接忽略，数据写入成功
strict：不支持动态扩展，新增数据有新的字段时，报错，数据写入失败

批量写入

批量请求显然会大大提升写入速率，且这个速率是可以量化的，官方建议每次批量的数据物理字节数5-15MB是一个比较不错的起点，注意这里说的是物理字节数大小。文档计数对批量大小来说不是一个好指标。比如说，如果你每次批量索引 1000 个文档，记住下面的事实：
1000 个 1 KB 大小的文档加起来是 1 MB 大。
1000 个 100 KB 大小的文档加起来是 100 MB 大。
这可是完完全全不一样的批量大小了。批量请求需要在协调节点上加载进内存，所以批量请求的物理大小比文档计数重要得多。
从 5–15 MB 开始测试批量请求大小，缓慢增加这个数字，直到你看不到性能提升为止。然后开始增加你的批量写入的并发度（多线程等等办法）。
用iostat 、 top 和 ps 等工具监控你的节点，观察资源什么时候达到瓶颈。如果你开始收到 EsRejectedExecutionException ，你的集群没办法再继续了：至少有一种资源到瓶颈了。或者减少并发数，或者提供更多的受限资源（比如从机械磁盘换成 SSD），或者添加更多节点。

索引和shard

es的索引，shard都会有对应的元数据，且因为es的元数据都是保存在master节点，且元数据的更新是要hang住集群向所有节点同步的，当es的新建字段或者新建索引的时候，都会要获取集群元数据，并对元数据进行变更及同步，此时会影响集群的响应，所以需要关注集群的index和shard数量，建议如下：
1.使用shrink和rollover api，相对生成合适的数据shard数；
2.根据数据量级及对应的性能需求，选择创建index的名称，形如：按月生成索引：test-YYYYMM，按天生成索引：test-YYYYMMDD；
3.控制单个shard的size，正常情况下，日志场景，建议单个shard不大于50GB，线上业务场景，建议单个shard不超过20GB；

segment merge

段合并的计算量庞大， 而且还要吃掉大量磁盘 I/O。合并在后台定期操作，因为他们可能要很长时间才能完成，尤其是比较大的段。这个通常来说都没问题，因为大规模段合并的概率是很小的。
如果发现merge占用了大量的资源，可以设置：
index.merge.scheduler.max_thread_count: 1
特别是机械磁盘在并发 I/O 支持方面比较差，所以我们需要降低每个索引并发访问磁盘的线程数。这个设置允许 max_thread_count + 2 个线程同时进行磁盘操作，也就是设置为 1 允许三个线程。
对于 SSD，你可以忽略这个设置，默认是 Math.min(3, Runtime.getRuntime().availableProcessors() / 2) ，对 SSD 来说运行的很好。
业务低峰期通过force_merge强制合并segment，降低segment的数量，减小内存消耗；
关闭冷索引，业务需要的时候再进行开启，如果一直不使用的索引，可以定期删除，或者备份到hadoop集群；

自动生成_id

当写入端使用特定的id将数据写入es时，es会去检查对应的index下是否存在相同的id，这个操作会随着文档数量的增加而消耗越来越大，所以如果业务上没有强需求，建议使用es自动生成的id，加快写入速率。

routing

对于数据量较大的业务查询场景，es侧一般会创建多个shard，并将shard分配到集群中的多个实例来分摊压力，正常情况下，一个查询会遍历查询所有的shard，然后将查询到的结果进行merge之后，再返回给查询端。此时，写入的时候设置routing，可以避免每次查询都遍历全量shard，而是查询的时候也指定对应的routingkey，这种情况下，es会只去查询对应的shard，可以大幅度降低合并数据和调度全量shard的开销。

使用alias

生产提供服务的索引，切记使用别名提供服务，而不是直接暴露索引名称，避免后续因为业务变更或者索引数据需要reindex等情况造成业务中断。

避免宽表

在索引中定义太多字段是一种可能导致映射爆炸的情况，这可能导致内存不足错误和难以恢复的情况，这个问题可能比预期更常见，index.mapping.total_fields.limit ，默认值是1000

避免稀疏索引

因为索引稀疏之后，对应的相邻文档id的delta值会很大，lucene基于文档id做delta编码压缩导致压缩率降低，从而导致索引文件增大，同时，es的keyword，数组类型采用doc_values结构，每个文档都会占用一定的空间，即使字段是空值，所以稀疏索引会造成磁盘size增大，导致查询和写入效率降低。

1.Elasticsearch Ingest Node 与Logstash性能对比。
http://t.cn/EUQQ0EQ
2.方法：如何将rsyslog与Kafka和Logstash集成。
http://t.cn/EUQ8Lyy
3.(自备梯子)iPhone的黄金时代即将结束。
http://t.cn/EUQ86dB

编辑：至尊宝
归档：https://elasticsearch.cn/article/6201
订阅：https://tinyletter.com/elastic-daily 

1.滴滴Elasticsearch多集群架构实践。
[http://t.cn/EUNLkNU](http://t.cn/EUNLkNU)

2. 用es作为存储进行机器学习的python库。
   [http://t.cn/EUWeDoI](http://t.cn/EUWeDoI)
   
   
3. 一周热点：职场寒冬，给你讲四个小故事
   [http://t.cn/Eydyut9](http://t.cn/Eydyut9)
   
   
   • 编辑：bsll
     
     
   • 归档：https://elasticsearch.cn/article/6200
     
     
   • 订阅：https://tinyletter.com/elastic-daily
     

介绍

本次想和大家分享一款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 />
  

 
 https://github.com/unimassystem/elasticsearch-jdbc

	BasicDataSource basicDataSource = new BasicDataSource();

	// 创建连接池 一次性创建多个连接池



	// 连接池 创建连接 ---需要四个参数

	basicDataSource.setDriverClassName("com.elasticsearch.jdbc.ElasticsearchDriver");

	basicDataSource.setUrl("jdbc:elasticsearch://127.0.0.1:5000");



	// 从连接池中获取连接

	Connection conn = basicDataSource.getConnection();

	String sql = "select SRC_IP,SRC_PORT from \"my_test-*\"";

	Statement stmt = conn.createStatement();

	ResultSet rs = stmt.executeQuery(sql);

	while (rs.next()) {

		System.out.println(rs.getString("SRC_IP"));

	}

	basicDataSource.close();





	String sql = "select SRC_IP,SRC_PORT from my_test* where SRC_PORT between 10 and 100 limit 1000";

	String url = "jdbc:elasticsearch://127.0.0.1:5000";

	Connection connection = DriverManager.getConnection(url, "test", null);

	Statement statement = connection.createStatement();

	ResultSet rs = statement.executeQuery(sql);

	ResultSetMetaData meta = rs.getMetaData();

	String columns = "|";

	for (int i = 0; i < meta.getColumnCount(); i++) {

		columns += meta.getColumnLabel(i) + " | ";

	}

	System.out.println(columns);

	while (rs.next()) {

		String row = "|";

		for (int i = 0; i < meta.getColumnCount(); i++) {

			row += rs.getString(i) + " | ";

		}

		System.out.println(row);

	}   

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

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

具体解决方案：

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

       通用数据存储模型

关键字段
    ■ 业务核心字段，用于查询过滤
系统字段
    ■ version 避免高并发操作导致数据覆盖
大字段
    ■ order_data订单详情数据(JSON)
    ■ 可灵活需要索引的字段返回的字段
 
 
2、系统可用性
     系统可用性保障：双机房高可用如下图。
       
     数据可用性保障：
            一、异步多写保证数据一致性。
                
二、数据补充机制：
  1、每天凌晨task扫描数据库热表数据与es数据版本进行比较。
  2、将第三方推送过来数据中的，订单号即时插入订单同步队列表中。如果数据模型解析转换、持久化成功。删除队列中订单号。同时设置1分钟一次的task 扫描队列表。
  3、推送第三方的数据也采用同样的方式。保证给第三方数据的准确性。

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