Elasticsearch

运行环境:win10工具:PowerShell ElasticSearch启动./elasticsearch关上浏览器，拜访本地端口9200，能够看到返回的es信息 { "name" : "ZSH-X1C", "cluster_name" : "elasticsearch", "cluster_uuid" : "fSGnr92ZTkG5t_9WtrQqhA", "version" : { "number" : "7.9.1", "build_flavor" : "default", "build_type" : "zip", "build_hash" : "083627f112ba94dffc1232e8b42b73492789ef91", "build_date" : "2020-09-01T21:22:21.964974Z", "build_snapshot" : false, "lucene_version" : "8.6.2", "minimum_wire_compatibility_version" : "6.8.0", "minimum_index_compatibility_version" : "6.0.0-beta1" }, "tagline" : "You Know, for Search"}查看es已装置插件 ./elasticsearch-plugin list除了命令行，也能够通过浏览器查问 localhost:9200/_cat/plugins装置es插件 ./elasticsearch-plugin install analysis-icu对于es插件的介绍，能够查阅对于es插件的介绍 在开发机上运行多个es实例 bin/elasticsearch -E node.name=node1 -E cluster.name=XXX -E path.data = node1_data -d...bin/elasticsearch -E node.name=nodeN -E cluster.name=XXX -E path.data = nodeN_data -d浏览器查看节点信息 ...

FST(Finite State Transducers) https://cs.nyu.edu/~mohri/pub/fla.pdfElasticSearch https://www.cnblogs.com/dreamroute/p/8484457.htmlSkip List

写在后面有一个问题被关注的比拟少，就是ES对本地磁盘的占用状况。有人可能感觉这个问题的答案不言而喻，不就是ES软件自身占用的空间，还有索引数据长久化占用的磁盘空间，另外就是一些日志了。 事实上，对于ES占用磁盘空间的问题远比这个要简单的多。本篇文章就想聚焦这个问题，深刻ES的底层原理来剖析磁盘的占用状况。 注释是否执行剖析首先对于一个索引，其中的字段在写入是，写入剖析对磁盘是有影响的。那么什么是写入剖析? 当咱们index一个文档时，如果不指定分析器，默认应用的是standard，能够做个测试，看下默认的分析器执行的后果。 GET /_analyze{ "analyzer": "standard", "text": "Text to analyze"}咱们能够为字段独自指定analyzed或者 not_analyzed， 比方： PUT /my_index{ "mappings": { "my_type": { "properties": { "status_code": { "type": "string", "index": "not_analyzed" } } } }}not_analyzed:将字段的原始值放入索引中，作为一个独立的term，它是除string字段以外的所有字段的默认值。analyzed:string字段的默认值，会先进行剖析后，再把剖析的term后果存入索引中。剖析的目标次要是为了建设倒排索引，进行全文检索剖析。如果没有这个需要能够关掉。 _all字段和_source字段很多时候，咱们查问文档会发现返回的后果里，带有一个_source字段，外面是全副字段的内容。_source字段默认是存储的，这个会占用磁盘空间。 什么状况下不必保留 _source字段？比方如果某个字段内容十分多，咱们的业务场景只须要能对该字段进行搜寻，能够思考敞开 _source字段，咱们搜寻到文档id后，再通过文档id去数据库拿到这个字段的内容。这样能够节俭很多空间。如何敞开呢？ PUT my-index-000001{ "mappings": { "_source": { "enabled": false } }}_all字段默认是敞开的，如果要开启_all字段，索引就更大，占用磁盘空间当然就更大。_all字段开启实用于不指定搜寻某一个字段，依据关键词，搜寻整个文档内容。 Doc valuesDoc Values 通过序列化把数据结构长久化到磁盘，咱们能够充分利用操作系统的内存，而不是 JVM 的 Heap 。 Doc Values 默认对所有字段启用，除了 analyzed strings。也就是说所有的数字、地理坐标、日期、IP 和不剖析（ not_analyzed ）字符类型都会默认开启。 Doc Values的作用是开启的字段能够反对排序，聚合等能力，如果业务场景确定不须要这样的能力能够显示的把这个性能禁掉，从而节俭磁盘空间。 PUT my_index{ "mappings": { "my_type": { "properties": { "session_id": { "type": "string", "index": "not_analyzed", "doc_values": false } } } }}正本机制这个其实不必多说。ES的正本分片机制，目标是实现高可用，然而就义了空间。每个正本其实都是主分片的残缺拷贝，在文档数量十分大的时候，这个对磁盘的占用是相当可观的。 ...

本篇是有一个问题引出的，在ES中文论坛看到这个样一个问题： es存储的某一个字段值为数组，现搜寻的时候须要搜寻出后果该字段值为空或蕴含某几个值的数据，该怎么写例如： "job_type" : ["12","49","67"] 或者 "job_type" : [ ]须要搜出job_type中蕴含49的或者为空的数据这个问题其实波及好几个相干的知识点。 ES对于数组类型的写入和查问是怎么的如何查问数组为空的记录在ES中，没有专门的数组数据类型，然而默认状况下，任意一个字段都能够蕴含0或多个值，这意味着每个字段默认都是数组类型。不过ES要求数组类型的各个元素值的数据类型必须雷同。比方，上面这种数组就就无奈存入ES。 [ 10, "apple" ]然而上面这几种就能够， [ "apple", "orange" ][ 1, 2 ]上面回到问题。看要求应该是须要关键字匹配，所以字段的mapping类型能够设置为keyword，而后查问应用term查问。 mapping如下： PUT my_index{ "mappings": { "properties": { "job_type": { "type": "keyword" } } }}而后写入两条文档，第二条是空的。 PUT my_index/_doc/1{ "job_type": ["12", "49", "67"]}PUT my_index/_doc/2{ "job_type": []}查问蕴含49的记录， GET my_index/_search{ "query": { "bool": { "must": [ {"term": { "job_type": { "value": "49" } }} ] } }}搜寻空值， POST my_index/_search{ "query": { "script": { "script": "doc['job_type'].getLength()==0" } }}搜寻空值这里应用了painless脚本，脚本的语法这里不开展了，有趣味的能够去理解下。 ...

写在后面Elasticsearch(以下简称ES)有个copy_to的性能，之前在一个我的项目中用到，感觉像是发现了一个神器。这个货色并不是像有些人说的是个语法糖。它用好了岂但能进步检索的效率，还能够简化查问语句。 根本用法介绍间接上示例。 先看看mapping， PUT my_index{ "mappings": { "properties": { "first_name": { "type": "text", "copy_to": "full_name" }, "last_name": { "type": "text", "copy_to": "full_name" }, "full_name": { "type": "text" } } }}first_name和last_name都指定了copy_to，示意他们这两个字段的值都会复制到full_name上。写入两条文档看看， PUT my_index/_doc/1{ "first_name": "John", "last_name": "Smith"}PUT my_index/_doc/2{ "first_name": "Tom", "last_name": "Cruise"}而后咱们在查问的时候，就能够指定从full_name这个字段查问了， GET my_index/_search{ "query": { "match": { "full_name": { "query": "John Smith", "operator": "and" } } }}查问后果如下： "hits" : { "total" : { "value" : 1, "relation" : "eq" }, "max_score" : 1.3862944, "hits" : [ { "_index" : "my_index", "_type" : "_doc", "_id" : "1", "_score" : 1.3862944, "_source" : { "first_name" : "John", "last_name" : "Smith" } } ] }如果没有应用copy_to的话，咱们须要指定两个字段查问，相似如下的语句： ...

前言举荐学习阮一鸣《Elasticsearch 核心技术与实战》本文对 Elasticsearch 7.x 实用同义词能够再建索引时（index-time synonyms）或者检索时（search-time synonyms）应用，个别在检索时应用本文介绍的是 search-time synonyms同义词文档格局单向同义词ipod, i-pod, i pod => ipod双向同义词马铃薯, 土豆, potato试验步骤增加同义词文件在 Elasticsearch 的 config 目录下新建 analysis 目录，在 analysis 下增加同义词文件 synonym.txt在检索时应用同义词，不须要重启 Elasticsearch，也不须要重建索引创立索引PUT my_index{ "settings": { "analysis": { "filter": { "word_syn": { "type": "synonym_graph", "synonyms_path": "analysis/synonym.txt" } }, "analyzer": { "ik_max_word_syn": { "filter": [ "word_syn" ], "type": "custom", "tokenizer": "ik_max_word" } } } }, "mappings": { "properties": { "title": { "type": "text", "analyzer": "ik_smart", "search_analyzer": "ik_max_word" }, "author": { "type": "keyword" } } }}间接测试分词器查问语句GET my_index/_analyze{ "analyzer": "ik_max_word_syn", "text": "马铃薯"}输入{ "tokens" : [ { "token" : "马铃薯", "start_offset" : 0, "end_offset" : 3, "type" : "CN_WORD", "position" : 0 }, { "token" : "土豆", "start_offset" : 0, "end_offset" : 3, "type" : "SYNONYM", "position" : 0 }, { "token" : "potato", "start_offset" : 0, "end_offset" : 3, "type" : "SYNONYM", "position" : 0 } ]}增加测试数据POST my_index/_doc/1{ "title": "马铃薯", "author": "土豆"}检索测试查问语句GET my_index/_search{ "query": { "query_string": { "analyzer": "ik_max_word_syn", "query": "title:potato AND author:potato" } }}后果输入{ "took" : 38, "timed_out" : false, "_shards" : { "total" : 1, "successful" : 1, "skipped" : 0, "failed" : 0 }, "hits" : { "total" : { "value" : 1, "relation" : "eq" }, "max_score" : 0.5753642, "hits" : [ { "_index" : "my_index", "_type" : "_doc", "_id" : "1", "_score" : 0.5753642, "_source" : { "title" : "马铃薯", "author" : "土豆" } } ] }}相干文档CSDN blog： Elasticsearch：应用同义词 synonyms 来进步搜寻效率官网 blog： 一样，却又不同：借助同义词让 Elasticsearch 更加弱小同义词过滤器： Synonym token filter、Synonym graph token filter本文出自 qbit snap

原文：http://elasticsearch.cn/artic...因为总是看到很多同学在说elasticsearch性能不够好，集群不够稳固，询问对于elasticsearch的调优，然而每次都是一个个点的独自讲，很多时候都是case by case的解答，明天简略梳理下日常的elasticsearch应用调优，以下仅为本人日常经验之谈，如有疏漏，还请大家帮忙斧正。 一、配置文件调优elasticsearch.yml内存锁定bootstrap.memory_lock：true 容许 JVM 锁住内存，禁止操作系统替换进来。 zen.discoveryElasticsearch 默认被配置为应用单播发现，以避免节点无心中退出集群。组播发现应该永远不被应用在生产环境了，否则你失去的后果就是一个节点意外的退出到了你的生产环境，仅仅是因为他们收到了一个谬误的组播信号。 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：节点确定退出到集群中，向主节点发送退出申请的超时工夫，默认为3sdiscovery.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/...队列数量不倡议自觉加大es的队列数量，如果是偶发的因为数据突增，导致队列阻塞，加大队列size能够应用内存来缓存数据，如果是持续性的数据阻塞在队列，加大队列size除了加大内存占用，并不能无效进步数据写入速率，反而可能加大es宕机时候，在内存中可能失落的上数据量。 哪些状况下，加大队列size呢？GET /_cat/thread_pool，察看api中返回的queue和rejected，如果的确存在队列回绝或者是继续的queue，能够酌情调整队列size。 https://www.elastic.co/guide/...内存应用设置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/...依据理论状况调整查问占用cache，防止查问cache占用过多的jvm内存，参数为动态的，须要在每个数据节点配置。 indices.queries.cache.size: 5%，管制过滤器缓存的内存大小，默认为10%。承受百分比值，5%或者准确值，例如512mb。 https://www.elastic.co/guide/...创立shard如果集群规模较大，能够阻止新建shard时扫描集群内全副shard的元数据，晋升shard调配速度。 cluster.routing.allocation.disk.include_relocations: false，默认为true。 https://www.elastic.co/guide/...二、零碎层面调优jdk版本以后依据官网倡议，抉择匹配的jdk版本； jdk内存配置首先，-Xms和-Xmx设置为雷同的值，防止在运行过程中再进行内存调配，同时，如果零碎内存小于64G，倡议设置略小于机器内存的一半，残余留给零碎应用。 同时，jvm heap倡议不要超过32G（不同jdk版本具体的值会略有不同），否则jvm会因为内存指针压缩导致内存节约，详见： https://www.elastic.co/guide/...替换分区敞开替换分区，避免内存产生替换导致性能降落（局部状况下，宁死勿慢） swapoff -a 文件句柄Lucene 应用了 大量的 文件。 同时，Elasticsearch 在节点和 HTTP 客户端之间进行通信也应用了大量的套接字，所有这所有都须要足够的文件描述符，默认状况下，linux默认运行单个过程关上1024个文件句柄，这显然是不够的，故须要加大文件句柄数 ulimit -n 65536 ...

导语 | 腾讯云Elasticsearch 被广泛应用于日志实时剖析、结构化数据分析、全文检索等场景中，本文将以情景植入的形式，向大家介绍与腾讯云客户单干过程中遇到的各种典型问题，以及相应的解决思路与办法，心愿与大家一起交换。文章作者：bellen，腾讯云大数据研发工程师。 一、背景某中型互联网公司的游戏业务，应用了腾讯云的 Elasticsearch 产品，采纳 ELK 架构存储业务日志。 因为游戏业务自身的日志数据量十分大(写入峰值在 100w qps )，在服务客户的几个月中，咱们踩了不少坑。通过数次优化与调整，最初将客户的 ES 集群调整得比较稳定，防止了在业务顶峰时客户集群的读写异样，并且升高了客户的资金老本和应用老本。 二、与客户的首次交锋解决方案架构师A：bellen, XX公司要上线一款新游戏，日志存储决定用 ELK 架构，他们决定在 XX云和咱们之间二选一，咱们首先去他们公司和他们交换一下，争取拿下！ bellen: 好，随时有空！ 随后和架构师一起返回该公司，跟负责底层组件的运维部门的负责人进行沟通。 XX公司运维老大：不要讲你们的PPT了，先通知我你们能给咱们带来什么！ bellen：呃，咱们有很多劣势，比方能够灵便扩缩容集群，还能够一键平滑降级集群版本，并且提供有跨机房容灾的集群从而实现高可用...... XX公司运维老大：你说的这些别的厂商也有，我就问一个问题，咱们当初要存储一年的游戏日志，不能删除数据，每天就按 10TB 的数据量算，一年也得有个 3PB 多的数据，这么大的数量，都放在SSD云盘上，老本太高了。你们有什么计划既可能满足咱们存储这么大数据量的需要，同时可能升高咱们的老本吗？ bellen：咱们自身提供的有冷热模式的集群，热节点采纳 SSD 云硬盘，冷节点采纳 SATA 盘，采纳 ES 自带的 ILM 索引生命周期治理性能，定期把较老的索引从热节点迁徙到冷节点上，这样从整体上能够降低成本。 另外，也能够定期把更老的索引通过 snapshot 快照备份到 COS 对象存储中，而后删除索引，这样老本就更低了。 XX公司运维老大：存储到 COS 就是冷存储呗，咱们须要查问 COS 里的数据时，还得再把数据恢复到 ES 里？这样不行，速度太慢了，业务等不了那么长时间。咱们的数据不能删除，只能放在 ES 里！你们能不能给咱们提供一个 API , 让老的索引数据尽管存储在 COS 里，然而通过这个 API 仍然能够查问到数据，而不是先复原到 ES ， 再进行查问？ bellen：呃，这个能够做，然而须要工夫。是否能够采纳 hadoop on COS 的架构，把存量的老的索引数据通过工具导入到 COS，通过 hive 去查问，这样老本会非常低，数据仍然是随时可查的。 ...

从这篇开始，以nacos-elasticsearch为例，一步步介绍如何开发插件。 nacos-elasticsearch是一个主动将以后es节点注册到nacos注册核心的插件。环境基于maven，至多须要援用如下两个包 <dependency> <groupId>org.elasticsearch</groupId> <artifactId>elasticsearch</artifactId> <version>${elasticsearch.version}</version> <scope>provided</scope></dependency><dependency> <groupId>org.elasticsearch.test</groupId> <artifactId>framework</artifactId> <version>${elasticsearch.version}</version> <scope>test</scope></dependency>开发es插件，必定是要援用es的依赖，而且es还提供了测试框架，不便测试。这里要留神两点： elasticsearch.version须要依据你的指标es版本在指定设置为provided防止打包时将es作为依赖打进来打包插件举荐这么配置： <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>3.1.1</version> <configuration> <appendAssemblyId>false</appendAssemblyId> <descriptors> <descriptor>src/assembly/release.xml</descriptor> </descriptors> </configuration> <executions> <execution> <id>make-assembly</id> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> </plugin> <plugin> <artifactId>maven-resources-plugin</artifactId> <version>3.1.0</version> <executions> <execution> <id>copy-resources</id> <!-- here the phase you need --> <phase>validate</phase> <goals> <goal>copy-resources</goal> </goals> <configuration> <outputDirectory>${basedir}/target/extra-resources</outputDirectory> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </configuration> </execution> </executions> </plugin>resources下减少文件： src/main/resources/plugin-descriptor.propertiessrc/main/resources/plugin-security.policy同时plugin-descriptor.properties内容如下，留神其中的变量： java.version=1.8name=${project.artifactId}version=${version}description=${project.description}.elasticsearch.version=${elasticsearch.version}classname=com.eoi.nacos.elasticsearch.NacosPluginmaven-resources-plugin会将src/main/resources下的资源文件复制到target/extra-resources目录，并替换文件中的变量。 maven-assembly-plugin依据src/assembly/release.xml的配置进行打包。src/assembly/release.xml如下： <assembly xmlns="http://maven.apache.org/ASSEMBLY/2.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.0.0 http://maven.apache.org/xsd/assembly-2.0.0.xsd"> <!-- Assembles a packaged version targeting OS installation. --> <id>${build.timestamp}</id> <formats> <format>zip</format> </formats> <includeBaseDirectory>false</includeBaseDirectory> <fileSets> <fileSet> <!-- maven-resources-plugin will filter the file and copy into the following directory --> <directory>${project.basedir}/target/extra-resources</directory> <outputDirectory>.</outputDirectory> <includes> <include>plugin-descriptor.properties</include> <include>plugin-security.policy</include> </includes> </fileSet> </fileSets> <dependencySets> <dependencySet> <excludes> <!-- exclude dependency that elasticsearch already contains --> <exclude>org.joda:joda-convert</exclude> <exclude>joda-time:joda-time</exclude> <exclude>org.yaml:snakeyaml</exclude> <exclude>com.fasterxml.jackson.dataformat:jackson-dataformat-yaml</exclude> <exclude>jackson-core</exclude> <!-- the following jar is duplicated in plugin repository-hdfs --> <exclude>commons-collections:commons-collections</exclude> <exclude>commons-logging:commons-logging</exclude> </excludes> <outputDirectory>.</outputDirectory> <useProjectArtifact>true</useProjectArtifact> <useTransitiveFiltering>true</useTransitiveFiltering> </dependencySet> </dependencySets></assembly>这里设置打包次要申明了生成zip包（es插件的规范公布形式），并把替换好的plugin-descriptor.properties和plugin-security.policy打到zip包中。同时设置排除一些包，这些包是与es有抵触的，在最终测试时，依据插件依赖的复杂度，这块很可能要调整。 ...

一、引言随着挪动互联网、物联网、云计算等信息技术蓬勃发展，数据量呈爆炸式增长。现在咱们能够轻易得从海量数据里找到想要的信息，离不开搜索引擎技术的帮忙。 作为开源搜索引擎畛域排名第一的 Elasticsearch，可能让咱们无需深刻理解背地简单的信息检索原理，就可实现根本的全文检索性能，在数据量达到十亿，百亿规模依然能够秒级返回检索后果。 对于零碎容灾、数据安全性、可扩展性、可维护性等用户关注的理论问题，在Elasticsearch 上也能失去无效解决。 二、Elasticsearch 介绍Elasticsearch（ES）是一个基于 Lucene 构建的开源分布式搜寻剖析引擎，能够近实时的索引、检索数据。具备高牢靠、易使用、社区沉闷等特点，在全文检索、日志剖析、监控剖析等场景具备广泛应用。 因为高可扩展性，集群可扩大至百节点规模，解决PB级数据。通过简略的 RESTful API 即可实现写入、查问、集群治理等操作。 除了检索，还提供丰盛的统计分析性能。以及官网性能扩大包 XPack 满足其余需要，如数据加密、告警、机器学习等。 另外，可通过自定义插件，如 COS 备份、QQ 分词等满足特定性能需要。 1. Elasticsearch 架构与原理 基本概念 ： Cluster「集群」：由部署在多个机器的ES节点组成，以解决较大数据集和实现高可用；Node「节点」：机器上的ES过程，可配置不同类型的节点；Master Node「主节点」：用于集群选主。由其中一个节点负责主节点，负责集群元数据管理，如索引创立，节点来到退出集群等；Data Node「数据节点」：负责索引数据存储；Index「索引」：索引数据的逻辑汇合，可类比关系型数据的DataBase；Shard「分片」：索引数据子集，通过将分片调配至集群不同节点，实现数据横向扩大。以解决单个节点CPU、内存、磁盘解决能力有余的状况；Primary Shard「主分片」：数据分片采纳主从模式，由分片接管索引操作；Replica Shard「正本分片」：主分片的拷贝，以进步查问吞吐量和实现数据高牢靠。主分片异样时，其中一个正本分片会主动晋升为新的主分片。为了便于大家了解ES里的数据模型，将它与关系型数据库 MySQL 做类比： 从下面架构图能够看出，ES 架构十分简洁。内置主动发现实现 Zen discovery，当一个节点启动后，通过分割集群成员列表即可退出集群。 由其中一个节点负责主节点，用于集群元数据管理，保护分片在节点间的分配关系。当新节点退出集群后，Master 节点会主动迁徙局部分片至新节点，平衡集群负载。 分布式集群不免有节点故障。主节点会定期探测集群其余节点存活状态，当节点故障后，会将节点移出集群，并主动在其余节点上复原故障节点上的分片。 主分片故障时会晋升其中一个正本分片为主分片。其余节点也会探活主节点，当主节点故障后，会触发内置的类 Raft 协定选主，并通过设置起码候选主节点数，防止集群脑裂。 除了集群治理，索引数据读写也是咱们关怀的重要局部。ES 采纳 peer-to-peer 架构，每个节点保留全量分片路由信息，也就是每个节点均能够接管用户读写。 如发送写入申请至节点 1，写入申请默认通过文档 ID 的 Hash 值确定写入到哪个主分片，这里假如写入到分片 0。 写完主分片 P0，并行转发写入申请至正本分片 R0 所在节点，当正本分片所在节点确认写入胜利后返回客户端报告写入胜利，保障数据安全性。并且写入前，会确保 quorum 数量的正本数，防止网络分区导致写入数据不统一。 查问采纳分布式搜寻，如申请发给节点3后，申请会转发至索引的主分片或正本分片所在节点。 当然如果写入、查问均带有路由字段信息。申请只会发送给局部分片，防止全量分片扫描。这些节点实现查问后将后果返回给申请节点，由申请节点汇聚各个节点的后果返回给客户端。 ...

只需五步骤： 启动 集成ik中文分词插件的Elasticsearch7.9 Docker镜像Laravel7 配置 Scout配置 Model模型导入数据搜寻演示地址 https://www.ar414.com搜寻范畴 文章内容题目标签后果权重 呈现关键词数量呈现关键词次数搜寻页面 高亮显示分词显示后果分页前言次要是博客刚好想做个搜寻,顺便就整顿成文章Laravel + Elasticsearch 很多前辈都写过教程和案例,然而随着Elasticsearch和laravel的版本升级 以前的文章很多都不实用新版本的,倡议大家应用任何开源我的项目时应该过一遍文档以以后应用的版本文档为主,教程为辅 Elasticsearch 7.9Laravel 7elasticsearch-analysis-ik v7.9参考ik 中文分词插件elasticsearch 官网文档应用集成ik中文分词插件的Elasticsearch拉取docker$ docker pull ar414/elasticsearch-7.9-ik-plugin创立日志和数据存储目录本地映射到docker容器内，避免docker重启数据失落$ mkdir -p /data/elasticsearch/data$ mkdir -p /data/elasticsearch/log$ chmod -R 777 /data/elasticsearch/data$ chmod -R 777 /data/elasticsearch/log运行docker run -d -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" -v /data/elasticsearch/data:/var/lib/elasticsearch -v /data/elasticsearch/log:/var/log/elasticsearch ar414/elasticsearch-7.9-ik-plugin 验证$ curl http://localhost:9200{ "name" : "01ac21393985", "cluster_name" : "docker-cluster", "cluster_uuid" : "h8L336qcRb2i1aydOv04Og", "version" : { "number" : "7.9.0", "build_flavor" : "default", "build_type" : "docker", "build_hash" : "a479a2a7fce0389512d6a9361301708b92dff667", "build_date" : "2020-08-11T21:36:48.204330Z", "build_snapshot" : false, "lucene_version" : "8.6.0", "minimum_wire_compatibility_version" : "6.8.0", "minimum_index_compatibility_version" : "6.0.0-beta1" }, "tagline" : "You Know, for Search"}测试中文分词curl -X POST "http://localhost:9200/_analyze?pretty" -H 'Content-Type: application/json' -d'{ "analyzer": "ik_max_word", "text": "laravel天下无敌"}'{ "tokens" : [ { "token" : "laravel", "start_offset" : 0, "end_offset" : 7, "type" : "ENGLISH", "position" : 0 }, { "token" : "天下无敌", "start_offset" : 7, "end_offset" : 11, "type" : "CN_WORD", "position" : 1 }, { "token" : "天下", "start_offset" : 7, "end_offset" : 9, "type" : "CN_WORD", "position" : 2 }, { "token" : "无敌", "start_offset" : 9, "end_offset" : 11, "type" : "CN_WORD", "position" : 3 } ]}Laravel 我的项目中应用 ElasticsearchElasticsearch官网有提供 SDK，在 Laravel 我的项目中能够更加优雅疾速的接入 Elasticsearch，Laravel 自身有提供 Scout全文搜寻 的解决方案，咱们只需将默认的 Algolia 驱动 替换成ElasticSearch驱动。 ...

原文: Elasticsearch平安篇，通过Nginx http basic 限度拜访 1. tengine配置: #关键点，配置帐号密码 auth_basic "ElasticSearch登录";#提示信息 auth_basic_user_file /var/local/password; #密码文件（docker中tengine挂载密码文件） autoindex on; proxy_pass http://es服务内网ip:9200;2. docker-compose配置 volumes: # elasticsearch通过nginx http-basic 限度公网拜访 - /data/tengine/conf/password:/var/local/password留神: 须要手动进入 docker tengine 容器创立/var/local/password文件并将明码数据复制进去3. elasticsearch.ymlcluster.name: "docker-es"# es在docker外面, 不能用127.0.0.1network.host: 0.0.0.0# 跨域http.cors.enabled: truehttp.cors.allow-origin: "*"http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETEhttp.cors.allow-headers: "X-Requested-With, Content-Type, Content-Length, X-User"4. 重启elasticsearch & tenginedocker restart elasticsearchdocker-compose up -d tengine5. 而后外网通过域名拜访es服务时会弹出登录窗口, 填写登录胜利即可(如果登录失败, 须要敞开浏览器从新关上才会弹出登录窗口)

