ElasticSearch

在早期版本的 ES 中，节点角色划分其实还是比较模糊的。但从 7.x 版本开始，特别是到了 8.x，ES 强烈推荐并默认使用基于角色的节点分工，来优化集群稳定性。 官方文档中有关于目前支持的node roles的介绍：https://www.elastic.co/docs/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles 目前支持以上这些，挑一些重点介绍下。 Master（主节点） 这是集群的“大脑”，负责管理集群层面的操作。主要用来管理集群状态、创建或删除索引、跟踪其他节点的加入和离开、决定分片（Shard）分配到哪个数据节点上。 一个集群同时只能有一个有效主节点，通过选举产生，避免“脑裂”问题。 主节点不负责与数据文档相关的操作（如索引、搜索），所以它的负载通常不高。 Master-eligible Node（主节点候选节点） 为了集群稳定性，通常会设置多个 主节点候选节点，它们不承担数据节点角色，以确保主节点选举的可靠性和集群管理的稳定性。通常配置为奇数个（如3、5 个） 防止脑裂。 Data Node（数据节点） 存储存储分片（包括主分片和副本分片）中的数据），执行CRUD 操作、搜索、聚合、排序等计算。数据节点是 CPU、内存和 I/O 密集型节点，需要强大的硬件资源。 Data Node还可以根据数据的冷热情况，进一步细分为更多角色： data_hot data_warm data_cold data_frozen Coordinating Node（协调节点） 协调节点，负责接收客户端（如应用程序）的 REST 请求（搜索、写入等）。路由请求到对应 data/master 节点、以及收集各个数据节点的返回结果，进行合并、排序等最终处理，然后将最终结果返回给客户端。 所有节点只要没显式禁用，默认都是 coordinating node Ingest Node（预处理节点） 在索引前对文档进行预处理，可以执行的任务包括：解析 CSV、重命名字段、添加新字段、根据条件删除数据等。 ML Node（机器学习节点） 专用于运行 Elasticsearch 的机器学习（ML）作业。 Remote Cluster Client Node（跨集群搜索节点） 用于跨集群搜索功能。 节点角色配置 可以在elasticsearch.yml中如下方式配置节点角色。 1 2 3 4 5 6 7 8 9 10 # 示例：专用 Master 节点 node.name: master-1 node.roles: [ master ] # 示例：Hot Data 节点 node.name: data-hot-1 node.roles: [ data_hot, data_content ] # 示例：专用协调节点 node.name: coordinat 典型架构 以下是ES中各个角色的关系图，来自Elastic中国官方社区。 ...

典型回答 在 ElasticSearch 中，倒排索引是一种常用的索引结构，用于快速搜索文档中的某个词汇。 倒排索引的结构与传统的索引结构相反，传统的索引结构是由文档构成的，每个文档包含了若干个词汇，然后根据这些词汇建立索引。而倒排索引是由词汇构成的，每个词汇对应了若干个文档，然后根据这些文档建立索引。 对于一个包含多个词汇的文档，倒排索引会将每个词汇作为一个关键字（Term），然后记录下该词汇所在的文档编号（Document ID）及该词汇在文档中的位置（Term Position）。这样，当用户输入一个关键字时，就可以快速地查找到包含该关键字的文档编号，然后通过文档编号再查找到对应的文档内容。 **倒排索引的优点在于它可以快速定位包含关键字的文档，而且可以支持复杂的搜索操作，如词组搜索、通配符搜索等。**同时，由于倒排索引是由词汇构成的，因此在进行数据分析和统计时也非常有用。在 ElasticSearch 中，倒排索引是一种非常重要的索引结构，它被广泛应用于搜索引擎、日志分析、推荐系统等领域。 扩展知识 倒排索引建立过程 ES中的倒排索引建立过程主要有2个步骤，分别是分词、建立倒排索引 比如我们现在有三份文档内容，分别是 id content 1 深入理解Java核心技术—Hollis 2 深入理解Java虚拟机—周志明 3 Java编程思想—布鲁斯·埃克尔 分词 在倒排索引建立过程中，首先需要将文档中的原始文本分解成一个个词项（Term）。Elasticsearch 中默认使用标准分词器（Standard Analyzer）进行分词。 以上三个文本内容，我们经过分词之后，就会包含了"深入"、“理解”、“Java”、“核心”、“技术”、“编程”、“思想”、“Hollis”、“周志明”、“布鲁斯·埃克尔"等词 生成倒排索引 将分开的词，当做索引，与对应的文档ID进行关联，形成倒排表。 词条 文档ID 深入 1,2 理解 1,2 Java 1,2,3 虚拟机 2 核心 1 技术 1 编程 3 思想 3 在生成了倒排表后，还会对倒排表进行压缩，减少空间占用。常用的压缩算法包括Variable Byte Encoding和Simple9等。最后再将压缩后的倒排表存储在磁盘中，以便后续的搜索操作能够快速地访问倒排表。

