Java搜索工程技术栈

字符过滤器处理初始输入的字符串，可以过滤掉特定的字符，或者转换成自定义的字符分词器分词器把字符串分成单个词条，一个分析器必须有一个唯一的分词器词单元过滤器词条按顺序通过词单元过滤器，词单元过滤器可以修改，添加或者移除词条。例如lowercase过滤器，会把字母全部转换为小写。{{{{...字符过滤器...},{...分词器...},"filter"{...词单元过滤器...},{...分析器...}}}}{{{"filter"{...

作者：empeliu，腾讯 TEG 后台开发工程师微信支付的账单系统是方便用户获取交易记录，针对不同的用户群，账单也分为三类：个人账单：针对普通用户群，这类用户特点是基数大，单个用户数据量小，使用账单系统主要是获取列表以及基础统计；商户账单：针对商户用户群，这类用户特点是基数小，单个用户数据量非常大，使用账单系统主要是获取列表，并且在获取列表时需要支持丰富查询条件；业务账单：针对用户群介于普通用户和商户之间，比如微商或面对面小商户，使用账单系统主要是获取列表以及丰富统计功能；目前账单平台为微信支付的这三类账

对于写索引负载很高但是对搜索性能要求不是很高的场景如日志搜索，采用优秀的写索引策略就显得非常重要了。可以尝试以下几种方法来提升写索引的性能。当有大量的写任务时，使用批量提交是种不错的方案。但是每次提交的数据量为多大时能达到最优的性能，受文件大小、数据类型、网络情况、集群状态等因素的影响。通用的策略如下。（1）批量提交的数据条数一般是根据文档的大小和服务器性能而定的，但是一次批处理的数据大小应从5MB～15MB开始，逐渐增加，直到性能没有提升时才结束。（2）在通过增加一次提交的数量而效果没有显著提升时，则需要

检索响应慢！并发检索用户多时，响应时间不达标卡死了！怎么还没有出结果？怎么这么慢？为啥竞品产品的很快就返回结果了？宕机了等等......这些都与可能检索有关，确切的说和检索性能有关。检索性能的优化涉及知识点比较零散，我以官方文档的检索性能优化部分作为大框架和主线，结合实战经验和咨询经验用通俗易懂的语言做下解读。Elasticsearch 严重依赖文件系统缓存来加快搜索速度。通常，你应该确保至少有一半的可用内存进入文件系统缓存，以便 Elasticsearch 可以将索引的热点区域保留在物理内存中。线上环境还

本文将会介绍 Elasticsearch 向量搜索的两种方式。提到向量搜索，我想你一定想知道：向量搜索是什么？向量搜索的应用场景有哪些？向量搜索与全文搜索有何不同？ES 的全文搜索简而言之就是将文本进行分词，然后基于词通过 BM25 算法计算相关性得分，从而找到与搜索语句相似的文本，其本质上是一种 term-based（基于词）的搜索。全文搜索的实际使用已经非常广泛，核心技术也非常成熟。但是，除了文本内容之外，现实生活中还有非常多其它的数据形式，例如：图片、音频、视频等等，我们能不能也对这些数据进行搜索呢？

分页问题是Elasticsearch中最常见的查询场景之一，正常情况下分页代码是如下面这样的：输出结果如下图：很好理解，即查询第一页的条数据。图中数字2即返回的五条文档数据。但是如果我们查询的数据页数特别大，达到什么程度呢？当大于的时候，就会出现问题，如下图报错信息所示：报错信息的解释为当前查询的结果超过了的最大值。那么疑问就来了，明明只查询了5条数据，为什么它计算最大值要加上我from的数量呢？而且Elasticsearch不是号称PB及数据秒级查询，几十亿的数据都没问题，怎么还限制最大查询前100

ES在主节点上产生分歧，产生多个主节点，从而使集群分裂，使得集群处于异常状态。这个现象叫做脑裂。脑裂问题其实就是同一个集群的不同节点对于整个集群的状态有不同的理解，导致操作错乱，类似于精神分裂举个栗子：下图是一个有两个节点的elasticsearch集群。集群维护一个单个索引并有一个分片和一个复制节点。节点1在启动时被选举为主节点并保存主分片（在下面的schema里标记为0P），而节点2保存复制分片（0R）这时如果在两个节点之间的通讯中断了（网络问题或只是因为其中一个节点无响应（例如stop-the-wor

前言Elasticsearch 是一个实时的分布式搜索与分析引擎，在使用过程中，有一些典型的使用场景，比如分页、遍历等。在使用关系型数据库中，我们被告知要注意甚至被明确禁止使用深度分页，同理，在 Elasticsearch 中，也应该尽量避免使用深度分页。这篇文章主要介绍 Elasticsearch 中分页相关内容！From/Size参数在ES中，分页查询默认返回最顶端的10条匹配hits。如果需要分页，需要使用from和size参数。 from参数定义了需要跳过的hits数，

目录序言一、案例描述1、背景描述2、优化设置二、ES技术原理1、global ordinals2、doc values3、cross index search三、OLTP与OLAP1、应用形态之争2、技术形态之争结语作者介绍李猛，数据领域专家，Elastic Stack国内顶尖实战专家，国内首批Elastic官方认证工程师21人之一。2012年入手Elasticsearch，对Elastic Stack技术栈开发、架构、运维、源码、算法等方面有深入

在双十一时，有用户反馈推广平台物料列表出现了耗时严重的情况。筛选排序系统出现过耗时严重的情况，根据业务系统的筛选排序慢接口的traceId, 我们分析了一下请求链路上的瓶颈是ES.问题排查首选我们在监控平台上确认了一下ES的访问流量，发现流量曲线变化不大，说明不是ES读请求压力突增导致的。接着我们看了ES的bigdesk监控，发现有不少Full GC，与此同时查看了GC日志，发现日志里有比较频繁的CMS。然后分析了下日志的内容，发现cms remark这个阶段时间特别长，甚至有3-5s的情况

目录一、配置文件调优内存锁定zen.discovery故障检测（ fault detection ）队列数量内存使用创建shard二、系统层面调优jdk版本jdk内存配置交换分区文件句柄mmap磁盘磁盘挂载磁盘其他注意事项三、elasticsearch使用方式调优hot_threadspending_tasks字段存储translogrefresh_interval禁止动态mapping批量写入索引和shar

一、什么是 ES Nested 嵌套Elasticsearch 有很多数据类型，大致如下： 基本数据类型： string 类型。ES 7.x 中，string 类型会升级为：text 和 keyword。keyword 可以排序；text 默认分词，不可以排序。 数据类型：integer、long 等 时间类型、布尔类型、二进制类型、区间类型等 复杂数据类型： 数组类型：Array 对象类型：Object

17.ElasticSearch 复合查询17.1 constant_score query当我们不关心检索词项的频率（TF）对搜索结果排序的影响时，可以使用 constant_score 将查询语句或者过滤语句包裹起来。GETbooks/_search{"query":{"constant_score":{"filter":{"term":{"name":"java"}},...

本篇文章不是讲ElasticSearch（下面简称ES）聚合分析的基本概念和用法的，这些网上的资料很多，不清楚的可以自行查阅。我下面聚合分析使用的数据都是kibana自带的，这样方便有些读者实际测试文中的示例。基本概念ES为了满足搜索的实时性，在聚合分析的一些场景会通过损失精准度的方式加快结果的返回。这其实ES在实时性和精准度中间的权衡。需要明确的是，并不是所有的聚合分析都会损失精准度，比如min,max等这些就没有精准度的问题。可能这样直接说不好理解，下面会有详细的分析。问题描述

我本人接触Elasticsearch（一下简称ES）有挺长一段时间了，本文结合自己的一些项目经验，给你总结几个实际项目中比较容易踩到的坑。希望读者能够避免犯这样的错误。坑一，时区问题在我们的项目中，索引下一般都会存在一个时间的字段，这个字段可以用来排序，或者做时间范围查询，或者聚合的场景等都会用到。ES底层默认采用UTC时间格式，而中国的时间(CST)是CST=UTC+8所以实际的项目中经常遇到查询结果和自己期望的不一致。关于时区的问题以及如何解决，我之前专门写了一篇文章，感兴趣的可

需求背景很多时候mysql的表之间是一对多的关系，比如订单表和商品表。一笔订单可以包含多个商品。他们的关系如下图所示。ElasticsSearch（以下简称ES）处理这种关系虽然不是特别擅长（相对于关系型数据库），因为ES和大多数 NoSQL 数据库类似，是扁平化的存储结构。索引是独立文档的集合体。不同的索引之间一般是没有关系的。不过ES目前毕竟发展到7.x版本了， 已经有几种可选的方式能够高效的支持这种一对多关系的映射。比较常用的方案是嵌套对象，嵌套文档和父子文档。后两种是我们本.

目录面试题面试官心理分析面试题剖析性能优化的杀手锏——FileSystem Cache数据预热冷热分离document 模型设计分页性能优化面试题es 在数据量很大的情况下（数十亿级别）如何提高查询效率啊？面试官心理分析这个问题是肯定要问的，说白了，就是看你有没有实际干过 es，因为啥？其实 es 性能并没有你想象中那么好的。很多时候数据量大了，特别是有几亿条数据的时候，可能你会懵逼的发现，跑个搜索怎么一下 5~10s，坑爹了。第一次搜索的时候，是5~10

1.近实时搜索1.1 实时与近实时实时搜索（Real-time Search）很好理解，对于一个数据库系统，执行插入以后立刻就能搜索到刚刚插入到数据。而近实时（Near Real-time），所谓“近”也就是说比实时要慢一点点。1.2 近实时的挑战对于一个单机系统来说，这也并不容易实现，因为还要保证数据的持久化，还要利用缓存等技术加快数据的访问（注：这里不讨论内存计算系统）。对于ElasticSearch这样一个分布式系统，保证持久化的同时，还要初始化好用于全文检索的内部数据结构，做到近实时

目录一、引言二、优化ES Query DSL1. 最初使用的multi_match2. 使用bool 查询的filter 增加筛选3. 使用match_phrase 提高搜索短语的权重4. 使用boost 调整查询语句的权重5. 使用function_score 增加更多的评分因素6. 最终结果三、优化相关性算法四、优化的建议五、使用_explain 做bad case 分析六、结语导语 |Elasticsearch（下文简称ES）是...

1、背景作为一家搜索引擎公司，我们会很倚赖ES帮忙处理包括文章召回，数据源划分，实体、标签管理等任务，而且都收到了不错的结果。最近我们需要对行业知识库进行建模，其中可能会涉及到实体匹配、模糊搜索、向量搜索等多种召回和算分方式，最终我们选择了通过ES 7.X（最终选择 7.10）里的新功能，Dense vector 帮忙一起完成这部分的需求。2、技术选型2.1 解决方案需求 支持向量搜索 支持多维度筛选、过滤 吞吐速率 学习、使用成本 运维...

00 序言Elasticsearch 在 5.3 版本中引入了 Cross Cluster Search（CCS 跨集群搜索）功能，跨集群搜索功能允许任何节点在多个集群之间充当 Federated Client（联合客户端）与 Tribe Node（部落节点）功能相比，进行跨集群搜索的节点将不会加入远程集群，而是以轻量的方式连接到远程集群，以便执行联合搜索请求。如上面所述，当我们的 client 向集群 cluster_1 发送请求时，它可以搜索自己本身的集群，同时也可以向另外的两个集群 clu

导读：以搜索为代表的策略产品经理，日常工作中一样会面临非常多的业务需求和badcase，有目标地满足需求和解决问题是容易的，但往往会面临另一个问题：当没有人提出具体需求时，怎样挖掘新的需求，推动搜索系统正常的迭代和运转？回答这个问题的过程，也是展现一个策略产品经理的思维方式和工作方法的过程。根据实际工作经验总结、需求的挖掘和系统的维护，可以从四个方面入手：从搜索策略的整体架构入手，从用户需求入手，从具体问题入手和从业务发展入手。其中整体架构是策略产品的独有部分，也是我们接下来花大量笔墨着重介绍的部分。