Elastic

0、引言 实战中经常遇到的问题： 问题 1：请问下大家是如何评估集群的规模？比如数据量达到百万，千万，亿万，分别需要什么级别的集群，这要怎么评估？ ps：自己搭建的测试环境很难达到这一级别。 问题 2： 问题 3：我看了很多文章关于 es 集群规划的文章，总感觉乱七八糟的，没有一个统一的规划思路。如何根据硬件条件和数据量来规划集群，设置多少节点，每个节点规划多少分片和副本？ Elasticsearch 集群规模和容量规划：是进行 Elasticsearch 集群部署前对所需资源类型和数量的规划。 通过本文，您将了解： Elasticsearch 计算资源详解 Elasticsearch 架构、增删改查操作和资源需求 Elasticsearch 集群规模和容量规划的方法论 1、Elasticsearch 基础架构 1.1 自顶向下的架构体系 Cluster—协同工作的节点组，以保障 Elasticsearch 的运行。 Node—运行 Elasticsearch 软件的 Java 进程。 Index—一组形成逻辑数据存储的分片的集合。 Shard—Lucene 索引，用于存储和处理 Elasticsearch 索引的一部分。 Segment—Lucene 段，存储了 Lucene 索引的一部分且不可变。 Document—条记录，用以写入 Elasticsearch

