暂时未有相关云产品技术能力~
暂无个人介绍
Elasticsearch基础但非常重要的功能还有哪些? 0,有安全比裸奔重要! 1,模板template比mapping重要。 2,显式映射 strict mapping比隐式mapping重要! 3,别名重要! 4,结合业务选择甚至自定义分词器比使用默认重要! 请留言写下您的思考。 https://t.zsxq.com/MrjQrfM
微信群里的线上实战问题: 诸位大哥,es中: keyword类型的字段进行高亮查询,值为 123asd456,查询 sd4,高亮结果是 em 123asd456 em 有没有办法只对我查询的sd4高亮? 明明查询id的一部分,却高亮结果是整个id串,怎么办? 死磕Elasticsearch技术微信群
1、期望Elasticsearch搜索结果更准确,不可回避的三个问题 问题1:用户真正的需求是什么? 如果不能获得用户的搜索意图,搜索的准确性无从谈起。 比如:同样输入“锤子”,工匠期望的是钉子对应的“锤子”,老罗的粉丝期望的是“锤子科技”、“锤子便签”、“锤子手机”等。 即使同一用户发出的同一个查询,也可能因为用户所处场景不同,其期望结果也存在很大差异。
percolator query 大家肯定在文档中见过,但实际业务中则较少用到。 本文探究一下percolator query的使用方法、原理、适用场景。
随着 Elastic 的上市,ELK Stack 不仅在 BAT 的大公司得到长足的发展,而且在各个中小公司都得到非常广泛的应用,甚至连“婚庆网站”都开始使用 Elasticsearch 了。随之而来的是 Elasticsearch 相关部署、框架、性能优化的文章早已铺天盖地。 初学者甚至会进入幻觉——“一键部署、导入数据、检索&聚合、动态扩展, So Easy,妈妈再也不用担心我的 Elastic 学习”! 但,实际上呢?仅就 Elasticsearch 索引设计,请回答如下几个问题:
实战中经常遇到的问题: 问题 1:请问下大家是如何评估集群的规模?比如数据量达到百万,千万,亿万,分别需要什么级别的集群,这要怎么评估? ps:自己搭建的测试环境很难达到这一级别。
现在几乎网上所有资料都说数据存储在传统数据库,再在 es 中同步一份数据作为检索使用,但是也都没有很详细的说明为什么要这么做,而且在 es 本身可以存储数据的情况下,存储两份数据是不是没有必要?还会引起别的问题。 虽然收费而且支持的语法不完全,但是在现在 es 已经支持 sql 的情况下,我越来越搞不清楚 es 和数据库之间的界限。 es 不支持事务但是能够确保单条数据的写入,这样事务可以通过代码实现。很难进行联合查询可以像其他 nosql 一样用宽表实现。实时性可以通过配置调整,而在扩展性能和复杂统计上肯定 es 更优。 基于以上疑问,请问现阶段 es 与数据库的区别或者说界限到底在哪
1、 引言 业务场景1:数据量非常大,需要进行索引生命周期管理,按日期划分索引,要求多个索引的Mapping一致,每次手动创建或者脚本创建都很麻烦! 怎么破? 业务场景2:实际业务多个索引,想让多个索引中的相同名字的字段类型完全一致,以便实现跨索引检索。怎么破?
1、问题引出 ES中文社区中,有如下问题: 问题1:存储数据,data目录从一个机器直接移到一台新的机器是否可以直接使用? 问题2:es升级时,data目录如果在外部路径,从低版本升级到高版本时,data目录是否直接可以使用? 问题3:将一个旧的es数据(400多G)迁移到新的es中的时候直接将旧es的data目录下indices文件拷贝到新es的data下(大概花了一个晚上),这种做法是否可取?
背景:大家知道elasticsearch早期版本安全部分收费(7.1 & 6.8 版本之前),实际中各个公司6.x,5.x,2.x,1.x都有在用,且非少数。 群随机投票结果如下:
Elasticsearch实战数据量级少的时候,单节点就能玩的很6,但是随着数据量的增长,多节点分布式横向扩展集群是大势所趋。 之前分享过基于时间创建索引及Curator实现索引生命周期管理。 当集群硬件资源有限,尤其SSD磁盘更紧俏的业务场景下,最大化集群的性能,如何让用户最关心的“热”数据分布到SSD磁盘对应的节点上,
除了官方文档,其他能找到的介绍Elasticsearch脚本(Scripting)的资料少之又少。 一方面:性能问题。 官方文档性能优化中明确指出使用脚本会导致性能低; 另一方面:使用场景相对少。 非复杂业务场景下,基础的增、删、改、查基本上就能搞定。 但,不能否认,在解决复杂业务问题(如:自定义评分、自定义文本相关度、自定义过滤、自定义聚合分析)时,脚本依然是Elasticsearch强悍的利器之一。
Elasticsearch是非常灵活且功能丰富的搜索引擎,它提供了许多不同查询数据的方法。在实战业务场景中,经常会出现远远低于预期查询速度的慢查询。作为分布式系统的Elasticsearch,可能有各种影响查询性能的因素,包括外部因素,如负载均衡设置,网络延迟(带宽,NIC卡/驱动程序)等。 本文主要讨论可能导致慢查询的原因以及如何在Elasticsearch的上下文中识别它们? 本文主要源于常见慢查询故障的排除方法,阅读本文的前提需要你对Elasticsearch的原理有大致的了解。 如果不了解Elastic相关原理,可以移步:elastic.blog.csdn.net 或 历史文章。
以下两个导出问题来自Elastic中文社区。 问题1、kibana怎么导出查询数据? 问题2:elasticsearch数据导出 就像数据库数据导出一样,elasticsearch可以么? 或者找到它磁盘上存放数据的位置,拷贝出来,放到另一个es服务器上或者转成自己要的数据格式?
在当今世界,各行各业每天都有海量数据产生,为了从这些海量数据中获取想要的分析结果,需要对数据进行提取、转换,存储,维护,管理和分析。 这已然远远超出了普通处理工具、数据库等的实现能力,只有基于的分布式架构和并行处理机制的大数据工具所才能实现这些功能。 Elasticsearch是响应如前所述大多数用例的最热门的开源数据存储引擎之一。
本文建立在干货 | Logstash Grok数据结构化ETL实战上,并专注于在Grok中使用自定义正则表达式。 有时Logstash没有我们需要的模式。 幸运的是,我们有正则表达式库:Oniguruma。 Oniguruma是一个灵活的正则表达式库。 它包含多种语言的不同正则表达式实现的特性。 Github地址:https://github.com/kkos/oniguruma
日志分析是ELK起家的最核心业务场景之一。 如果你正在使用Elastic Stack并且正尝试将自定义Logstash日志映射到Elasticsearch,那么这篇文章适合您。 Logstash写入ES之前的中间数据处理过程一般叫做:数据ETL或者数据清洗。 本文重点介绍数据清洗环节的非结构数据转化为结构化数据的——Grok实现。
如何做一次Elasticsearch技术分享?
1、 做搜索容易,做好搜索相当难。 这是 Elastic 大佬 Wood 大叔在《熟练使用ES离做好搜索还差多远?》的回复。当时看到回复后,感觉振聋发聩。 的确,经常在涉及检索的方案选型的时候,会听到:“不就是检索吗?上 ES 就搞定了”。
1、问题引出 来自星球同学的提问: “Ingest node什么场景会遇到它? 一直没搜到它是在什么场景工作的?” 的确我们比较关心集群的节点角色的划分。包括: 集群应该几个节点? 几个节点用于数据存储? 要不要独立Master节点、协调节点? 但是Ingest node的场景用的比较少。
Elastic社区主席M大、Elastic源码解析书作者超哥都曾多次强调Elastic日报是非常好的学习资料,然后呢? Elastic日报自2017年7月30日发布第一篇文章,截止2019年6月6日,近10位责任编辑累计贡献了1653篇文章。 日报分散在社区文章专区,全部看完至少需要翻页40次+(每页18条数据,还需要过滤掉非日报文章),检索相对不方便。 能不能把Elastic日报爬取并导入Elasticsearch,借助ELK实现分析呢? 好想法,开搞!很期待~~
本文是系列文章第一篇。介绍Elasticsearch的一些非常基础但实战开发确非常有用的技术点。了解这些技术点会帮助你设计更易于维护的数据索引,预先知道PB级大数据索引实战中的坑,提升工作效率。 本文从别名分类、索引别名实践、索引别名的好处、索引别名常见问题及坑解读、字段别名实践一把五个方面进行详细解读。
2019年5月21日,Elastic官方发布消息: Elastic Stack 新版本6.8.0 和7.1.0的核心安全功能现免费提供。 这意味着用户现在能够对网络流量进行加密、创建和管理用户、定义能够保护索引和集群级别访问权限的角色,并且使用 Spaces 为 Kibana 提供全面保护。 免费提供的核心安全功能如下: 1)TLS 功能。 可对通信进行加密; 2)文件和原生 Realm。 可用于创建和管理用户; 3)基于角色的访问控制。 可用于控制用户对集群 API 和索引的访问权限; 通过针对 Kibana Spaces 的安全功能,还可允许在Kibana 中实现多租户。
0、监控Elasticsearch集群的重要性 Elasticsearch具有通用性,可扩展性和实用性的特点,集群的基础架构必须满足如上特性。合理的集群架构能支撑其数据存储及并发响应需求。相反,不合理的集群基础架构和错误配置可能导致集群性能下降、集群无法响应甚至集群崩溃。 适当地监视群集可以帮助您实时监控集群规模,并且可以有效地处理所有数据请求。 本文我们将从五个不同的维度来看待集群,并从这些维度中提炼出监控的关键指标,并探讨通过观察这些指标可以避免哪些潜在问题。
实际业务场景中,会遇到基础数据存在Mysql中,实时写入数据量比较大的情景。 迁移至kafka是一种比较好的业务选型方案。
来自星友的一个真实业务场景问题: 我现在的业务需求是这样的。有一个作者字段,比如是这样的Li,LeiLei;Han,MeiMei;还有一些是LeiLei Li...。 现在要精确匹配。 我的想法是:用自定义分词通过分号分词。但是这样我检索Li,LeiLei那么LeiLei Li就不能搜索到,我希望的结果是LeiLei Li也被搜索到 而且这种分词,Li,LeiLei不加逗号,也不能匹配到。但是不知道为什么我在mapping里面添加停用词也不管用?
Elasticsearch多表关联问题是讨论最多的问题之一,如:博客和评论的关系,用户和爱好的关系。 多表关联通常指:1对多,或者多对多。 本文以星球问题会出发点,引申出ES多表关联认知,分析了4种关联关系的适用场景、优点、缺点, 希望对你有所启发,为你的多表关联方案选型、实战提供帮助。
关系型数据库Mysql/Oracle增量同步Elasticsearch是持续关注的问题,也是社区、QQ群等讨论最多的问题之一。 问题包含但不限于: 1、Mysql如何同步到Elasticsearch? 2、Logstash、kafka_connector、canal选型有什么不同,如何取舍? 3、能实现同步增删改查吗? … 本文给出答案。
题记 Elasticsearch 目前被广泛使用,也越来越受到欢迎。一些传统的行业甚至婚庆公司都已经在使用Elasticsearch。 人们喜欢Elasticsearch,不单单因为它的典型特征: 1)易于部署; 2)无需额外的软件即可扩展到数百个节点; 3)内置RESTful API,上手快; 4)开源+更新快+社区相当活跃。
来自Elasticsearch中文社区的问题—— MySQL中表无唯一递增字段,也无唯一递增时间字段,该怎么使用logstash实现MySQL实时增量导数据到es中?
Elasticsearch是被Netflix,微软,eBay,Facebook等Top N 顶级公司使用的搜索引擎。它很容易使用,但从长远来看相对难掌握。在本文中,我们分享了在系统中使用Elasticsearch六个不太明显但非常值得了解的特性。
题记 git上发现了网友总结的Elasticsearch BAT大厂面试题。只有题目,部分有答案,但不全。 正好抽出一些时间一起梳理一下。 既然是面试题,每个人都会有自己的结合业务场景的答案,没有非常标准的答案。 欢迎大家留言拍砖指正。
、痛点 Elasticsearch集群管理中索引的管理非常重要。 数据量少的时候,一个或者几个索引就能满足问题。 但是一旦数据量每天几TB甚至几十TB的增长时,索引的生命周期管理显得尤为重要。
0、题记 Elasticsearch性能优化的最终目的:用户体验爽。 关于爽的定义——著名产品人梁宁曾经说过“人在满足时候的状态叫做愉悦,人不被满足就会难受,就会开始寻求。如果这个人在寻求中,能立刻得到即时满足,这种感觉就是爽!”。 Elasticsearch的爽点就是:快、准、全! 关于Elasticsearch性能优化,阿里、腾讯、京东、携程、滴滴、58等都有过很多深入的实践总结,都是非常好的参考。本文换一个思路,基于Elasticsearch的爽点,进行性能优化相关探讨。
1、题记: Elasticsearch写入流程,网上有视频、笔记等各种版本,本文结合最新官方文档进行重新梳理,节省大家的时间。 思考如下几个问题?
网罗Elasticsearch最佳实践,实际应用场景中常见错误要预知和避免,以最大化提升集群性能。
引言 这是国外培训ppt课程的节选内容。 以下是我们的Core Elasticsearch:Operations课程中的一些很棒的幻灯片,它们有助于解释分片分配的概念。 我们建议您更全面地了解这一点,但我会在此提供我们培训的概述: 分片分配是将分片分配给节点的过程。 这可能发生在初始恢复,副本分配,重新平衡或添加或删除节点期间。 大多数时候,你不需要考虑它,这项工作是由Elasticsearch在后台完成的。 如果您发现自己对这些细节感到好奇,本文将探讨在几种不同情况下的分片分配。 由于是图解,为方便阅读,我分了4篇文章逐一呈现。
1、问题抛出 1.1 新增节点问题 我的群集具有黄色运行状况,因为它只有一个节点,因此副本保持未分配状态,我想要添加一个节点,该怎么弄?
0、概要 在Elasticsearch实战场景中,我们或多或少会遇到嵌套文档的组合形式,反映在ES中称为父子文档。 父子文档的实现,至少包含以下两种方式: 1)父子文档 父子文档在5.X版本中通过parent-child父子type实现,即:1个索引对应多个type; 6.X+版本已经不再支持一个索引多个type,6.X+的父子索引的实现改成Join。 2)Nested嵌套类型
使用Elasticsearch的过程中,除了全文检索,或多或少会做统计操作,而做统计操作势必会使用Elasticsearch聚合操作。 类似mysql中group by的terms聚合用的最多,但当遇到复杂的聚合操作时,往往会捉襟见肘、不知所措… 这也是社区中聚合操作几乎每天都会被提问的原因。 本文基于官方文档,梳理出聚合的以下几个核心问题,目的:将Elasticsearch的聚合结合实际场景说透。
题记 刚接触Elasticsearch的朋友,或多或少会遇到一个问题,Elasticsearch在实际公司应用中除了搜索到底能做什么? 本文给出了答案。 除了“You Know, for Search”,Elasticsearch的使用会不断增长和变化。ObjectRocket作为一家托管云计算公司,已经在ObjectRocket平台上提供托管Elasticsearch一段时间了,并且能够看到我们客户之间的一些明确趋势以及他们如何使用该产品。以下是我们在平台上看到的Top5场景用例:
在本文中,我们将研究Elasticsearch的各个部分写入数据目录的文件。我们将查看节点,索引和分片级文件,并简要说明其内容,以便了解Elasticsearch写入磁盘的数据。
1、什么是数据模型? 数据模型是抽象描述现实世界的一种工具和方法,是通过抽象的实体及实体之间联系的形式,用图形化的形式去描述业务规则的过程,从而表示现实世界中事务的相互关系的一种映射。
思维导图 | Elasticsearch加速检索的15个核心建议
1、题记 Elasticsearch开发实战的后期会遇到性能问题,包括:创建索引性能、写入数据性能、检索性能等。网上有很多结合自己实际应用场景的相关优化建议,但“对症下药”才是关键。 实际,官网已经有非常明确的相关优化建议。如果没有实战场景,一些特性的理解可能不到位。为此,我特定将官网建议做了翻译,并加了结合实战开发的通俗理解注释。 此为第一篇:通用优化一般建议。
#1、reindex的速率极慢,是否有办法改善? 以下问题来自社区:https://elasticsearch.cn/question/3782 问题1:reindex和snapshot的速率极慢,是否有办法改善? reindex和snapshot的速率比用filebeat或者kafka到es的写入速率慢好几个数量级(集群写入性能不存在瓶颈),reindex/snapshot的时候CPU还是IO使用率都很低,是不是集群受什么参数限制了reindex和snapshot的速率? reindex不管是跨集群还是同集群上都很慢,大约3~5M/s的索引速率,会是什么原因导致的?
引言 Elasticsearch上海Meetup中ebay工程师提了索引生命周期管理的概念。的确,在Demo级别的验证阶段我们数据量比较小,不太需要关注索引的生命周期,一个或几个索引基本就能满足需要。所以,这也会产生一种假象,认为:“Elasticsearch不就是增删改查,毛毛雨啦”的荒诞的假象。 但是,在实战开发的生产环境中,索引的动态模板设置、索引Mapping设置、索引分片数/副本数设置、索引创建、打开、关闭、删除的全生命周期的管理必须高度关注,做好提前知识储备, 否则,会在开发后期出现由于数据激增暴露架构设计不合理问题,甚至引发分片/节点数据丢失、集群宕机等严重问题。
1、Elasticsearch集群不同颜色代表什么? 绿色——最健康的状态,代表所有的主分片和副本分片都可用; 黄色——所有的主分片可用,但是部分副本分片不可用; 红色——部分主分片不可用。(此时执行查询部分数据仍然可以查到,遇到这种情况,还是赶快解决比较好。
1、题记 Elasticsearch后台程序开发完毕后,相关的ES配置、部署、ES DSL查询、聚合语句也做了优化,但实际客户仍然要求提高QPS,要求保障性能的前提下的很高的并发用户数。 这时候,你能想到的方案是什么呢? 实际调研发现,优选方案是Nginx负载均衡方案。
1、问题 源自星球同学的提问:es如何与hive或mysql结合使用?es不支持事务有什么好的弥补方案吗?