我的ElasticSearch集群部署总结--大数据搜索引擎你不得不知-其它-@大数据资讯
你好，游客
我的ElasticSearch集群部署总结--大数据搜索引擎你不得不知
来源：博客园-原创精华区&
三类书籍 和 两类知识：
& & &有一些书是对某一新知识领域的介绍，将此知识领域从头到尾、从内而外剖开了分析，吸收这些知识主要在于&记忆&，（也有&领会&）。而有一些&好书，往往整本书就是在阐述一句或几句话，一个或数个思想，这些就是这本书最重要的部分，主要在于&领会&。还有一些书可能就像是工具，例如字典，遇到问题去查就好，主要在&查找&。也有各种类型掺杂的书。这几类书各有其方向、着重点，阅读时方法也不尽相同。
& & &对于各种林林总总的技术，无论是它的安装步骤、使用说明还是其疑难杂症，电子书、在网络中的文章及FAQ中总是会有解决办法；或者技术它存有尚未解决的问题、待修复的BUG，也大部分能在网上找到答案，（不能找到的就等你来发明和创造了，诺贝尔奖就靠你咯！）。上面这些都属于&techknowledge(技术)&的范畴，就像第一类或第三类书，主要在于&记忆&或&查找&。可是，还有一些思想上的、认知上的东西，网上是很难获取的，也很不容易表达清楚，它们应该归类于&Thinking(思想)&，像是第二类书籍，重点在于&领会&。在分享&techknowledge(技术)&的同时，我更希望把这些&Thinking(思想)&分享出来。
& & &以下是我在&部署&ElasticSearch集群时的经验总结，它们大体属于第一类知识&techknowledge(技术)&&。但其中也穿插一些我个人的理解。敬请指正。
〇、环境配置
服务器：3台（node1&-&&node3）
操作系统：Cent&OS&5.6，添加普通用户deploy
ElasticSearch版本：1.7.1
JDK版本：1.8
一、安装JDK（所有服务器）
在每台服务器（node1&-&&node3）上安装JDK，安装过程略。
以下二至六步可以选取某台服务器执行。
二、安装ElasticSearch
1、下载elasticsearch-1.7.1.tar.gz
2、解压：[&~]$&tar&-xf&elasticsearch-1.4.2.tar.gz
三、安装elasticsearch-head插件
elasticsearch-head是一个elasticsearch的集群管理工具,它是完全由html5编写的独立网页程序。
1、联网环境，执行下面语句进行安装：
[&~]$&./elasticsearch-1.7.1/bin/plugin&-install&mobz/elasticsearch-head
2、离线安装：
[&~]$&unzip&elasticsearch-head-master.zip
[&~]$&mkdir&./elasticsearch-1.7.1/plugins
[&~]$&mkdir&./elasticsearch-1.7.1/plugins/head
[&~]$&mkdir&./elasticsearch-1.7.1/plugins/head/_site
[&~]$&cp&-r&~/elasticsearch-head-master/*&./elasticsearch-1.7.1/plugins/head/_site
在执行：[&~]$&./elasticsearch-1.7.1/bin/elasticsearch
启动ElasticSearch后，可以通过访问：&http://&node1&:9200/_plugin/&head&/&，
可以看到如下图：
四、安装elasticsearch-sql插件
elasticsearch-sql插件可以做到：Query&elasticsearch&using&familiar&SQL&syntax.&You&can&also&use&ES&functions&in&SQL.
执行下面语句进行安装：
[&~]$&./bin/plugin&-u&/NLPchina/elasticsearch-sql/releases/download/1.3.5/elasticsearch-sql-1.3.5.zip&--install&sql
在启动ElasticSearch后，可以通过访问：&http://localhost:9200/_plugin/&sql&/&，
可以看到如下图：
看到这个界面你也能想像到它是做什么的了吧？更多的信息可以去&/NLPchina/elasticsearch-sql&获取，当然不能通过elasticsearch-sql把elasticsearch当关系型数据库用，但毕竟elasticsearch的查询语句不如solr那般简洁，所以对于熟悉sql的朋友，这样拼sql语句也是很方便的吧。此工具的开发者真是体贴。
五、安装elasticsearch-Bigdesk插件
bigdesk是elasticsearch的一个集群监控工具，可以通过它来查看es集群的各种状态，如：cpu、内存使用情况，索引数据、搜索情况，http连接数等。
1、联网环境
[&~]$&./bin/plugin&-install&lukas-vlcek/bigdesk
在启动ElasticSearch后，可以通过访问：&http://&node1:&9200/_plugin/bigdesk/&，
可以看到如下图：
这个插件使得elasticsearch太直观了，数据在哪、怎么变动的都显示的一清二楚，大赞！为啥Solr没有这样的东东呢？
六、安装elasticsearch-servicewrapper插件
elasticsearch-servicewrapper插件是ElasticSearch的服务化插件。
在/elasticsearch/elasticsearch-servicewrapper下载该插件后，解压缩。将service目录拷贝到elasticsearch目录的bin目录下。
而后，可以通过执行以下语句安装、启动、停止ElasticSearch。（先不要执行）
[&service]#&sh&elasticsearch&install (Must&be&root&to&perform&this&action.)
[&service]#&sh&elasticsearch&start
[&service]#&sh&elasticsearch&stop
这个插件也是实用的不要不要的。没有此插件，有多少人还要写一个脚本来开机启动啊。需要的请举手！
七、将配置好的ElasticSearch拷贝到各服务器
在一台服务器上执行完成步骤二到步骤七后，得到最终的elasticsearch-1.7.1文件夹。将此文件夹打包并scp拷贝到各服务器。
八、配置ElasticSearch集群
在各服务器（node1&-&&node3）中。
执行下面语句对配置文件elasticsearch.yml中的内容进行修改：
[&~]$&vim&elasticsearch-1.7.1/config/elasticsearch.yml
修改elasticsearch.yml后的部分文件内容：
###################################&Cluster&###################################
#&Cluster&name&identifies&your&cluster&for&auto-discovery.&If&you're&running
#&multiple&clusters&on&the&same&network,&make&sure&you're&using&unique&names.
cluster.name:&elasticsearch_deploy
####################################&Node&#####################################
#&Node&names&are&generated&dynamically&on&startup,&so&you're&relieved
#&from&configuring&them&manually.&You&can&tie&this&node&to&a&specific&name:
node.name:&"node196"
九、启动ElasticSearch集群
可以通过执行sh&elasticsearch&start或./elasticsearch语句启动ElasticSearch。
也可以在通过执行[&service]#&sh&elasticsearch&install后，通过执行：[&service]#&chmod&777& /home/deploy/elasticsearch-1.7.1/bin/service/elasticsearch，分配给elasticsearch执行权限。执行[&service]#&/etc/init.d/elasticsearch&start启动ElasticSearch服务。而后就可以执行[&service]#&service&elasticsearch&start来启动ElasticSearch了。系统reboot后也能开机启动。
在所有服务器（node1&-&&node3）上的ElasticSearch配置相同的cluster.name后，依次启动各服务器上的ElasticSearch，便可以通过bigdesk查看该集群下的所有node状态。集群启动结束。
十、ElasticSearch集群功能测试
可以在head页面新建索引、删除索引、数据浏览、查询等操作，新建索引时需要设置分片数、副本数，可以在bigdesk页面进行分片及副本的查看。
数据均存储于elasticsearch-1.7.1/data目录下，以cluster.name进行分目录存储。下图说明了两个cluster.name的存储方式。
我们对已启动的（node1&-&&node3）上的ElasticSearch进行监控。下面图1&-&&图4是当集群中一个node重启时，集群内数据复制移动的过程。索引的分片数为5，副本数为1。
图1:&三个node稳定后&
& & 图2:&关闭一个node196
图3:&两个node稳定后&
& & &图4:&启动node196，恢复三个node稳定后
可以通过上面的操作和形象的图形，看到宕机一个对这个集群真是一点关系都没有，数据在各服务器间自如流动、分布，各服务器并无主次之分。
Solr我也用过很久，我个人感觉，ElasticSearch比Solr好就好在有那么多好用的插件可以用，即有形象直观的显示，又有方便实用的工具，真是感谢这些开源贡献者们，没有你们就没有这么一个好用的搜索引擎&ElasticSearch了，很多的公司业务也便无法开展了！当然&ElasticSearch目前也有不少亟需解决的问题，以后有空再聊。
相关新闻 & & &
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款Loggly日志管理服务在其很多核心功能里使用ElasticSearch作为搜索引擎。Jon Gifford在其文章&ElasticSearch vs Solr&中指出，日志管理领域对搜索技术有了更高的要求。总的来说，它必须能够：
可靠地进行大规模实时索引－对我们来说，每秒处理10万条以上日志数据；
高性能、可靠地处理同一索引上的高并发搜索请求。
当我们搭建Gen2日志管理服务时，我们对ElasticSearch的各项配置信息进行了反复研究，以便能获得索引和搜索的最高性能。不幸的是，这些配置项散落各处，一一找到它们并不容易。这篇文章总结了我们的经验，您可以参考本文列出的这些项，优化ES在您应用中的使用效果。
技巧1:在开始前，要搞清楚部署拓扑结构
Loggly 使用ES 0.90.13，采用主节点与数据节点相互分离的部署拓扑结构，这里我们不过多讲解其中的细节，但我们要强调的是在决定如何配置之前，你要对部署拓扑结构非常清晰。
此外，我们使用ES节点客户端（ES node client）与数据节点交互。这使得客户端对数据节点是透明的；它只关心与节点客户端（node client）的交互。要设置节点为主节点还是数据节点，只需要通过将两个属性设置为true或false。例如要设置一个ElasticSearch为数据节点，可以这样设置：
node.master:false 和node.data: true
很容易对吧。那么下面我们将讨论一些你可能感兴趣的ES高级属性。在大部分情况下，ES的默认配置都是够用的，但如果你想让你的服务表现不论何时都能像我们看到的高性能日志管理服务一样，那下面的建议就对你有用了。
技巧2:mlockall属性是获取性能效率回报的终极武器
Linux将它的物理内存（RAM）分成一组称为pages的内存块。而Swapping是将内存页拷贝到硬盘上一块预定义空间（swapspace，交换空间），从而释放内存的处理过程。物理内存和交换空间的合并大小是可用的虚拟内存的数量。
Swapping有个缺点。与内存相比，磁盘速度很慢。内存速度以纳秒计，而硬盘速度却以毫秒计；所以访问磁盘的时间开销是访问内存的数十万倍。访问磁盘次数越多，性能就越慢，所以要想方设法避免Swapping。
mlockall 属性可以让ES节点不进行Swapping。（注意仅适用于Linux／Unix系统）。这个属性可以在yaml文件中设置。
bootstrap.mlockall:true
mlockall 默认是false的，意味着ES节点被允许Swapping。注意，如果你在文件中设置了该属性，就必须重启ES节点。你可以通过执行以下语句查看属性设置是否生效：
curlhttp://localhost:9200/_nodes/process?pretty
如果你决定设置这个属性，一定确保通过-DXmx选项或ES_HEAP_SIZE给ES节点预留足够的内存。
技巧3: discovery.zen 属性集合控制ElasticSearch的发现协议
Zen发现协议用于ElasticSearch发现集群中的其它节点，并建立通讯。discovery.zen.*属性集合构成了zen发现协议。单播和多播均是发现协议的有效组成部分：
1、多播是指当发送一个或多个请求给所有节点时，集群中的节点将被发现。
2、单播是在节点和discovery.zen.ping.unicast.hosts中的IP地址之间的一对一连接。
为了使单播生效，你需要将discovery.zen.ping.multicast.enabled设置为false。还需要通过discovery.zen.ping.unicast.hosts来设置一组主机域名，其中应包含用于通信的主节点域名。
discovery.zen.minimum_master_nodes用于设置为了进行集群操作，一个节点需要能看见&see&的最小数量的合格主节点。强烈建议在集群中超过2个节点时，将该值设置为比1大的值。该值的一个计算方法是N/2+ 1，N是主节点数量。
数据节点和主节点通过以下两种不同方式相互检查：
主节点通过pinging集群中所有其它节点，判断它们是否正常运行；
所有其它节点通过pinging主节点确认它们是否正常运行，否则就需要启动选举程序。
节点检测过程由discover.zen.fd.ping_timeout属性控制。该属性定义了节点等待反馈的最长时间，默认值是30s。如果你的网速条件不好，需要适当调整该值大小。如果网速很慢，这个值应该设置更高一些。值越高，发现失败的可能性就越小。
Loggly设置discovery.zen属性集合如下：
discovery.zen.fd.ping_timeout:30s
discovery.zen.minimum_master_nodes:2
discovery.zen.ping.multicast.enabled:false
discovery.zen.ping.unicast.hosts:[&esmaster01&P,&esmaster02&P,&esmaster03&P]
以上属性的含义是，节点检测超时为30s，通过设置discovery.zen.fd.ping_timeout即可。此外，至少两个主节点要能被其它节点检测到（我们一共3个主节点）。采用单播协议，单播域名列表是：esmaster01,esmaster02, esmaster03。
技巧4:谨慎对待delete_all_indices！
有个特别重要的事情是ES中的curl API并没有内置很好认证机制。一共简单的curlAPI就能导致索引全部被删，丢失所有数据。下面就是一个会导致误删的指令：
curl-XDELETE &http://localhost:9200/*/&
为了避免这样的悲剧发生，你只需要设置以下属性：
action.disable_delete_all_indices:true.
这个属性可以确保即便以上curl指令被执行，也不会删除索引导致错误。
技巧5: 字段数据缓存会导致极慢的分类搜索（facet search）
这是ElasticSearch指南中如何描述字段数据缓存的：
&&&&&&&&字段数据缓存主要用在对一个字段进行排序或分类时。它将把所有字段值加载到内存。为一个字段建立字段数据缓存将是代价高昂的，需要分配足够的内存，确保能完全加载。
你要牢记，该值设置不当将导致：
分类搜索和排序性能低下
如果你对很大的索引进行分类查询，将导致ES节点内存溢出
indices.fielddata.cache.size:25%
在设置这个值时，关键要考虑你的应用将要进行什么类型分类搜索。
技巧6: 优化索引请求
在Loggly，我们构建了自己的索引管理系统，因为日志管理的本质意味着将有频繁的更新和映射关系变更。这个索引管理系统的功能就是管理ES集群的索引。当索引需要根据现有配置策略被创建或关闭时，它会做检查。索引管理有很多策略。例如，当索引大小增长到特定值或者存在时间超过某个时间值，索引管理系统将关闭旧的，创建新的。
&&&&&&&&本文由日志帮（公众号id：rizhibang）翻译整理。
当索引管理系统发送一个索引请求给节点处理时，节点更新它自己的映射关系表并发给主节点。主节点会发送给那个节点一共更旧版本的映射关系表。如果有冲突，并不是坏事（也就是说集群实际上有正确的映射关系表），我们只需要从这个节点向主节点发送一个更新。为了索引请求更高效，我们在数据节点上设置了这个属性。
indices.cluster.send_refresh_mapping:false
而反过来，发送更新的映射关系表更重要，因为某些原因，主节点上的映射关系表与实际节点上的冲突。这种情况，更新映射关系表将会在主节点上记录一个警告。
技巧7: 教你使用ElasticSearch分配相关属性
分片（Shard）分配是分配分片给节点的处理过程。这可能发生在初始恢复、副本分配或再平衡过程中。也可能发生在添加或删除节点时。
cluster.routing.allocation.cluster_concurrent_rebalance属性指定用于并发再平衡的分片数。此属性的设置要取决于硬盘条件，如CPU数量，IO性能等。如果该属性设置不当，将影响ElasticSearch索引性能。
cluster.routing.allocation.cluster_concurrent_rebalance:2
该值默认为2，意思是任何时间点，只能有2个分片被移动。该值设置低一些，能降低分片再平衡，从而避免影响索引。
另一个分片分配属性是cluster.routing.allocation.disk.threshold_enabled。如果该属性设置为true，在给节点分配分片时将考虑磁盘空间。
当设置为true时，分片分配会考虑两种情况：低位值、高位值。
低位值对应的磁盘使用率， 达到后ES不再分配新分片。在下面的例子中，磁盘使用率97%时，ES将停止分配分片
高位值对应的磁盘使用率，达到后分片开始移出节点（下面示例中为99%）
cluster.routing.allocation.disk.threshold_enabled:true
cluster.routing.allocation.disk.watermark.low:.97
cluster.routing.allocation.disk.watermark.high:.99
技巧8:设置恢复相关属性可以缩短重启时间
ES包含几个恢复相关的属性项，使用它们可以改进ElasticSearch集群的恢复和重启时间。我们下面将展示几个简单的示例。对你来说，最佳的值取决于正在使用的硬件条件，我们能给的建议就是测试、测试，还是测试。
这个属性定义的是，在任何时间，一个节点可以有多少分片被用于执行恢复。回收分片是一个IO密集型操作，所以需要谨慎设置该属性值。
cluster.routing.allocation.node_initial_primaries_recoveries:18
这个属性控制的是单个节点上同时初始化的主要分片（primaryshards）数量。从节点传输到对等节点的回收分片的平行流数量是由indices.recovery.concurrent_streams属性控制。下面的值是给亚马逊云的实例设置的，如果你是使用了自己的硬件，这个值可能需要设置更高。max_bytes_per_sec属性用于设置每秒传输多少字节，这个属性也是需要根据硬件条件来配置的。
indices.recovery.concurrent_streams:4
indices.recovery.max_bytes_per_sec:40mb
所有上述属性，需要在重启集群后生效。
技巧9:Threadpool属性防止数据丢失
ES节点有几个threadpools属性，用于改进节点内管理的线程数量。在Loggly，我们广泛使用块请求（bulkrequest），我们发现使用threadpool.bulk.queue_size属性给批量线程池设置正确的数值至关重要，能避免数据丢失或者批量重试。
threadpool.bulk.queue_size:3000
这个属性值是关于块请求的。它指定了在没有更多线程来处理批量请求时，ES节点队列中等待处理的请求数。根据你的块请求负载情况设置该值。如果你的块请求数量比这个值高，你将收到像下方示例中的一个RemoteTransportException异常。
注意，在ES中，块请求队列中，一个分片对应一个的项，所以如果你想发送的块请求数包含很多给分片的数据项，那么这个属性的数值需要设置为比你要发送的批量请求数更高的数值。例如，单个块请求中包含了10个分片的数据项，那即使你只发送一个块请求，也必须至少将队列大小设置为10。这个值设置过大，会消耗你的JVM堆，但却可以让ES充分发挥队列功效，解放你的客户端。
你要么把这个值设置高一些，要么在客户端妥善处理好RemoteTransportException异常。如果没有妥善处理异常，你将丢失数据。下面我们将通过发送超过10个块请求（队列值设置为10）的方式模拟展示异常。
RemoteTransportException[[&Bantam&][inet[/192.168.76.1:9300]][bulk/shard]];nested: EsRejectedExecutionException[rejected execution (queue capacity 10) on org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$1@13fe9be];
总结：ES的配置属性对它的灵活伸缩性至关重要
ElasticSearch配置项对其有效性越深入，Loggly的收益也就越大，因为在我们的使用案例中，已经将ES的设计参数用到了极致（有时更甚，后续文章我们将继续分享）。如果在使用默认配置的情况下，已经能满足你应用现阶段需要，那么请放心，随着应用增长，你还有很大的优化空间。
原文地址：
译者：日志帮（微信ID：rizhibang）
阅读(...) 评论()6被浏览333分享邀请回答0添加评论分享收藏感谢收起elasticsearch（1）
elasticsearch以集群配置的简便、搜索性能、分布式存储吸引这不少用户。不过通过晚上看到应用方案大都是ELK日志分析的方案。但我们在开发中使用es做查询和存储操作。日订单量在25w左右。四台内存12G 硬盘60G的虚拟机搭建的集群。业务需要查询全部订单。
看一下我们集群的具体配置： elasticsearch.yml
基础的基础群名和节点名称。根据自己机器的划分命名就可以。
cluster.name: eb_es_cluster
node.name: "eb_es_node1"
内存设置：
使用mlockall在Linux / Unix系统上,或者VirtualLock在Windows上,试图锁进程地址空间到RAM中,防止任何Elasticsearch内存被换出
bootstrap.mlockall: true
3、把多点 传播关掉。防止在同局域网内。有节点自动加入集群。
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.multicast.ping.enabled: false
4、打开单一传播指定集群内。所有机器的IP和端口。只有在配置内的ip和端口的节点才能加入集群。
discovery.zen.ping.unicast.enabled: true
discovery.zen.ping.unicast.hosts: ["ip:端口", "ip:端口"]
5、很多时候把自动创建索引去掉，但是你如果安装了其他的插件。需要创建一些索引数据。如果直接设置为false。会导致报错。所以我们可以通过一下配置。一下配置的使用+号可以增加正则匹配。
+.marvel* ：允许.marvel开头的索引名称的创建。
-*：所有名称的索引都不能创建。
然后以逗号分割。前面的配置优先后面的配置。
action.auto_create_index: +.marvel*,-*
6、这个配置是对索引创建时生成的index.mapping文件的设置。不让自动创建mapping文件。这点好处就是你在使用字段时。能明确知道字段的类型。所有创建的时候可以在 config/mappings/index名称/type.mapping配置。
"dynamic_date_formats": [
"yyyy-MM-dd",
"yyyy-MM-dd HH:mm:ss",
"date_optional_time"
"dynamic": "false",
"_all":{"enabled":false},
"properties": {
"orderChannel": {
"type": "integer"
"priceAmount": {
"type": "double"
"orderFlag": {
"type": "integer"
index.mapper.dynamic: false
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：23859次
排名：千里之外
原创：55篇
(1)(50)(1)(1)(2)(1)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'ElasticSearch性能优化主要分为4个方面的优化。
一、服务器部署
二、服务器配置
三、数据结构优化
四、运行期优化
一、服务器部署
1、增加1-2台服务器，用于负载均衡节点
elasticSearch的配置文件中有2个参数：node.master和node.data。这两个参 数搭配使用时，能够帮助提供服务器性能。
1.1& node.master: false&&& node.data: true
该node服务器只作为一个数据节点，只用于存储索引数据。使该node服务器功能 单一，只用于数据存储和数据查询，降低其资源消耗率。
1.2& node.master: true&&& node.data: false
该node服务器只作为一个主节点，但不存储任何索引数据。该node服务器将使用 自身空闲的资源，来协调各种创建索引请求或者查询请求，讲这些请求合理分发到相关 的node服务器上。
1.3& node.master: false&&& node.data: false
该node服务器即不会被选作主节点，也不会存储任何索引数据。该服务器主要用 于查询负载均衡。在查询的时候，通常会涉及到从多个node服务器上查询数据，并请 求分发到多个指定的node服务器，并对各个node服务器返回的结果进行一个汇总处理， 最终返回给客户端。
2、关闭data节点服务器中的http功能
针对ElasticSearch集群中的所有数据节点，不用开启http服务。将其中的配置 参数这样设置：http.enabled: false，同时也不要安装head, bigdesk, marvel等监控 插件，这样保证data节点服务器只需处理创建/更新/删除/查询索引数据等操作。
http功能可以在非数据节点服务器上开启，上述相关的监控插件也安装到这些服 务器上，用于监控ElasticSearch集群状态等数据信息。
这样做一来出于数据安全考虑，二来出于服务性能考虑。
3、一台服务器上最好只部署一个Node
一台物理服务器上可以启动多个Node服务器节点（通过设置不同的启动port）， 但一台服务器上的CPU,内存，硬盘等资源毕竟有限，从服务器性能考虑，不建议一台 服务器上启动多个node节点。
二、服务器配置
1、配置索引线程池的大小
ElastiSearch服务器有多个线程池大小配置。主要有：index，search，suggest， get，bulk，percolate，snapshot，snapshot_data，warmer，refresh。
在此主要针对index和search进行一个配置调整。index操作包含：创 建/更新/删除索引数据。search操作主要针对用户的各种搜索操作。
具体配置如下：
threadpool:
type: fixed
type: fixed
size: 1000
2、创建/查找索引设置相同的分词解析器
索引服务器用到了ik中文分词插件，对于添加到该搜索服务器中的数据都使用该 中文分词（例如orgglobal对象中的orgName就使用了ik中文分词）。当执行搜索请求 时，搜索关键词也需要用到相关的中文分词器，如果不指定设置的话，则会使用服务器 默认的中文分词standard，而使用standard作为中文分词器进行查询时，性能不好。 通过将ik中分词设置为默认的分词器时，则查询效率是standard的2-3倍。
该配置具体如下：
alias: [news_analyzer_ik,ik_analyzer]
type: org.elasticsearch.index.analysis.IkAnalyzerProvider
index.analysis.analyzer.default.type: ik
3、确定分片(shard)的数量和副本(replica)的数量
ElasticSearch在创建索引数据时，最好指定相关的shards数量和replicas，
否则会使用服务器中的默认配置参数shards=5，replicas=1。
因为这两个属性的设置直接影响集群中索引和搜索操作的执行。假设你有足够的&&
机器来持有碎片和副本，那么可以按如下规则设置这两个值：
1) 拥有更多的碎片可以提升索引执行能力，并允许通过机器分发一个大型的索引；
2) 拥有更多的副本能够提升搜索执行能力以及集群能力。
对于一个索引来说，number_of_shards只能设置一次，而number_of_replicas可以使用索引更新设置API在任何时候被增加或者减少。
这两个配置参数在配置文件的配置如下：
index.number_of_shards: 5
index.number_of_shards: 1
4、查询速度慢的日志配置
在进行实际应用中，会记录下查询速度慢或者添加索引速度慢的操作记录，为后
续性能优化提供依据。其具体配置如下：
index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.: 5s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500ms
index.search.slowlog.threshold.fetch.warn: 1s
index.search.slowlog.: 800ms
index.search.slowlog.threshold.fetch.debug: 500ms
index.search.slowlog.threshold.fetch.trace: 200ms
index.indexing.slowlog.threshold.index.warn: 10s
index.indexing.slowlog.: 5s
index.indexing.slowlog.threshold.index.debug: 2s
index.indexing.slowlog.threshold.index.trace: 500ms
三、数据结构优化
1、尽量减少不需要的字段
ElasticSearch中存储的数据是用于搜索服务，因此其他一些不需要用于搜索的字段最好不存到ES中，这样即节省空间，同时在相同的数据量下，也能提高搜索性能。
2、routing值的设置
通常情况下，往ElasticSearch服务器添加索引数据时，是无需指定routing值。ElasticSearch会根据索引Id，将该条数据存储到ElasticSearch集群中的一个shard中。而当指定了routing值为accountId(用户Id)，则ElasticSearch会将相同accountId的多个数据都存放到同一个shard中，后续查询的时候，在指定routing值后，ElasticSearch只需要查询一个shard就能得到所有需要的数据，而不用再去查询所有的shard，从而大大提供了搜索性能。
四、运行期优化
1、optimize
随着时间的推移，ElasicSearch中每个shard的数据也会越来越多，索引越来越大，而生成的segment（在每个shard中，每个索引文件实际是由多个sgment文件组成）也会越来越多。而segment越多的话，则查询的性能越差，所以通过调用optimize命令，将多个segment合并成更少数量的segment(最少为一个)，从而来提高查询性能。
在调用该命令时，可以设置几个参数，这些参数的具体含义如下：
1.1& max_num_segments
段数优化。要全面优化索引，将其设置为1。默认设置只需检查是否需要执行一个合并，如果需要，则执行它。【经过测试，该值越小，查询速度越快】
1.2& only_expunge_deletes
该优化操作是否只清空打有删除标签的索引记录。在Lucence中，在执行删除操作时，不会直接删除segment中的记录，而是对该记录打上delete标签。当多个segment进行合并操作时，就会生成一个新的segment，而该新的segment中不再包含删除的记录。这个参数允许只对哪些包含删除记录的segment进行优化操作。
在执行完优化操作之后，再执行刷新操作。默认值为true
1.4&wait_for_merge
当该参数设置为true时，表示其他请求操作要等到合并segment操作结束之后，再进行响应。值得注意的是，由于这个优化操作是一个非常耗时，耗资源的事情，用户提交的请求操作是不能容忍等待这么久，所以这个参数最好设置为false.
具体调用命令如下：
http://localhost:9200/indexName/_optimize?only_expunge_deletes=true&wait_for_merge=false
2、warmers
当ElasticSearch服务器启动之后，业务系统中要使用的索引数据暂时没有导入到内存中，因此当用户进行第一次数据搜索时，会因为数据导入耗时很久，而严重影响用户的使用体验。为了解决该问题，可以使用warmer工具。通过ElastiSearch提供的工具，可以register/delete/get特定名称的warmer。通常情况下，warmer包含的请求需要载入大量的索引数据（例如在数据搜索中需要针对特定字段的排序操作，或者用到一些聚合sum,min,max函数的查询等），这样才能达到预热的效果。
具体调用示例如下（下面的warmer是针对索引名为test的warmer,warmer定义的名字为warmer_1）：
curl -XPUT localhost:9200/test/_warmer/warmer_1 -d '{
"query" : {
"match_all" : {}
"aggs" : {
"aggs_1" : {
"terms" : {
"field" : "field"
阅读(...) 评论() &}