典型回答 数据模型 **Elasticsearch 是基于文档的搜索引擎，它使用 JSON 文档来存储数据。**在 Elasticsearch 中，相关的数据通常存储在同一个文档中，而不是分散在多个表中。 **MySQL 是一个关系型数据库管理系统，它使用表、行和列的结构来组织数据。**数据通过外键关系分散在多个表中。 查询语言 Elasticsearch 使用 Query DSL（Domain Specific Language），这是一种非常灵活的查询语言，基于 JSON，支持全文搜索、复合查询、过滤以及聚合等。 MySQL 使用 SQL（Structured Query Language），这是一种强类型和非常成熟的语言，专门用于查询和管理关系数据库。 全文搜索 **Elasticsearch 的核心功能是全文搜索。**它对数据进行索引时会自动建立全文搜索索引，使其在搜索大量文本数据时表现优异。 MySQL 虽然也提供了基本的全文搜索功能，但其主要设计目标是处理结构化数据的存储和查询，对全文搜索的支持不如 Elasticsearch 那样强大。 事务支持 **Elasticsearch 不支持传统的 ACID（原子性、一致性、隔离性、持久性）事务。**虽然它确保了单个文档操作的原子性，但不适用于跨多个文档的复杂事务。 MySQL 支持 ACID 事务，这使得它非常适合需要严格数据一致性的应用，如金融服务和其他商业数据处理。 主要场景和优势 Elasticsearch是一个开源的分布式搜索和分析引擎，主要适用于以下场景： 搜索引擎：用于快速检索文档、商品、新闻等。 日志分析：通过分析日志数据，帮助企业了解其业务的性能情况。 数据分析：帮助数据科学家和数据分析师进行数据分析，以获取有价值的信息。 商业智能：帮助企业制定数据驱动的决策，以实现商业上的成功。 实时监控：帮助企业实时监测系统性能、监控数据变化，以保证系统正常运行。 安全性：帮助企业保证数据的安全性，保证数据不被非法窃取。 应用程序开发：帮助开发人员开发基于搜索的应用程序，以增加用户体验。 Elasticsearch具有以下几个优势： 高性能：Elasticsearch具有高性能的搜索和分析能力，其中涵盖了多种查询语言和数据结构。 可扩展性：Elasticsearch是分布式的，可以通过增加节点数量扩展搜索和分析能力。 灵活性：Elasticsearch支持多种数据类型，支持多种语言，支持动态映射，允许快速地调整模型以适应不同的需求。 实时分析：Elasticsearch支持实时分析，可以对数据进行实时查询，这对于快速检索数据非常有用。 可靠性：Elasticsearch具有可靠性和高可用性，支持数据备份和恢复。

典型回答 Elasticsearch是一个高性能、分布式搜索引擎，它之所以快，主要有以下几个原因： 分布式存储：Elasticsearch使用分布式存储技术，将数据存储在多个节点上，从而减少单个节点的压力，提高整体性能。 索引分片：Elasticsearch把每个索引划分成多个分片，这样可以让查询操作并行化，从而提高查询速度。 全文索引：Elasticsearch使用了高效的全文索引技术，把文档转化成可搜索的结构化数据，使得搜索操作快速高效。 倒排索引：Elasticsearch支持倒排索引这种数据结构，倒排索引将文档中的每个词与该词出现在哪些文档中进行映射，并存储这些信息。当搜索请求发生时，ES可以快速查找包含所有搜索词的文档，从而返回结果。 索引优化：Elasticsearch通过索引优化技术，可以使查询速度更快。例如，它支持索引覆盖、索引下推等优化技术，使得查询速度更快。 预存储结果：Elasticsearch在插入数据时，对数据进行预处理，把结果预存储到索引中，从而在查询时不需要再重新计算，提高查询速度。 高效的查询引擎：Elasticsearch使用了高效的查询引擎，支持各种类型的查询，并对复杂查询提供了优化策略，从而提高查询速度。 异步请求处理：ES使用了异步请求处理机制，能够在请求到达时立即返回，避免长时间的等待，提高用户体验。 内存存储：ES使用了内存存储技术，能够在读写数据时大大减少磁盘访问次数，提高数据存储和查询效率。 总之，Elasticsearch快的原因在于它使用了各种高效的技术，使得数据存储、查询、处理都变得更加高效，从而实现了快速的搜索体验。