前言这段时间在保护产品的搜寻性能，每次在治理台看到 elasticsearch 这么高效的查问效率我都很好奇他是如何做到的。 这甚至比在我本地应用 MySQL 通过主键的查问速度还快。 为此我搜寻了相干材料： 这类问题网上很多答案，大略意思呢如下： ES 是基于 Lucene 的全文检索引擎，它会对数据进行分词后保留索引，善于治理大量的索引数据，绝对于 MySQL 来说不善于常常更新数据及关联查问。说的不是很透彻，没有解析相干的原理；不过既然重复提到了索引，那咱们就从索引的角度来比照下两者的差别。 MySQL 索引先从 MySQL 说起，索引这个词想必大家也是烂熟于心，通常存在于一些查问的场景，是典型的空间换工夫的案例。 以下内容以 Innodb 引擎为例。常见的数据结构假如由咱们本人来设计 MySQL 的索引，大略会有哪些抉择呢？ 散列表首先咱们该当想到的是散列表，这是一个十分常见且高效的查问、写入的数据结构，对应到 Java 中就是 HashMap 这个数据结构应该不须要过多介绍了，它的写入效率很高O(1),比方咱们要查问 id=3 的数据时，须要将 3 进行哈希运算，而后再这个数组中找到对应的地位即可。 但如果咱们想查问 1≤id≤6 这样的区间数据时，散列表就不能很好的满足了，因为它是无序的，所以得将所有数据遍历一遍能力晓得哪些数据属于这个区间。 有序数组 有序数组的查问效率也很高，当咱们要查问 id=4 的数据时，只须要通过二分查找也能高效定位到数据O(logn)。 同时因为数据也是有序的，所以天然也能反对区间查问；这么看来有序数组适宜用做索引咯? 天然是不行，它有另一个重大问题；假如咱们插入了 id=2.5 的数据，就得同时将后续的所有数据都挪动一位，这个写入效率就会变得非常低。 均衡二叉树既然有序数组的写入效率不高，那咱们就来看看写入效率高的，很容易就能想到二叉树；这里咱们以均衡二叉树为例： 因为均衡二叉树的个性： 左节点小于父节点、右节点大于父节点。所以假如咱们要查问 id=11 的数据，只须要查问 10—>12—>11 便能最终找到数据，工夫复杂度为O(logn)，同理写入数据时也为O(logn)。 但仍然不能很好的反对区间范畴查找，假如咱们要查问5≤id≤20 的数据时，须要先查问10节点的左子树再查问10节点的右子树最终能力查问到所有数据。 导致这样的查问效率并不高。 跳表跳表可能不像上边提到的散列表、有序数组、二叉树那样日常见的比拟多，但其实 Redis 中的 sort set 就采纳了跳表实现。 这里咱们简略介绍下跳表实现的数据结构有何劣势。 ...

Spark读取ElasticSearch数据优化个别业务上，咱们只会关怀写ElasticSearch，写也没有用到spark-elasticsearch组件。应用的是ElasticSearch原生的bulkProcessor。 查问方面个别在kibana敲敲查问代码就够了。 然而某天还是须要用到这个组件，特此记录下。 第一次应用引入maven <dependency> <groupId>org.elasticsearch</groupId> <artifactId>elasticsearch-spark-20_2.11</artifactId> <version>7.8.0</version> </dependency>写一手简略的代码，根本整个思路有了。 import org.elasticsearch.spark.sql._// 配置信息 val spark = SparkSession.builder().appName("ES 读取数据 商品关联视频") .config(ConfigurationOptions.ES_NODES_WAN_ONLY, "true") .config(ConfigurationOptions.ES_NODES, "***") .config(ConfigurationOptions.ES_PORT, "9200") .config(ConfigurationOptions.ES_NET_HTTP_AUTH_USER, "***") .config(ConfigurationOptions.ES_NET_HTTP_AUTH_PASS, "***") .getOrCreate() val query = """{ | "query": { | "bool": { | "must": [ | { | "term": { | "date": { | "value": "20200816" | } | } | }, | { | "term": { | "room_id": { | "value": "6861399602093165326" | } | } | } | ] | } | } |}""".stripMargin val df = spark.esDF("live-product-room-alias/origin", query) 放到线上怼一波，发现分区只有一个。跑了4.6小时~数据量在1.2亿左右。太慢了。 ...

ElasticSearch ILM试玩创立一个生命周期管理策略官网给的例子 PUT _ilm/policy/datastream_policy { "policy": { "phases": { "hot": { "actions": { "rollover": { "max_size": "50GB", "max_age": "30d" } } }, "delete": { "min_age": "90d", "actions": { "delete": {} } } } }}本人轻易造一个，齐全能够在Kibana界面上实现操作~ GET _ilm/policy{ "ljktest_policy" : { "version" : 1, "modified_date" : "2020-08-17T04:41:55.293Z", "policy" : { "phases" : { "hot" : { "min_age" : "0ms", "actions" : { "rollover" : { "max_size" : "1mb", "max_age" : "1h", "max_docs" : 1 } } }, "delete" : { "min_age" : "4h", "actions" : { "delete" : { } } } } } }}创立一个带有策略的索引正本官网示例 ...

写在后面应用elasticsearch(以下简称ES)也有挺长时间了，始终想找机会深刻源码钻研下。我看源码有个习惯，就是肯定要运行起来。不是只把源码下载下来看看就行的。 搭建整个调试环境简直花了一整天的功夫，这里记录下，心愿能帮到须要的人。 环境介绍MAC Mojave零碎idea 2019.2JDK版本： jdk12elasticsearch 版本：7.1.0gradle 版本：5.2.1源码下载能够间接去github下载指定release版本的源码，也能够间接clone目前的master分支，而后checkout到一个特定的版本。 git clone https://github.com/elastic/elasticsearch.git切换到指定公布版本 git checkout v7.x我个别会fork一份到本人的仓库，这样看代码的时候写的正文能够提交到本人的仓库。 配置gradle和jdk的环境具体的SDK和gradle的装置步骤不在这里开展了，自行搜寻吧。 我本人的电脑是通过sdkman治理不同的JDK版本，能够同时有多个JDK版本存在一台主机随时切换应用。 这里须要重点说下ES对JDK和Gradle的版本要求。ES运行和编译所须要的JDK版本是须要离开探讨的。 ES运行只有8或者以上就能够了，我本人就是本地用JDK8运行ES实例，尽管启动过程中会有相干正告版本低，然而不影响应用。比方我会收到相似上面的正告： future versions of Elasticsearch will require Java 11; your Java version from [/Users/xxxx/.sdkman/candidates/java/8.0.242-amzn/jre] does not meet this requirement如果是编译源码，对JDK的版本要求又高一点。个别在源码根目录下的contributing.md文件会有对于编译某个版本的ES须要的JDK的版本要求，比方我编译的版本，有这么一段阐明： JDK 12 is required to build Elasticsearch. You must have a JDK 12 installation with the environment variable JAVA_HOME referencing the path to Java home for your JDK 12 installation. gradle的版本要求，咱们也能够在 ...

写在后面应用elasticsearch(以下简称ES)也有挺长时间了，始终想找机会深刻源码钻研下。我看源码有个习惯，就是肯定要运行起来。不是只把源码下载下来看看就行的。 搭建整个调试环境简直花了一整天的功夫，这里记录下，心愿能帮到须要的人。 环境介绍MAC Mojave零碎idea 2019.2JDK版本： jdk12elasticsearch 版本：7.1.0gradle 版本：5.2.1源码下载能够间接去github下载指定release版本的源码，也能够间接clone目前的master分支，而后checkout到一个特定的版本。 git clone https://github.com/elastic/elasticsearch.git切换到指定公布版本 git checkout v7.x我个别会fork一份到本人的仓库，这样看代码的时候写的正文能够提交到本人的仓库。 配置gradle和jdk的环境具体的SDK和gradle的装置步骤不在这里开展了，自行搜寻吧。 我本人的电脑是通过sdkman治理不同的JDK版本，能够同时有多个JDK版本存在一台主机随时切换应用。 这里须要重点说下ES对JDK和Gradle的版本要求。ES运行和编译所须要的JDK版本是须要离开探讨的。 ES运行只有8或者以上就能够了，我本人就是本地用JDK8运行ES实例，尽管启动过程中会有相干正告版本低，然而不影响应用。比方我会收到相似上面的正告： future versions of Elasticsearch will require Java 11; your Java version from [/Users/xxxx/.sdkman/candidates/java/8.0.242-amzn/jre] does not meet this requirement如果是编译源码，对JDK的版本要求又高一点。个别在源码根目录下的contributing.md文件会有对于编译某个版本的ES须要的JDK的版本要求，比方我编译的版本，有这么一段阐明： JDK 12 is required to build Elasticsearch. You must have a JDK 12 installation with the environment variable JAVA_HOME referencing the path to Java home for your JDK 12 installation. gradle的版本要求，咱们也能够在 ...

插件的作用和分类elasticsearch(简称es)是一款使用宽泛的反对实时搜寻的数据库。罕用于全文检索、时序数据分析等畛域。es自身基于模块设计，同时反对插件定制，当现有的性能和插件无奈满足需要的时候，咱们能够基于es的插件框架和接口，实现本人的插件，实现性能。常见的插件，有中文分词、hdfs数据备份还原、云平台主动发现(ec2, gce, azure)等。es的免费模块xpack也是基于插件机制开发进去的，xpack提供了诸如index申明周期治理、es监控、平安认证、告警、机器学习、sql等实用功能。应用插件实现这些性能的益处是，可能更好的整合es的基础设施，不便部署。 es的插件次要分为如下几大类： 分词插件扩大restful接口集群和主动发现Ingest插件存储插件脚本扩大搜寻相干个别插件这个系列将会基于笔者的理论开发教训，介绍其中扩大restful接口, Ingest插件和个别插件。 es提供的基础设施在开始开发前，咱们能够先理解一下，作为es的插件能够从es的中获取哪些可间接应用的根底接口。 Client: 相当于restful Client，但其外部实现并不是简略的http申请ClusterService: 集群相干治理接口ScriptService: script相干ThreadPool: es治理的线程池，实现多线程或定时工作NodeEnvironment: 节点环境...实时上基础设施还有许多，笔者也不是全副理解。只是列举一下用到过的。es官网对插件开发的文档反对还是很无限的，所以如果心愿进行插件开发的话，学习已有的插件源码，甚至是跟踪到es外围源码简直是必须的。 插件部署插件在es中运行，除了须要实现一些接口，还须要遵循一些约定。这些约定关系到开发和部署。 在es中内部插件被部署在plugins目录下。有两种形式能够部署插件，一种是通过es自带的elasticsearch-plugin命令装置打包好的插件zip包；另一种是间接复制插件到plugins目录下。个别在开发测试阶段应用第二种形式比拟不便。如果心愿他人应用，则最好依照要求公布成zip包。 但无论是哪种形式，一个插件最终能被es加载必须满足几个条件： 在plugins目录下有对应插件的目录目录中蕴含打好的jar包和依赖包目录中蕴含plugin-descriptor.properties插件形容文件目录中蕴含plugin-security.policy文件，申明插件会用到的java平安项以repository-hdfs插件为例，插件中的蕴含文件如下（省略了依赖的jar包）： repository-hdfs├── plugin-descriptor.properties├── plugin-security.policy├── repository-hdfs-7.0.0.jar...plugin-descriptor.properties例如 description=The HDFS repository plugin adds support for Hadoop Distributed File-System (HDFS) repositories.version=7.0.0name=repository-hdfsclassname=org.elasticsearch.repositories.hdfs.HdfsPluginjava.version=1.8elasticsearch.version=7.0.0extended.plugins=has.native.controller=falseplugin-descriptor.properties中最要害的局部是elasticsearch.version和classname。前者申明了插件兼容的es版本（这个版本必须与正在运行的es版本exactly统一），后者是插件的入口类 plugin-security.policy例如 grant { permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.util.PropertyPermission "*", "read,write"; permission java.lang.RuntimePermission "shutdownHooks"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "doAs"; permission javax.security.auth.PrivateCredentialPermission "org.apache.hadoop.security.Credentials * \"*\"", "read"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.kerberos.KeyTab * \"*\"", "read"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.kerberos.KerberosTicket * \"*\"", "read"; permission java.lang.RuntimePermission "loadLibrary.jaas"; permission java.lang.RuntimePermission "loadLibrary.jaas_unix"; permission java.lang.RuntimePermission "loadLibrary.jaas_nt"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission java.security.SecurityPermission "putProviderProperty.SaslPlainServer"; permission java.security.SecurityPermission "insertProvider.SaslPlainServer"; permission javax.security.auth.kerberos.ServicePermission "*", "initiate"; permission java.net.SocketPermission "*", "connect"; permission java.net.SocketPermission "localhost:0", "listen,resolve";};plugin-security.policy是插件对敏感资源(比方本地文件)或者利用代码(类的办法)的拜访申明。因为es是在java.security开启的状况下运行插件的，所以有很多咱们悉数平时的操作都无奈通过jvm的Access Control机制的查看（例如读写文件、反射、Classloader操作、Socket相干），会报莫名其妙的权限问题。es要求插件开发者在plugin-security.policy中申明对敏感资源的需要，并在代码中应用AccessController.doPrivileged包裹蕴含敏感操作的代码。 ...

插件的作用和分类elasticsearch(简称es)是一款使用宽泛的反对实时搜寻的数据库。罕用于全文检索、时序数据分析等畛域。es自身基于模块设计，同时反对插件定制，当现有的性能和插件无奈满足需要的时候，咱们能够基于es的插件框架和接口，实现本人的插件，实现性能。常见的插件，有中文分词、hdfs数据备份还原、云平台主动发现(ec2, gce, azure)等。es的免费模块xpack也是基于插件机制开发进去的，xpack提供了诸如index申明周期治理、es监控、平安认证、告警、机器学习、sql等实用功能。应用插件实现这些性能的益处是，可能更好的整合es的基础设施，不便部署。 es的插件次要分为如下几大类： 分词插件扩大restful接口集群和主动发现Ingest插件存储插件脚本扩大搜寻相干个别插件这个系列将会基于笔者的理论开发教训，介绍其中扩大restful接口, Ingest插件和个别插件。 es提供的基础设施在开始开发前，咱们能够先理解一下，作为es的插件能够从es的中获取哪些可间接应用的根底接口。 Client: 相当于restful Client，但其外部实现并不是简略的http申请ClusterService: 集群相干治理接口ScriptService: script相干ThreadPool: es治理的线程池，实现多线程或定时工作NodeEnvironment: 节点环境...实时上基础设施还有许多，笔者也不是全副理解。只是列举一下用到过的。es官网对插件开发的文档反对还是很无限的，所以如果心愿进行插件开发的话，学习已有的插件源码，甚至是跟踪到es外围源码简直是必须的。 插件部署插件在es中运行，除了须要实现一些接口，还须要遵循一些约定。这些约定关系到开发和部署。 在es中内部插件被部署在plugins目录下。有两种形式能够部署插件，一种是通过es自带的elasticsearch-plugin命令装置打包好的插件zip包；另一种是间接复制插件到plugins目录下。个别在开发测试阶段应用第二种形式比拟不便。如果心愿他人应用，则最好依照要求公布成zip包。 但无论是哪种形式，一个插件最终能被es加载必须满足几个条件： 在plugins目录下有对应插件的目录目录中蕴含打好的jar包和依赖包目录中蕴含plugin-descriptor.properties插件形容文件目录中蕴含plugin-security.policy文件，申明插件会用到的java平安项以repository-hdfs插件为例，插件中的蕴含文件如下（省略了依赖的jar包）： repository-hdfs├── plugin-descriptor.properties├── plugin-security.policy├── repository-hdfs-7.0.0.jar...plugin-descriptor.properties例如 description=The HDFS repository plugin adds support for Hadoop Distributed File-System (HDFS) repositories.version=7.0.0name=repository-hdfsclassname=org.elasticsearch.repositories.hdfs.HdfsPluginjava.version=1.8elasticsearch.version=7.0.0extended.plugins=has.native.controller=falseplugin-descriptor.properties中最要害的局部是elasticsearch.version和classname。前者申明了插件兼容的es版本（这个版本必须与正在运行的es版本exactly统一），后者是插件的入口类 plugin-security.policy例如 grant { permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.util.PropertyPermission "*", "read,write"; permission java.lang.RuntimePermission "shutdownHooks"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "doAs"; permission javax.security.auth.PrivateCredentialPermission "org.apache.hadoop.security.Credentials * \"*\"", "read"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.kerberos.KeyTab * \"*\"", "read"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.kerberos.KerberosTicket * \"*\"", "read"; permission java.lang.RuntimePermission "loadLibrary.jaas"; permission java.lang.RuntimePermission "loadLibrary.jaas_unix"; permission java.lang.RuntimePermission "loadLibrary.jaas_nt"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission java.security.SecurityPermission "putProviderProperty.SaslPlainServer"; permission java.security.SecurityPermission "insertProvider.SaslPlainServer"; permission javax.security.auth.kerberos.ServicePermission "*", "initiate"; permission java.net.SocketPermission "*", "connect"; permission java.net.SocketPermission "localhost:0", "listen,resolve";};plugin-security.policy是插件对敏感资源(比方本地文件)或者利用代码(类的办法)的拜访申明。因为es是在java.security开启的状况下运行插件的，所以有很多咱们悉数平时的操作都无奈通过jvm的Access Control机制的查看（例如读写文件、反射、Classloader操作、Socket相干），会报莫名其妙的权限问题。es要求插件开发者在plugin-security.policy中申明对敏感资源的需要，并在代码中应用AccessController.doPrivileged包裹蕴含敏感操作的代码。 ...

当 ElasticSearch 的业务量足够大，比方每天都会产生数百 GB 数据的时候，你就会自然而然的须要一个性能更强的 ElasticSearch 集群。特地是当你应用的场景是一些典型的大量数据进入的场景，比方网站日志、用户行为记录、大型电商网站的站内搜索时，一个强劲的 ElasticSearch 是必不可少的组件。在这样的场景下，如何找到一组适合的 ElasticSearch 集群？如何评估 ElasticSearch 集群的性能，就成为了一个非常重要的因素。 用什么 ElasticSearch 进行压力测试？对于 ElasticSearch 性能测试和压力测试方面，其实有很多不同的计划，比方： Rally：Rally 是 Elastic 官方针对于 ElasticSearch 的宏观测试工具。ESPerf：一个基于 Golang 编写的 ElasticSerch 性能测试工具Elasticsearch Stress Test：由驰名的 ElasticSearch 服务提供商 Logzio 开发的性能测试工具除了这些定制化的工具意外以外，ElasticSearch 也能够借由其 Restful API 来应用Load Runner、JMeter等老牌工具进行测试，这些工具零零散散，各有各的用法和用处，不过，对于宽广开发者而言，还是官网出的 Rally 更令人满意。 在本篇文章中，将会应用 Rally 来实现 ElasticSearch 集群的压力测试 Rally 作为官网出品的工具，来自官网的信赖加成让他成为各家进行压力测试的首选工具。其次， Rally 官网给出了多种默认的数据集（Tracks）。如果你的应用场景笼罩在这些数据集(比方HTTP 拜访事件数据、天文名称数据、地理坐标点数据、HTTP 申请日志、问答场景、打车记录等场景)中，能够间接应用已有的数据集，来实现测试，而无需制作测试数据。 即便你的场景比拟非凡，无奈被官网的数据集所笼罩，也仍然能够依据本人的线上数据，来创立数据集，确保测试成果的精确。 如何应用 Rally 进行测试？在理解了 Rally 后，来具体看一看 Rally 的应用。 测试前的筹备对于 Rally 的根本装置，这里就不再介绍，总的来说非常简略，在配置好了 JDK 和 Python 环境当前，只须要执行pip install rally 就能够实现装置。如果你的环境简单，心愿以一个更简略的形式来运行，你也能够抉择应用 Docker 来运行 Rally ，进行测试。对于更多的装置形式，你能够参考 Rally 的装置文档. ...

Elasticsearch权威指南（中文版） 下载地址: https://pan.baidu.com/s/1bUGJmwS2Gp0B32xUyXxCIw 扫码上面二维码关注公众号回复100010 获取分享码 本书目录构造如下: 1. Introduction 2. 入门 i. 是什么 ii. 装置 iii. API iv. 文档 v. 索引 vi. 搜寻 vii. 聚合 viii. 小结 ix. 分布式 x. 结语 3. 分布式集群 i. 空集群 ii. 集群衰弱 iii. 增加索引 iv. 故障转移 v. 横向扩大 vi. 更多扩大 vii. 应答故障 4. 数据 i. 文档 ii. 索引 iii. 获取 iv. 存在 v. 更新 vi. 创立 vii. 删除 viii. 版本控制 ix. 部分更新 ...

elasticsearch技术解析与实战ES 下载地址: https://pan.baidu.com/s/1NpPX05C0xKx_w9gBYaMJ5w 扫码上面二维码关注公众号回复100008 获取分享码 本书目录构造如下： 1章　Elasticsearch入门1 1.1　Elasticsearch是什么1 1.1.1　Elasticsearch的历[0史0]2 1.1.2　相干产[0品0]3 1.2　全文搜寻3 1.2.1　Lucene介绍4 1.2.2　Lucene倒排索引4 1.3　根底[0知0]识6 1.3.1　Elasticsearch术语及概念6 1.3.2　JSON介绍10 1.4　装置配置12 1.4.1　装置Java12 1.4.2　装置Elasticsearch12 1.4.3　配置13 1.4.4　运行15 1.4.5　进行17 1.4.6　作为服务17 1.4.7　版本升级19 1.5　对外接口21 1.5.1　API约定22 1.5.2　REST介绍25 1.5.3　Head插件装置26 1.5.4　创立库27 1.5.5　插入数据28 1.5.6　批改文档28 1.5.7　查问文档29 1.5.8　删除文档29 1.5.9　删除库30 1.6　Java接口30 1.6.1　Java接口阐明30 1.6.2　创立索引文档33 1.6.3　减少文档34 1.6.4　批改文档35 1.6.5　查问文档35 1.6.6　删除文档35 1.7　小结36 [0第0]2章　索引37 2.1　索引治理37 2.1.1　创立索引37 2.1.2　删除索引39 2.1.3　获取索引39 2.1.4　关上/敞开索引40 2.2　索引映射治理41 2.2.1　减少映射41 2.2.2　获取映射44 2.2.3　获取字段映射45 2.2.4　判断类型是否存在46 2.3　索引别[0名0]46 2.4　索引配置51 2.4.1　更新索引配置51 2.4.2　获取配置52 2.4.3　索引剖析52 2.4.4　索引模板54 2.4.5　复制配置55 2.4.6　重建索引56 2.5　索引监控60 2.5.1　索引统计60 2.5.2　索引分片62 2.5.3　索引复原63 2.5.4　索引分片存储64 2.6　状态治理64 2.6.1　革除缓存64 2.6.2　索引刷新64 2.6.3　冲洗65 2.6.4　合并索引65 2.7　文档治理66 2.7.1　减少文档66 2.7.2　更新删除文档69 2.7.3　查问文档73 2.7.4　多文档操作76 2.7.5　索引词频率80 2.7.6　查问更新接口83 2.8　小结87 [0第0]3章　映射88 3.1　概念88 3.2　字段数据类型90 3.2.1　外围数据类型91 3.2.2　简单数据类型96 3.2.3　天文数据类型100 3.2.4　专门数据类型106 3.3　元字段108 3.3.1　_[0all0]字段109 3.3.2　_field_names字段109 3.3.3　_id字段110 3.3.4　_index字段110 3.3.5　_meta字段111 3.3.6　_parent字段111 3.3.7　_routing字段112 3.3.8　_source字段114 3.3.9　_type字段115 3.3.10　_uid字段115 3.4　映射参数116 3.4.1　analyzer参数116 3.4.2　boost参数118 3.4.3　coerce参数119 3.4.4　copy_to参数120 3.4.5　doc_values参数121 3.4.6　dynamic参数122 3.4.7　enabled参数122 3.4.8　fielddata参数123 3.4.9　format参数126 3.4.10　geohash参数128 3.4.11　geohash_precision参数129 3.4.12　geohash_prefix参数130 3.4.13　ig[0no0]re_above参数131 3.4.14　ig[0no0]re_malformed参数131 3.4.15　include_in_[0all0]参数132 3.4.16　index参数133 3.4.17　index_options参数133 3.4.18　lat_lon参数134 3.4.19　fields参数135 3.4.20　[0no0]rms参数136 3.4.21　null_value参数137 3.4.22　[p1o1s] ition_increment_gap参数137 3.4.23　precision_step参数138 3.4.24　properties参数138 3.4.25　search_analyzer参数139 3.4.26　similarity参数140 3.4.27　store参数141 3.4.28　term_vector参数141 3.5　动静映射142 3.5.1　概念142 3.5.2　_default_映射143 3.5.3　动静字段映射143 3.5.4　动静模板145 3.5.5　重写默认模板148 3.6　小结148 [0第0]4章　搜寻149 4.1　深刻搜寻149 4.1.1　搜寻形式149 4.1.2　从新[0评0]分153 4.1.3　滚动查问申请155 4.1.4　暗藏内容查问158 4.1.5　搜寻相干函数161 4.1.6　搜寻模板164 4.2　查问DSL167 4.2.1　查问和过滤的区别167 4.2.2　全文搜寻168 4.2.3　字段查问179 4.2.4　复合查问183 4.2.5　连贯查问188 4.2.6　天文查问190 4.2.7　跨度查问197 4.2.8　高亮显示200 4.3　简化查问203 4.4　小结206 [0第0]5章　聚合207 5.1　聚合的分类207 5.2　度量聚合209 5.2.1　平均值聚合209 5.2.2　基数聚合211 5.2.3　[0大0]值聚合213 5.2.4　小值聚合214 5.2.5　和聚合214 5.2.6　值计数聚合215 5.2.7　统计聚合215 5.2.8　百分比聚合215 5.2.9　百分比分级聚合216 5.2.10　高命中排行聚合217 5.2.11　脚本度量聚合217 5.2.12　天文边界聚合221 5.2.13　天文重心聚合222 5.3　分组聚合223 5.3.1　子聚合224 5.3.2　直方图聚合226 5.3.3　日期直方图聚合230 5.3.4　工夫范畴聚合233 5.3.5　范畴聚合234 5.3.6　过滤聚合235 5.3.7　多重过滤聚合236 5.3.8　空值聚合238 5.3.9　嵌套聚合239 5.3.10　采样聚合240 5.3.11　重要索引词聚合242 5.3.12　索引词聚合245 5.3.13　总体聚合251 5.3.14　天文点间隔聚合251 5.3.15　天文散列网格聚合253 5.3.16　IPv4范畴聚合255 5.4　管道聚合257 5.4.1　均匀分组聚合259 5.4.2　挪动均匀聚合261 5.4.3　总和分组聚合262 5.4.4　总和累计聚合262 5.4.5　[0大0]分组聚合264 5.4.6　小分组聚合265 5.4.7　统计分组聚合266 5.4.8　百分位分组聚合268 5.4.9　差值聚合269 5.4.10　分组脚本聚合273 5.4.11　串行差分聚合275 5.4.12　分组选择器聚合276 5.5　小结277 [0第0]6章　集群治理278 6.1　集群节点监控278 6.1.1　集群衰弱值278 6.1.2　集群状态279 6.1.3　集群统计280 6.1.4　集群工作治理280 6.1.5　待定集群工作281 6.1.6　节点信息281 6.1.7　节点统计282 6.2　集群分片迁徙283 6.3　集群节点配置284 6.3.1　主节点285 6.3.2　数据节点286 6.3.3　客户端节点286 6.3.4　部落节点287 6.4　节点发现287 6.4.1　主节点选举288 6.4.2　故障检测288 6.5　集群均衡配置289 6.5.1　分片调配设置289 6.5.2　基于磁盘的配置290 6.5.3　分片智能调配291 6.5.4　分片配置过滤292 6.5.5　其余集群配置293 6.6　小结293 [0第0]7章　索引分词器294 7.1　分词器的概念294 7.2　中文分词器298 7.3　插件300 7.3.1　插件治理301 7.3.2　插件装置301 7.3.3　插件清单302 7.4　小结304 [0第0]8章　高级配置305 8.1　网络相干配置305 8.1.1　本地网关配置305 8.1.2　HTTP配置306 8.1.3　网络配置307 8.1.4　传输配置308 8.2　脚本配置310 8.2.1　脚本应用311 8.2.2　脚本配置313 8.3　快照和复原配置318 8.4　线程池配置324 8.5　索引配置326 8.5.1　缓存配置326 8.5.2　索引碎片调配329 8.5.3　合并332 8.5.4　类似模块332 8.5.5　响应慢日志监控333 8.5.6　存储335 8.5.7　事务日志336 8.6　小结337 [0第0]9章　告警、监控和[0权0]限治理338 9.1　告警338 9.1.1　装置338 9.1.2　构造339 9.1.3　示例352 9.1.4　告警输入配置354 9.1.5　告警治理355 9.2　监控356 9.2.1　装置356 9.2.2　配置357 9.3　[0权0]限治理360 9.3.1　工作原理361 9.3.2　用户认证361 9.3.3　角色治理366 9.3.4　综合示例368 9.4　小结369 [0第0]10章　ELK利用370 10.1　Logstash370 10.1.1　配置371 10.1.2　插件治理374 10.2　Kibana配置377 10.2.1　Discover379 10.2.2　Visualize381 10.2.3　Dashboard383 10.2.4　Settings386 10.3　综合示例387 10.4　小结390 ...

