ElasticSearch是现在技术前沿的大数据引擎，常见的组合有ES+Logstash+Kibana作为一套成熟的日志系统，其中Logstash是ETL工具，Kibana是数据分析展示平台。ES让人惊艳的是他强大的搜索相关能力和灾备策略，ES开放了一些接口供开发者研发自己的插件，ES结合中文分词的插件会给ES的搜索和分析起到很大的推动作用。ElasticSearch是使用开源全文检索库ApacheLucene进行索引和搜索的，说架构必须和Lucene的一些东西打交道。
关于Lucene：
　　ApacheLucene将写入索引的所有信息组织成一种倒排索引（Inverted Index）的结构之中，该结构是种将词项映射到文档的数据结构。其工作方式与传统的关系数据库不同，大致来说倒排索引是面向词项而不是面向文档的。且Lucene索引之中还存储了很多其他的信息，如词向量等等，每个Lucene都是由多个段构成的，每个段只会被创建一次但会被查询多次，段一旦创建就不会再被修改。多个段会在段合并的阶段合并在一起，何时合并由Lucene的内在机制决定，段合并后数量会变少，但是相应的段本身会变大。段合并的过程是非常消耗I/O的，且与之同时会有些不再使用的信息被清理掉。在Lucene中，将数据转化为倒排索引，将完整串转化为可用于搜索的词项的过程叫做分析。文本分析由分析器（Analyzer）来执行，分析其由分词器（Tokenizer），过滤器（Filter）和字符映射器（Character Mapper）组成，其各个功能显而易见。除此之外，Lucene有自己的一套完整的查询语言来帮助我们进行搜索和读写。
&　　[注]ES中的索引指的是查询/寻址时URI中的一个字段如：[host]：[port（9200）]/[index]/[type]/[ID]?[option]，而Lucene中的索引更多地和ES中的分片的概念相对应。
回到ElasticSearch，ES的架构遵循的设计理念有以下几个特征：
1.&合理的默认配置：只需修改节点中的Yaml配置文件，就可以迅捷配置。这和Spring4中对配置的简化有相似的地方。
2.&分布式工作模式：ES强大的Zen发现机制不仅支持组广播也支持点单播，且有&知一点即知天下&之妙。
3.&对等架构：节点之间自动备份分片，且使分片本身和样本之间尽量&远离&，可以避免单点故障。且Master节点和Data节点几乎完全等价。
4.&易于向集群扩充新节点：大大简化研发或运维将新节点加入集群所需的工作。
5.&不对索引中的数据结构增加任何限制：ES支持在一个索引之中存在多种数据类型。
6.&准实时：搜索和版本同步，由于ES是分布式应用，一个重大的挑战就是一致性问题，无论索引还是文档数据，然而事实证明ES表现优秀。
（一）分片策略
　　选择合适的分片数和副本数。ES的分片分为两种，主分片（Primary Shard）和副本（Replicas）。默认情况下，ES会为每个索引创建5个分片，即使是在单机环境下，这种冗余被称作过度分配（Over Allocation），目前看来这么做完全没有必要，仅在散布文档到分片和处理查询的过程中就增加了更多的复杂性，好在ES的优秀性能掩盖了这一点。假设一个索引由一个分片构成，那么当索引的大小超过单个节点的容量的时候，ES不能将索引分割成多份，因此必须在创建索引的时候就指定好需要的分片数量。此时我们所能做的就是创建一个新的索引，并在初始设定之中指定这个索引拥有更多的分片。反之如果过度分配，就增大了Lucene在合并分片查询结果时的复杂度，从而增大了耗时，所以我们得到了以下结论：
　　我们应该使用最少的分片！
　　主分片，副本和节点最大数之间数量存在以下关系：
　　节点数&=主分片数*（副本数+1）
&　 &控制分片分配行为。以上是在创建每个索引的时候需要考虑的优化方法，然而在索引已创建好的前提下，是否就是没有办法从分片的角度提高了性能了呢？当然不是，首先能做的是调整分片分配器的类型，具体是在elasticsearch.yml中设置cluster.routing.allocation.type属性，共有两种分片器even_shard,balanced（默认）。even_shard是尽量保证每个节点都具有相同数量的分片，balanced是基于可控制的权重进行分配，相对于前一个分配器，它更暴漏了一些参数而引入调整分配过程的能力。
　　每次ES的分片调整都是在ES上的数据分布发生了变化的时候进行的，最有代表性的就是有新的数据节点加入了集群的时候。当然调整分片的时机并不是由某个阈值触发的，ES内置十一个裁决者来决定是否触发分片调整，这里暂不赘述。另外，这些分配部署策略都是可以在运行时更新的，更多配置分片的属性也请大家自行Google。
（二）路由优化
　　ES中所谓的路由和IP网络不同，是一个类似于Tag的东西。在创建文档的时候，可以通过字段为文档增加一个路由属性的Tag。ES内在机制决定了拥有相同路由属性的文档，一定会被分配到同一个分片上，无论是主分片还是副本。那么，在查询的过程中，一旦指定了感兴趣的路由属性，ES就可以直接到相应的分片所在的机器上进行搜索，而避免了复杂的分布式协同的一些工作，从而提升了ES的性能。于此同时，假设机器1上存有路由属性A的文档，机器2上存有路由属性为B的文档，那么我在查询的时候一旦指定目标路由属性为A，即使机器2故障瘫痪，对机器1构不成很大影响，所以这么做对灾况下的查询也提出了解决方案。所谓的路由，本质上是一个分桶（Bucketing）操作。当然，查询中也可以指定多个路由属性，机制大同小异。
（三）ES上的GC调优
　　ElasticSearch本质上是个Java程序，所以配置JVM垃圾回收器本身也是一个很有意义的工作。我们使用JVM的Xms和Xmx参数来提供指定内存大小，本质上提供的是JVM的堆空间大小，当JVM的堆空间不足的时候就会触发致命的OutOfMemoryException。这意味着要么内存不足，要么出现了内存泄露。处理GC问题，首先要确定问题的源头，一般有两种方案：
　　1. 开启ElasticSearch上的GC日志
　　2. 使用jstat命令
　　3. 生成内存Dump
　　第一条:在ES的配置文件elasticsearch.yml中有相关的属性可以配置，关于每个属性的用途这里当然说不完。
　　第二条:jstat命令可以帮助我们查看JVM堆中各个区的使用情况和GC的耗时情况。
　　第三条:最后的办法就是将JVM的堆空间转储到文件中去，实质上是对JVM堆空间的一个快照。
　　想了解更多关于JVM本身GC调优方法请参考：http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
　　另外，通过修改ES节点的启动参数，也可以调整GC的方式，但是实质上和上述方法是等同的。
（四）避免内存交换
　　这一点很简单，由于操作系统的虚拟内存页交换机制，会给性能带来障碍，如数据写满内存会写入Linux中的Swap分区。
　　可以通过在elasticsearch.yml文件中的bootstrap.mlockall设置为true来实现，但是需要管理员权限，需要修改操作系统的相关配置文件。
（五）控制索引合并
　　上文提到过，ES中的分片和副本本质上都是Lucene索引，而Lucene索引又基于多个索引段构建（至少一个），索引文件中的绝大多数都是只被写一次，读多次，在Lucene内在机制控制下，当满足某种条件的时候多个索引段会被合并到一个更大的索引段，而那些旧的索引段会被抛弃并移除磁盘，这个操作叫做段合并。&
　　Lucene要执行段合并的理由很简单充分：索引段粒度越小，查询性能越低且耗费的内存越多。频繁的文档更改操作会导致大量的小索引段，从而导致文件句柄打开过多的问题，如修改系统配置，增大系统允许的最大文件打开数。总的来讲，当索引段由多一个合并为一个的时候，会减少索引段的数量从而提高ES性能。对于研发者来讲，我们所能做的就是选择合适的合并策略，尽管段合并完全是Lucene的任务，但随着Lucene开放更多配置借口，新版本的ES还是提供了三种合并的策略tiered，log_byte_size，log_doc。另外，ES也提供了两种Lucene索引段合并的调度器：concurrent和serial。其中各者具体区别，这里暂不赘述，只是抛砖引玉。
阅读(...) 评论()Elasticsearch到底能玩多大的数据量？ - 知乎351被浏览<strong class="NumberBoard-itemValue" title="4分享邀请回答slideshare.net/TinLe1/elk-atlinked-in linkedin的ELK演讲，单集群规模应该还没我大，不过也是有好多个集群。 Verizon的ELK演讲。1511 条评论分享收藏感谢收起156 条评论分享收藏感谢收起阅读(3318)
这个月初，正式开始做大数据相关工作，关于这一块，自己也是初生毛驴，不过慢慢来吧。
　　大数据大数据大数据，都特么被说烂了的词语，在做这个工作之前，我对它有诸多不解，并且我相信很多没有接触的人，一定会有和我一样的底层基础问题。
　　例如）hadoop输入源哪儿来：hadoop也是一个被玩烂的了的词语，我这边和ibm合作，由ibm提供硬件和hadoop环境，我们负责写hadoop的job，关于hadoop是干嘛的，如何搭建各种hadoop环境，网上早已经是烂大街，各种helloworld也是遍地都是，各种大神针对hadoop的各种文章五花八门，在之前我也看了非常多的hadoop文章，但是有一个问题至始至终都没有提到：所有的hadoop的文章都是把那个统计词语个数的例子拿来翻来覆去的讲，创建一个txt文本，然后去分析它，但是没有一个人提到，这个txt怎么来的，我们生产库是mysql，oracle这些关系库，它和txt没有半毛钱的关系，里面的数据如何交给hadoop分析？就是这么简单基础的问题，也许是我领悟低，各路大神都不屑于讲它，但它在我之前，就是实实在在困扰我的问题。
elasticsearch）
　　一）精确搜索
　　因为做的是数据分析的问题，所以搜索是一个精确查找的问题，当然不能使用联想搜索法，于是很自然的干掉分词法，但是我们知道，es自带smartcn分词法，也就是说不管如何，它都会给你分词，这可不是我想要的，放眼网上一看，都是如何使用第三方分词法替代es自己的分词法，像我这样的需求还真不好找。经过到大半夜的摸索，源码在手，何惧之有？找出三个解决办法：
　　1）删掉文件：不同es版本文件位置不一样，直接搜索smartcn删除所有相关分词文件，当然有风险。
　　2）创建序列的时候声明不分词：我们在创建es索引的时候，都是startObject()的方法，于是我们在里面增加filed，声明index为
not_analyzed，则能不使用分词，当然这个也有弊端，那就是如果有一天需要分词的时候，就需要重新创建索引了。
　　3）修改输入：这个方法乃上上之策，也是非常非常简单，那就是在es里面，如果你的字符串是被双引号括起来，那么es就认为是一个原子，不会被分词，也就是我们需要转义引号，一起作为搜索字符串传递给es，这个简单点办法，发现之后我居然仰天长啸，你个二b es，这个神气你居然藏着掖着。
　　二）es的filter
　　es的fiter着实让我纠结，由于时间有限，我需要在实现not的搜索，也就是不包含某个结果，我们知道在es里面使用queryBuilder条件去设定过滤条件，会出现长度溢出，最好的做法当然是filter，于是很自然的创建了filter：
BoolFilterBuilder notFilter = FilterBuilders.boolFilter().mustNot(FilterBuilders.termsFilter("body", "fedde").cache(false));
　　在es里面的filter有两类，not,or,and等这一类，还有一类是bool等这一类，他们的区别就是是否会使用es内部核心大数组，在性能下优先考虑bool类，因为它会使用内部数组，这个filter有个核心的坑就是仅仅只有body完全等于输入字符串的时候，才能被not，我觉得es不会没有解决这个问题，或许是我没有发现，时间有限，直接手动修改hits。。
　　三）es的and
　　我们在实现es的and功能的时候，一般也是建立filter，并且es内部提供了and操作，我们理想的and操作就是将我们的多个输入得到并结果，于是filter的建立如下：
QueryFilterBuilder queryFilterBuilder = FilterBuilders.queryFilter(QueryBuilders.multiMatchQuery(value, eachStringQueryRequest.getQueryFiled()).operator(MatchQueryBuilder.Operator.AND).minimumShouldMatch(Global.MARCHPERCENT));
　　但是结果却始终不正确，都是or的结果，于是我一度恼火，后来发现这个坑，妈蛋的，multiMatchQuery这个方法传递两个参数，一个是object的输入，一个是可变长的es的filed的名字，原来es的and，是and它的可变长filed，而不是我们自己的多个输入。
　　四）感悟
　　所谓数据分析挖掘，自己的感觉就是从同一个通道进去，每个人根据自己不同的角色，配置不同的工作流，从数据源里面产生自己需要的分析报告，所有人用的四同一个数据同一个通道，但是根据不同的需求，能够产生不同的结果，就是这么简单。。。
　　五）小东西还的玩
　　在还没有做大数据的时候，我就有一个想法，那就是我们从出生到死去，所有的人生记录都被记录在不同的系统，甚至我们的每一次刷卡每一次买书每一次上厕所都有登记，那么只要我们能够合并这些数据，就能够计算一个人的人生轨迹。。
　　这个数据有啥好处？当然我们有了这些数据，我们就可以逆向计算出一个人的成长，分析一个人的梦想。。
　　比如：
　　我输入10年后要成为科学家，那么系统能够根据足够的例子计算出，8年后要达到什么水平，5年后要成为什么，3年内要得到什么经验，从而推出今年应该考取什么证书，现在应该开始读哪本书。。。。
　　六）书不能不读
　　一直以来自己都想给自己量身做一款app用来定制自己的作息时间与学习轨迹，但是做了很多都不满意，都删除了，最近打算只做读书记录这一块，功能很简单，记录某本书读到那个位置，预定在哪个时间段读取哪本书，并且到点了提醒读书，没了。。
　　android5的控件ui很漂亮，代码丢在：
　　刚刚起步开始写，后面慢慢push代码吧，毕竟个人爱好嘛，留几张图：
　　原文链接:
阅读排行榜使用elasticsearch的scroll和scan解决深度分页问题 | 峰云就她了
10,990 views
使用ElasticSearch的scroll和scan解决大数据集合问题
我的连接，http://xiaorui.cc/?p=3072
内容概要, 主要是解决在ElasticSearch中大数据集合的查询需求，可以使用scroll scan可以较轻松的遍历elasticsearch的某个index.
深度分页那些事
我们知道ElasticSearch的深度分页是相当没有效率的，这根mongodb的limit skip分页一个道理! 什么是深度分页？ 使用es的from和size语法来进行范围取值。 比如size=10&from=5000 ，这就是深度分页的用法。 我为了你想要的size 10个数据，es首先会扫描shard分片进行匹配并排序数据，之后算出5000个。这样就能拿到你想要那10个数据。&
但是每次都这样是否很蛋疼？ 所以ElasticSearch就有了scroll的概念.&
elasticsearch的scroll是什么？&
可以简单理解为mysql的cursor游标，比如你一次请求的数据会很大，可以使用scroll这样的流式接口，scroll会把你的所需要的结果标记起来。
但是这scroll的查询还是会对数据进行排序的，这样会影响性能。 &如果你只是单纯的想要数据，那么可以使用scan，因为scan会告诉 elasticsearch 不去排序。scan模式会扫描shard分片中的数据,单纯的扫除匹配，而不会像scroll进行排序处理。&
如果没有排序的深度分页需求，最好使用 scan scroll的组合。
scan scroll的流式接口用法很是简单,在url里扩充字段 search_type 是scan类型，scroll是3分钟，当次查询的结果会在elasticsearch标记3分钟。&
这里的size 1000个会在每个shard起到作用。 &并不是把所有结果限制为1000个 ！ 如果你的分片数目有10个，那么你最多可以拿到 1000 * 10的数据。
该文章写的有些乱，欢迎来喷 ! 另外文章后续不断更新中，请到原文地址查看更新。
例子我就不用python elasticsearch库了，直接用curl了演示，下面是请求体:
#xiaorui.cc
curl -XGET xiaorui.cc:9200/blog/breif/_search?pretty&search_type=scan&scroll=3m -d
{"size":1000,"query":{"match_all":{}}}
#xiaorui.cccurl -XGET xiaorui.cc:9200/blog/breif/_search?pretty&search_type=scan&scroll=3m -d {"size":1000,"query":{"match_all":{}}}
#xiaorui.cc
"_scroll_id": : "UVM4U0NMd2sdfcvrtrtpjWlJ3YWlBOzExOTpRNV9aY1VyUVM4U0NMd2pjWlJ3YWlBOzExNjpRNV9aY1VyUVM4U0NMd2pjWlJ3YWlBOzExNzpRNV9sdfou4kjldsfkoicvuefldfjldfgjaY1VyUVM4U0NMd2pjWlJ3YW",
"took" : 1,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"failed" : 0
"hits" : {
"total" : 0,
"max_score" : null,
"hits" : [ ]
12345678910111213141516
#xiaorui.cc{&&"_scroll_id": : "UVM4U0NMd2sdfcvrtrtpjWlJ3YWlBOzExOTpRNV9aY1VyUVM4U0NMd2pjWlJ3YWlBOzExNjpRNV9aY1VyUVM4U0NMd2pjWlJ3YWlBOzExNzpRNV9sdfou4kjldsfkoicvuefldfjldfgjaY1VyUVM4U0NMd2pjWlJ3YW",&&"took" : 1,&&"timed_out" : false,&&"_shards" : {&&&&"total" : 5,&&&&"successful" : 5,&&&&"failed" : 0&&&&}&&&&"hits" : {&&&&&&"total" : 0,&&&&&&"max_score" : null,&&&&&&"hits" : [ ]&&&&}}&&
如果你想设定更多的时间:
Time&&&&Unitsy&& YearM&& Monthw&& Weekd&& Dayh&& Hourm&& Minutes&& Second
注意: 第一次的查询结果只能拿到scroll_id token，并没有数据。 接着我们可以拿着这个token继续去访问，我们就能拿到真实命中的数据。 这个token只能访问一次，切记&#8230;&
curl –XGET 'localhost:9200/_search/scroll?scroll=2m&pretty&scroll_id=UVK8sdfdfgNMSDF2pcRaftJKHlovaMNDSF4M4U0NMd2pjWlJ3YWlBOzExOTpRNV9aY1VyUVM4U0NMd2pjWlJ3YWlBOzExNjpRNV9aY1VyUVM4U0NMd2pjWlJ3YWlBOzExNzpRNV9sdfou4kjldsfkoicvuefldfjldfgjaY1VyUVM4U0NMd2pjWlJ3YW'
curl –XGET 'localhost:9200/_search/scroll?scroll=2m&pretty&scroll_id=UVK8sdfdfgNMSDF2pcRaftJKHlovaMNDSF4M4U0NMd2pjWlJ3YWlBOzExOTpRNV9aY1VyUVM4U0NMd2pjWlJ3YWlBOzExNjpRNV9aY1VyUVM4U0NMd2pjWlJ3YWlBOzExNzpRNV9sdfou4kjldsfkoicvuefldfjldfgjaY1VyUVM4U0NMd2pjWlJ3YW'
检索下一批结果在url里面不用再写index、type。 每一次对scrollAPI的请求都会返回结果的下一批直到没有更多的结果返回为止。比如，当hits数组为空的时候。 这样每次的查询都会拿到一个scroll token和response hits结果集。
如果你想删除scroll id，那么可以调用delete方法删除. &除非是你的scan任务特别的，一般scroll设立个5分钟就可以了。
#xiaorui.cc
curl –XDELETE 'localhost:9200/_search/scroll -d "UVK8sdfdfgNMSDF2pcRaftJKHlovaMNDSF4M4U0NMd2pjWlJ3YWlBOzExOTpRNV9aY1VyUVM4U0NMd2pjWlJ3YWlBOzExNjpRNV9aY1VyUVM4U0NMd2pjWlJ3YWlBOzExNzpRNV9sdfou4kjldsfkoicvuefldfjldfgjaY1VyUVM4U0NMd2pjWlJ3YW"
#xiaorui.cccurl –XDELETE 'localhost:9200/_search/scroll -d "UVK8sdfdfgNMSDF2pcRaftJKHlovaMNDSF4M4U0NMd2pjWlJ3YWlBOzExOTpRNV9aY1VyUVM4U0NMd2pjWlJ3YWlBOzExNjpRNV9aY1VyUVM4U0NMd2pjWlJ3YWlBOzExNzpRNV9sdfou4kjldsfkoicvuefldfjldfgjaY1VyUVM4U0NMd2pjWlJ3YW"
对于ElasticSearch大批量数据分页的方法就说这么多了，尽量别用深度分页那性能真的是没谁了。 找个时间把python elasticsearch库的scan scroll讲解说一遍。
对Python及运维开发感兴趣的朋友可以加QQ群 ：
!!! { 2000人qq大群内有各厂大牛，常组织线上分享及沙龙，对高性能及分布式场景感兴趣同学欢迎加入该QQ群
另外如果大家觉得文章对你有些作用！ &
帮忙点击广告. 一来能刺激我写博客的欲望，二来好维护云主机的费用.
如果想赏钱，可以用微信扫描下面的二维码. 另外再次标注博客原地址 && …… &&感谢！
您可能也喜欢:
上篇文章已经讲过elasticsearch scan scroll的用途， 他们是用来解决获取大数据返回时的性能问题. &有兴趣的朋友可以回顾下 scan，scroll的作用一篇....Elasticsearch到底能玩多大的数据量？ - 知乎351被浏览<strong class="NumberBoard-itemValue" title="4分享邀请回答11 条评论分享收藏感谢收起