314被浏览31917分享邀请回答01 条评论分享收藏感谢收起ElasticSearch与大数据的不解情缘
你好，游客
ElasticSearch与大数据的不解情缘
来源：大讲台&
　　一、ElasticSearch 产生背景
　　1. 海量数据组合条件查询
　　2. 毫秒级或者秒级返回数据
　　Lucene 定义
　　lucene是一个开放源代码的全文检索引擎工具包，但它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎。
　　ElasticSearch 定义
　　ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
　　二、ElasticSearch vs Lucene
　　1. 成品与半成品的关系
　　2. Lucene专注于搜索底层的建设，而ElasticSearch专注于企业应用。
　　三、ElasticSearch vs Solr
　　Solr 定义：Solr是Apache 下的一个开源项目，使用Java基于Lucene开发的全文检索服务是一个独立的企业级搜索应用服务器，它对外提供类似于Web-service的API接口。用户可以通过http请求，向搜索引擎服务器提交一定格式的XML文件，生成索引;也可以通过Http Get操作提出查找请求，并得到XML格式的返回结果。
　　ElasticSearch vs Solr 优缺点
　　ElasticSearch vs Solr 检索速度
　　当单纯的对已有数据进行搜索时，Solr更快。
　　当实时建立索引时, Solr会产生io阻塞，查询性能较差, Elasticsearch具有明显的优势。
　　随着数据量的增加，Solr的搜索效率会变得更低，而Elasticsearch却没有明显的变化。
　　大型互联网公司，实际生产环境测试，将搜索引擎从Solr转到Elasticsearch以后的平均查询速度有了50倍的提升。
　　ElasticSearch vs Solr 热度
　　ElasticSearch vs Solr 总结
　　1. 二者安装都很简单。
　　2. Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能。
　　3. Solr 支持更多格式的数据，比如JSON、XML、CSV，而 Elasticsearch 仅支持json文件格式。
　　4. Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供
　　5. Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。
　　6. Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。
　　四、ElasticSearch vs 关系型数据库
　　五、ElasticSearch 架构
　　六、ElasticSearch 在Hadoop生态圈的位置
　　七、ElasticSearch 应用场景
　　1. 站内搜索：主要和 Solr 竞争，属于后起之秀
　　2. NoSQL Json文档数据库：主要抢占 Mongo 的市场，它在读写性能上优于 Mongo ，同时也支持地理位置查询，还方便地理位置和文本混合查询。
　　3. 监控：统计、日志类时间序的数据存储和分析、可视化，这方面是引领者
　　4. 国外：Wikipedia(维基百科)使用 ES 提供全文搜索并高亮关键字、Stack Overflow(IT问答网站)结合全文搜索与地理位置查询、Github使用Elasticsearch检索1300亿行的代码
　　5. 国内：百度(在云分析、网盟、预测、文库、钱包、风控等业务上都应用了ES，单集群每天导入30TB+数据，总共每天60TB+)、新浪 、阿里巴巴、腾讯等公司均有对ES的使用
　　6. 使用比较广泛的平台ELK(ElasticSearch, Logstash, Kibana)
相关新闻 & & &
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款　　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调优方法请参考：/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。其中各者具体区别，这里暂不赘述，只是抛砖引玉。
阅读(...) 评论()