什么是Elasitcsearch

筹备工作 VirtualBox 虚拟机增加 新建虚拟机内存大小虚构硬盘虚构硬盘文件类型存储在物理硬盘上文件地位和大小载入镜像文件网卡配置Centos 7.8 装置 抉择语言磁盘分区手动分区网络配置设置Root明码docker 装置 && Elasticsearch 镜像 docker 装置docker 查看版本拉取镜像数据目录 config && Log && Data文件权限vm.max_map_count 调整参数阐明配置文件 && 运行 Es0Es1Es2启动ElasticSearch集群容器查看集群状态Elasticsearch-Head 装置Node.js查看集群状态模仿节点下线ik 插件装置 下载地址复制获取容器ID复制ikdocker 启动 or 敞开快捷命令Elasticsearch 集群连贯 PHPJAVAElasticsearch 节点分类 主节点数据节点客户节点援用筹备工作VirtualBox 虚拟机增加1、新建虚拟机 2、内存大小 3、虚构硬盘 4、虚构硬盘文件类型 5、存储在物理硬盘上 6、文件地位和大小 7、载入镜像文件 8、网卡配置 Centos 7.8 装置1、抉择语言 2、磁盘分区 3、手动分区 swap 分区，个别物理内存的2倍 boot 分区, centos 6.x 100M 7.X 300M /根分区，调配剩下来所有存储空间4、网络配置 5、设置Root明码 docker 装置 && Elasticsearch 镜像1、docker 装置curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun2、docker 查看版本docker version3、拉取镜像docker pull elasticsearch:5.4.3数据目录1、config && Log && Datamkdir -p /usr/local/elasticsearch/{config,logs/{node0,node1,node2},data/{node0,node1,node2}}touch es0.yml es1.yml es2.ymltree elasticsearchelasticsearch/├── config│   ├── es0.yml│   ├── es1.yml│   └── es2.yml├── data│   ├── node0│   ├── node1│   └── node2└── logs ├── node0 ├── node1 └── node22、文件权限chmod -R 777 /usr/local/elasticsearch/data/*chmod -R 777 /usr/local/elasticsearch/logs/*chmod -R 777 /usr/local/elasticsearch/config/*4、vm.max_map_count 调整echo vm.max_map_count=262144 >> /etc/sysctl.confsysctl -p参数阐明集群名称cluster.name: elasticsearch-cluster节点名node.name: es-nodex主节点node.master数据节点node.data外网拜访配置network.bind_host 设置成0.0.0.0 任何主机都能够拜访本机ipnetwork.publish_host设置对外服务的http端口，默认为9200http.port设置节点间交互的tcp端口，默认是9300transport.tcp.port ...

导语 | Elasticsearch（下文简称ES） 是以后热门的开源全文搜索引擎，利用它咱们能够方便快捷搭建出搜寻平台，但通用的配置还须要依据平台内容的具体情况做进一步优化，能力产生令用户称心的搜寻后果。下文将介绍对 ES 搜寻排名的优化实际，心愿与大家一起交换。文章作者：曹毅，腾讯利用开发工程师。一、引言尽管应用 ES 能够十分不便疾速地搭建出搜寻平台，但搜进去的后果往往不合乎预期。因为 ES 是一个通用的全文搜索引擎，它无奈了解被搜寻的内容，通用的配置也无奈适宜所有内容的搜寻。所以 ES 在搜寻中的利用须要针对具体的平台做很多的优化才能够达到良好的成果。 ES 搜寻后果排序是通过 query 关键字与文档内容计算相关性评分来实现的。想把握相关性评分并不容易。首先 ES 对中文并不是很敌对，须要装置插件与做一些预处理，其次影响相关性评分的因素比拟多，这些因素可控性高，灵活性高。 下文将为大家介绍 ES 搜寻排名优化上的实践经验，本篇文章示例索引数据来自一份报告文档，如下图所示： 二、优化 ES Query DSL构建完搜寻平台后，咱们首先要进行 ES Query DSL 的优化。针对 ES 的优化，关键点就在于优化 Query DSL，只有 DSL 应用失当，搜寻的最终成果就会很好。 1. 最后应用的 multi_match当咱们构建好索引同步好数据当前，想比拟快实现全文索引的形式就是应用 multi_match 来查问，例如: 这样应用十分不便和疾速，并且实现了全文搜寻的需要。然而搜寻的后果可能不太合乎预期。然而不必放心，咱们能够持续往下优化。 2. 应用 bool 查问的 filter 减少筛选在利用中，咱们应该防止间接让用户针对所有内容进行查问，这样会返回大量的命中后果，如果后果的排序略微有一点出入，用户将无奈获取到更精准的内容。 针对这种状况，咱们能够给内容减少一些标签、分类等筛选项提供给用户做抉择，以达到更好的后果排名。这样搜寻时被 ES 引擎评分的指标后果将会变少，评分的抖动影响会更小。 实现这个性能就应用到 bool 查问的过滤器。bool 查问中提供了4个语句，must / filter / should / must_not，其中 filter / must_not 属于过滤器，must / should 属于查询器。对于过滤器，你须要晓得以下两点： 过滤器并不计算相关性评分，因为被过滤掉的内容不会影响返回内容的排序；过滤器能够应用 ES 外部的缓存，所以过滤器能够进步查问速度。这里须要留神：尽管 must 查问像是一种正向过滤器，然而它所查问的后果将会返回并会和其余的查问一起计算相关性评分，因而无奈应用缓存，与过滤器并不一样。 ...

导语 | 腾讯会议于2019年12月底上线，两个月内日活冲破1000万，被广泛应用于疫情防控会议、近程办公、师生近程授课等场景，为疫情期间的停工复产提供了重要的近程沟通工具。上线100天内，腾讯会议疾速迭代20个版本，满足一直增长的用户需要，屡次登顶APP STROE中国区收费榜总榜No.1。 极速增长的会议需要，让腾讯会议服务质量剖析零碎禁受着微小的考验。为了向全网用户提供高效稳固的服务，以及对重要的大型会议进行保障护航。在充沛探讨调研了大量计划后，腾讯会议服务质量剖析团队与腾讯云Elasticsearch（下文简称“ES”）团队开展单干，积极探索云端服务质量数据分析引擎架构的更多可能。 一、数据极速增长，业务稳固面临挑战随同暴发增长的用户需要，腾讯会议的日活也在一直地刷新着历史记录。 从1月29日起，为了应答疫情下近程办公的需要，腾讯会议每天都在进行资源扩容，日均扩容云主机靠近1.5万台，8天总共扩容超过10万台云主机，共波及超百万核的计算资源投入。 在会议中，偶然存在会议实时音视频卡顿、音视频不同步等会议品质问题，造成上述问题的可能因素比拟多，以后运行的网络有丢包或连贯不稳固的状况就是其中一种。 为了帮忙经营团队疾速精准地定位剖析问题，须要大量运行时的会议品质数据撑持，如网络相干的入网类型、码率、丢包率、网络切换、ip切换等数据，以及客户端相干的CPU使用率、内存使用率、操作系统版本、产品版本等数据信息。 因会议是一个多用户参加交互的过程，定位问题不仅须要波及到单个用户的状况，也要从房间的维度洞察各个用户之间的分割。通过腾讯会议客户端实时上报的会议品质信息，经营团队能够疾速地对单用户、单房间的视频会议品质状况有直观的理解，为剖析问题提供了数据撑持。 除了数据的实时上报，另一方面，借助多维分析，咱们还能够在实时数据中挖掘出异常情况。如某个地区大面的卡顿，某个版本呈现特定的问题等。通过dashboard或数据报表的模式，帮忙经营团队及时掌控全局状况，疾速发现潜在问题。 快速增长的用户数以及一直刷新纪录的同时在线房间数，让腾讯会议服务质量剖析零碎禁受高压力，给经营团队及时排查用户问题带来了微小的挑战。深究根本原因，是因为服务质量剖析零碎在如此高压力、高吞吐的场景下，写入性能严重不足导致。因为零碎最要害的局部，是一个基于lucene自研的搜索引擎，扩容能力比拟差，依赖于研发团队针对业务的优化。在数据量暴涨的背景下，不能进行疾速扩容以满足需要。 二、选型ES及技术考量为了保障全网腾讯会议用户都能高效稳固地进行会议沟通，保障经营团队能对用户会议中的卡顿等问题及时进行排查，以及对重要的大型会议进行保障护航。在充沛探讨调研了大量计划后，腾讯会议服务质量剖析团队决定从原来的自研服务质量数据分析系统，紧急迁徙至应用腾讯云ES作为数据分析引擎的架构上。 新老架构比照图 在进行架构计划选型的过程中，次要从以下几个方面进行了思考： 1. 高性能腾讯会议服务质量数据上报至ES的流量，峰值高达1000+w/s。在如此高吞吐的极限写入场景下，能继续稳固地提供数据读写服务，的确是一个挑战。在腾讯外部，也存在着相似腾讯会议这样的大批量、大吞吐写入场景，在应用过程中，业务部门常常会发现写入性能不高，且CPU使用率不稳固的问题，资源利用率严重不足。 腾讯云ES内核团队对相似的高压力写入场景进行了追踪及剖析，并在同样的场景下进行了多个计划的压力测试，发现ES单节点的压力写入测试与lucene基准的写压力测试有较大的差距。通过对调用火焰图进行剖析并比照测试translog的一些调优参数，最终定位发现translog文件的rollGeneration操作与flush操作有互斥，两个操作相互频繁的加锁烦扰，一次rollGeneration操作的均匀耗时达到了570ms，在高压力写入场景下，频繁的rollGeneration会重大影响写入性能。 在与社区进行了大量的探讨及压测之后，最终确定了优化计划：采纳rollGeneration的过程中，在敞开原translog文件之前，先执行一次flush，奇妙地防止了操作的互斥。这个计划对流程的革新最轻量优雅，且优化后的写入性能进步了20%以上。这部分优化的代码经腾讯外部的业务验证后，最终整顿提交回馈给了社区。因为这个优化在ES写入的所有场景下均实用，且对性能的晋升十分显著，Elastic的创始人对该PR高度赞扬，并给腾讯云总裁发来了公开感谢信。 腾讯云ES在社区开源的内核之上，依据云上的内外部业务的场景案例积攒，做了大量的内核优化。除了下面介绍的translog的优化，还有带“_id”的写入操作剪枝优化、查问打算优化等等，满足了客户在性能方面的须要，并踊跃将一些通用的优化提交至社区，截至目前为止，腾讯云提交的pr约有50+被合并到了骨干。 2.扩容能力在疫情期间，持续沿用原有的架构很难满足疾速扩容的需要，导致服务质量数据上报写入慢，数据大量沉积在队列中。腾讯云ES有着欠缺的分布式设计，单个集群反对扩容至数百甚至上千个节点。有牢靠齐备的选主算法逻辑以及sharding路由策略做保障。数据分片反对数据冗余，避免因为硬件故障导致的数据失落，并晋升集群的读性能。同时，数据能够按索引维度设置数据分片及正本数目，能够依据业务特点更灵便地设置正当的数值，升高了数据存储的老本。 腾讯云ES依靠于腾讯云CVM进行构建，资源池短缺，仅在疫情刚开始的一个月内就扩容了3W核，集群弹性伸缩的便利性失去了验证。扩容节点数目及变更节点配置等均为自动化性能，反对控制台及API一键操作，扩容过程平滑，不影响业务读写。 在集群扩容的场景中，置信很多业务都遇到过应用ES进行扩容后，大量新写入数据有读写热点，都沉积到新退出的节点上，导致节点被打挂，影响整个集群的写入性能。随着数据的增长，腾讯会议业务也扩容至千级节点的规模，那么下面的问题在腾讯云ES中是如何解决的呢？ 社区开源版本的ES，在shard调配的时候，会优先思考各个节点上已有的shard数量，目标是尽量放弃各个节点的shard和数据的平衡。当集群数据在各节点之间曾经处于balance状态时，这时候减少新节点。因为新节点下面的shard数起码，就会造成下面的问题，新写入的数据都调配在新的节点上，造成新的节点压力过高而宕机。 为了帮忙客户解决上述问题，腾讯云ES内核团队在原有allocationDecider责任链根底上，开发了一个新的decider调配算法，将一个index的所有分片，尽量均匀地调配在各个节点上，使得新写入数据的读写流量被平均分担，防止了新写入数据的拜访热点。 3. 稳定性腾讯会议服务质量剖析零碎，从2月份进行ES架构的计划切换开始，写入吞吐从5w/s一直攀升，现已达到100w+/s。业务的突发增长有时候来的很忽然，并不能在后期做无效的评估。社区中的很多用户也遇到过相似的问题，因为没有预估到业务突发的增长，并且在业务层没有做好服务降级等机制，导致突发的写入查问流量打崩了整个集群，使ES服务甚至整个业务长时间不可用。那么，在相似腾讯会议这样的场景中，是怎么解决ES突增写入查问流量的问题的呢？ 例如晚期咱们外部一个日志集群，写入量一天突增 5 倍，集群多个节点 Old GC 卡住脱离集群，集群 RED，写入进行，这个痛点的确有点痛。咱们对挂掉的节点做了内存剖析，发现大部分内存是被反序列化前后的写入申请占用。咱们来看看这些写入申请是沉积在什么地位。 ES high level 的写入流程，用户的写入申请先达到其中一个数据节点，咱们称之为数据节点。而后由该协调节点将申请转发给主分片所在节点进行写入，主分片写入结束再由主分片转发给从分片写入，最初返回给客户端写入后果。左边是更细节的写入流程，而咱们从堆栈中看到的写入申请沉积的地位就是在红色框中的接入层，节点挂掉的根因是协调节点的接入层内存被打爆。 针对这种高并发场景，咱们的优化计划是服务限流。除了要能管制并发申请数量，还要能精准地管制内存资源，因为内存资源有余是次要的矛盾。另外通用性要强，能作用于各个层级实现全链限流。 在很多数据库应用场景，会采纳从业务端或者独立的 proxy 层配置相干的业务规定的限流计划，通过资源预估等形式进行限流。这种形式适应能力弱，运维老本高，而且业务端很难精确预估资源耗费。 ES原生版本自身无限流策略，是基于申请数的漏桶策略，通过队列加线程池的形式实现。线程池大小决定了解决并发度，解决不完放到队列，队列放不下则拒绝请求。然而单纯地基于申请数的限流不能管制资源使用量，而且只作用于分片级子申请的传输层，对于咱们后面剖析的接入层无奈起到无效的爱护作用。原生版本也有内存熔断策略，然而在协调节点接入层并没有做限度。 咱们的优化计划是基于内存资源的漏桶策略。咱们将节点 JVM 内存作为漏桶的资源，当内存资源足够的时候，申请能够失常解决；当内存使用量达到肯定阈值的时候分区间阶梯式平滑限流。例如上图中浅黄色的区间限度写入，深黄色的区间限度查问，底部红色局部作为预留 buffer，预留给解决中的申请、merge 等操作，以保障节点内存的安全性。 限流计划外面有一个挑战是：咱们如何能力实现平滑限流？因为采纳繁多的阈值限流很容易呈现申请抖动，例如申请一上来把内存打上去马上触发限流，而放开一点点申请又会涌进来把内存打上去。咱们的计划是设置了高下限流阈值区间，在这个区间中，基于余弦变换实现申请数和内存资源之间的平滑限流。当内存资源足够的时候，申请通过率 100%，当内存达到限流区间逐渐回升的时候，申请通过率随之逐渐降落。而当内存使用量降落的时候，申请通过率也会逐渐回升，不会一把放开。通过理论测试，平滑的区间限流能在高压力下保持稳定的写入性能。 咱们基于内存资源的区间平滑限流策略是对原生版本基于申请数漏桶策略的无效补充，并且作用范畴更广，笼罩协调节点、数据节点的接入层和传输层，并不会代替原生的限流计划。 4. 易用性用户数暴增，留给系统验证切换的工夫十分短，这要求咱们必须应用一种简略疾速的解决方案。须要在一周之内输入实用计划，并进行线上数据的切换。如原架构应用kafka队列做数据的投递，由自研的音讯接入服务进行音讯的接入、荡涤并最终写入自研的服务质量数据存储剖析服务。因为工夫紧迫，新的计划须要尽量保留原有架构的大部分基础设施，并做尽量少的代码开发改变。 在这方面，ES的社区生态做得十分齐备。从采集端、收集端到存储都有一整套解决方案。通过logstash的易用性和弱小的生态插件，能够疾速代替原有的自研数据接入组件，进行数据的荡涤转换等ETL过程。如原有架构中应用的kafka，在logstash中就曾经蕴含了相应的input插件。并且有大量数据格式的解析插件反对，对于数据的一些解析、过滤、荡涤等操作能够间接在logstash的pipeline中进行简略的配置即可，基本上是0开发量。 ...

摘要：脏数据对数据计算的正确性带来了很重大的影响。因而，咱们须要摸索一种办法，可能实现Spark写入Elasticsearch数据的可靠性与正确性。概述Spark与Elasticsearch（es）的联合，是近年来大数据解决方案很炽热的一个话题。一个是杰出的分布式计算引擎，另一个是杰出的搜索引擎。近年来，越来越多的成熟计划落地到行业产品中，包含咱们耳熟能详的Spark+ES+HBase日志剖析平台。 目前，华为云数据湖摸索（DLI）服务已全面反对Spark/Flink跨源拜访Elasticsearch。而之前在实现过程中也遇到过很多场景化问题，本文将筛选其中比拟经典的分布式一致性问题进行探讨。 分布式一致性问题问题形容数据容错是大数据计算引擎面临的次要问题之一。目前，支流的开源大数据比方Apache Spark和Apache Flink曾经齐全实现了Exactly Once语义，保障了外部数据处理的正确性。然而在将计算结果写入到内部数据源时，因为内部数据源架构与拜访形式的多样性，始终没能找到一个对立的解决方案来保障一致性（咱们称为Sink算子一致性问题）。再加上es自身没有事务处理的能力，因而如何保障写入es数据一致性成为了热点话题。 咱们举一个简略的例子来阐明一下，图1在SparkRDD中（这里假如是一个task），每一条蓝色的线代表100万条数据，那么10条蓝色的线示意了有1000万条数据筹备写入到CSS（华为云搜寻服务，外部为es）的某个index中。在写入过程中，零碎产生了故障，导致只有一半（500万条）数据胜利写入。 task是Spark执行工作的最小单元，如果task失败了，以后task须要整个从新执行。所以，当咱们从新执行写入操作（图2），并最终重试胜利之后（这次用红色来示意雷同的1000万条数据），上一次失败留下的500万条数据仍然存在（蓝色的线），变成脏数据。脏数据对数据计算的正确性带来了很重大的影响。因而，咱们须要摸索一种办法，可能实现Spark写入es数据的可靠性与正确性。 图1 Spark task失败时向es写入了局部数据 图2 task重试胜利后上一次写入的局部数据成为脏数据 解决方案1.写笼罩从上图中，咱们能够很直观的看进去，每次task插入数据前，先将es的index中的数据都清空就能够了。那么，每次写入操作能够看成是以下3个步骤的组合： 步骤一 判断以后index中是否有数据步骤二 清空以后index中的数据步骤三 向index中写入数据换一种角度，咱们能够了解为，不论之前是否执行了数据写入，也不论之前数据写入了多少次，咱们只想要保障以后这一次写入可能独立且正确地实现，这种思维咱们称为幂等。 幂等式写入是大数据sink算子解决一致性问题的一种常见思路，另一种说法叫做最终一致性，其中最简略的做法就是“insert overwrite”。当Spark数据写入es失败并尝试从新执行的时候，利用笼罩式写入，能够将index中的残留数据笼罩掉。 图 应用overwrite模式，task重试时笼罩上一次数据 在DLI中，能够在DataFrame接口里将mode设置成“overwrite”来实现笼罩写es： val dfWriter = sparkSession.createDataFrame(rdd, schema)//// 写入数据至es//dfWriter.write .format("es") .option("es.resource", resource) .option("es.nodes", nodes) .mode(SaveMode.Overwrite) .save()也能够间接应用sql语句： // 插入数据至essparkSession.sql("insert overwrite table es_table values(1, 'John'),(2, 'Bob')")2.最终一致性利用上述“overwrite”的形式解决容错问题有一个很大的缺点。如果es曾经存在了正确的数据，这次只是须要追加写入。那么overwrite会把之前index的正确的数据都笼罩掉。 比如说，有多个task并发执行写入数据的操作，其中一个task执行失败而其余task执行胜利，从新执行失败的task进行“overwrite”会将其余曾经胜利写入的数据笼罩掉。再比如说，Streaming场景中，每一批次数据写入都变成笼罩，这是不合理的形式。 图 Spark追加数据写入es 图 用overwrite写入会将原先正确的数据笼罩掉 其实，咱们想做的事件，只是清理脏数据而不是所有index中的数据。因而，外围问题变成了如何辨认脏数据？借鉴其余数据库解决方案，咱们仿佛能够找到办法。在MySQL中，有一个insert ignore into的语法，如果遇到主键抵触，可能单单对这一行数据进行疏忽操作，而如果没有抵触，则进行一般的插入操作。这样就能够将笼罩数据的力度细化到了行级别。 es中有相似的性能么？如果es中每一条数据都有主键，主键抵触时能够进行笼罩（疏忽和笼罩其实都能解决这个问题），那么在task失败重试时，就能够仅针对脏数据进行笼罩。 咱们先来看一下Elasticsearch中的概念与关系型数据库之间的一种对照关系： 咱们晓得，MySQL中的主键是对于一行数据（Row）的惟一标识。从表中能够看到，Row对应的就是es中的Document。那么，Document有没有惟一的标识呢？ 答案是必定的，每一个Document都有一个id，即doc_id。doc_id是可配置的，index、type、doc_id三者指定了惟一的一条数据（Document）。并且，在插入es时，index、type、doc_id雷同，原先的document数据将会被笼罩掉。因而，doc_id能够等效于“MySQL主键抵触疏忽插入”性能，即“doc_id抵触笼罩插入”性能。 因而，DLI的SQL语法中提供了配置项“es.mapping.id”，能够指定一个字段作为Document id，例如： create table es_table(id int, name string) using es options('es.nodes' 'localhost:9200','es.resource' '/mytest/anytype','es.mapping.id' 'id')")这里指定了字段“id”作为es的doc_id，当插入数据时，字段“id”的值将成为插入Document的id。值得注意的是，“id”的值要惟一，否则雷同的“id”将会使数据被笼罩。 ...

本文源码：GitHub·点这里 || GitEE·点这里 一、集群环境搭建1、环境概览ES版本6.3.2，集群名称esmaster，虚拟机centos7。 ElasticSearch根底性能和用法： MySQL数据全量和增量形式向ES搜索引擎同步Linux零碎Centos7环境搭建ElasticSearch中间件SpringBoot2整合ElasticSearch搜索引擎框架在真正海量数据的业务场景中，ElasticSearch搜索引擎都是须要集群化治理的，实时搜素几十亿的数据非常常见。 2、集群配置配置文件 vim /opt/elasticsearch-6.3.2/config/elasticsearch.yml 主节点配置 # 集群主节点配置cluster.name: esmasternode.master: true# 节点名称 node.name: esnode1# 开发拜访network.host: 0.0.0.0从节点配置 留神这里两个从节点配置，node.name别离配置为esnode2和esnode3即可。 # 集群名称cluster.name: esmaster# 节点名称node.name: esnode2# 开发拜访network.host: 0.0.0.0# 主节点IPdiscovery.zen.ping.unicast.hosts: ["192.168.72.133"]内存权限 vim /etc/sysctl.conf# 增加内容vm.max_map_count=262144# 执行sysctl -p3、集群启动增加esroot用户，并受权。 /opt/elasticsearch-6.3.2/bin/elasticsearch单服务查看 ps -aux |grep elasticsearch集群状态查看 http://localhost:9200/_cluster/health?pretty{ "cluster_name" : "esmaster", # 集群名称 "status" : "green", # 绿：衰弱，黄：亚健康，红：病态 "timed_out" : false, # 是否超时 "number_of_nodes" : 3, # 节点个数}二、集群模式测试1、环境配置dev环境 配置单个节点，抉择任意单节点，进行数据写入测试。 spring: data: elasticsearch: # 集群名称 cluster-name: esmaster # 单节点 # cluster-nodes: en-master:9300 # cluster-nodes: en-node01:9300 cluster-nodes: en-node02:9300test环境 ...

query_string参数 之 auto_generate_phrase_queries ，default_operator 默认值导致呈现以上问题：auto_generate_phrase_queries：是否主动生成短语查问（有可能一条字符串 生成多个短语） 默认值 false;default_operator：词与词，或短语与短语之间的运算符 （and 或 or） 默认 or 如果有以下三条数据ID题目1我想学习elasticsearch2什么是elasticsearch3我想学习java and elasticsearch张三搜寻 我想学习elasticsearchelasticsearch query 为 { "query": { "query_string": { "query": "title:我想学习elasticsearch" } }}后果会把，ID为1，2,3的都查问进去 起因是query_string 有一个参数 default_operator 默认值为 or如果分析器把 我想学习elasticsearch 分词为我， 想 ， 学习， elasticseach ， 那么当 default_operator值为 or或不设置时只有title 里边蕴含 我， 想 ， 学习， elasticseach ， 其中一个就会查问进去； 同理当 default_operator值为 and 时title 里边必须同时蕴含 我， 想 ， 学习， elasticseach ， ， 才会查问进去 { "query": { "query_string": { "default_operator":"and", "query": "title:我想学习elasticsearch" } }}后果会把ID为1,3的查问进去; ...

前言忽然想写一个对于Elasticsearch根本应用的文档，因为Elasticsearch入门的门槛特地低，加上本人很久没有应用了。最近我的项目接入Elasticsearch 想了想还是写一篇对于根本应用，前面写文章掰开揉碎了剖析Elasticsearch。本文不会再有表情包呈现，是个比拟正经的小白入门手册。 大佬就请绕道吧！！！低微在线祷告。 看完本篇你对Elasticsearch还是无所不知 哈哈哈哈哈哈哈哈哈本篇讲的官网文档全都有 惟一的是能够依据代码装个环境本人入手 环境筹备1.首先你要有个docker docker pull elasticsearch:6.7.2docker run -d --name elasticsearch -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" elasticsearch:6.7.2// 就曾经启动胜利了 不须要再任何操作2.其次你 会点php 事实上demo换成任何语言都很简略3.git clone https://github.com/hongg-coder/es.git4.用的官网的sdk 对应链接地址packagist 务必提前看下readme5.debug的数据源大略有1000条 依据上面走 执行脚本主动构建 数据文件在data/user_list.json 数据筹备如果你习惯mysql能够转变下概念mysql -> databases -> talbes -> rows -> Columselasticsearch-> Inices -> Types -> Documents -> Fields 来自elasticsearch权威指南阐明demo以简略用户为例子 user_id 用户id 须要范畴查问nickname 用户昵称 须要准确查问tag 用户标签 须要多条件查问birthday用户出世日 须要日期查问mail 用户邮箱 须要准确查问description 用户简介须要分词查问 { // 用户id "user_id":1, // 用户昵称 "nickname":"洪二光", // 用户标签 "tag":[ "渣男", "菜鸟" ], // 出生日期 "birthday":"1994-11-30", // 邮箱 "mail":"1569498875@qq.com", // 用户备注 "description":"oh shit"}index定义为usertype定义为_doc ...

一、全量构建索引ElasticSearch集群环境搭建好当前，首次须要全量地从关系型数据库中将指标待索引数据写入到ElasticSearch搜索引擎中，以下咱们将用到logstash的插件logstash-input-jdbc来全量同步数据。 参考ElasticSearch本地集群搭建1、Logstash管道构建全量索引Logstash好比一个数据管道，通常一端连贯着关系型数据库来往管道中输出数据，一端连贯着ElasticSearch将管道中的数据输入。 下载Logstash返回官网下载Logstash，须要与ElasticSearch版本统一，兼容性更好。将下载的Logstash压缩包上传到服务器上，示例将Logstash装置在了与ElasticSearch同一台服务器上。 装置Logstash#进入logstash压缩包所在目录cd /usr/local#加压logstash压缩包unzip logstash-7.8.0.zip 装置logstash的插件logstash-input-jdbc#进入logstash装置目录的bin目录下cd /usr/local/logstash-7.8.0/bin#装置插件，留神logstash依赖jdk，装置插件前请确保装置了jdk#以后logstash-7.8.0版本曾经默认装置了logstash-integration-jdbc，而此插件曾经蕴含logstash-input-jdbc./logstash-plugin install logstash-input-jdbc#查看logstash所有已装置的插件./logstash-plugin list配置logstashlogstash须要与mysql通信并获取数据，于是须要筹备与mysql通信的驱动程序，须要筹备拉取数据所须要执行的sql语句，还须要logstash的输出、输入端点。 创立相干目录及文件cd /usr/local/logstash-7.8.0mkdir mysqlcd mysqltouch jdbc.conftouch jdbc.sql mysql驱动程序，返回maven地方仓库获取获取数据的sql脚本（jdbc.sql）SELECT a.id, a.NAME, a.tags, concat( a.latitude, ',', a.longitude ) AS location, a.remark_score, a.price_per_man, a.category_id, b.NAME AS category_name, a.seller_id, c.remark_score AS seller_remark_score, c.disabled_flag AS seller_disabled_flag FROM shop a INNER JOIN category b ON a.category_id = b.id INNER JOIN seller c ON c.id = a.seller_idlogstash输出、输入配置input { jdbc { # mysql 数据库链接,dianping为数据库名 jdbc_connection_string => "jdbc:mysql://192.168.15.150:3306/dianping" # 用户名和明码 jdbc_user => "root" jdbc_password => "123456" # 驱动 jdbc_driver_library => "/usr/local/logstash-7.8.0/mysql/mysql-connector-java-5.1.47.jar" # 驱动类名 jdbc_driver_class => "com.mysql.jdbc.Driver" jdbc_paging_enabled => "true" jdbc_page_size => "50000" # 执行的sql 文件门路+名称 statement_filepath => "/usr/local/logstash-7.8.0/mysql/jdbc.sql" # 设置监听距离 各字段含意（由左至右）分、时、天、月、年，全副为*默认含意为每分钟都更新 schedule => "* * * * *" }}output { elasticsearch { # ES的IP地址及端口 hosts => ["192.168.15.151:9200"] # 索引名称 index => "shop" document_type => "_doc" # 自增ID 须要关联的数据库中有有一个id字段，对应索引的id号 document_id => "%{id}" } stdout { # JSON格局输入 codec => json_lines }}启动logstash#进入logstash装置目录cd /usr/local/logstash-7.8.0#后盾过程形式启动logstashnohup ./bin/logstash -f mysql/jdbc.conf &#查看logstash日志tail -f -n 100 ./nohup.out ...

一、基本概念1、Cluster（集群）es集群对外提供索引和搜寻的服务，其蕴含一个或者多个节点，每个节点都有对立的集群名称。参考本地集群搭建。 2、Node（节点）独自一个Elasticsearch服务器实例称为一个node，node是集群的一部分，每个node有独立的名称，默认是启动时获取一个UUID作为名称，也能够自行配置。 3、Shard（分片）Shard分片也称为primary shard，是单个Lucene索引，因为单台机器的存储容量是无限的，而Elasticsearch索引的数据可能特地大，单台机器无奈存储全副数据，就须要将索引中的数据切分为多个shard，散布在多台服务器上存储。利用shard能够很好地进行横向扩大，存储更多数据，让搜寻和剖析等操作散布到多台服务器下来执行，晋升集群整体的吞吐量和性能。创立索引时就应该预估好须要的分片数量，一旦创立则分片数量无奈更改。 4、Replica（复制分片）replica全称叫replica shard，是索引的正本，齐全拷贝shard的内容，shard与replica的关系能够是一对多，同一个shard能够有一个或多个replica。当集群中有节点宕机了，失落的shard会由replica补位，保证数据高可用；replica shard也能分担查问申请，晋升集群的吞吐量。 5、Index（索引）es索引，其保留具备雷同构造的文档汇合，相似于关系型数据库的数据库实例（6.0.0版本type废除后，索引的概念降落到等同于数据库表的级别）。一个集群里能够定义多个索引 6、Type（类型）类型，本来是在索引(Index)内进行的逻辑细分，但起初发现企业研发为了加强可浏览性和可维护性，制订的标准束缚，同一个索引下很少还会再应用type进行逻辑拆分（如同一个索引下既有订单数据，又有评论数据），因此在6.0.0版本之后，此定义废除。 7、Document（文档）Elasticsearch最小的数据存储单元，JSON数据格式，相似于关系型数据库的表记录（一行数据），构造定义多样化，同一个索引下的document，构造尽可能雷同。 8、Field type（字段类型）text：被剖析索引的字符串类型keyword：不能被剖析，只能被准确匹配的字符串类型date：日期类型，能够配合format一起应用long：长整型，数字类型integer：整型，数字类型short：短整型，数字类型double：双精度浮点型，数字类型Boolean：布尔型，true、falsearray：数组类型object：对象类型，json嵌套ip：ip类型geo_point：地理位置类型9、分词器ElasticSearch借助各种类型的分词器来对文档内容进行分词解决，以便于创立倒排索引，这是搜寻的外围。同时也对搜寻内容进行分词解决，用以在倒排索引中索引文档。 1、内置分词器规范分词器（standard analyzer）（默认）剖析过程：字符过滤器->字符解决->分词过滤（分词转换）阐明：首先是字符过滤器过滤掉特殊符号以及量词（the、an、a等），进一步将分词小写解决， 英文分词器（english analyzer）剖析过程：字符过滤器->字符解决->分词过滤（分词转换，词干转化）阐明：首先是字符过滤器过滤掉特殊符号以及量词（the、an、a等），进一步将分词小写解决，再次进行分词转换，例如：eating -> eat，其实它们两是一回事。 简略分词器（simple analyzer）先依照空格分词，英文大写转小写。 空格分词器（whitespace analyzer）先依照空格分词，英文不做大小写解决。 2、内部分词器中文分词器（ik_maxword）会将文本做最细粒度的拆分；尽可能多的拆分出词语，例如：如南京市长江大桥 --> 南京市/南京/市长/长江大桥/长江/大桥 中文分词器（ik_smart）会做最粗粒度的拆分；已被分出的词语将不会再次被其它词语占有，如南京市长江大桥 --> 南京市/长江大桥 二、根本语法1、筹备数据抱着学习的目标，首先须要ElasticSearch的环境，有了环境当前，咱们还须要初始化一批数据，咱们能够借助TMDB（the movie database）数据源来不便咱们练习根本语法。 参考本地ElasticSearch集群搭建TMDB（the movie database）数据源下载2、创立索引非结构化形式创立索引PUT /employee{ "settings": { "number_of_shards": 1, "number_of_replicas": 1 }}结构化形式创立索引PUT /movie{ "settings": { "number_of_shards": 1, "number_of_replicas": 1 }, "mappings": { "properties": { "title":{"type": "text","analyzer": "english"}, "tagline":{"type": "text","analyzer": "english"}, "release_date":{"type": "date","format": "8yyyy/MM/dd||yyyy/M/dd||yyyy/MM/d||yyyy/M/d"}, "popularity":{"type": "double"}, "overview":{"type": "text","analyzer": "english"}, "cast":{ "type": "object", "properties": { "character":{"type":"text","analyzer":"standard"}, "name":{"type":"text","analyzer":"standard"} } } } }}阐明：以上指定了个别字段应用英文分词器，日期类型指定了format，能够反对解析多种类型的日期字符串格局。 ...

下载ES安装包 wget https://artifacts.elastic.co/...解压缩 tar -zxvf elasticsearch-7.8.0-linux-x86_64.tar.gz将解压后的文件夹复制多份（这里复制三份，分别为node1, node2, node3）分别进入node1, node2, node3中修改配置文件(省略注释掉的信息) node1: node.name: node-1node.master: truenetwork.host: 0.0.0.0http.port: 9200transport.tcp.port: 9300discovery.seed_hosts: ["127.0.0.1:9300", "127.0.0.1:9310", "127.0.0.1:9320"]cluster.initial_master_nodes: ["node-1"]http.cors.enabled: truehttp.cors.allow-origin: "*"node2: node.name: node-2 node.master: false network.host: 0.0.0.0 http.port: 9210 transport.tcp.port: 9310 discovery.seed_hosts: ["127.0.0.1:9300", "127.0.0.1:9310", "127.0.0.1:9320"] http.cors.enabled: true http.cors.allow-origin: "*"node3: node.name: node-3 node.master: false network.host: 0.0.0.0 http.port: 9220 transport.tcp.port: 9320 discovery.seed_hosts: ["127.0.0.1:9300", "127.0.0.1:9310", "127.0.0.1:9320"] http.cors.enabled: true http.cors.allow-origin: "*"分别执行node1 node2 node2 中 bin/elasticseach 启动三个节点, -d 为后台启动./bin/elasticseach -d访问 http://ip:9200/ 即可查看到es实例信息ps: 节点内相互访问： ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍 06.当Elasticsearch进行文档索引时，它是如何工作的? 07.Elasticsearch中的映射方式—简洁版教程 08.Elasticsearch中的分析和分析器应用方式09.Elasticsearch中构建自定义分析器10.Kibana科普-作为Elasticsearhc开发工具11.Elasticsearch查询方法12.Elasticsearch全文查询13.Elasticsearch查询-术语级查询14.Python中的Elasticsearch入门15.使用Django进行ElasticSearch的简单方法16.关于Elasticsearch的6件不太明显的事情17.使用Python的初学者Elasticsearch教程18.用ElasticSearch索引MongoDB,一个简单的自动完成索引项目19.Kibana对Elasticsearch的实用介绍20.不和谐如何索引数十亿条消息21.使用Django进行ElasticSearch的简单方法 另外Elasticsearch入门，我强烈推荐ElasticSearch新手搭建手册和这篇优秀的REST API设计指南 给你，这两个指南都是非常想尽的入门手册。 前一段时间，我在Django项目上工作，想实现快速的自由文本搜索。我决定使用NoSQL数据库，而不是使用常规数据库来执行此搜索功能（例如MySQL或PostgreSQL）。那就是我发现ElasticSearch的时候。 ElasticSearch为您的数据索引文档，而不是像常规关系数据库那样使用数据表。这可以加快搜索速度，并提供其他常规数据库无法获得的其他好处。我还保留了一个常规的关系数据库，用于存储用户详细信息，登录名和其他不需要ElasticSearch索引的数据。 在搜索了如何使用Django正确实现ElasticSearch的很长时间之后，我并没有真正找到令人满意的答案。一些指南或教程令人费解，似乎正在采取不必要的步骤来将数据索引到ElasticSearch中。有关如何执行搜索的信息很多，但有关如何完成索引的信息却不多。我觉得那里肯定有一个更简单的解决方案，所以我决定自己尝试一下。 我想使它尽可能简单，因为简单的解决方案在我看来往往是最好的解决方案。KISS（保持简单愚蠢），少即是多，所有这些东西都引起了我的共鸣，特别是当其他解决方案非常复杂时。我决定在此视频中使用HonzaKrál的示例来为我的代码提供基础。我建议您观看它，尽管此时它有点过时了。 由于我使用的是用Python编写的Django，因此与ElasticSearch进行交互非常容易。有两个客户端库可通过Python与ElasticSearch进行交互。有elasticsearch-py，这是官方的低级客户端。还有elasticsearch-dsl，它是在前者的基础上构建的，但是它提供了更高层次的抽象，但功能却少了一点。 我们将很快讨论一些示例，但首先我需要阐明我们要完成的工作：● 在我们的本地计算机上设置ElasticSearch并确保其正常运行● 设置一个新的Django项目● 批量索引数据库中已经存在的数据● 用户保存到数据库的每个新实例的索引● 基本搜索示例 好吧，这似乎很简单。让我们开始在我们的机器上安装ElasticSearch。另外，所有代码都将在我的GitHub上可用，因此您可以轻松地遵循示例。 安装ElasticSearch由于ElasticSearch在Java上运行，因此必须确保您具有更新的JVM版本。检查java -version终端中的版本。然后运行以下命令来创建新目录，下载，解压缩并启动ElasticSearch： mkdir elasticsearch-examplewget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-5.1.1.tar.gztar-xzf elasticsearch-5.1.1.tar.gz./elasticsearch-5.1.1/bin/elasticsearch当ElasticSearch启动时，应该在终端窗口上打印很多输出。要检查其启动和运行是否正确，请打开一个新的终端窗口并运行以下curl命令： curl -XGET http：// localhost：9200响应应该是这样的：{ "name" : "6xIrzqq", "cluster_name" : "elasticsearch", "cluster_uuid" : "eUH9REKyQOy4RKPzkuRI1g", "version" : { "number" : "5.1.1", "build_hash" : "5395e21", "build_date" : "2016-12-06T12:36:15.409Z", "build_snapshot" : false, "lucene_version" : "6.3.0" }, "tagline" : "You Know, for Search"太好了，您现在已经在本地计算机上运行了ElasticSearch！现在该设置您的Django项目了。设置Django项目首先，您要使用创建一个虚拟环境，virtualenv venv然后使用进行输入，source venv/bin/activate以保留所有内容。然后安装一些软件包： ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍 06.当Elasticsearch进行文档索引时，它是如何工作的? 07.Elasticsearch中的映射方式—简洁版教程 08.Elasticsearch中的分析和分析器应用方式09.Elasticsearch中构建自定义分析器10.Kibana科普-作为Elasticsearhc开发工具11.Elasticsearch查询方法12.Elasticsearch全文查询13.Elasticsearch查询-术语级查询14.Python中的Elasticsearch入门15.使用Django进行ElasticSearch的简单方法16.关于Elasticsearch的6件不太明显的事情17.使用Python的初学者Elasticsearch教程18.用ElasticSearch索引MongoDB,一个简单的自动完成索引项目19.Kibana对Elasticsearch的实用介绍20.不和谐如何索引数十亿条消息 另外Elasticsearch入门，我强烈推荐ElasticSearch新手搭建手册给你，非常想尽的入门指南手册。 每月有数百万用户在Discord上发送数十亿条消息。一种搜索历史记录的方法迅速成为我们构建的最受欢迎的功能之一。让我们搜索吧！要求● 经济高效： Discord的核心用户体验是我们的文本和语音聊天。搜索是一项辅助功能，而反映这一功能所需的基础架构价格。理想情况下，这意味着搜索的费用不应超过消息的实际存储量。● 快速直观：我们构建的所有功能都必须快速直观，包括搜索。我们产品的搜索体验也需要看起来和使用起来很棒。● 自我修复：我们还没有一支专门的devop小组（因此），因此搜索需要能够以最少的操作员干预或完全没有操作员的干预来容忍失败。● 线性可扩展：就像我们存储消息的方式一样，增加搜索基础结构的容量应涉及添加更多节点。● 懒惰地索引：并非所有人都使用搜索-我们不应该对消息建立索引，除非有人尝试至少搜索一次。此外，如果索引失败，我们需要能够动态地重新索引服务器。 在查看这些要求时，我们向自己提出了两个关键问题：问：我们可以将搜索外包给托管的SaaS吗？（简易模式）A.不。我们研究过的每一项解决方案都进行了托管搜索，这会浪费我们的预算（天文数字很高）。此外，将消息从我们的数据中心中发送出去的想法与团队并不协调。作为一个注重安全的团队，我们希望控制用户消息的安全性，而不是让第三方知道他们在做什么。问：是否存在可以使用的开源搜索解决方案？答：是的！我们环顾四周，内部很快就开始讨论Elasticsearch vs Solr，因为两者都适合我们的用例。Elasticsearch具有优势：● Solr上的节点发现需要ZooKeeper。我们运行etcd，并且不想拥有专门用于Solr的其他基础结构。Elasticsearch的Zen Discovery自成一体。● Elasticsearch支持自动分片重新平衡，这将使我们能够向集群添加新节点，从而满足开箱即用的线性可扩展性要求。● Elasticsearch具有内置的结构化查询DSL，而您必须使用第三方库以Solr编程方式创建查询字符串。● 团队的工程师拥有更多与Elasticsearch合作的经验Elasticsearch可以工作吗？Elasticsearch似乎具备了我们想要的一切，并且我们的工程师在过去曾有过使用它的经验。它提供了一种跨不同节点复制数据的方法，以容忍单个节点的故障，通过添加更多节点来扩展群集，并可以吸收要索引的消息而不会费劲。到处阅读，我们听到了一些有关管理大型Elasticsearch集群的恐怖故事，实际上，除了日志记录基础架构之外，我们的后端团队都没有任何管理Elasticsearch集群的经验。我们想避免这些繁琐的大型集群，因此我们想到了将分片和路由委托给应用程序层的想法，使我们可以将消息索引到较小的Elasticsearch集群池中。这意味着在群集中断的情况下，仅受影响的群集上包含的Discord消息将不可搜索。这还为我们提供了以下优势：如果无法恢复整个群集的数据，则可以丢弃整个群集的数据（系统可以在用户下次执行搜索时懒惰地重新索引Discord服务器）。组成部分当文档被大量索引时，Elasticsearch喜欢它。这意味着我们无法为实时发布的消息编制索引。取而代之的是，我们设计了一个队列，其中工作人员在单个批量操作中抓取一堆消息并将它们编入索引。我们认为，从发布消息到可搜索消息之间的微小延迟是一个完全合理的约束。毕竟，大多数用户搜索的都是历史记录而不是刚才所说的消息。 在摄取方面，我们需要一些注意事项：● 消息队列：我们需要一个队列，我们可以在消息实时发布时将其放入（供工作人员使用）。● 索引工作人员：执行实际路由和批量插入的工作人员从队列插入Elasticsearch。我们已经在Celery之上构建了一个任务排队系统，因此我们也将其用于历史索引工作者。● 历史索引工作人员：负责在给定服务器中遍历消息历史并将其插入到Elasticsearch索引中的工作人员。我们还需要快速，轻松地映射Discord服务器的消息将驻留在哪个Elasticsearch集群上并建立索引。我们将此“群集+索引”对称为碎片（不要与索引中的Elasticsearch的本地碎片混淆）。我们创建的映射分为两层：● 持久性碎片映射：我们将其放在Cassandra上，这是持久性数据的主要数据存储，是事实的来源。● 分片映射缓存：当我们在工作人员上接收消息时，向Cassandra查询分片是一个很慢的操作。我们将这些映射缓存在Redis中，以便我们可以执行mget操作来快速确定需要将消息路由到的位置。 首次为服务器建立索引时，我们还需要一种方法来选择用于保留Discord服务器消息的碎片。由于分片是应用程序分层的抽象，因此我们可以对如何分配它们有所了解。通过利用Redis的功能，我们使用了排序集来构建负载感知的分片分配器。● 分片分配器：在Redis中使用排序集，我们保留了一组分片，其得分代表其负荷。得分最低的分片是接下来应该分配的分片。分数随着每次新分配而增加，并且在Elasticsearch中索引的每条消息也都有可能增加其Shard的分数。随着分片中获得更多数据，它们被分配给新Discord服务器的可能性就较小。当然，如果没有从应用程序层发现集群及其中的主机的方法，那么整个搜索基础架构将是不完整的。● etcd：我们在系统的其他部分中使用etcd进行服务发现，因此我们也将其用于Elasticsearch集群。由于集群中的节点可以将自己声明到etcd上，以供系统其余部分查看，因此我们不必对任何Elasticsearch拓扑进行硬编码。最后，我们需要一种让客户能够实际搜索事物的方法。● 搜索API：客户端可以向其发出搜索查询的API端点。它需要进行所有权限检查，以确保客户端仅搜索他们实际有权访问的消息。 索引和映射数据在非常高的层次上，在Elasticsearch中，我们有一个“索引”的概念，其中包含许多“碎片”。在这种情况下，分片实际上是Lucene索引。Elasticsearch负责将索引内的数据分发到属于该索引的分片。如果需要，可以使用“路由键”控制数据在分片之间的分配方式。索引也可以包含“复制因子”，即索引（及其中的分片）应复制到的节点数。如果索引所在的节点发生故障，则副本可以接管（不相关但相关，这些副本也可以用于搜索查询，因此您可以通过添加更多副本来扩展索引的搜索吞吐量）。由于我们在应用程序级别（我们的分片）中处理了所有分片逻辑，因此让Elasticsearch为我们进行分片实际上没有任何意义。但是，我们可以使用它在集群中的节点之间进行索引的复制和平衡。为了让Elasticsearch使用正确的配置自动创建索引，我们使用了索引模板，其中包含索引配置和数据映射。索引配置非常简单：● 索引只能包含一个分片（不要为我们做任何分片）● 索引应复制到一个节点（能够容忍索引所在的主节点的故障）● 索引每60分钟应刷新一次（为什么要这样做，下面将进行说明）。 索引包含一个文档类型： message 将原始消息数据存储在Elasticsearch中几乎没有意义，因为数据的格式不是易于搜索的格式。相反，我们决定采用每条消息，并将其转换为一堆字段，其中包含有关消息的元数据，我们可以对其进行索引和搜索： 您会注意到，我们没有在这些字段中包含时间戳，并且如果您从我们以前的博客文章中回忆起，我们的ID是Snowflakes，这意味着它们固有地包含时间戳（我们可以在之前，之后和之后使用它来加电）使用最小和最大ID范围进行查询）。 但是，这些字段实际上并没有“存储”在Elasticsearch中，而是仅存储在反向索引中。实际存储和返回的唯一字段是张贴消息的消息，通道和服务器ID。这意味着消息数据在Elasticsearch中不会重复。折衷是，我们必须在返回搜索结果时从Cassandra获取消息，这是完全可以的，因为我们必须从Cassandra中提取消息上下文（前后2条消息）以始终为UI供电。将实际的消息对象保留在Elasticsearch之外意味着我们不必为存储它而额外的磁盘空间。但是，这意味着我们无法使用Elasticsearch突出显示搜索结果中的匹配项。我们必须将标记生成器和语言分析器内置到我们的客户端中以进行突出显示（这确实很容易做到）。 实际编码我们认为可能不需要微服务来搜索，而是向Elasticsearch公开了一个封装了路由和查询逻辑的库。我们唯一需要运行的附加服务是索引工作程序（它将使用此库来执行实际的索引工作）。暴露给团队其他成员的API表面积也很小，因此，如果确实需要将其转移到它自己的服务中，则可以轻松地将其包装在RPC层中。该库也可以由我们的API工作者导入，以实际执行搜索查询并通过HTTP将结果返回给用户。 对于团队的其他成员，该库暴露了用于搜索消息的最小表面积：排队要编制索引或删除的消息： 批量索引工作人员中的实时消息（大致）： 为了对服务器的历史消息建立索引，一个历史索引作业将执行一个工作单元，并返回继续运行该服务器所需的下一个作业。每个作业代表进入服务器消息历史记录和固定执行单位的光标（在这种情况下，默认值为500条消息）。作业将新游标返回到要索引的下一批消息，如果没有更多工作要做，则返回“无”。为了快速返回大型服务器的结果，我们将历史索引分为两个阶段，即“初始”阶段和“深度”阶段。“初始”阶段为服务器上最近7天的邮件编制索引，并使索引可供用户使用。之后，我们在“深层”阶段对整个历史进行索引，该阶段以较低的优先级执行。本文显示给用户的外观。这些作业在一组芹菜工作者中执行，从而可以在这些工作者执行的其他任务中安排这些工作。大致如下所示： 在生产中进行测试 在对此进行编码并在我们的开发环境上对其进行测试之后，我们决定是时候看看它在生产中的性能了。我们创建了一个包含3个节点的单个Elasticsearch集群，配置了索引工作器，并计划对1,000个最大的Discord服务器进行索引。一切似乎都正常，但是在查看集群中的指标时，我们注意到了两件事： CPU使用率高于预期。磁盘使用率增长得太快了，无法索引大量消息。我们很困惑，在让它运行了一段时间并用完了太多的磁盘空间之后，我们取消了索引作业，并将其命名为通宵。不太正确。第二天早上回来时，我们注意到磁盘使用量减少了很多。Elasticsearch是否丢弃了我们的数据？我们尝试在我们索引其中一台服务器所在的一台服务器上发出搜索查询。结果返回的很好-而且速度也很快！是什么赋予了？ 磁盘使用率快速增长然后逐渐减少 CPU使用率经过研究后，我们提出了一个假设！默认情况下，Elasticsearch的索引刷新间隔设置为1秒。这就是在Elasticsearch中提供“近实时”搜索功能的原因。每隔一千个索引（跨越一千个索引），Elasticsearch会将内存缓冲区刷新到Lucene段，并打开该段使其可搜索。一整夜，Elasticsearch在空闲时将其生成的大量细小段合并为磁盘上更大（但更节省空间）的段。测试这一点非常简单：我们将所有索引都放在了集群上，将刷新间隔设置为任意大的数字，然后我们计划对同一服务器进行索引。提取文档时，CPU使用率几乎降为零，并且磁盘使用率没有以惊人的速度增长。晕！减少刷新间隔后的磁盘使用率 CPU使用率 但是，不幸的是，实际上，关闭刷新间隔是无效的……刷新困境显而易见，Elasticsearch的自动近实时索引可用性无法满足我们的需求。可能服务器无需执行单个搜索查询就可以运行数小时。我们需要建立一种方法来控制应用程序层的刷新。我们通过Redis中过期的hashmap做到了这一点。假设Discord上的服务器已在Elasticsearch上共享为共享索引，我们可以构建一个快速映射，该索引随索引一起更新，跟踪是否需要刷新索引（给定要搜索的服务器）。数据结构很简单：存储哈希图的Redis密钥prefix + shard_key到标记guild_id 值的哈希图，表示需要刷新。回想起来，这可能是一个集合。因此，索引生命周期变为：从队列中提取N条消息。找出这些消息应由其路由到何处guild_id对相关集群执行批量插入操作。更新Redis映射，表示该碎片和该碎片中的给定guild_id s现在已变脏。1小时后使该密钥过期（因为此时Elasticsearch会自动刷新）。搜索生命周期变成：如果脏了，请刷新碎片的Elasticsearch索引，并将整个碎片标记为干净。执行搜索查询并返回结果。您可能已经注意到，即使我们现在已经在Elasticsearch上显式控制了刷新逻辑，我们仍然让它每小时自动刷新基础索引。如果在我们的Redis映射上发生数据丢失，则系统最多需要一个小时才能自动更正自身。未来自1月份部署以来，我们的Elasticsearch基础架构已扩展到2个集群中的14个节点，使用GCP上的n1-standard-8实例类型，每个实例类型具有1TB的Provisioned SSD。文件总数约为260亿。索引速率达到峰值，约为每秒30,000条消息。Elasticsearch毫不费力地处理了它-在我们推出搜索的整个过程中，CPU保持在5-15％。 到目前为止，我们已经能够轻松地向集群添加更多节点。在某个时候，我们将启动更多集群，以便新的Discord服务器被索引到它们上（这要归功于我们的加权分片分发系统）。在我们现有的集群上，随着向集群中添加更多数据节点，我们将需要限制主合格节点的数量。我们还偶然发现了4个主要指标，用于确定何时需要增长集群： ...

引言Elasticsearch（以下简称ES）并不像mysql这么容易上手，很多java程序员会觉得ES的java客户端比较难以掌握，尽管ES 7.x官方推荐的high level client已经相对于早期的TransportClient好用很多了。 Spring Boot通过整合Spring Data ElasticSearch为我们提供了非常便捷的检索功能支持，我们几乎可以像操作数据库一样操作ES了。本篇文章是我肝了4个小时写出的文章，希望能对大家有所帮助。 看这篇文章的小伙伴，我假设是对ES有基本了解的。比如了解ES中索引（index），文档（document），文档的属性（field）等基本概念。 本篇最后给出代码示例的下载地址，小伙们可以放心使用，我的示例都是经过验证的。 环境准备ES的环境我是本地搭建的7.1.0的版本，你可以启动集群模式或者单节点模式。集群模式是用不同的端口模拟的伪集群。具体的过程不是本文的重点这里不表。 spring boot 使用的是2.3.1.RELEASE版本。 spring data 使用的是 4.0.1.RELEASE版本。 示例引入依赖首先是maven引入依赖，我这里引入写这篇文章时最新的spring data，如下： <dependency> <groupId>org.springframework.data</groupId> <artifactId>spring-data-elasticsearch</artifactId> <version>4.0.1.RELEASE</version> </dependency>这里有一点需要强调，4.0.1的spring-data-elasticsearch默认引入的ES客户端版本是7.6.2，而我前面说了集群是7.1.0版本。 在启动的时候会有警告信息告诉我们客户端和服务端版本不一致。因为我们是演示DEMO，并不影响。但是在实际项目中我还是建议你尽量保持客户端和服务端版本的一致。 集群配置然后我们需要使用配置文件或者配置类注入ES集群的客户端，代码如下： @Configurationpublic class RestClientConfig extends AbstractElasticsearchConfiguration { @Override @Bean public RestHighLevelClient elasticsearchClient() { final ClientConfiguration clientConfiguration = ClientConfiguration.builder() .connectedTo("localhost:9200", "localhost:9201", "localhost:9202", "localhost:9203") .build(); return RestClients.create(clientConfiguration).rest(); }}前面说过，我是用本地的伪集群搭建的ES环境，这里大家根据自己的集群情况配置地址即可。 测试连通性我写个单元测试看看集群连接是否正常， @SpringBootTest(classes = {DemoApplication.class})class DemoApplicationTests { @Autowired RestHighLevelClient highLevelClient; @Test void testESClient() throws IOException { GetRequest getRequest= new GetRequest("kibana_sample_data_ecommerce", "V5z1f28BdseAsPClo7bC"); GetResponse getResponse = highLevelClient.get(getRequest, RequestOptions.DEFAULT); System.out.println(getResponse.getIndex()); System.out.println(getResponse.toString()); }}很简单，我读取集群中名为kibana_sample_data_ecommerce的索引（这是kibana自带的一个电商的索引示例），查询ID等于V5z1f28BdseAsPClo7bC的文档，这个测试程序打印的结果如下： ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍 06.当Elasticsearch进行文档索引时，它是如何工作的? 07.Elasticsearch中的映射方式—简洁版教程 08.Elasticsearch中的分析和分析器应用方式09.Elasticsearch中构建自定义分析器10.Kibana科普-作为Elasticsearhc开发工具11.Elasticsearch查询方法12.Elasticsearch全文查询13.Elasticsearch查询-术语级查询14.Python中的Elasticsearch入门15.使用Django进行ElasticSearch的简单方法16.关于Elasticsearch的6件不太明显的事情17.使用Python的初学者Elasticsearch教程18.用ElasticSearch索引MongoDB,一个简单的自动完成索引项目19.Kibana对Elasticsearch的实用介绍 另外Elasticsearch入门，我强烈推荐ElasticSearch新手搭建手册给你，非常想尽的入门指南手册。 什么是ElasticsearchElasticsearch是一个高度可扩展的开源搜索引擎。它使您可以实时地保留和分析大量信息。Elasticsearch使用JSON文档文件。使用内部结构，它可以几乎实时地解析您的数据以搜索所需的信息。在处理大数据时非常有用。 定义和其他东西有关Elasticsearch的一些技术（但有用）信息是：● 它是一个实时的分布式分析引擎。● 它是开源的，用Java开发。● 它使用基于文档的结构而不是表和架构。我发现的最大好处是速度和可伸缩性。它以允许查询真正快速的方式实现。关于可伸缩性，它可以在您的笔记本电脑或数以PB计的数据的数百台服务器中运行。 除了速度和可伸缩性之外，它还具有与故障相关的高弹性，并且在数据类型方面具有很高的灵活性。 同样，Elasticsearch对大数据非常有用，可以轻松地在几乎实时的搜索中分析数百万个数据。这就是Elasticsearch的魔力。 但是，您如何搜索所有这些数据？为此，您使用查询。 查询：执行和组合多种类型的搜索（例如结构化，非结构化，地理，度量等）的语言。您可以“无论如何都要”进行查询。 关于分析，Elasticsearch使您可以轻松了解数十亿条日志行。它提供了汇总，可帮助您缩小范围以探索数据中的趋势和模式。 例如，如果您有一个具有500个节点的云，则可以在短时间内分析整个基础架构，将日志导入Elasticsearch，然后根据其响应，找出导致基础架构出现问题的根本原因。 其他使用示例：● 显示具有特定值的数据。例如：从数据库中显示所有23岁的用户。● 选择具有特定值的数据按地理位置搜索数据● 地理搜索按天汇总数据 客户群Elasticsearch非常有趣，以至Mozilla，GitHub，Stack Exchange，Netflix和更多用户使用它。动手既然您已经对Elasticsearch有所了解，那么我们来看这个故事的实际部分。安装 要执行Elasticsearch，您必须：安装Java：版本应为8或更高。安装Elasticsearch：并按照以下步骤在您的操作系统中进行安装。如果您安装了装有Homebrew的MacOS，则只需输入以下内容即可安装 brew install elasticsearch接口要使用Elasticsearch，您将需要一个接口。在这个故事中，我将使用Kibana（一个很棒的Web界面）来可视化和操纵Elasticsearch的数据。 可以在elastic.co中下载并按照此处介绍的步骤进行安装，或者通过以下命令使用Homebrew： brew install kibana 您需要为Elasticsearch和Kibana下载相同的版本。将来，当您发现自己需要开发与Elasticsearch进行交互的软件时，可以使用编程语言与之交互。一些可接受的编程语言是：● Java● C#● Python● JavaScript● PHP● Perl● Ruby基本概念好！现在您已经安装了Elasticsearch和Kibana。在开始使用它之前，让我们看一些有关Elasticsearch的有用概念。Elasticsearch是由 簇群集是一个或多个节点的集合，这些节点一起保存整个数据。它在所有节点上提供联合索引和搜索功能，并由唯一名称标识（默认情况下为'/ elasticsearch'/） 节点节点是作为群集一部分的单个服务器，它存储数据并参与群集的索引和搜索功能。 指数索引是具有相似特征的文档的集合，并由名称标识。此名称用于在对索引中的文档执行索引，搜索，更新和删除操作时引用索引。在单个群集中，您可以定义任意多个索引。 文件文件是可以编制索引的基本信息单位。它以JSON表示，JSON是一种普遍存在的Internet数据交换格式。 碎片Elasticsearch提供了将索引细分为多个碎片的功能。每个分片本身就是一个功能齐全且独立的“索引”，可以托管在群集内的任何节点上。当放置在单个节点中的索引占用的磁盘空间超过可用磁盘空间时，这很有用。然后，将索引细分为不同的节点。此外，分片允许您在各个分片之间分配和并行化操作，从而提高性能。 复制品Elasticsearch允许您为索引的分片制作一个或多个副本，这些副本称为副本分片或副本。如果节点发生故障，它可以提供高可用性，并且由于可以在所有副本上并行执行搜索，因此可以扩展搜索量。执行中好吧，现在，让我们真正地动手吧。转到安装Elasticsearch的目录，然后通过终端执行该命令$ ./elasticsearch 如果您是使用Homebrew安装的，请尝试输入elasticsearch 终端。它可以启动Elasticsearch，而无需转到其目录。Elasticsearch开始现在，正在执行Elasticsearch，打开另一个终端窗口并执行Kibana，转到其目录并执行，$ ./kibana 或者使用Homebrew，只需输入 $ kibanaKibana开始了如果一切顺利，那么您将同时被执行。要进行验证，请打开网络浏览器，然后转到：http://localhost:9200http://localhost:9200 结果表明Elasticsearch正在运行如果您看到与上述相似的结果，则表明Elasticsearch已启动并正在运行。要查看Kibana界面，请转到： http://localhost:5601 位于http：// localhost：5601的Kibana界面如果一切都如上所示，现在让''播放一些数据。指令在Kibana界面中，选择左侧菜单上的开发工具。您将看到一个左侧的控制台来键入命令，而右侧的控制台来查看结果。让我们看看可用于操作数据的命令。 ...

概要性能调优是系统架构里所有组件必不可少的话题，Elasticsearch也不例外，虽说Elasticsearch内的默认配置已经非常优秀，但这不表示它就是完美的，必要的一些实践我们还是需要了解一下。 开启慢查询日志慢查询日志是性能诊断的重要利器，常规操作是设置慢查询的阀值，然后运维童鞋每天对慢日志进行例行巡查，有特别慢的查询，立即报备事件处理，其余的定期将慢日志的top n取出来进行优化。 慢日志的配置在elasticsearch 6.3.1版本下是通过命令配置的，读操作和写操作可以单独设置，阀值的定义可根据实际的需求和性能指标，有人觉得5秒慢，有人觉得3秒就不可接受，我们以3秒为例： PUT /_all/_settings{"index.search.slowlog.threshold.query.warn":"3s","index.search.slowlog.threshold.query.info":"2s","index.search.slowlog.threshold.query.debug":"1s","index.search.slowlog.threshold.query.trace":"500ms","index.search.slowlog.threshold.fetch.warn":"1s","index.search.slowlog.threshold.fetch.info":"800ms","index.search.slowlog.threshold.fetch.debug":"500ms","index.search.slowlog.threshold.fetch.trace":"200ms","index.indexing.slowlog.threshold.index.warn":"3s","index.indexing.slowlog.threshold.index.info":"2s","index.indexing.slowlog.threshold.index.debug":"1s","index.indexing.slowlog.threshold.index.trace":"500ms","index.indexing.slowlog.level":"info","index.indexing.slowlog.source":"1000"}这三段分别表示query查询、fetch查询和index写入三类操作的慢日志输出阀值，_all表示对所有索引生效，也可以针对具体的索引。 同时在log4j2.properties配置文件中增加如下配置： # 查询操作慢日志输出appender.index_search_slowlog_rolling.type = RollingFileappender.index_search_slowlog_rolling.name = index_search_slowlog_rollingappender.index_search_slowlog_rolling.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}_index_search_slowlog.logappender.index_search_slowlog_rolling.layout.type = PatternLayoutappender.index_search_slowlog_rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c] %.10000m%nappender.index_search_slowlog_rolling.filePattern = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}_index_search_slowlog-%d{yyyy-MM-dd}.logappender.index_search_slowlog_rolling.policies.type = Policiesappender.index_search_slowlog_rolling.policies.time.type = TimeBasedTriggeringPolicyappender.index_search_slowlog_rolling.policies.time.interval = 1appender.index_search_slowlog_rolling.policies.time.modulate = truelogger.index_search_slowlog_rolling.name = index.search.slowloglogger.index_search_slowlog_rolling.level = tracelogger.index_search_slowlog_rolling.appenderRef.index_search_slowlog_rolling.ref = index_search_slowlog_rollinglogger.index_search_slowlog_rolling.additivity = false# 索引操作慢日志输出appender.index_indexing_slowlog_rolling.type = RollingFileappender.index_indexing_slowlog_rolling.name = index_indexing_slowlog_rollingappender.index_indexing_slowlog_rolling.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}_index_indexing_slowlog.logappender.index_indexing_slowlog_rolling.layout.type = PatternLayoutappender.index_indexing_slowlog_rolling.layout.pattern = [%d{ISO8601}][%-5p][%-25c] %marker%.10000m%nappender.index_indexing_slowlog_rolling.filePattern = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}_index_indexing_slowlog-%d{yyyy-MM-dd}.logappender.index_indexing_slowlog_rolling.policies.type = Policiesappender.index_indexing_slowlog_rolling.policies.time.type = TimeBasedTriggeringPolicyappender.index_indexing_slowlog_rolling.policies.time.interval = 1appender.index_indexing_slowlog_rolling.policies.time.modulate = truelogger.index_indexing_slowlog.name = index.indexing.slowlog.indexlogger.index_indexing_slowlog.level = tracelogger.index_indexing_slowlog.appenderRef.index_indexing_slowlog_rolling.ref = index_indexing_slowlog_rollinglogger.index_indexing_slowlog.additivity = false重启elasticsearch实例后，就能在/home/esuser/esdata/log目录中看到生成的两个日志文件了。 ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍 06.当Elasticsearch进行文档索引时，它是如何工作的? 07.Elasticsearch中的映射方式—简洁版教程 08.Elasticsearch中的分析和分析器应用方式09.Elasticsearch中构建自定义分析器10.Kibana科普-作为Elasticsearhc开发工具11.Elasticsearch查询方法12.Elasticsearch全文查询13.Elasticsearch查询-术语级查询14.Python中的Elasticsearch入门15.使用Django进行ElasticSearch的简单方法16.关于Elasticsearch的6件不太明显的事情17.使用Python的初学者Elasticsearch教程18.用ElasticSearch索引MongoDB,一个简单的自动完成索引项目 另外Elasticsearch入门，我强烈推荐ElasticSearch入门指南给你，非常想尽的入门指南手册。 关于全文搜索如今，在任何网站或应用程序中都具有搜索功能已经很普遍。这通常发生在具有大量信息要提供给用户的平台上。从拥有数千种不同类别产品的电子商务网站，到拥有数千篇文章的博客或新闻网站。每当客户/用户/阅读者访问此类网站时，他们都会自动趋向于找到一个搜索框，在其中可以键入查询以找到所需的特定文章/产品/内容。糟糕的搜索引擎会导致用户沮丧，他们很可能永远不会再回到我们的网站。全文搜索为您每天在网站上使用的所有搜索框提供强大的功能，以查找所需的内容。每当您想在Amazon产品数据库中找到该蝙蝠侠手机壳时，或者当您在Youtube上搜索玩有激光灯视频的猫时。当然，这个庞大的网站还依赖其他许多功能来增强搜索引擎的功能，但是所有搜索的基础都是全文索引。也就是说，让我们看看这篇文章是关于什么的。MongoDB的局限性如果您快速进行Google搜索，MongoDB full text 则会在MongoDB文档中发现支持全文搜索。那么，为什么我们要麻烦学习像Elastic Search这样的新复杂技术，又为什么要在我们的系统架构中引入新的复杂性呢？让我们看一下MongoDB文本搜索支持以找出原因。我将假定您已经安装了MongoDB，并且您已经了解它的基础知识。如果是这种情况，请继续打开控制台，然后运行mongo 命令以访问MongoDB控制台并创建一个名为的数据库fulltext $ mongo$ use fulltext switched to db fulltext我们的测试数据库将存储文章，因此让我们添加一个称为的集合articles$ db.createCollection('articles') '{ "ok" : 1 }'现在，让我们添加一些对测试有用的文档。我们将插入标题和段落作为内容的文章。我从《纽约时报》的《交易手册》的两篇文章中摘录了几段。$ db.articles.insert({ ... title: 'Yahoo sale to Verizon', ... content: 'The sale is being done in two steps. The first step will be the transfer of any assets related to Yahoo business to a singular subsidiary. This includes the stock in the business subsidiaries that make up Yahoo that are not already in the single subsidiary, as well as the odd assets like benefit plan rights. This is what is being sold to Verizon. A license of Yahoo’s oldest patents is being held back in the so-called Excalibur portfolio. This will stay with Yahoo, as will Yahoo’s stakes in Alibaba Group and Yahoo Japan.' ... }) WriteResult({ "nInserted" : 1 })$ db.articles.insert({ ... title: 'Chinese Group to Pay $4.4 Billion for Caesars Mobile Games', ... content: 'In the most recent example in a growing trend of big deals for smartphone-based games, a consortium of Chinese investors led by the game company Shanghai Giant Network Technology said in a statement on Saturday that it would pay $4.4 billion to Caesars Interactive Entertainment for Playtika, its social and mobile games unit. Caesars Interactive is controlled by the owners of Caesars Palace and other casinos in Las Vegas and elsewhere.' ... }) WriteResult({ "nInserted" : 1 })现在我们有了文档，我们需要使用MongoDB文本索引对它们进行索引。因此，让我们在集合的 ...

前言Elasticsearch + Logstash + Kibana（ELK）是一套开源的日志管理方案，分析网站的访问情况时我们一般会借助 Google / 百度 / CNZZ 等方式嵌入 JS 做数据统计，但是当网站访问异常或者被攻击时我们需要在后台分析如 Nginx 的具体日志，而 Nginx 日志分割 / GoAccess/Awstats 都是相对简单的单节点解决方案，针对分布式集群或者数据量级较大时会显得心有余而力不足，而 ELK 的出现可以使我们从容面对新的挑战。 Logstash：负责日志的收集，处理和储存 Elasticsearch：负责日志检索和分析 Kibana：负责日志的可视化 ELK(Elasticsearch + Logstash + Kibana) 搭建过程环境准备下载RPM包 P.S： 由于ES的官网的速度对我们国内很不友好，我已经将安装包传至国内网站上，直接下载即可 kibana-7.8.0-x86_64.rpm elasticsearch-7.8.0-x86_64.rpm logstash-7.8.0.rpm windows:先下载在主机上，通过软件上传至服务器端Linux:通过SCP命令上传至服务器端 安装Elasticsearchyum -y install elasticsearch-7.8.0-x86_64.rpmsed -i '17s/#cluster.name: my-application/cluster.name: elk/' /etc/elasticsearch/elasticsearch.ymlsed -i '23s/#node.name: node-1/node.name: node-1/' /etc/elasticsearch/elasticsearch.ymlsed -i '55s/#network.host: 192.168.0.1/network.host: 127.0.0.1/' /etc/elasticsearch/elasticsearch.ymlsystemctl daemon-reloadsystemctl enable elasticsearch.servicesystemctl start elasticsearch安装Kibanayum -y install kibana-7.8.0-x86_64.rpmsed -i '7s/#server.host: "localhost"/server.host: "0.0.0.0"/' /etc/kibana/kibana.ymlsed -i '28s/#elasticsearch.hosts: .*/elasticsearch.hosts: ["http:\/\/127.0.0.1:9200"]/' /etc/kibana/kibana.yml#清空防火墙规则iptables -F service iptables savesystemctl enable kibanasystemctl start kibana安装Logstashyum -y install logstash-7.8.0.rpm 验证访问 http://服务器地址:5601/ ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍 06.当Elasticsearch进行文档索引时，它是如何工作的? 07.Elasticsearch中的映射方式—简洁版教程 08.Elasticsearch中的分析和分析器应用方式09.Elasticsearch中构建自定义分析器10.Kibana科普-作为Elasticsearhc开发工具11.Elasticsearch查询方法12.Elasticsearch全文查询13.Elasticsearch查询-术语级查询14.Python中的Elasticsearch入门15.使用Django进行ElasticSearch的简单方法16.关于Elasticsearch的6件不太明显的事情17.使用Python的初学者Elasticsearch教程 另外Elasticsearch入门，我强烈推荐ElasticSearch搭建手册给你，非常想尽的入门指南手册。 Elasticsearch是一个实时的分布式搜索和分析引擎。它使您能够以前所未有的速度和规模探索数据。它用于全文搜索，结构化搜索，分析以及所有这三种方法的组合。弹性搜索是基于Apache Lucecne（一个全文本搜索引擎库）构建的开源搜索引擎。安装并运行Elasticsearch：安装Elasticsearch的唯一要求是Java的最新版本。要安装Elasticsearch，请从elastic.co/downlaods/elasticsearch下载并提取存档文件，然后只需运行bin elasticsearch.bat。 索引就像传统数据库中的数据库。它是存储相关文档的地方。要检索任何文档，我们需要三条信息 索引—数据库数据类型-文档类型ID-文件ID让我们开始表演吧…… Import Elasticsearch packagefrom elasticsearch import Elasticsearch Connect to the elastic clusteres=Elasticsearch([{'host':'localhost','port':9200}])es<Elasticsearch([{'host': 'localhost', 'port': 9200}])> Elasticsearch是面向文档的，这意味着它可以存储整个对象或文档。它不仅存储它们，而且索引每个文档的内容以使其可搜索。在Elasticsearch中，您可以对文档进行索引，搜索，排序和过滤。Elasticsearch使用JSON作为文档的序列化格式。现在让我们开始索引员工文档。在Elasticsearch中存储数据的行为称为索引编制。Elasticsearch集群可以包含多个索引，而索引又包含多个类型。这些类型包含多个文档，并且每个文档都有多个字段。 e1={ "first_name":"nitin", "last_name":"panwar", "age": 27, "about": "Love to play cricket", "interests": ['sports','music'],}print e1{'interests': ['sports', 'music'], 'about': 'Love to play cricket', 'first_name': 'nitin', 'last_name': 'panwar', 'age': 27}插入文件：＃现在让我们将此文档存储在Elasticsearch res = es.index（index ='megacorp'，doc_type ='employee'，id = 1，body = e1）中简单！无需先执行任何管理任务，例如创建索引或指定每个字段包含的数据类型。我们可以直接为文档建立索引。Elasticsearch附带所有内容的默认值，因此使用默认值在后台处理了所有必要的管理任务。检索文档：在Elasticsearch中这很容易。我们只需执行一个HTTP GET请求并指定文档的地址-索引，类型和ID。使用这三段信息，我们可以返回原始JSON文档。 ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍 06.当Elasticsearch进行文档索引时，它是如何工作的? 07.Elasticsearch中的映射方式—简洁版教程 08.Elasticsearch中的分析和分析器应用方式09.Elasticsearch中构建自定义分析器10.Kibana科普-作为Elasticsearhc开发工具11.Elasticsearch查询方法12.Elasticsearch全文查询13.Elasticsearch查询-术语级查询14.Python中的Elasticsearch入门15.使用Django进行ElasticSearch的简单方法 第16篇-关于Elasticsearch的6件不太明显的事情 另外Elasticsearch入门，我强烈推荐ElasticSearch搭建手册给你，非常想尽的入门指南手册。 Elasticsearch是被广泛采用的搜索引擎。Netflix，Microsoft，eBay，Facebook等大公司都在使用它。开始工作很容易，但从长远来看却很难掌握。在本文中，我们分享了有关Elasticsearch的六个不太明显的知识，值得在您的系统中使用它之前了解。 1.弹性堆叠Elasticsearch最初是作为独立产品开发的。它的唯一作用是提供可扩展的搜索引擎，该引擎可以从任何语言使用。因此，它是使用分布式模型在最核心的地方创建的，并使用REST API与之通信。在早期采用阶段之后，发明了新工具来与Elasticsearch一起使用。它从用于可视化和数据分析的Kibana和用于日志收集的Logstash开始。当前有许多工具都是在Elastic公司的照顾下开发的： Elasticsearch-您知道，对于搜索，Kibana-数据分析和可视化，Logstash-服务器端数据处理管道，节拍-单一用途的数据托运人，Elastic Cloud-托管Elasticsearch集群，机器学习-用于发现数据模式，APM —应用程序性能监控，Swiftype-一键式站点搜索。工具的数量每年都在增长，这使公司能够实现新的目标并创造新的机会。 2.两种数据集 基本上，您可以在Elasticsearch中索引（即存储）所需的任何数据。但是实际上有两类，它们严重影响了群集的配置和管理方式：静态数据和时间序列数据。 静态数据是可能增长或变化缓慢的数据集。像目录或物品清单。您可以将它们视为存储在常规数据库中的数据。博客文章，图书馆书籍，订单等。您可能希望在Elasticsearch中对此类数据编制索引，以实现快速的快速搜索，而这使常规SQL数据库不堪一击。另一方面，您可以存储时间序列数据集。这些事件可以是与通常迅速增长的时间相关的事件，例如日志文件或指标。您基本上可以在Elasticsearch中为它们建立索引，以进行数据分析，模式发现和系统监视。 根据您存储的数据类型，应该以不同的方式对集群建模。 对于静态数据，应选择固定数量的索引和分片。它们不会很快增长，并且您始终希望在数据集中的所有文档中进行搜索。对于时间序列数据，您应该选择有时间限制的滚动索引。您将更多地查询最近的数据，最终甚至会删除或至少存档过时的文档，以节省机器成本。 3.搜索分数Elasticsearch的主要目的是提供一个搜索引擎。目标是提供最匹配的文档。但是，Elasticsearch实际上如何知道它们是什么？对于每个搜索查询，Elasticsearch都会计算相关性得分。分数基于tf-idf算法，该算法代表术语频率-反向文档频率。该算法基本上计算出两个值。第一个-术语频率-表示文档中给定术语的使用频率。第二个参数是反文档频率，它表示给定术语在所有文档中的唯一性。例如，如果我们有两个文档： To be or not to be, that is the question.To be. I am. You are. He, she is.问题一词的TF 是 for document 1: 1/10 (1 occurrence out of 10 terms)for document 2: 0/9 (0 occurrences out of 9 terms).另一方面，将IDF计算为整个数据集的单个值。它是所有文档与包含搜索词的文档的比率。在我们的例子中是：log（2/1）= 0.301（2-所有文档数，1-包含疑问词的文档数）。最后，两个文档的tf-idf得分均作为两个值的乘积计算得出：● 文件1：1/10 x 0.301 = 0.1 * 0.301 = 0.03● 文件2：0/9 x 0.301 = 0 * 0.301 = 0.00现在我们看到文档1的相关性值为0.03，而文档2的相关性为0.00。因此，文档1将在结果列表中提供更高的服务。4.数据模型Elasticsearch在性能方面有两个好处。它是水平可扩展的，并且非常快。后者来自哪里？它基于数据存储的事实。当您为文档建立索引时，它将通过三个步骤：字符过滤器，标记生成器和标记过滤器。它们用于规范化文档。例如文档： ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍 06.当Elasticsearch进行文档索引时，它是如何工作的? 07.Elasticsearch中的映射方式—简洁版教程 08.Elasticsearch中的分析和分析器应用方式09.Elasticsearch中构建自定义分析器10.Kibana科普-作为Elasticsearhc开发工具11.Elasticsearch查询方法12.Elasticsearch全文查询13.Elasticsearch查询-术语级查询14.Python中的Elasticsearch入门15.使用Django进行ElasticSearch的简单方法 另外Elasticsearch入门，我强烈推荐ElasticSearch学习搭建指南给你，非常想尽的入门指南手册。 前一段时间，我在Django项目上工作，想实现快速的自由文本搜索。我决定使用NoSQL数据库，而不是使用常规数据库来执行此搜索功能（例如MySQL或PostgreSQL）。那就是我发现ElasticSearch的时候。 ElasticSearch为您的数据索引文档，而不是像常规关系数据库那样使用数据表。这样可以加快搜索速度，并提供其他常规数据库无法获得的其他好处。我还保留了一个常规的关系数据库，用于存储用户详细信息，登录名和其他不需要ElasticSearch索引的数据。 在搜索了如何使用Django正确实现ElasticSearch的很长时间之后，我并没有真正找到令人满意的答案。似乎正在采取不必要的步骤来将数据索引到ElasticSearch中。有关如何执行搜索的信息很多，但有关如何完成索引的信息却不多。我觉得那里肯定有一个更简单的解决方案，所以我决定自己尝试一下。 我想使它尽可能简单，因为在我看来，简单的解决方案往往是最好的解决方案。KISS（保持简单愚蠢），少即是多，所有这些东西都引起了我的共鸣，特别是当其他解决方案非常复杂时。我决定在本视频中使用HonzaKrál的示例来为我的代码提供基础。我建议您观看它，尽管此时它有点过时了。 由于我使用的是用Python编写的Django，因此与ElasticSearch进行交互非常容易。有两个客户端库可通过Python与ElasticSearch进行交互。有elasticsearch-py，这是官方的低级客户端。还有elasticsearch-dsl，它是在前者的基础上构建的，但是它提供了更高层次的抽象，但功能却有所减少。 我们将很快讨论一些示例，但是首先我需要阐明我们要完成的工作：● 在我们的本地计算机上设置ElasticSearch并确保其正常运行● 设置一个新的Django项目● 批量索引数据库中已经存在的数据● 用户保存到数据库的每个新实例的索引● 基本搜索示例 好吧，这似乎很简单。让我们开始在我们的机器上安装ElasticSearch。另外，所有代码都将在我的GitHub上可用，因此您可以轻松地遵循示例。安装ElasticSearch由于ElasticSearch在Java上运行，因此必须确保您具有更新的JVM版本。检查java -version 终端中的版本。然后运行以下命令来创建新目录，下载，解压缩并启动ElasticSearch： mkdir elasticsearch-examplewget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-5.1.1.tar.gztar -xzf elasticsearch-5.1.1.tar.gz./elasticsearch-5.1.1/bin/elasticsearch当ElasticSearch启动时，应该在终端窗口上打印很多输出。要检查其启动和运行是否正确，请打开一个新的终端窗口并运行以下curl 命令：curl -XGET http：// localhost：9200 响应应该是这样的： { “ name”：“ 6xIrzqq”， “ cluster_name ”：“ elasticsearch”，“ cluster_uuid”：“ eUH9REKyQOy4RKPzkuRI1g”， “ version”：{ “ number”：“ 5.1.1”， “ build_hash”：“ 5395e21”， “ build_date “：” 2016-12-06T12：36：15.409Z“， ” build_snapshot“：否， ” lucene_version“：” 6.3.0“ }，”标语“：”您知道，要搜索“太好了，您现在已经在本地计算机上运行了ElasticSearch！现在该设置您的Django项目了。设置Django项目首先，您要使用创建一个虚拟环境，virtualenv venv ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍 06.当Elasticsearch进行文档索引时，它是如何工作的? 07.Elasticsearch中的映射方式—简洁版教程 08.Elasticsearch中的分析和分析器应用方式09.Elasticsearch中构建自定义分析器10.Kibana科普-作为Elasticsearhc开发工具11.Elasticsearch查询方法12.Elasticsearch全文查询13.Elasticsearch查询-术语级查询14.Python中的Elasticsearch入门 另外Elasticsearch入门，我强烈推荐ElasticSearch搭建手册给你，非常想尽的入门指南手册。 在本文中，我将讨论Elasticsearch以及如何将其与不同的Python应用程序集成。 什么是ElasticSearch？ ElasticSearch（ES）是基于Apache Lucene构建的分布式且高度可用的开源搜索引擎。这是一个用Java构建的开源，因此可用于许多平台。您以JSON格式存储非结构化数据，这也使其成为NoSQL数据库。因此，与其他NoSQL数据库不同，ES还提供搜索引擎功能和其他相关功能。 ElasticSearch用例 您可以将ES用于多种用途，下面提供了其中的几个： 您正在运行的网站提供许多动态内容。无论是电子商务网站还是博客。通过实施ES，您不仅可以为您的Web应用程序提供强大的搜索引擎，还可以在应用程序中提供本机自动完成功能。 您可以摄取不同种类的日志数据，然后可以用来查找趋势和统计数据。 设置和运行安装ElasticSearch的最简单方法是下载并运行可执行文件。您必须确保使用的是Java 7或更高版本。下载后，解压缩并运行其二进制文件。 elasticsearch-6.2.4 bin / elasticsearch 滚动窗口中将有很多文本。如果您看到类似下面的内容，则表明情况已解决。 [2018-05-27T17：36：11,744] [INFO] [oehnNetty4HttpServerTransport] [c6hEGv4] publish_address {127.0.0.1:9200}、bound_addresses {[:: 1]：9200}，{127.0.0.1:9200} 但是，既然眼见为实，http://localhost:9200那就在浏览器中或通过cURL 访问URL ，下面的内容应该会很欢迎您。 { "name" : "c6hEGv4", "cluster_name" : "elasticsearch", "cluster_uuid" : "HkRyTYXvSkGvkvHX2Q1-oQ", "version" : { "number" : "6.2.4","build_hash" : "ccec39f","build_date" : "2018-04-12T20:37:28.497551Z","build_snapshot" : false,"lucene_version" : "7.2.1","minimum_wire_compatibility_version" : "5.6.0","minimum_index_compatibility_version" : "5.0.0"}, "tagline" : "You Know, for Search"} ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍 06.当Elasticsearch进行文档索引时，它是如何工作的? 07.Elasticsearch中的映射方式—简洁版教程 08.Elasticsearch中的分析和分析器应用方式09.Elasticsearch中构建自定义分析器10.Kibana科普-作为Elasticsearhc开发工具11.Elasticsearch查询方法12.Elasticsearch全文查询 另外Elasticsearch入门，我强烈推荐ElasticSearch搭建手册给你，非常想尽的入门指南手册。 在上一个博客中，我们看到了Elasticsearch世界中一些重要且使用最广泛的全文查询。我们将介绍此博客中一些最有用和最相关的术语级别查询。什么是学期水平查询？术语级别查询是用于根据组织/结构化数据中的确切值查找记录/文档的那些查询。结构化数据的示例包括产品代码，日期范围，PIN码，IP等。术语查询与全文查询的不同之处在于，搜索关键字（要搜索的文本）将经过分析过程然后被查询。与术语查询执行中一样，搜索查询关键字将照原样进行。（注意：关键字的标准化可以通过标准化设置进行，但默认情况下，搜索查询关键字照原样进行。）例如，如果我使用全文查询搜索“ Arun Mohan”，则搜索将继续进行分别为“阿伦”和“莫汉”。但是，当我对与上述相同的关键字使用术语查询时，搜索将作为单个关键字完成，而不会拆分为“ Arun Mohan”本身。样本数据集可以在此处找到为此操作执行的数据集。加载CSV的步骤可以在我以前在Kibana上的博客中找到。我已将数据索引到名为“ testindexterms”的索引。该索引中的样本文档如下所示： { "_index" : "testindexterms", "_type" : "_doc", "_id" : "-6Ry3m0B5ZMO9aBbs5Sg", "_score" : 1.0, "_source" : { "id" : "1", "first_name" : "Jasmina", "last_name" : "Crocetto", "email" : "jcrocetto0@odnoklassniki.ru", "gender" : "Female", "ip_address" : "90.139.240.83", "socialSecurity" : "896-40-5515", "age" : "33" } }基本术语查询基本字词查询不会在搜索时分析为其指定的搜索关键字。考虑一个示例，让我们在“性别”字段上搜索关键字“男性”，如下所示： #term queryPOST testindexterms/_search{ "query": { "term": { "gender": { "value": "Male" } } }}上面的查询将导致返回所有带有“ gender”字段且值为“ Male”的文档。现在，如果我们通过将大小写更改为“ male”来给出相同的查询，则相同的查询将不会产生任何结果。POST testindexterms / _search { “ query”：{ “ term”：{ “ first_name”：{ “ value”：“ jasmina” } } } }这表明在“性别”字段的倒排索引中没有“男性”值。只有“男”和“女”两个值（注意大小写不同）。 ...