1、es安装 先安装 elasticsearch -php （这个对php的版本有要求，推荐composer安装）， 对应版本传送 ，安装完成后，搭建JAVA 环境（网上搜索），环境配置完成后（需要添加几个系统配置的环境变量），下载 对应 php版本 的elastic 对应版本传送 ， elastic 下载传送 ，安装说明在下载的页面有相关文档，推荐下载对应的分词 【ik版本传送】 ，安装比较简单，解压缩，复制/剪切到 elastic 的 plugins 文件夹下（没有就新建），重启elastic， 2、logstash 安装 这个需要的是ruby 环境，所以搭建ruby环境，然后下载安装 推荐参考范例 ，按照这个操作很快就可以完成，是我找到最好的教程， 3、php 实现搜索 由于数据还没有处理完成，就以上述案例的数据为准，进行操作 1）全部搜索没有 等价于 MySQL【select * 】 public function search($key){ $hosts = [ // '192.168.1.1:9200', // IP + Port // '192.168.1.2', // Just IP // 'mydomain.server.com:9201', // Domain + Port // 'mydomain2.server.com', // Just Domain //

假设需求 因为业务需要将日志系统收集到的信息进行图表化展示并交付到用户进行业务交流。 解决方案 这个需求看着似乎蛮简单的，如何解决？ 1.对需要的数据进行过滤制作图表 2.对用户的权限限制为只读级别，并且用户不能看除图以外的其它信息 解决需求 以流量渠道为例： 对需要的数据进行过滤制作图表 正则： vhost : ( www.xxx.com xxx.com sxxx.xxxx.com) and not path : *api* and not path : socket and not path : *css* and not path : *js* and not path : *ico* and not path : *txt* and not path : *png* and not path : *jpg* and not path : *wasm* and not path : *svg* 仪表盘： 对用户的权限限制为只读级别，并且用户不能看除图以外的其它信息 因为使用的kibana是购买aliyun的elasticsearch时赠送的，安装有x-p插件，所以有用户权限控制。 但是经过几次对users的尝试发现似乎只使用自带的users权限管理难以达到目的。 通过查阅官方文档： https://www.elastic.co/guide/en/elasticsearch

实验目的，熟悉AWS Elastic Container Service 实验包括： 1. 创建和定义ECS的任务（Task） 2. 创建ECS Cluster 3. 部署应用到ECS Service中 实验前准备： AWS账号 熟悉IAM role、EC2、Docker等知识 Task1：使用ecs-sample image注册和定义Task 进入到ECS服务，创建Task Definitions： { "family": "myContainer", "containerDefinitions": [ { "volumesFrom": [], "portMappings": [ { "hostPort": 80, "containerPort": 80 } ], "command": null, "environment": [], "essential": true, "entryPoint": null, "links": [], "mountPoints": [ { "containerPath": "/usr/local/apache2/htdocs", "sourceVolume": "my-vol", "readOnly": null } ], "memory": 300, "name": "simple-app", "cpu": 10, "image":

目录 安装操作Elasticsearch的PHP库 PHP连接Elasticsearch 创建索引和映射 添加文档 单一文档索引 批量(bulk)索引 获取文档 更新文档 部分更新 script更新 删除文档 首先打开Elasticsearch官网了解对应编程语言的API https://www.elastic.co/guide/en/elasticsearch/client/index.html 点击 PHP API即可查看当前7.X版本的文档内容了 安装操作Elasticsearch的PHP库 我们使用TP5来作为示例 首先需要安装操作Elasticsearch的PHP客户端库，我们打开https://packagist.org/，搜索Elasticsearch。 这里有个Elasticsearch-PHP和Elasticsearch版本的对照表，我们需要根据我们自己使用的Elasticsearch的版本下载对应的Elasticsearch-PHP 由于我的Elasticsearch版本是7.6.2，所以这里我们可以下载最新的Elasticsearch-PHP版本为7.8.0 我们进入到自己的项目目录里安装Elasticsearch-PHP composer require elasticsearch/elasticsearch=7.8.* PHP连接Elasticsearch

少废话，直接开始。 1、大文件是多大？ ES建立索引完成全文检索的前提是将待检索的信息导入Elaticsearch。 项目中，有时候需要将一些扫描件、PDF文档、Word、Excel、PPT等文档内容导入Elasticsearch。 比如：将《深入理解Elasticsearch》这边书导入ES，而这边书的全文内容被识别后的大小可能为3MB——5MB以上的字节。 存入ES后是一个content字段，对这个content执行全文检索&高亮显示，就存在检索效率低的问题，会耗时30S以上的时间。 这点，作为习惯了搜索引擎极速体验的用户，是不能忍的。 本文，详细记录了大文件的全文检索性能问题排查及提升实践方式。 2、问题描述 从检索症状来看： 1）翻页到1000+页（每页10条数据）以上，响应时间会比较长。 2）当遇到某些文件的时候（事后分析得知是大文件），响应时间尤其长，超过30S以上返回高亮结果。 3、问题排查与定位 步骤1： 限定返回记录条数。不提供直接访问末页的入口。 baidu，360，搜狗等搜索引擎都不提供访问末页的请求方式。都是基于如下的请求方式： 通过点击上一下、下一页逐页访问。 这个从用户的角度也很好理解，搜索引擎返回的前面都是相关度最高的，也是用户最关心的信息。 Elasticsearch的默认支持的数据条数是10000条，可以通过post请求修改。 最终

1. 背景 在使用ES进行查询的时候，往往可以发现同一条query，查询多次后，越来越快直至1,2毫秒，聪明的你肯定一下就联想到，这肯定是缓存了查询结果到内存。 通过查询官方文档，可以看到有3个小章节描述缓存： https://www.elastic.co/guide/en/elasticsearch/reference/current/query-cache.html https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-request-cache.html https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-fielddata.html 以及1个小章节描述如何清理缓存： https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-clearcache.html PS：分片中数据发生改变的时候，缓存自动失效 通过 GET /_stats/query_cache(request_cache,fielddata)?human 或者 GET /_nodes/stats/indices/query_cache(request

概要 上一篇中多次提到了按相关性评分，本篇我们就来简单了解一下相关性评分的算法，以及正排索引排序的优势。 评分算法 Elasticsearch进行全文搜索时，Boolean Model是匹配的基础，先用boolean model将匹配的文档挑选出来，然后再运用评分函数计算相关度，参与的函数如我们提到的TF/IDF、Length Norm等，再加上一些控制权重的参数设置，得到最后的评分。 Boolean Model 作为全文搜索的基础，Boolean Model的结果决定文档是否要进行下一步的评分操作，使用AND、OR、NOT这种逻辑操作符来判断查找的文档，整个过程不评分，非常快速地将匹配的文档筛选出来。 由于Elastisearch各个版本相关度评分算法有异同，我们以6.3.1版本的BM25算法为准。 TFNORM/IDF 由Boolean Model之后得到的文档，我们开始计算文档的评分，每个文档的评分取决于每个关键词在文档中的权重，权重我们会从以下几个方面考虑： TFNORM 即词频长度(Term Frequency Norm)，单个term在文档中出现的频率，并结合字段长度，出现次数越高，字段长度越低，分越高，计算公式： tfNorm(t in d) = (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * fieldLength /

1. 背景 通过 Spring Cloud 和微服务 的学习，我们了解到使用Spring Cloud实现微服务的架构基本成型，大致是这样的： 我们使用Spring Cloud Netflix中的Eureka实现了 服务注册中心 以及服务注册与发现；而服务间通过 Ribbon 或Feign实现服务的消费以及均衡负载。为了使得服务集群更为健壮，使用 Hystrix 的熔断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。 在该架构中，服务集群包含：内部服务Service A 和 Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块，直接暴露我们的服务地址，这样的实现是否合理，或者是否有更好的实现方式呢？ 先来说说这样的架构需要做的一些事儿以及存在的不足： • 破坏了服务无状态特点。 为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。 从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外考虑对接口访问的控制处理。 • 无法直接复用既有接口。 当我们需要对一个即有的集群内访问接口，实现外部服务访问时

0、题记 Elastic中文社区和各种Elastic爱好者交流群中会遇到形形色色的问题。 来自运维球友讨论的真实线上吐槽问题总结： 问题1：开发不规范。 我们这边es 都是我们在推,很多开发不会用或者用的不规范！ 问题2：不管性能，用起来再说！ 场景1：我们这边开发只要work，管他wildcard，能模糊就好，管他内存，windows size死命地设，不管多少页都让它翻。 问题3：不评估可行性和高可用性，先搞起来。 场景1, 我们还在2.x，这些开发的大爷可以把size给你堆几万！ 场景2, 那你叫产品看百度嘛，你搜个东西，前几页就有你想要的，会不会翻到10页以后？ 场景3, 对嘛，好多公司都是后台开发用ES，也许是为了缓解MySQL其他库的查询压力就不管ES这边的性能效率了，几万条数据都往回吐。 如下图，某公司26岁的程序员王某的Elasitcsearch一把梭用法，能很形象的说出了问题产生的根因。 这里引发大家思考：Elasticsearch到底是不是一把梭，用起来再说？！还是有更好的方式？ 快速部署、快速增删改查、快速上线就完了吗？遇到问题怎么办？ 我把常见问题总结为常见的坑，希望您实战中能避免踩坑。 1、坑1：不重视安全。 2019年12月初安全事件《Elasticsearch27亿数据泄露，10亿明文，波及中国大厂》。看到类似自媒体标题就很容易让人恐慌