典型回答 在业务中，我们通常需要把数据库中的数据变更同步到ES中，那么如何保证数据库和ES的一致性呢？通常有以下几种做法： 双写 在代码中，对数据库和ES进行双写，并且先操作本地数据库，后操作ES，而且还需要把两个操作放到一个事务中： 1 2 3 4 5 6 7 @Transactional(rollbackFor = Exception.class) public void update(OrderDTO orderDTO) { //更新本地数据库 updateDb(orderDTO); //远程更新ES updateEs(orderDTO); } 在以上逻辑中，如果写数据库成功，写ES失败，那么事务会回滚。 如果写数据库成功，写ES超时，实际上ES操作成功，这时候数据库会回滚，导致数据不一致。这时候需要重试来保证最终一致性。 这个方案的好处就是简单，容易实现。并且实时性比较高。 缺点首先是需要改代码，有侵入性，还有就是存在不一致的情况。并且在本地事务中发生了外调（外部调用，调ES），大大拖长了事务，白白占用数据库链接，影响整体的吞吐量。 MQ异步消费 在应用中，如果我要更新数据库了，那么就抛一个消息出去，然后数据库和ES各自有一个监听者，监听消息之后各自去做数据变更，如果失败了就基于消息的重试在重新执行。 或者像之前那个方案一样，先操作数据库，然后异步通知ES去更新，这时候就可以借助本地消息表的方式来保证最终一致性了。 这个方案的好处是用了MQ，起到了解耦的作用，而且还做到了异步，提升了整体性能。 缺点就是MQ可能存在延迟，并且需要引入新的中间件，复杂度有所提升。 扫表定时同步 如果是ES中的数据变更的实时性要求不高，可以考虑定时任务扫表， 然后批量更新ES。 这个方案优点是没有侵入性，数据库的写操作处不需要改代码。 缺点是实时性很差，并且轮询可能存在性能问题、效率问题以及给数据库带来压力。 监听binlog同步 还有一种方案，就是可以利用数据库变更时产生的binlog来更新ES。通过监听binlog来更新ES中的数据，也有成熟的框架可以做这样的事情 好处就是对业务代码完全没有侵入性，业务也非常解耦，不需要关心这个ES的更新操作。 缺点就是需要基于binlog监听，需要引入第三方框架。存在一定的延迟。 总结一下，目前业内比较流行的方案是基于binlog监听的这种，首先一般业务量小的业务也不太需要用ES，所以用了ES的团队，一般并不太会关心引入新框架的复杂度问题，而且ES这种搜索，一般来说，毫秒级的延迟都是可以接受的，所以，综合来讲，基于canal做数据同步的方案，是比较合适的。

典型回答 Elasticsearch支持以下数据类型 Text: 用于存储全文文本数据，如文章或书籍内容。支持全文搜索和分析。 Keyword: 用于存储文本值，通常用于索引结构化内容，如邮件地址、标签或任何需要精确匹配的内容。 Date: 存储日期或日期和时间。 Long, Integer, Short, Byte, Double, Float: 这些是数值类型，用于存储各种形式的数字。 Boolean: 存储 true 或 false 值。 Binary: 用于存储二进制数据。 Object: 用于嵌套文档，即文档内部可以包含文档。 Nested: 类似于 Object 类型，但用于存储数组列表，其中列表中的每个元素都是完全独立且可搜索的。 我们经常会把MySQL 中的数据同步到 ES 中，他们之间的类型的映射关系如下： MySQL 类型 Elasticsearch 类型 说明 VARCHAR text, keyword 根据是否需要全文搜索或精确搜索选择使用 text 或 keyword。 CHAR keyword 通常映射为 keyword，因为它们用于存储较短的、不经常变化的字符序列。 BLOB/TEXT text 大文本块使用 text 类型，支持全文检索。 INT, BIGINT long 大多数整数类型映射为 long，以支持更大的数值。 TINYINT byte 较小的整数可以映射为 byte 类型。 DECIMAL, FLOAT, DOUBLE double, float 根据精确度需求选择 double 或 float。 DATE, DATETIME, TIMESTAMP date 所有的日期时间类型均可映射为 date。 TINYINT(1) boolean 扩展知识 text 和 keyword 有啥区别？ text 类型被设计用于全文搜索。这意味着当文本被存储为 text 类型时，Elasticsearch 会对其进行分词，把文本分解成单独的词或短语，便于搜索引擎进行全文搜索。因为 text 字段经过分词，它不适合用于排序或聚合查询。 ...

典型回答 在Elasticsearch中进行分页查询通常使用from和size参数。当我们对Elasticsearch发起一个带有分页参数的查询（如使用from和size参数）时，ES需要遍历所有匹配的文档直到达到指定的起始点（from），然后返回从这一点开始的size个文档。 1 2 3 4 5 6 7 8 GET /your_index/_search { "from": 20, "size": 10, "query": { "match_all": {} } } 在这个例子中： from 参数定义了要跳过的记录数。在这里，它跳过了前20条记录。 size 参数定义了返回的记录数量。在这里，它返回了10条记录。 from + size 的总数不能超过Elasticsearch索引的index.max_result_window设置，默认为10000。这意味着如果你设置from为9900，size为100，查询将会成功。但如果from为9900，size为101，则会失败。 ES的检索机制决定了，当进行分页查询时，Elasticsearch需要先找到并处理所有位于当前页之前的记录。例如，如果你请求第1000页的数据，并且每页显示10条记录，系统需要先处理前990条记录，然后才能获取到你请求的那10条记录。这意味着，随着页码的增加，数据库需要处理的数据量急剧增加，导致查询效率降低。 这就是ES的深度分页的问题，深度分页需要数据库在内存中维护大量的数据，并对这些数据进行排序和处理，这会消耗大量的CPU和内存资源。随着分页深度的增加，查询响应时间会显著增加。在某些情况下，这可能导致查询超时或者系统负载过重。 所以，需要想办法解决ES的深度分页的问题。 scroll Scroll API在Elasticsearch中的主要目的是为了能够遍历大量的数据，它通常用于数据导出或者进行大规模的数据分析。可以用于处理大量数据的深度分页问题。 1 2 3 4 5 6 7 GET /your_index/_search?scroll=1m { "size": 10, // 每页10条记录 "query": { "match_all": {} } } 如上方式初始化一个带有scroll参数的搜索请求。这个请求返回一个scroll ID，用于后续的滚动。Scroll参数指定了scroll的有效期，例如1m表示一分钟。 ...

典型回答 优化 Elasticsearch（ES）的查询性能涉及多个方面，从查询本身到集群配置和硬件资源。以下是一些关键的优化策略： 集群和硬件优化 负载均衡: 确保查询负载在集群中均衡分配。 硬件资源: 根据需要增加 CPU、内存或改善 I/O 性能（例如使用 SSD）。 配置 JVM: 优化 JVM 设置，如堆大小，以提高性能。 合理分片和副本 虽然更多的分片可以提高写入吞吐量，因为可以并行写入多个分片。但是，查询大量分片可能会降低查询性能，因为每个分片都需要单独处理查询。而且分片数量过多可能会增加集群的管理开销和降低查询效率，尤其是在内存和文件句柄方面。所以，需要考虑数据量和硬件资源，合理设置分片数量。 但是这个说起来比较玄学，毕竟没有一种“一刀切”的方法来确定最优的分片和副本数量，因为这取决于多种因素，包括数据的大小、查询的复杂性、硬件资源和预期的负载等。 在ES每个节点上可以存储的分片数量与可用的堆内存大小成正比关系，但是 Elasticsearch 并未强制规定固定限值。这里有一个很好的经验法则：确保对于节点上已配置的每个 GB，将分片数量保持在 20 以下。如果某个节点拥有 30GB 的堆内存，那其最多可有 600 个分片，但是在此限值范围内，您设置的分片数量越少，效果就越好。一般而言，这可以帮助集群保持良好的运行状态。（来源参考：https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster ） 精确的映射和索引设置 映射（Mapping）是定义如何存储和索引文档中字段的规则。我们可以在以下几个方面做一些优化： 确切定义字段类型：为每个字段指定正确的数据类型（如 text, keyword, date, integer 等），这是因为不同的数据类型有不同的存储和索引方式。需要注意的是：text 类型用于全文搜索，它会被分析（analyzed），即分解为单个词项。keyword 类型用于精确值匹配，过滤，排序和聚合。它不会被分析。 根据需要选择合适的分析器（Analyzer），对于 text 类型的字段，可以指定分析器来定义文本如何被分割和索引。对于不需要全文搜索的字段，使用 keyword 类型以避免分析开销。 查询优化 很多人用ES很慢，是因为自己的查询本身就用的不对，我们可以尝试着优化一下你的查询。如： 避免高开销查询: 如 wildcard、regexp 等类型的查询往往开销较大，尽量避免使用或优化其使用方式。 使用过滤器: 对于不需要评分的查询条件，使用 filter 而不是 query，因为 filter 可以被缓存以加快后续相同查询的速度。 查询尽可能少的字段: 只返回查询中需要的字段，减少数据传输和处理时间。 避免深度分页: 避免深度分页，对于需要处理大量数据的情况，考虑使用 search_after。 避免使用脚本：尽量避免使用脚本（Script）查询，因为它们通常比简单查询要慢。（脚本执行通常比静态查询更消耗资源。每次执行脚本时，都需要进行编译（除非缓存）和运行，这会增加CPU和内存的使用。脚本执行不能利用索引，因此可能需要全面扫描文档。） 使用 term 而非 match 查询文本字段： 一般来说，term 查询比 match 查询快，因为 term 查询不需要对查询内容进行分词。term 查询直接查找精确的值，索引定位效率高。 避免使用通配符、正则表达式：这类查询往往非常消耗资源，特别是以通配符开头的（如 *text）。 合理使用聚合：聚合可以用于高效地进行数据分析，但复杂的聚合也可能非常消耗资源。优化聚合查询，如通过限制桶的数量，避免过度复杂的嵌套聚合。 使用缓存 请求缓存: 对于不经常变化的数据，利用 ES 的请求缓存机制。 清理缓存: 定期清理不再需要的缓存，释放资源。 监控和分析 监控: 使用 Kibana、Elasticsearch-head、Elastic HQ 等工具监控集群状态和性能。 慢查询日志: 启用慢查询日志来识别和优化慢查询。

典型回答 ES 虽然也可以认为是一个数据库，但是他并不支持传统意义上的 ACID 事务，因为 ES它被设计出来是主要用作搜索引擎的，主要是提升查询效率的。如果支持复杂的事务操作意味着就要牺牲性能优势。 **虽然 Elasticsearch 不支持传统的事务，但是他是可以确保单个文档的更改（如创建、更新、删除）是原子性的。**这意味着任何文档级的操作都完整地成功或完整地失败，但不保证跨多个文档或操作的一致性。

典型回答 ✅ES支持哪些数据类型，和MySQL之间的映射关系是怎么样的？ 通过上文我们知道，ES 不支持 decimal 类型的，只有 double、float 等类型，那么，MySQL 中的 decimal 类型，同步到 ES 之后，如何避免丢失精度呢？ 1 price DECIMAL(10, 2) 如以上 price 字段，在 es 中如何表示呢？有以下几种方式： 使用字符串类型（推荐） 将 decimal 数据作为字符串类型存储在 Elasticsearch 中。这种方式可以保证数字的精度不会丢失，因为字符串会保留数字的原始表示形式。 优点：完全保留数字的精度。简单易于实现，数据迁移时不需特别处理。 缺点：作为字符串存储的数字不能直接用于数值比较或数学运算，需要在应用层处理转换。 1 2 3 4 5 6 7 { "properties": { "price": { "type": "keyword" } } } 扩大浮点类型的精度（推荐） 虽然 double 类型在理论上可能会有精度损失，但实际上 double 类型提供的精度对于许多业务需求已经足够使用。如果决定使用这种方法，可以在数据迁移或同步时适当扩大数值范围以尽量减小精度损失。 优点：可以直接进行数值比较和数学运算。 缺点：在非常高精度的需求下可能存在精度损失。 1 2 3 4 5 6 7 { "properties": { "amount": { "type": "double" } } } 使用scaled_float（推荐） Elasticsearch 的 scaled_float 类型是一种数值数据类型，专门用于存储浮点数。其特点是通过一个缩放因子（scaling factor）将浮点数转换为整数来存储，从而在一定范围内提高存储和计算的效率。 ...