介绍 Elasticsearch（ES）是一个基于Lucene构建的开源、分布式、RESTful接口的全文搜索引擎。Elasticsearch还是一个分布式文档数据库，其中每个字段均可被索引，而且每个字段的数据均可被搜索，ES能够横向扩展至数以百计的服务器存储以及处理PB级的数据。可以在极短的时间内存储、搜索和分析大量的数据。通常作为具有复杂搜索场景情况下的核心发动机。 Elasticsearch能做什么 当你经营一家网上商店，你可以让你的客户搜索你卖的商品。在这种情况下，你可以使用ElasticSearch来存储你的整个产品目录和库存信息，为客户提供精准搜索，可以为客户推荐相关商品。当你想收集日志或者交易数据的时候，需要分析和挖掘这些数据，寻找趋势，进行统计，总结，或发现异常。在这种情况下，你可以使用Logstash或者其他工具来进行收集数据，当这引起数据存储到ElasticsSearch中。你可以搜索和汇总这些数据，找到任何你感兴趣的信息。对于程序员来说，比较有名的案例是GitHub，GitHub的搜索是基于ElasticSearch构建的，在github.com/search页面，你可以搜索项目、用户、issue、pull request，还有代码。共有40~50个索引库，分别用于索引网站需要跟踪的各种数据。虽然只索引项目的主分支（master），但这个数据量依然巨大，包括20亿个索引文档，30TB的索引文件。Elasticsearch基本概念 Near Realtime(NRT) 几乎实时Elasticsearch是一个几乎实时的搜索平台。意思是，从索引一个文档到这个文档可被搜索只需要一点点的延迟，这个时间一般为毫秒级。 Cluster 集群群集是一个或多个节点（服务器）的集合， 这些节点共同保存整个数据，并在所有节点上提供联合索引和搜索功能。一个集群由一个唯一集群ID确定，并指定一个集群名（默认为“elasticsearch”）。该集群名非常重要，因为节点可以通过这个集群名加入群集，一个节点只能是群集的一部分。 确保在不同的环境中不要使用相同的群集名称，否则可能会导致连接错误的群集节点。例如，你可以使用logging-dev、logging-stage、logging-prod分别为开发、阶段产品、生产集群做记录。 Node节点节点是单个服务器实例，它是群集的一部分，可以存储数据，并参与群集的索引和搜索功能。就像一个集群，节点的名称默认为一个随机的通用唯一标识符（UUID），确定在启动时分配给该节点。如果不希望默认，可以定义任何节点名。这个名字对管理很重要，目的是要确定你的网络服务器对应于你的ElasticSearch群集节点。 我们可以通过群集名配置节点以连接特定的群集。默认情况下，每个节点设置加入名为“elasticSearch”的集群。这意味着如果你启动多个节点在网络上，假设他们能发现彼此都会自动形成和加入一个名为“elasticsearch”的集群。 在单个群集中，你可以拥有尽可能多的节点。此外，如果“elasticsearch”在同一个网络中，没有其他节点正在运行，从单个节点的默认情况下会形成一个新的单节点名为”elasticsearch”的集群。 Index索引索引是具有相似特性的文档集合。例如，可以为客户数据提供索引，为产品目录建立另一个索引，以及为订单数据建立另一个索引。索引由名称（必须全部为小写）标识，该名称用于在对其中的文档执行索引、搜索、更新和删除操作时引用索引。在单个群集中，你可以定义尽可能多的索引。 Type类型在索引中，可以定义一个或多个类型。类型是索引的逻辑类别/分区，其语义完全取决于你。一般来说，类型定义为具有公共字段集的文档。例如，假设你运行一个博客平台，并将所有数据存储在一个索引中。在这个索引中，你可以为用户数据定义一种类型，为博客数据定义另一种类型，以及为注释数据定义另一类型。 Document文档文档是可以被索引的信息的基本单位。例如，你可以为单个客户提供一个文档，单个产品提供另一个文档，以及单个订单提供另一个文档。本文件的表示形式为JSON（JavaScript Object Notation）格式，这是一种非常普遍的互联网数据交换格式。 在索引/类型中，你可以存储尽可能多的文档。请注意，尽管文档物理驻留在索引中，文档实际上必须索引或分配到索引中的类型。 Shards & Replicas分片与副本索引可以存储大量的数据，这些数据可能超过单个节点的硬件限制。例如，十亿个文件占用磁盘空间1TB的单指标可能不适合对单个节点的磁盘或可能太慢服务仅从单个节点的搜索请求。 为了解决这一问题，Elasticsearch提供细分你的指标分成多个块称为分片的能力。当你创建一个索引，你可以简单地定义你想要的分片数量。每个分片本身是一个全功能的、独立的“指数”，可以托管在集群中的任何节点。 Shards分片的重要性主要体现在以下两个特征： 1.副本为分片或节点失败提供了高可用性。为此，需要注意的是，一个副本的分片不会分配在同一个节点作为原始的或主分片，副本是从主分片那里复制过来的。 2.副本允许用户扩展你的搜索量或吞吐量，因为搜索可以在所有副本上并行执行。 ES基本概念与关系型数据库的比较

package mainimport ( "fmt" "gopkg.in/olivere/elastic.v2")type Ess struct { name string Xq string }func main() { client, err := elastic.NewClient(elastic.SetSniff(false), elastic.SetURL("http://127.0.0.1:9200/")) if err != nil { fmt.Println("connect es error", err) return } fmt.Println("conn es succ") for i := 0; i < 20; i++ { es := Ess{name: "text", Xq: "phone"} _, err = client.Index(). Index("es"). Type("es"). Id(fmt.Sprintf("%d", i)). BodyJson(es). Do() if err != nil { panic(err) return } } fmt.Println("save ok")}运行结果PS D:\goLang\test1> go run main.goconn es oksave ok ...

Elasticsearch的标准版本及以上是支持设置同义词功能的, 其实也就是除了OSS(开源)版以外其它的都支持. 环境说明Elasticsearch 7.6.x与ES相匹配的IK分词插件示例中会分别使用到shell命令和Kibana, 以$开头的代表是shell命令, 否则表示Kibana的console命令操作同义词可以使用 synonym 参数来内嵌指定，或者必须 存在于集群每一个节点上的同义词文件中。 同义词文件路径由 synonyms_path 参数指定，应绝对或相对于 Elasticsearch config 目录。下面以同义词的两种设置方式来介绍: 同义词文件方式设置同义词文件# 进入Elasticsearch目录执行,生成文件$ echo '"iPhone,苹果手机 => iPhone,苹果手机", "2233,22娘,33娘 => bilibili,B站"' > config/analysis/synonyms.txt创建索引PUT /goods2{ "settings": { "analysis": { "filter": { "my_synonym_filter": { "type": "synonym", "updateable": true, "synonyms_path": "analysis/synonyms.txt" } }, "analyzer": { "my_synonyms_analyzer": { "tokenizer": "ik_smart", "filter": [ "my_synonym_filter" ] } } } }, "mappings": { "properties": { "title": { "type": "text", "analyzer": "ik_smart", "search_analyzer": "my_synonyms_analyzer" } } }}my_synonym_filter是自定义的词汇过滤器, my_synonyms_analyzer是自定义的分析器, 可以看出后者是包含并引用了前者的.在本索引中自定义的词汇过虑器和分析器也只能在当前索引中使用. ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍 06.当Elasticsearch进行文档索引时，它是如何工作的? 07.Elasticsearch中的映射方式—简洁版教程 08.Elasticsearch中的分析和分析器应用方式09.Elasticsearch中构建自定义分析器10.Kibana科普-作为Elasticsearhc开发工具11.Elasticsearch查询方法12.Elasticsearch全文查询 另外Elasticsearch入门，我强烈推荐ElasticSearch搭建小白指南给你，非常想尽的入门指南手册。 我们已经学习了Elasticsearch查询的基本分类，这两个类别的基本知识以及查询/过滤器上下文。在此博客中，其目的是向您介绍Elasticsearch世界中常见的全文查询。让我们索引一些主要由一些文本组成的数据。为简单起见，我采用了Facebook帖子的修剪版本及其说明和详细信息的CSV，这些内容可以在公共网站上获得。您可以将这些tweet索引到Elasticsearch我已将上述推文索引到名为fb-post的索引。索引后的样本数据文档如下所示： { "_index" : "fb-post", "_type" : "_doc", "_id" : "TszxwG0Bm6hFGbtHjVCC", "_score" : 1.0, "_source" : { "status_type" : "shared_story", "link" : "http://abcnews.go.com/blogs/headlines/2011/12/chief-justice-roberts-responds-to-judicial-ethics-critics/", "description" : "PAUL J. RICHARDS/AFP/Getty Images Chief Justice John Roberts issued a ringing endorsement Saturday night of his colleagues’ ability to determine when they should step down from a case because of a conflict of interest. “I have complete confidence in the capability of my colleagues to determine when ...", "caption" : "abcnews.go.com", "love_count" : 0, "shares_count" : 12, "page_id" : 86680728811, "wow_count" : 0, "post_type" : "link", "id" : "86680728811_272953252761568", "posted_at" : "2012-01-01 00:30:26", "sad_count" : 0, "angry_count" : 0, "message" : "Roberts took the unusual step of devoting the majority of his annual report to the issue of judicial ethics.", "picture" : "https://external.xx.fbcdn.net/safe_image.php?d=AQAPXteeHLT2K7Rb&w=130&h=130&url=http%3A%2F%2Fabcnews.go.com%2Fimages%2FPolitics%2Fgty_chief_justice_john_roberts_jt_111231_wblog.jpg&cfs=1&sx=108&sy=0&sw=269&sh=269", "likes_count" : 61, "thankful_count" : 0, "@timestamp" : "2012-01-01T00:30:26.000+05:30", "comments_count" : 27, "name" : "Chief Justice Roberts Responds to Judicial Ethics Critics", "haha_count" : 0 } } 在上面的文档中，我们感兴趣的字段是诸如“名称”，“消息”和“描述”之类的文本字段。现在让我们一个接一个地转到每个全文查询。1.匹配查询我们在之前的博客中讨论了匹配查询，但是没有提到匹配查询的正常用例。匹配查询最常见的用例是当我们拥有大量数据集时，我们需要快速找到一些近似精确的匹配项。例如，在我们的Twitter数据集中，我们需要确定整个推文集中是否存在“信心”一词。可以使用针对以下“文本”字段的简单匹配查询来完成此操作： ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍 06.当Elasticsearch进行文档索引时，它是如何工作的? 07.Elasticsearch中的映射方式—简洁版教程 08.Elasticsearch中的分析和分析器应用方式09.Elasticsearch中构建自定义分析器10.Kibana科普-作为Elasticsearhc开发工具 另外Elasticsearch入门，我强烈推荐ElasticSearch搭建小白指南给你，非常想尽的入门指南手册。 在上一个博客中，我们了解了如何将Kibana用作开发工具以及如何使用Kibana加载示例数据。从这个博客中，我们将研究Elasticsearch的查询DSL，它非常强大，对于任何Elasticsearch用户来说都是必不可少的知识领域。Elasticsearch查询类型Elasticsearch中的查询可以大致分为两类，1.叶子查询叶子查询在某些字段中查找特定值。这些查询可以独立使用。其中一些查询包括匹配，条件，范围查询。2.复合查询复合查询使用叶/复合查询的组合。基本上，它们将多个查询组合在一起以实现其目标结果。下图大致显示了这两个查询的大致分类： 如上图所示，Leaf和化合物分类中仍然有许多类别。在接下来的博客中，我们将更详细地访问上图中的大多数查询/查询类型。基本查询样本现在，让我们熟悉叶子的2个基本查询和复合查询类型中的一个查询以开始操作。1.简单的“匹配”查询假设我们考虑建立索引的文件在以前的博客，让我们尝试在球场上“FIRST_NAME”为搜索关键词“丹尼”的简单匹配查询。该查询将如下所示： POST employees/_search{ “query”: { “match”: { “country”: “China” } }}上面的查询将返回给我们所有国家为中国的文件2.范围查询现在让我们触发另一个查询，这个查询也是一个叶子查询。该查询将向我们返回所有薪水大于或等于500,000的员工。可以使用如下范围查询来实现： POST/ _{ “ query”：{ “ range”：{ “ salary”：{ “ gte”：500000 } } } }3.布尔查询现在来了有趣的部分。我们如何比较以上查询？也就是说，我需要所有来自中国但收入超过50万的员工。这需要上述两个叶查询的组合。现在，Elasticsearch提供了使用bool查询组合这些查询的工具。让我们讨论布尔查询的一般结构，然后回到问题所在。布尔查询的一般结构： POST _search { “ query”：{ “ bool”：{ “ must”：[...]， “ filter”：[...]， “ must_not”：[...]， “ should”：[.. 。] } } }must：子句（查询）必须出现在匹配的文档中，并将有助于得分。filter：子句（查询）必须出现在匹配的文档中。但是与查询分数不同的是，忽略该分数。应该：子句（查询）应出现在匹配的文档中。must_not：子句（查询）不得出现在匹配的文档中。现在回到我们的问题，我们的bool查询旨在重整所有来自中国的雇员并赚取超过500,000的工资，如下所示： POST employee / _search { “ query”：{ “ bool”：{ “ must”：[ { “ match”：{ “ country”：“ China” } }， { “ range”：{ “ salary”：{ “ gte” ：500000 } } } ] } } }现在，让我们考虑是否要从列表中筛选出所有男性雇员。我们应该做什么？。只需在上面的查询中添加条件性别为“ Male”的must_not部分即可，如下所示： ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍 06.当Elasticsearch进行文档索引时，它是如何工作的? 07.Elasticsearch中的映射方式—简洁版教程 08.Elasticsearch中的分析和分析器应用方式09.Elasticsearch中构建自定义分析器 另外Elasticsearch入门，我强烈推荐Elasticsearch基础入门教程给你，非常想尽的入门指南手册。 介绍在此阶段的上一篇博客中，我已经解释了有关常规分析器结构和组件的更多信息。我也解释了每个组件的功能。在此博客中，我们将通过构建自定义分析器，然后查询并查看差异来了解实现方面。定制分析仪的外壳因此，让我们考虑定制分析仪的情况。假设我们输入到Elasticsearch的文本包含以下内容 html标签html标签在索引时可能会出现在我们的文本中，其实这在大多数情况下是不需要的。所以我们需要删除这些。2.停止词像the,and,or等这样的词，在搜索内容时意义不大，一般被称为停止词。3.大写字母。4.简写形式如H2O、$、%。在某些情况下，像这样的简式应该用英文原词代替。 应用自定义分析器在上面的示例文本中，下表列出了需要执行的操作以及自定义分析器的相应组件 Arun has 100 $ which accounts to 3 % of the total <h2> money </h2>“ settings”中的层次结构如下所示： 应用所有组件现在应用上述所有组件创建一个自定义分析器，如下所示： curl -XPUT localhost:9200/testindex_0204 -d '{ "settings": { "analysis": { "char_filter": { "subsitute": { "type": "mapping", "mappings": [ "$=> dollar", "%=> percentage" ] }, "html-strip": { "type": "html_strip" } }, "tokenizer": "standard", "filter": { "stopwords_removal": { "type": "stop", "stopwords": [ "has", "which", "to", "of", "the" ] } }, "analyzer": { "custom_analyzer_type_01": { "type": "custom", "char_filter": [ "subsitute", "html_strip" ], "tokenizer": "standard", "filter": [ "stopwords_removal", "lowercase" ] } } } }, "mappings": { "test_type": { "properties": { "text": { "type": "string", "analyzer": "custom_analyzer_type_01" } } } }}'这将使用名为“ custom_analyzer_01” 的自定义分析器创建索引。详细说明了此映射，下图说明了每个部分：使用自定义分析器生成令牌使用分析器可以看到使用此分析器生成的令牌，如下所示： ...

我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍06.当Elasticsearch进行文档索引时，它是如何工作的?07.Elasticsearch中的映射方式—简洁版教程08.Elasticsearch中的分析和分析器应用方式 另外ES入门，我强烈推荐这篇Elasticsearch权威搭建指南给你，非常想尽的指南手册。 介绍在本系列的第一个博客中，我们看到了在Elasticsearch中对文档建立索引时的反向索引计算，而在第二个博客中，我们看到了Elasticsearch中的映射基础。现在，在此博客中，我们将详细介绍Elasticsearch的分析部分，如何完成以及如何定制分析。1.分析过程说明为了了解Elasticsearch中的分析过程及其需求，我们需要对inverted index Elasticsearch中的创建进行更深入的了解。我们在阶段02的博客01中讨论的关于inverted index 创建的内容是基本版本，在这里让我为倒排索引创建场景添加一些复杂性。当我们将这些文档索引到Elasticsearch时，流程如下： 现在让我解释反向索引创建之前的每个阶段：1.1字符过滤器字符过滤器具有对提供给他们的输入文本执行添加，删除或替换操作的能力。为了更清楚地理解它，如果输入字符串包含重复出现的拼写错误的单词，而我们需要用正确的单词替换它，那么我们可以使用字符过滤器对此进行相同的处理。此过滤器最常见的应用之一是html 从输入文本中剥离标签。让我们看看使用Elasticsearch的Analyze API进行字符过滤的工作。在这里，我们将使用字符过滤器“ html_strip”从文本中删除html标签。卷曲请求如下：curl -XPOST 'localhost:9200/_analyze?pretty' -H 'Content-Type: application/json' -d '{ "tokenizer": "standard", "char_filter": [ "html_strip"], "text": "The Auto-generation is a success"}'生成的令牌如下所示： “The”,”Auto”,”generation”,”is”,”a”,”success” 在这里我们可以看到令牌中没有html标记。同样，尝试不带的上述curl请求， “char_filter”:[“html_strip”] 然后看看有什么不同。1.2分词器从“字符”过滤器转换后的输入文本将传递到令牌处理程序。令牌生成器会将输入文本拆分为特定字符处的单个令牌（或术语）。elasticsearch中的默认标记器是“标准标记器”，它使用基于语法的标记化技术，该技术不仅可以扩展到英语，还可以扩展到许多其他语言。让我们在下面看到一个标准令牌生成器的示例： curl -XPOST ‘localhost:9200/_analyze?pretty’ -H ‘Content-Type: application/json’ -d '{ “tokenizer”: “standard”, “text”: “The Auto-generation is a success”}' 在响应中，您可以看到文本分为以下标记：“ The”，“ Auto”，“ Generation”，“ is”，“ a”，“ success” 在这里，只要有空格和连字符（-），单词就会被拆分。注意：有不同类型的标记器，用于不同的目的。在某些用例中，我们可能不需要拆分特殊字符（例如，在使用电子邮件ID或url的情况下），因此为了满足此类需求，我们可以使用“ UAX URL Email Tokenizer”等标记器。可以在此处找到Elasticsearch提供的标记器列表 ...

概要本篇继续讲解Elasticsearch集群部署的细节问题 集群重启问题如果我们的Elasticsearch集群做了一些离线的维护操作时，如扩容磁盘，升级版本等，需要对集群进行启动，节点数较多时，从第一个节点开始启动，到最后一个节点启动完成，耗时可能较长，有时候还可能出现某几个节点因故障无法启动，排查问题、修复故障后才能加入到集群中，此时集群会干什么呢？ 假设10个节点的集群，每个节点有1个shard，升级后重启节点，结果有3台节点因故障未能启动，需要耗费时间排查故障，如下图所示: 整个过程步骤如下： 集群已完成master选举(node6)，master发现未加入集群的node1、node2、node3包含的shard丢失，便立即发出shard恢复的指令。在线的7台node，将其中一个replica shard升级为primary shard，并且进行为这些primary shard复制足够的replica shard。执行shard rebalance操作。故障的3台节点已排除，启动成功后加入集群。这3台节点发现自己的shard已经在集群中的其他节点上了，便删除本地的shard数据。master发现新的3台node没有shard数据，重新执行一次shard rebalance操作。这个过程可以发现，多做了四次IO操作，shard复制，shard首次移动，shard本地删除，shard再次移动，这样凭空造成大量的IO压力，如果数据量是TB级别的，那费时费力不讨好。 出现此类问题的原因是节点启动的间隔时间不能确定，并且节点越多，这个问题越容易出现，如果可以设置集群等待多少个节点启动后，再决定是否对shard进行移动，这样IO压力就能小很多。 针对这个问题，我们有下面几个参数： gateway.recover_after_nodes：集群必须要有多少个节点时，才开始做shard恢复操作。gateway.expected_nodes: 集群应该有多少个节点gateway.recover_after_time: 集群启动后等待的shard恢复时间如上面的案例，我们可以这样设置： gateway.recover_after_nodes: 8gateway.expected_nodes: 10gateway.recover_after_time: 5m这三个参数的含义：集群总共有10个节点，必须要有8个节点加入集群时，才允许执行shard恢复操作，如果10个节点未全部启动成功，最长的等待时间为5分钟。 这几个参数的值可以根据实际的集群规模来设置，并且只能在elasticsearch.yml文件里设置，没有动态修改的入口。 上面的参数设置合理的情况，集群启动是没有shard移动的现象，这样集群启动的时候就可以由之前的几小时，变成几秒钟。 JVM和Thread Pool设置一提到JVM的调优，大家都有手痒的感觉，好几百个JVM参数，说不定开启了正确的按钮，从此ES踏上高性能、高吞吐量的道路。现实情况可能是我们想多了，ES的大部分参数是经过反复论证的，基本上不用咱们太操心。 JVM GCElasticsearch默认使用的垃圾回收器是CMS。 ## GC configuration-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=75-XX:+UseCMSInitiatingOccupancyOnlyCMS回收器是并发式的回收器，能够跟应用程序工作线程并发工作，最大程度减少垃圾回收时的服务停顿时间。 CMS还是会有两个停顿阶段，同时在回收特别大的heap时也会有一些问题。尽管有一些缺点，但是CMS对于要求低延时请求响应的软件来说，还是最佳的垃圾回收器，因此官方的推荐就是使用CMS垃圾回收器。 有一种最新的垃圾回收器叫做G1。G1回收器可以比CMS提供更少的回收停顿时间，而且能够这对大heap有更好的回收表现。它会将heap划分为多个region，然后自动预测哪个region会有最多可以回收的空间。通过回收那些region，就可以最小化停顿时长，而且可以针对大heap进行回收。 听起来还挺好的，只是G1还是比较年轻的一种垃圾回收器，而且经常会发现一些新的bug，这些bug可能会导致jvm挂掉。稳定起见，暂时不用G1，等G1成熟后ES官方推荐后再用不迟。 线程池我们开发Java应用系统时，对系统调优的一个常见手段就是调整线程池，但在ES中,默认的threadpool设置是非常合理的，对于所有的threadpool来说，除了搜索的线程池，都是线程数量设置的跟cpu core一样多的。如果我们有8个cpu core，那么就可以并行运行8个线程。那么对于大部分的线程池来说，分配8个线程就是最合理的数量。 搜索会有一个更加大的threadpool，线程数量一般被配置为：cpu core * 3 / 2 + 1。 Elasticsearch的线程池分成两种：接受请求的线程和处理磁盘IO操作的线程，前面那种由ES管理，后一种由Lucene管理，它们之间会进行协作，ES的线程不会因为IO操作而block住，所以ES的线程设置跟CPU核数一样或略大于CPU核数即可。 服务器的计算能力是非常有限的，线程池的数量过大会导致上下文频繁切换，更费资源，如果threadpool大小设置为50，100，甚至500，会导致CPU资源利用率很低，性能反而下降。 只需要记住：用默认的线程池，如果真要修改，以CPU核数为准。 heap内存设置最佳实践Elasticsearch默认的jvm heap内存大小是2G，如果是研发环境，我会改成512MB，但在生产环境2GB有点少。 在config/jvm.options文件下，可以看到heap的设置： # Xms represents the initial size of total heap space# Xmx represents the maximum size of total heap space-Xms2g-Xmx2g分配规则Elasticsearch使用内存主要有两个大户：jvm heap和lucene，前者ES用来存放很多数据结构来提供更快的操作性能，后者使用os cache缓存索引文件，包括倒排索引、正排索引，os cache内存是否充足，直接影响查询检索的性能。 ...

1.基本概念 Index索引 Document 文档Type 类型Node节点 Shard分片1.1 文档（Document）1.1.1 文档Elasticsearch是面向文档的，文档是所有可搜索数据的最小单位。文档会被序列化成JSON格式，保存在Elasticsearch中。 JSON对象由字段构成。每个字段都有对应的字段类型（字符串、数值、布尔、日期、二进制、范围）每个文档都有一个Unique ID 可以自己指定ID也可以由Elasticsearch自动生成。1.1.2 JSON文档一篇文档类似于数据库表中的一条记录。JSON文档格式灵活，不需要预先定义格式。 字段的类型可以指定或者通过Elasticsearch自动推算。支持数组、嵌套。1.1.3 文档元数据{ "_index" : "movies", "_type" : "_doc", "_id" : "8609", "_score" : 1.0, "_source" : { "year" : 1923, "title" : "Our Hospitality", "@version" : "1", "id" : "8609", "genre" : [ "Comedy" ] }}_index：文档所属的索引名_type：文档所属的类型名_id： 文档唯一id_score：文档相关性打分_source：文档的原始JSON数据_version：文档的版本信息1.2 索引(Index)1.2.1 索引索引是文档的容器，是一类文档的集合。 Index：体现了逻辑空间的概念。每个索引都有自己的Mapping定义，用于定义包含的文档的字段名和字段类型。Shard：体现了物理空间的概念，索引中的数据分布在 Shard 上。索引的 Mapping 和 Setting Mapping：定义文档字段的类型。Setting：定义不同的数据分布。1.2.2 索引的不同语义名词：一个Elasticsearch集群中，可以创建很多个不同的索引。动词：保存一个文档到Elasticsearh的过程也叫索引（indexing） Elasticsearch创建倒排索引。1.3 类型(Type)7.0之前，一个Index可以设置多个Types7.0开始，一个Index只能创建一个Type：_doc 6.0开始，Type被Deprated。1.4 REST API GET /_cat/indices?v： 查看索引GET /_cat/indices?v&health=green：查看状态为绿的索引GET /_cat/indices?v&s=docs.count:desc：按照文档个数对索引进行排序1.5 集群(Cluster)1.5.1 分布式特性高可用性 ...

我的我的Elasticsearch系列文章，逐渐更新中，欢迎关注 0A.关于Elasticsearch及实例应用 00.Solr与ElasticSearch对比 01.ElasticSearch能做什么？ 02.Elastic Stack功能介绍 03.如何安装与设置Elasticsearch API 04.如果通过elasticsearch的head插件建立索引_CRUD操作 05.Elasticsearch多个实例和head plugin使用介绍06.当Elasticsearch进行文档索引时，它是如何工作的?07.Elasticsearch中的映射方式—简洁版教程 另外对于入门小白，我强烈推荐这篇Elasticsearch手把手搭建指南给你，新手碰到的坑，这里都已经写了答案。 介绍在这个简短的博客中，我将解释Elasticsearch中的映射以及一些常见的有用最佳实践。在本系列博客后面的Elasticsearch中学习分析/分析器时，对映射有一个很好的了解将很方便。映射映射不过是Elasticsearch中文档的架构。正如我之前在阶段01的博客之一中提到的那样，Elasticsearch的架构较少。这意味着，与其他数据库（例如MongoDb或MySql）不同，在将文档索引到Elasticsearch之前，无需预定义文档的架构。那么这是如何工作的呢？简而言之，Elasticsearch具有检测文档字段类型并生成模式并将其应用于整个索引的内置功能。当然，这里有一些事情要注意，但是我们稍后会在本博客中再次讨论。首先让我们看看在索引示例文档时映射是如何存在的。步骤1创建没有任何文档的索引。 curl -XPUT localhost:9200/testindex-0202对于上面的命令，我们将得到以下响应： { “acknowledged”: true, ”shards_acknowledged”: true, ”index”: ”testindex-0202"}现在，让我们通过使用如下所示的“获取映射” API来查看是否对其应用了任何映射： curl -XGET localhost:9200/testindex-0202/_mapping上面的命令将导致以下响应： { “testindex-0202”: { “mappings”: { } }}从响应中可以看到，“映射”部分为空，这意味着在此阶段没有应用任何映射。 第2步现在将文档索引到创建的索引，如下所示： curl -XPUT localhost:9200/testindex-0202/testtype/1 — d ‘{ “name”: ”ArunPMohan”, ”age”: 31, ”married”: true}’如您在上面的文档中看到的，我有三个字段，字段的类型是字符串（对于“名称”字段），整数（对于“年龄”字段）和布尔值（对于“已婚”字段）。当我们键入此命令时，它不会导致任何错误，这仅表示Elasticsearch已自动检测到字段类型。上面的用于为文档建立索引的命令从Elasticsearch产生以下输出： { “_index”: ”testindex-0202",”_type”:”testtype”,”_id”:”1", ”_version”: 1, ”result”: ”created”, ”_shards”: { “total”: 2, ”successful”: 1, ”failed”: 0 }, ”created”: true}现在，在创建文档之后，我们可以使用“ GET mapping” API来查看映射更改。因此，应用以下命令： ...

云妹导读： 据美国调研机构Gartner公司调研指出，2020年，企业“无云”就像“无网络”一样窘迫。如果企业对于信息化和数字化视而不见，势必将被这个时代所淘汰。近日，国常会议指出，要对“互联网+”、平台经济等加大支持力度，发展数字经济新业态，依托工业互联网促进传统产业加快上线上云。在顶层架构的带动下，“企业上云”概念，再次站上风口。京东物流在上云过程中算走在京东集团的最前列，截止目前已经有超过90%的应用在公有云上部署了实例，包括去年的双11.11大量业务都是运行在公有云上，在业务流量超过了三倍以上的情况下，整体运营也都非常平稳。 1 京东物流为什么要“上云”京东物流之所以需要迁移上云，除了整个京东集团上云战略上的考虑，从物流集团内部自驱来看有三点考虑，即轻资产化、降低成本、架构升级。 物流是非常重资产的行业，要有库房、大量的员工还有物流系统也是非常庞大的，而这么大体量的系统却常年跑在很多物理机上面，随着时间的推移，这些物理机可能过保或者损坏，带来了大量的维护成本，而随着业务的发展，还要采购更多的物理机，这就导致资产会越来越重。而从整个互联网趋势来看，大家都是希望自己的架构越来越轻，资产越来越轻。 第二就是降低成本，大家都知道云计算的特点就是虚拟化和共享化。如果资源在不使用的时候可以回收掉，使用的时候可以采用按需申请，包括计费的模式，就可以按小时按天进行计费。这样对集团内部资产进行规划，对于集团制定服务器的预算都有很好的帮助。 第三，如果只是简单的把系统搬到云上去的话是没有任何意义的，仅仅把系统服务器部署从私有云搬到公有云上意义也不大，真正有意义的是，在这个迁移的过程中，可以对自身的系统架构进行梳理，同时也可以对陈旧的、过时的和现在业务发展不太匹配的系统架构进行一定的升级，包括云原生的架构，这是一个非常好的机会。 而这三点就是京东物流启动上云的驱动力。 2 京东物流迁移上云方案依托京东智联云云搜索Elasticsearch高可用、易扩展、近实时等特性，产品在降低使用门槛，减少资源投入成本的前提下，成功助力京东物流分拣中心自动化系统、冷链流程监控系统、开放订单跟踪系统等上百个系统迁移上云。 迁移方案的选择 根据业务需求，方案包括停机迁移和不停机迁移2种： 1、停机迁移 迁移过程中，旧集群可以暂时停止服务或者暂停写入，待数据全部迁移到新集群后，再将业务切换到新集群进行读写。 停机迁移可以通过elasticsearch-dump、snapshot、reindex、logstash等方式完成数据迁移。 2、不停机迁移 迁移过程中，旧集群不能停止写入，业务不能停服，这也是京东物流上云主要采用的方案。 如果旧集群不能停止写入，此时进行在线数据迁移，需要保证新旧集群的数据一致性。目前看来，除了官方商业版提供的CCR功能，开源版本并没有开源的严格保证数据一致性的在线数据迁移工具。因此京东智联云Elasticsearch团队基于京东物流需求提供了业务不停机场景下的迁移工具。 工作原理 在云端创建新集群，将云上集群和用户集群合并成一个大集群，利用Elasticsearch数据分布API（cluster.routing.allocation.exclude）将用户集群中的索引数据迁移到云上集群的数据节点，最后将用户集群和云上集群构成的大集群拆分，关闭用户集群即可完成迁移。 但采用这种方式必须要同时满足如下两个条件： 用户集群版本和云上集群版本相同用户集群所有节点和云上集群所有节点网络能够互通操作步骤 整个迁移过程包括新建镜像集群、镜像集群加入源集群、移动数据到镜像集群、切换客户端流量、切分集群5个方面。 #1 创建云上集群。在京东智联云云搜索Elasticsearch控制台（https://es-console.jdcloud.com/clusters）创建与用户源集群版本一致、网络互通的云上集群，作为镜像集群。 #2 合并集群。设置用户源端集群地址和云上集群实例ID，创建迁移任务后，将镜像集群加入源集群。 #3 迁移数据。集群合并成功后，可以先尝试迁移一个索引，迁移后切换该索引的应用端流量，观察应用端读写数据正常后，迁移全部索引。 #4 切换流量。索引迁移成功后，应用侧需要将配置的集群地址修改为云上集群的地址，切换应用的集群地址后，建议运行一段时间，观察应用是否读写正常。 #5 切分集群。集群切分后无法恢复，建议运行一段时间，确认集群运行正常后，再切分集群，同时关闭源集群，才会最终切分完成。 通过上述方法，仅6个月时间京东物流就完成了近百个系统的数百个集群、数千个节点数据迁移工作。还配套提供了一键报警等核心功能，进行全天候、全方位掌握集群健康等情况。 3 为什么使用ES？京东物流作为全球唯一拥有中小件、大件、冷链、B2B、跨境和众包(达达)六大物流网络的企业，产生的数据规模极大，需要的组件必然是多元化的，Elasticsearch作为排名最高的搜索引擎，完美兼容Logstash、Kibana周边生态，在搜索查询领域，几乎完胜所有竞争产品，解决一切搜索查询问题。因此，这也是Elasticsearch成为京东物流大件二手仓系统、订单跟踪系统等上百个系统搜索查询场景下的不二选择的重要原因。 但在物流上云之前，使用的Elasticsearch系统均是采用自行搭建方式完成的，使用传统自建服务器的方式其实存在很多的问题： 开源集群、索引管理工具问题——一是缺少对公司业务的感知和数据治理能；二是缺乏与公司基础设施的联动集群、索引的运维问题——在操作的安全性和标准化的运维手段、流程健全性等方面都有待优化线上问题排查——较多依赖手动操作和人工经验判断，解决问题的最佳实践没有固化资金成本问题——硬件采购需要大量资金，机房托管、部署机器等工作，需要较长的时间周期和人力成本云计算高可用、全托管、易扩展等特性可以很好的解决用户服务的痛点。云搜索Elasticsearch围绕企业需要和运维中面临的问题，提供了完善的解决能力： 全托管——用户分钟级即可成功创建出可用Elasticsearch集群，无需部署维护软硬件设施，集成完整的集群管理、监控与告警系统，专业团队7*24小时不间断守护，用户只需专注于业务开发。高可用——能够方便地为数据建立索引，拥有节点自动发现和替换失效节点能力,零配置实现分布。当有新节点加入集群时，自动发现并重新进行负载均衡，为新节点分配数据；当某节点失效时，它同样会自动重新为可用节点分配数据。易扩展——云搜索Elasticsearch服务提供实时扩容功能，实现集群的轻松扩展。用户可根据数据量和查询量选择合适的机型，自定义节点的存储空间，灵活实现按需配置，动态扩容集群以满足业务增长需求。近实时——自动将海量数据分散到多台服务器上去存储和检索，在秒级别对数据进行搜索和分析，达到海量数据近实时处理。开放兼容——100%兼容开源Elasticsearch，开放大量简单易用的RestfulAPI，集成了可视化分析工具Kibana和集群管理工具Head。安全可控——云搜索Elasticsearch部署在逻辑隔离的专有网络内，杜绝了外网直连风险。同时只开放云搜索Elasticsearch服务所需特定端口，加固了数据访问安全。以上，Enjoy~ 点击【阅读】，可了解更多Elasticsearch详请！

我的Elasticsearch系列文章，逐渐更新中，欢迎关注0A.关于Elasticsearch及实例应用00.Solr与ElasticSearch对比01.ElasticSearch能做什么？02.Elastic Stack功能介绍03.如何安装与设置Elasticsearch API04.如果通过elasticsearch的head插件建立索引_CRUD操作05.Elasticsearch多个实例和head plugin使用介绍 另外对于入门小白，我强烈推荐这篇Elasticsearch搭建教程给你，小白会碰到的坑，这里都已经写了答案。 这是elasticsearch简介系列的一个简短的可选博客。该博客包含两个部分 在系统中安装多个Elasticsearch实例使用插件elasticsearch-head将视频博客进行各种操作1.运行多个实例Elasticsearch有不同的版本，从最新的6.0到最旧的版本。因此，常见的情况是我们对不同的对象使用不同的版本。知道如何在单个系统中使用不同版本的elasticsearch可能非常方便，以便我们可以尝试同时测试不同版本的查询和其他查询，从而节省大量时间。样品设置在此博客中，我们将设置两个Elasticsearch实例，第一个是5.4.0版本，第二个是2.4.0，并同时运行它们。我将默认端口9540分配给5.4.0版本，对于2.4.0版本，让我们分配端口9240。第1步-下载zip文件安装因此，对于这类开发人员友好的多实例实例安装，更好的做法是两次下载elasticsearch的zip文件安装。对于5.4.0，可以从此处下载用于安装的zip文件。对于2.4.0，可以从此处下载用于安装的zip文件。下载两个版本的zip文件后，将zip文件解压缩到相应的文件夹中。第2步-编辑配置文件在zip文件安装中，配置文件（elasticsearch.yml）位于config文件夹内，如下所示：对于2.4.0 /elasticsearch-2.4.0/config/elasticsearch.yml同样，对于5.4.0 /elasticsearch-5.4.0/config/elasticsearch.yml 现在，为两个编辑配置文件，如下所示： !在上图中，您可以在参数“ http.port”（标记为1的框）中看到端口信息已更改。标记为2的框是常规设置，当我们运行elasticsearch-head或将任何其他UI元素指向此实例时，这些设置将防止发生CORS问题。步骤— 3运行单独的实例现在，从每个提取的文件夹中键入以下命令，如下所示：1590935853263-070c65fac43dee09.png! 现在，这将在配置文件中提到的相应端口上启动两个elasticsearch版本。为了再次验证，我们可以在 sudo netstat -ntlp终端中键入命令，并查看端口中正在运行的过程。结果将如下图所示： 1590935853268-72fc6aeab0db848f.png 第4步-访问为了访问这些单独的实例，我们可以仅调用各个调用，如下图所示： Elasticsearch头中的基本操作下面嵌入的是一个简短的视频博客，介绍如何使用Elasticsearch执行基本的CRUD操作。结论在这个博客中，我们看到了如何在同一台机器上运行多个elasticsearch实例，以及如何使用插件elasticsearch-head运行基本的Elasticsearch CRUD操作。

我的系列文章列表(不断增加中)01.ElasticSearch能做什么？02.Elastic Stack功能介绍03.如何安装与设置Elasticsearch API 如果你是ElasticSearch实用主义者，我推荐你直接看这篇，手把手教你ElasticSearch搭建与配置。 在本文中，“ elasticsearch-head”的简单可视化工具的设置，以及如何使用此工具进行一些CRUD操作。工具的目的Elasticsearch-head主要是用于存储在Elasticsearch中的数据的可视化工具，从而使用户能够查询和执行其他CRUD操作。当我们处理Elasticsearch时，它是一个非常有用的工具，特别是尝试新查询，检查索引的映射（类似于SQL世界中的模式）以及查看文档的数据结构时，这也是非常有用的工具。明智的选择必须通过编程或终端方式完成。安装 在此链接中克隆仓库在系统中安装nodeJs。（您可以在此处找到安装指南）现在在克隆的仓库中浏览并键入“ npm install”在上一步中安装了必要的软件包之后，输入“ npm start”。现在，用户界面在链接http：// localhost：9200中准备就绪用户界面中的常见错误下面的屏幕快照给出了我们尝试使用Elasticsearch-head UI时的常见错误： 这主要是一个CORS问题，可以通过配置Elasticsearch允许访问来自本地主机的请求来解决。这可以通过编辑“ elasticsearch.yml”文件来完成。将以下行添加到位于elasticsearch安装路径/ etc / elasticsearch中的elasticsearch.yml文件中 http.host：0.0.0.0 http.cors.enabled：true http.cors.allow-origin：“ *” http.cors.allow-methods：OPTIONS，HEAD，GET，POST，PUT，DELETE http.cors.allow-标头：X-Requested-With，X-Auth-Token，Content-Type，Content-Length现在，使用命令“ sudo service elasticsearch restart”重新启动elasticsearch。现在，在刷新http：// localhost：9100中的elasticsearch-head UI时，我们将看到该UI，没有任何错误。UI熟悉-登陆页面现在让我们进一步探索elasticsearch-head插件。以下是用户界面登录页面的屏幕截图。让我们一一探索上图中的标记项目：1.概述指示用户界面现在位于哪个选项卡上。2.连接栏在这里，我们指定要连接的Elasticsearch实例的主机和端口。在这种情况下，我们使用本地主机作为主机，使用端口作为9200，因为Elasticsearch在本地本地的默认端口9200上运行。 3.集群运行状况指示集群的运行状况。红色的群集健康状况表明群集中有一些尚不可用的节点（主分片），这可能是一个严重的问题，因此颜色为红色。如果某些副本分片不可用，则将显示为黄色，最后，如果每个分片均可用，则将显示为绿色。这为我们提供了有关Elasticsearch健康状态的快速概述。注意：术语shard，cluster，node将在以后的详细博客中进行解释。 4.索引名称和其他信息这是索引名称，此处显示索引中的文档大小和数量。 5.“信息和操作”选项卡每个索引都有元数据，并允许对其执行某些操作。信息选项卡允许使用元数据列表，单击后将在用户界面中显示。最有用的元数据之一是“映射”，可以从此处轻松查看。 6.节点列表在介绍博客中，我告诉我们Elasticsearch是分布式解决方案。这意味着它可以部署在多个系统或节点上。该列显示节点列表，并提供选项以使用“ info”和“ actions”下拉列表查看节点详细信息。 7.分片信息分片是Elasticsearch中基本的存储单元。每个索引均分为碎片。这些碎片可以分布在不同的节点之间或单个节点上。对于索引“ training-test-01”，我们在单个节点“ 9CCT_A1”上有5个分片。双击每个分片可获得状态和信息。 8.信息信息选项卡使我们能够查看集群运行状况，节点以及与elasticsearch相关的其他一般事物的统计信息。UI熟悉-请求页面下一个在elasticsearch-head中探索UI的主页是请求页面，如下所示：这个UI基本上允许我们执行上一个博客中通过终端执行的所有CRUD操作。 请求字符串发出请求的位置。在此示例中，对于GET请求，我们提到了索引名称，类型名称和文档ID API列我们可以在此处指定用于与Elasticsearch进行交互的API。在屏幕快照中显示的此请求中，我们没有调用任何API方法，因此将其留空。 请求类型说明符可以在此处指定请求的类型，无论是POST，GET，PUT还是DELETE。 查询空间如果有与请求相关的任何查询，我们可以在此处提供。 响应区域这是响应区域，它将显示按“ Reguest”按钮时由前面几节生成的请求的响应。 结束语在这篇简短的文章中，我们已经看到了Elasticsearch-head工具的设置以及对它的熟悉。

如何安装与设置Elasticsearch API 到目前为止，在本系列文章中，我一直在撰写有关Elasticsearch和Elastic堆栈组件的一般知识。系列文章列表01.ElasticSearch能做什么？02.Elastic Stack功能介绍03.如何安装与设置Elasticsearch API 如果想找更实操的操作手册，我推荐你看这篇从小白到大师成长_ElasticSearch入门教程_ 从本文开始，我们将开始深入研究Elasticsearch API。在本文中，我们将主要侧重于Elasticsearch的安装，然后学习如何使用Elasticsearch提供的基本CRUD API。我们还将安装一个名为elasticsearch-head的第三方应用程序，以查看UI中的更改。1.安装Elasticsearch首先，让我们首先在系统中安装和配置Elasticsearch。在本教程中，我将Ubuntu 16.04用作具有8GB RAM的计算机上的操作系统。 1.1 Java安装正如我们在之前的博客中所看到的那样，Elasticsearch是建立在名为Lucene的库之上的，而Lucene又是建立在Java之上的。因此，Java是安装Elasticsearch的先决条件。以下是在计算机中安装Java的步骤：sudo add-apt-repository ppa:webupd8team/java -ysudo apt-get updatesudo apt-get install oracle-java8-installer1.2 Elasticsearch安装让我们看看如何在此处将Elasticsearch作为服务安装。 在此处下载最新版本的Elasticsearch输入sudo dpkg -i elasticsearch-5.6.3.deb 完成上述安装后，键入sudo service elasticsearch start 以启动服务。这将在您的本地环境中作为服务安装并启动elasticsearch。elasticsearch运行的默认端口是9200。要检查它是否正在运行，只需在终端中键入以下命令：curl localhost:9200 上面的命令将导致如下所示的响应： { “name” : “9CCT_A1”, “cluster_name” : “elasticsearch”, “cluster_uuid” : “QqZcNgcdRDW8sWMaLNf-Jg”, “version” : { “number” : “5.6.3”, “build_hash” : “1a2f265”, “build_date” : “2017–10–06T20: 33: 39.012Z”, “build_snapshot” : false, “lucene_version” : “6.6.1” }, “tagline” : “YouKnow, forSearch”}1.3配置文件在Elasticsearch世界中最重要的事情之一就是正确配置它。我们应该熟悉Elasticsearch中两个重要的配置文件。这些是 ：1.3b elasticsearch.yml此配置文件允许使用许多配置选项，例如更改elasticsearch的端口，定义集群中的节点，解决cors问题等。该配置文件的位置在文件夹“ etc / elasticsearch”下。在这里，您可以看到elasticsearch.yml文件。 ...

我本人接触Elasticsearch（一下简称ES）有挺长一段时间了，本文结合自己的一些项目经验，给你总结几个实际项目中比较容易踩到的坑。希望读者能够避免犯这样的错误。 坑一，时区问题在我们的项目中，索引下一般都会存在一个时间的字段，这个字段可以用来排序，或者做时间范围查询，或者聚合的场景等都会用到。 ES底层默认采用UTC时间格式，而中国的时间(CST)是 CST=UTC+8所以实际的项目中经常遇到查询结果和自己期望的不一致。关于时区的问题以及如何解决，我之前专门写了一篇文章，感兴趣的可以看看： ES系列之一文带你避开日期类型存在的坑 坑二，使用默认的mappingsES本身支持我们在写入一个索引的时候，可以不为该索引设置任何的mappings。这种情况下，ES会为索引根据写入的字段值，"推断"该字段的类型。 看起来似乎不错，但是根据我的经验，还是建议应该明确的为自己的索引定义mappings。 因为有时候ES "推断"出来的结果并不一定是我们想要的，然后给我们带来一些头疼的问题。 我还是给你举个例子： 写入一个名为message的索引， PUT /message/_doc/1{ "head": "message001", "body": "2020-05-30"}然后继续再插入一条， PUT /message/_doc/2{ "head": "message002", "body": "this is an emergency"}这里就报错了，错误的内容是提示我们，body这个字段无法被解析。产生这个问题的原因是当我们写入第一条文档的时候，ES "擅自做主"把body这个字段标记成日期类型了，然后写入文档2的时候不是日期字符串，所以无法解析。 可以用下面的命令看下索引的mapping，证实我们的猜想： GET message/_mapping在这个示例中，我们如果明确的定义body为text类型就不会有这样的问题了。 坑三，没有规划好分片我们一般都需要为索引设置分片的数量，具体设置成多少需要根据你的项目实际情况来定。 一般来说，单个 Shard 的建议最大大小是 20G 左右，最大不要超过 50G。 单个shard过大，或者shard过小导致shard数量太多，都会影响查询的效率。 举个例子，比如你预估索引的大小是100G，这个时候分片是3~5比较好。 如果你的索引是每天增量比较大的场景，比如日志类，订单类的索引，可能你首先要把根据日期来新建不同的索引，根据时间的数据规模选择按天，周，甚至月来建索引。然后这些索引使用相同的分片设置。 坑四，过多依赖ES聚合的结果ES某些场景下的聚合结果是不准确的，计算的结果只是告诉你一个大概的分布情况，并不是精确的。 如果你不了解这个情况，可能会在实际的项目中犯错误。 我曾经写过一篇文章，对这个坑有过详细的分析以及闭坑指南，有兴趣可以看看这篇文章： ES系列之原来ES的聚合统计不准确啊 坑五，分桶聚合查询的内存爆炸在分桶聚合的场景下，大多数时候对单个字段的聚合查询非常快的，如果是多个字段嵌套聚合。有可能撑爆内存，引发OOM。看下面一个例子。 假设我们有个很多电影数据的索引，有个字段是数组，保存演员的名字。 { "actors" : [ "Fred Jones", "Mary Jane", "Elizabeth Worthing" ]}然后，我们希望查询出演影片最多的10个演员，以及他们合作最多的5位演员，可以使用下面这个聚合， { "aggs" : { "actors" : { "terms" : { "field" : "actors", "size" : 10 }, "aggs" : { "costars" : { "terms" : { "field" : "actors", "size" : 5 } } } } }}结果返回前10位演员，以及与他们合作最多的5位演员。但是就是这样一个简单的查询，可能导致OOM。 ...

概要本篇开始介绍Elasticsearch生产集群的搭建及相关参数的配置。 ES集群的硬件特性我们从开始编程就接触过各种各样的组件，而每种功能的组件，对硬件要求的特性都不太相同，有的需要很强的CPU计算能力，有的对内存需求量大，有的对网卡要求高等待，下面我们讨论一下ES集群对几种硬件的特性需求。 CPUES集群对CPU的要求相对低一些，毕竟纯计算的比重要小一些，选用主流的CPU，2核到8核的都可以。 如果有两种CPU可以挑选，一种是主频高但核数少的CPU，另一种是主频一般核数多的CPU，肯定选后一种，因为多核的CPU可以提供更多的并发处理能力，远比单核高性能带来的效益要高。 内存ES集群对内存的要求很高，部署ES集群时，要把大部分资源投入到内存当中。内存分配主要有两部分，JVM heap内存（堆内存）和OS Cache内存。 JVM heap内存用得不多，主要是OS Cache，我们知道，ES建立的倒排索引，正排索引，过滤器缓存，都是优先放在内存当中的，OS Cache的大小直接决定搜索的性能，如果OS Cache不够，ES搜索等操作只有被迫读硬盘，延时就会从毫秒级升到秒级。 OS Cache具体在多大才算够，取决于数据量，如果是百万级别的数据，16GB左右应该可以接受，如果是亿级，一般单节点都是64GB内存。生产环境最低要求内存应不低于8GB。 硬盘硬盘成本本身比较便宜，能用SSD就用SSD，访问速度肯定比机械硬盘快，预估好数据量后就尽可能多规划一些容量。 另外尽量使用本地存储，网络存储还依赖于网络传输，这个容易造成一些延迟。 网络对ES集群这种分布式系统来说，快速并且可靠的网络还是比较重要的，shard的分配和rebalance都需要占用大量的带宽，集群最好部署在同一个局域网内，异地容灾等跨数据中心的部署方案，要考虑到网络故障带来的影响。 JVM选择使用ES官网推荐的JDK版本，服务端和客户端尽量使用同一个版本的JDK。 涉及到ES服务端的JVM调优设置，保持原样不要轻易改动，毕竟ES已经花了大量人力物力验证过的，随意调整jvm参数可能适得其反。 容量规划规划集群里，要规划好投入几台服务器，数据量上限是多少，业务模型数据读写的比例是多少，历史数据的迁移方案等，一般来说，百万到10亿内的数据量，使用ES集群还是能够支撑下来的，ES节点数建议不要超过100个。 举个例子：数据量10亿以内，部署5台服务器，8核64GB内存，是能够支撑的。 生产案例模拟Linux操作系统搭建我们使用Linux虚拟机来演示一个生产ES集群的搭建。我们创建4台虚拟机，每台2核CPU，4GB内存，操作系统为CentOS 7 64bit。 虚拟机我用的是VMware workstation，有用virtual box也行，CentOS 7、JDK的安装不赘述。记得把CentOS的防火墙关了。 修改每台机器的hostname信息，命令vi /etc/hostname，修改文件，保存即可，建议修改成elasticsearch01，elasticsearch02，elasticsearch03，elasticsearch04。 假定我们4台虚拟机的域名和IP是这样分配的： 192.168.17.138 elasticsearch01192.168.17.137 elasticsearch02192.168.17.132 elasticsearch03192.168.17.139 elasticsearch04把这段配置放在 /etc/hosts文件末尾，4台机器做相同的配置。 这4台机器之间，可以配置免密登录，如在elasticsearch01机器上，我们执行以下操作： 生成公钥文件，命令：ssh-keygen -t rsa一直输入回车，不要设置密码默认会将公钥放在/root/.ssh目录下生成id_rsa.pub和id_rsa两个文件 拷贝公钥文件cp id_rsa.pub authorized_keys将公钥文件拷贝到另外三台机器ssh-copy-id -i elasticsearch02ssh-copy-id -i elasticsearch03ssh-copy-id -i elasticsearch03拷贝完成后，可以在目标机器上/root/.ssh/目录下看到多了一个authorized_keys文件。 尝试免密登录，在elasticsearch01机器上输入ssh elasticsearch02，如果不需要输入密码就能登录到elasticsearch02，说明配置成功，其他机器类似。这4台机器也可以相互做ssh免密设置。 这里补充一点免密登录的方向性问题，上面的案例是在elasticsearch01机器生成的公钥，并且发送给了elasticsearch02等三台机器，那么我从elasticsearch01跳到elasticsearch02是不需要密码的，反过来从elasticsearch02登录到elasticsearch01，还是需要密码的。 最后补充几个常用检查命令： 检查NetManager的状态：systemctl status NetworkManager.service检查NetManager管理的网络接口：nmcli dev status检查NetManager管理的网络连接：nmcli connection showElasticsearch服务端这里选用的JDK版本为1.8.0_211，Elasticsearch版本为6.3.1，自行安装不赘述。 ES解压后的目录结构： # 用 "tree -L 1" 命令得到的树状结构.├── bin├── config├── lib├── LICENSE.txt├── logs├── modules├── NOTICE.txt├── plugins└── README.textilebin：存放es的一些可执行脚本，比如用于启动进程的elasticsearch命令，以及用于安装插件的elasticsearch-plugin插件config：用于存放es的配置文件，比如elasticsearch.ymllogs：用于存放es的日志文件plugins：用于存放es的插件data：用于存放es的数据文件的默认目录，就是每个索引的shard的数据文件，一般会另外指定一个目录。Elasticsearch参数设置在config目录下的文件，包含了ES的基本配置信息： ...

这是我的博客系列“ Elasticsearch简介”的第一篇文章。本系列旨在指导您入门Elasticsearch，了解其功能，现实生活中的用例以及熟悉Elasticsearch堆栈中的其余组件。该博客将为您简要介绍Elasticsearch，其提供的解决方案以及选择Elasticsearch服务的原因。 如果你已经了解Elasticsearch是怎么回事，开始着手搭建，那我推荐你看这篇：elasticsearch初学终极教程: 从零到一 一、什么是Elasticsearch？这是新手碰到的第一个问题！我来概括以下：Elasticsearch是一个NoSql数据库，其搜索引擎基于Lucene构建。Elasticsearch提供了一个分布式的，基于JSON的实时，多租户的全文搜索解决方案。即使上面的定义仅用两句话就结束了，但您还是不会听到很多术语。让我们拆分它们并分别进行探索1 Lucene简而言之，Lucene是一个用Java编写的库。因此，下一个显而易见的问题是它的作用和功能是什么！Lucene是一个搜索库。这意味着，有一些用Java编写的函数和方法已针对不同的搜索策略进行了优化。Lucene是有史以来最受欢迎的搜索库。大多数开源/商业搜索实现都以Lucene为骨干。因此，在阅读了上面对Lucene的定义之后，出现了一系列问题，例如，如果Elasticsearch将Lucene用于搜索部分，为什么我们不能将裸露Lucene用于我们的目的呢？为什么选择Elasticsearch？或者，Elasticsearch和Lucene有什么区别？这些问题的答案是，Lucene是一个编写得非常出色的库，这也使得在根据最终客户需求进行定制时很难处理。因此，Elasticsearch所做的就是在Lucene之上构建一个API层，这将使Lucene方法和功能的使用变得非常简单。2.分布式系统除了在我们的应用程序中配置Lucene的难以置信的困难之外，使Elasticsearch优于Lucene的原因是前者的分布式特性。从本质上讲，分布式意味着Elasticsearch可以同时在不同的系统/节点上运行，并尝试利用网络中的系统资源来解决单个问题。Lucene不支持此功能，它是许多实现的主要障碍。3.实时搜索插入Elasticsearch的文档几乎可以立即用于搜索。此功能开箱即用，无需外部/附加配置。4.基于JSONElasticsearch使用基于JSON的通信。这意味着它将JSON格式用于API和其他通信。由于当今大多数Web应用程序和服务都以JSON进行通信，因此这在使用和互操作性方面提供了极大的灵活性。5.多租户能力多租户是指一种应用程序的架构，其中服务器/云上的应用程序实例可以由具有不同级别可访问性选项的多个租户（用户组）访问。二、Elasticsearch-用例1.搜索Elasticsearch的主要用例和目的是使“搜索”更快，更好。因此，搜索是Elasticsearch的第一个用例。它提供了许多搜索策略，例如开箱即用的大小写相关/独立搜索，部分匹配，自动建议搜索。同样，根据用户依赖的策略（例如选择性加权，突出显示等）对搜索进行大量定制非常容易在Elasticsearch中构建和实现。这些因素使其成为搜索操作中最常见的选择。2.日志收集/解析和分析Elasticsearch与堆栈的其他成员（例如Logstash）和Beats平台使从各种来源收集数据变得非常容易和顺畅。Logstash和Beats使来自各种来源的数据转发变得容易，并且由于它们与Elasticsearch的本机集成，在Elasticsearch中设置和开始收集数据非常容易。Elasticsearch在这里解决的问题是需要来自不同来源的不同数据处理程序。也就是说，如果您要从不同来源收集日志并需要对日志进行标准化，则可以使用Elasticsearch的Logstash轻松处理此过程的数据转发和数据解析解析应用。因此，使用这种方法可以解决许多中间步骤，以及由此花费的时间和精力来制作标准格式。使用Elasticsearch的可视化工具Kibana可以轻松可视化已解析和保存的数据。Elasticsearch的功能内置了许多类型的分析功能，例如不同类型的聚合和许多统计计算，它们可以应用于日志，然后使用Kibana进行交互式可视化，以获取有关日志数据的有用见解。3.内容连接器就像上一节中提到的日志一样，Elasticsearch的下一个最大用例是来自众多来源的数据收集如Twitter，Sharepoint，JIVE等。有强大的社区连接器插件可提取数据，并具有来自各种来源的所需自定义并将其添加到Elasticsearch中。反过来，这不仅可以为特定目的提供强大的数据收集，还可以使其变得可搜索。例如：可以将来自特定主题标签的数据流式传输到Elasticsearch，然后，如果我们能够对该数据进行快速的搜索，请想象简化用户所需内容的简便性。卫报新闻社正在使用类似的实现方式，在那里将其新闻的最新评论流式传输到Elasticsearch。然后，对这些数据进行分析并使其可搜索，以便他们可以尽快找到文章的趋势。4.即时可视化快速数据可视化功能可在Elasticsearch中建立数据索引后的几分钟内创建具有洞察力的仪表板，这也是Elasticsearch堆栈的主要用例之一。Elasticsearch提供的可视化工具是Kibana，它可以依次加载来自Elasticsearch的数据并可以对它们进行大量分析，然后将其呈现为各种图表，可以按照任何顺序排列以创建报告/仪表板。应用程序监视区域可以使用Kibana -Elasticsearch组合找到大量用例，因为可以实时检测和应对异常或威胁。三、为什么选择Elasticsearch？最后进入百万美元的问题，为什么要优先使用Elasticsearch？让我们看看最完美地回答这个问题的最重要因素：1.可扩展性使用Elasticsearch的主要优势之一是其可伸缩性。在大多数情况下，只需花费相当长的搜索时间，您就可以将数据索引到Elasticsearch中。是的，没错，在处理Elasticsearch的分布式特性时不会遇到麻烦或痛苦。Elasticsearch自行处理缩放。例如，如果将一个新节点添加到集群中，则无需设置路由，也无需进行重大的关键设置更改即可使其可发现并正常运行，Elasticsearch的主节点只需很少的干预即可解决此问题。 。2.模式少通过设计，Elasticsearch被设计为无模式的应用程序。这意味着我们无需事先提供用于将文档放入Elasticsearch的架构。当涉及多个数据源时，这确实是一个巨大的缓解。在类似MongoDb的类似NoSQL数据库中，我们需要预先指定架构。在Elasticsearch中，我们可以对此部分感到叹为观止，然后就可以开始为数据建立索引了。如果没有模式，Elasticsearch会自动为文档字段分配一个模式。3.定制这个问题的另一个响亮答案，为什么是Elasticsearch？是它在其提供的解决方案中提供的自定义选项。例如，如前一节所述，它为开发人员提供的搜索选项的自定义可以使搜索的几乎所有用例都包含在内。此外，Elasticsearch的数据通信部分也可以通过多种方式完成，包括默认的插件，插件或用户开发的解决方案，可以与之完美集成。4.社区最后但并非最不重要的一点是，由Shay Banon和其他同样才华横溢的开发人员领导的令人惊叹的社区使其成为强大的开源社区之一。社区的努力创建了许多插件，插件和库，从简单的分析器插件到数据河实现。快速的响应式论坛和活跃的在线状态也将节省大量开发时间。四、结论在本文中，我介绍了Elasticsearch，其要解决的问题和问题以及拥有Elasticsearch的令人信服的原因。在该系列的下一篇文章中，我将向您简要介绍Elasticsearch堆栈以及每个组件的功能。关于如何搭建Elasticsearch，搭建可以看这篇

网上有很多Apache Solr和ElasticSearch之间的比较，我来写写我的看法。 Solr可能是构建标准搜索应用时的首选武器，但Elasticsearch将其提升到了一个新的层次，它的架构可以创建现代实时搜索应用。Percolation是一个令人兴奋的创新功能，这个功能能轻松打败Solr。Elasticsearch具有可扩展性、速度快，并且是一个集成。Adios Solr，很高兴认识你。维基百科上关于ElasticSearch的文章引用了德国著名的iX杂志的比较，列举了优缺点，基本概括了上面已经说过的内容。 优势 ElasticSearch是分布式的。不需要单独的项目。复制也是近实时的，也就是所谓的 "推送复制"。ElasticSearch完全支持Apache Lucene的近实时搜索。处理multitenancy不是一个特殊的配置，在Solr中需要更高级的设置。ElasticSearch引入了网关的概念，这使得完全备份变得更加容易。劣势 只有一个主开发者没有自动升温功能总结它们是完全不同的技术，解决的是完全不同的用例，因此不能进行任何有意义的比较。 关于ElasticSearch的部署教程，推荐大家看这篇文章：elasticsearch初学终极教程: 从零到一 Apache Solr - Apache Solr提供了Lucene的功能，在一个简单易用、快速的搜索服务器中提供了Lucene的功能，并具有额外的功能，如分面、可扩展性等。 Amazon ElastiCache - Amazon ElastiCache 是一种 Web 服务，可轻松部署、操作和扩展云中的内存内缓存。 请注意，Amazon ElastiCache 是与 Memcached 协议兼容的，Memcached 是一种被广泛采用的内存对象缓存系统，因此您现在使用现有 Memcached 环境的代码、应用程序和流行的工具都将与该服务无缝地配合使用 也许大家已经把它和下面两个相关的技术混淆了，下面我们来看看这两个相关的技术。 ElasticSearch---它是一个基于Apache Lucene之上构建的开源（Apache 2）、分布式、RESTful、搜索引擎。 Amazon CloudSearch---亚马逊云搜索（Amazon CloudSearch）是一个完全管理的云端搜索服务，可以让客户轻松地将快速、高扩展性的搜索功能集成到他们的应用中。 Solr和ElasticSearch的产品乍听起来非常相似，都使用了相同的后端搜索引擎，即Apache Lucene。 Solr比较老，功能相当丰富，也相当成熟，因此被广泛使用，而ElasticSearch则是专门为解决Solr的不足之处而开发的，在现代云环境下的可扩展性要求，而这些都是Solr难以解决的。 因此，将ElasticSearch与最近推出的Amazon CloudSearch进行比较可能是最有用的，因为两者都声称在原理上涵盖了相同的用例。

elasticSearch性能elastic的性能跟机器的分配内存和是否使用ssd固态硬盘有很大关系,主要是因为搜索的时候可以减少磁盘的读写交互, 以及数据的寻址, 将数据基本上全部放到内存中;elasticsearch不适合特别大量的数据, 就是因为他占用内存过多, 如果数据量很大, 可以考虑使用大数据技术, 因此在使用之前要估算业务的数据量和要使用的机器以及内存情况;集群的发现机制unicastunicast-list就是将集群中的几个节点作为通讯节点来接受和返回其他要加入节点的信息, 不需要将所有的节点都设置为unicast list配置项: discovery.zen.ping.uncast.hostsmaster选举节点间通讯超时时间配置: discovery.zen.ping_timeout节点设置cluster-name: 需要设置成一样的才能加入到集群node-name: 每一个节点需要有自己的一个名字network-host: 需要绑定到自己的机器上去集群故障探查两种方法: master去ping其他的节点保证其他节点都存活, 或者其他节点去ping master节点配置项ping_interval: 每隔多长时间ping一个nodeping_timeout: 每次ping的超时时间ping_retries: 一个node被ping多少次失败就认为是故障了集群状态更新类似于zookeeper的二阶提交, 不过zookeeper是强一致性的, 而elasticsearch则可以配置返回消息的节点数量;配置项: discovery.zen.minimum_master_nodes一般建议的目录地址path.logs var/log/elasticsearchpath.data var/data/elasticsearchlog日志配置appender.rolling.strategy.type = DefaultRolloverStrategyappender.rolling.strategy.action.type = Deleteappender.rolling.strategy.action.basepath = ${sys:es.logs.base\_path}appender.rolling.strategy.action.condition.type = IfLastModifiedappender.rolling.strategy.action.condition.age = 7Dappender.rolling.strategy.action.PathConditions.type = IfFileNameappender.rolling.strategy.action.PathConditions.glob = ${sys:es.logs.cluster\_name}-\*第一行是配置了默认的DefaultRolloverStrategy第二行是配置了Delete action，在rollover之后，就会删除文件第三行是配置了es log的基础路径第四行是配置了rollover发生的条件，是基于IfLastModified第五行是配置了保留的天数，这里是7天第六行是配置了删除匹配7天前的文件第七行是配置了一个删除文件的格式，这样就只是删除过期日志文件，但是不要删除慢查询日志集群脑裂问题参数配置脑裂主要是由于网络问题引起的, 由于一个集群被划分到两个网络中去, 相互之间不能通讯, 因此会对集群重新选举master, 当网络恢复后, 会造成数据不一致或者丢失的问题;配置项: discovery.zen.master_minimum_nodes 取值为node数量 n\2 + 1 个, 当只有两个节点时,不论这个值取几都是有问题的;集群重启时无意义的shard重新分配原因: 如果有十个节点, 其中五个节点先启动了, 剩余五个节点启动很慢, 那么先启动的五个节点会组成一个集群, 记性p-shard和r-shard的分配, 当其他五个节点启动后, 这些shard会重新分配, 耗费大量资源和时间;配置项: gateway.recover_after_nodesgateway.expected_nodesgateway.recover_after_timejvm分配的一般方法通常会将机器的内存一半分配给jvm, 因为机器占用内存的不光是jvm还有lucene, 以及系统资源, 如果不是用大量的聚合或者filedata数据, 可以将jvm内存设置的小一点, 但jvm的内存不能超过32G, 超过32会造成内存的浪费, 和内存中数据的指针压缩有关系; ...