芯片短缺重创欧洲汽车市场！ 7月和8月的销量出现了两位数的百分比下降
06-08
概述elasticsearch设计的理念是分布式搜索引擎。底层实现仍然基于Lucene。
核心思想是在一台多态机器上启动多个es进程实例，形成一个es集群。 ES的基本概念 1.集群（cluster） 集群是由多个节点（服务器）组成的。
所有节点将您的所有数据保存在一起，并使用节点集合的联合索引和搜索功能。每个集群都有一个唯一的名称标识 2. 节点（node） 节点是单个服务器，它是集群的一部分，存储数据并参与集群和搜索功能。
节点可以通过配置特定的名称来加入特定的集群。在集群中，您可以启动任意数量的节点。
3.索引（index） 索引是具有某些共同特征的文档的集合。一个索引由一个名称唯一标识，这个名称被索引Document用来执行搜索、更新和删除操作 4.类型（type） 6.0及以上版本不再建议使用type，默认为_doc5。
文档（document） 文档是基本的搜索单位 总结：es中存储数据的基本单位是索引。例如，如果你想在es中存储一些订单数据，你应该在es中创建一个索引order_idx。
所有订单数据都会写入该索引。索引几乎相当于mysql。
一张桌子的。索引 -> 类型 -> 映射 -> 文档 -> 字段。
索引相当于mysql中的表。在es的高版本中，不再推荐使用type（es7。
mapping就是这个type的表结构定义，定义了这个表的字段和类型。你在索引中写入一个type的一条数据是一个文档代表mysql中一个表的一行，每个文档有多个字段，每个字段代表一个文档的字段值。
扩展和高可用的概念 ES 默认为一个索引创建 5 个主分片，并为其分别创建一个副本分片。也就是说，每个索引由5个主分片花费，每个主分片都有一个对应的副本1。
搜索中存储在分片中的数据可能会超出单个节点硬件的存储限制。为了解决这个问题，elasticsearch提供了分片功能，可以将索引分为多个分片。
创建索引时，您可以简单地定义所需的分片数量。每个分片本身都是一个功能齐全且完全独立的索引，可以部署到集群中。
中的任意节点。 2、复制（replica） 在网络情况下，随时都可能发生故障，需要故障恢复机制。
为了实现这一目的，ES 允许您在网络中制作一个或多个副本，称为复制分片或临时副本。 Replica主要解决以下两个问题：（1）高可用性：提供高可用性，防止分片或节点宕机。
因此，需要注意的一个非常重要的点是永远不要在其旁边放置分片的副本。 (2) 该分片在同一台机器上的高并发性：它允许您的分片提供超出其自身吞吐量的搜索服务，并且搜索行为可以在该分片的所有副本上并行执行。
简而言之，一个完整的过程就是ES客户端向主分片写入一条数据，主分片会将其分为成对的分片分片并复制数据。当 ES 客户端检索数据时，会在副本或主分片中读取。
ES集群有多个节点，其中一个节点会自动选举为主节点。这个主节点实际上做了一些管理操作，比如维护元数据，并负责切换主分片和副本分片的身份。
如果主节点宕机了，那么下一个节点会重新选举为主节点。如果master宕机了，就会有一个主节点，宕机节点上的主分片的身份会转移到副本分片上。
如果宕机的机器修复了，重启后，主节点会控制丢失副本分片的分配，同步后续修改，使集群恢复正常。es读写流程及原理 es写数据流程 客户端选择一个节点向其发送请求。
这个节点就是协调节点（coordinating node），它对文档进行路由，并将请求转发到实际节点上的相应节点。主分片处理请求，然后将数据同步到副本节点协调节点。
如果发现主节点和所有副本节点都完成了，就会向客户端es返回写入数据的请求。底层原理是先将数据写入缓冲区，然后在缓冲区内的数据是无法被搜索到的。
同时，数据被写入translog日志文件。如果缓冲区快满了，或者一定时间后，内存缓冲区数据会刷新到新的段文件中，但此时数据不是直接进入段文件磁盘文件，而是先进入os 缓存。
这个过程就是刷新。 （在操作系统中，磁盘文件其实有一个叫做os cache的东西，就是操作系统缓存。
也就是说，数据在写入磁盘文件之前，会先进入os缓存和操作时的内存缓存）系统层面只要通过刷新操作将缓冲区中的数据刷新到os缓存中，就可以搜索到这个数据）每一秒，es都会将缓冲区中的数据写入一个新的段文件，一个新的段。文件每秒生成一次。
磁盘文件段文件，该段文件存储最近1秒写入缓冲区的数据。但如果此时缓冲区中没有数据，那么当然不会执行刷新操作。
如果缓冲区中有数据，则默认每秒执行一次刷新操作，并刷新一个新的段文件。 （es为什么叫准实时？NRT，全称是近实时，默认是1秒刷新一次，所以es是准实时的，因为写入的数据1后才能看到第二，可以使用es Restful API或者Java API，手动执行刷新操作，即手动将buffer中的数据刷新到os缓存中，这样就可以立即查找到数据。
只要有数据输入到os cache中，buffer就会被清空，因为不需要保留buffer，并且数据在translog中已经持久化到磁盘了。 ）重复上述步骤，新的数据不断进入buffer和translog，buffer数据不断被陆续写入新的segment文件中。
每次刷新后，缓冲区都会被清除，并保留传输日志。随着这个过程的进行，translog 将变得越来越大。
当translog达到一定长度时，会触发commit操作。提交操作的第一步是将缓冲区中现有的数据刷新到os缓存并清除缓冲区。
然后，向磁盘文件写入一个提交点，该提交点标识了该提交点对应的所有段文件，同时将当前os缓存中的所有数据强制fsync到磁盘文件中。最后，清除现有的translog日志文件并重新启动translog。
此时commit操作就完成了。这个提交操作称为刷新。
默认情况下，每30分钟自动执行一次flush，但如果translog太大，也会触发一次flush。 Flush操作对应着整个commit过程。
我们可以通过es api手动执行flush操作，将os缓存中的数据手动fsync到磁盘。 translog 日志文件的用途是什么？在执行提交操作之前，数据要么保留在缓冲区中，要么保留在操作系统缓存中。
缓冲区和操作系统缓存都是内存。一旦机器死掉，内存中的所有数据都会丢失。
因此，需要将数据对应的操作写入专门的日志文件translog中。一旦机器崩溃并再次重启，es会自动读取translog日志文件中的数据，并将其恢复到内存缓冲区和os缓存中。
。Translog实际上是先写入os缓存的。
默认情况下，每 5 秒刷新一次到磁盘。因此，默认情况下，5秒的数据可能只保留在缓冲区或translog文件的os缓存中。
如果机器挂了，5秒的数据就会丢失。不过，这种方式性能更好，最多会丢失 5 秒的数据。
也可以设置translog，让每次写操作都要直接fsync到磁盘，但性能会差很多。 （这里有一种情况：es是准实时的，数据写入后1秒就可以查找到；数据可能会丢失。
有5秒的数据停留在buffer、translog os cache、segment file os缓存中，并且不在磁盘上，如果此时机器宕机，会导致5秒的数据丢失）数据写入段文件后，同时建立倒排索引。删除/更新数据的基本原理。
如果是删除操作，commit时会生成一个.del文件，该文件会将某个doc标记为已删除。然后在搜索时，根据.del文件就可以知道该doc是否被删除了。
如果是更新，操作就是将原来的doc标记为删除，然后写入一条新的数据。每次刷新缓冲区时，都会生成一个段文件，因此默认情况下每秒生成一个段文件。
这样，segment文件就会越来越多，并且会定期执行merge。每次合并时，多个段文件将合并为一个。
同时，标记为已删除的doc将被物理删除，然后将新的segment文件写入磁盘。这里会写入一个提交点来标识所有新的段文件，然后打开该段文件供搜索使用，并删除旧的段文件。
数据读取过程可以通过doc id查询。文档 ID 将被散列以确定当时将文档 ID 分配给哪个分片，并且将从该分片执行查询。
客户端向任意节点发送请求，该节点成为坐标节点。协调节点对doc id进行hash路由，将请求转发到对应节点。
此时，使用循环随机轮询算法来随机选择主分片及其所有副本中的doc ID。选择其中之一，让读请求负载均衡器接收到请求的节点将文档返回给坐标节点。
坐标节点在查找数据的过程中将文档返回给客户端。客户端向坐标节点发送请求。
协调节点将搜索请求转发给所有分片。相应的主分片或副本分片可以是查询阶段：每个分片将提供自己的搜索结果。
（实际上是一些doc id）返回到协调节点，协调节点进行数据合并、排序、分页等操作，并产生最终的结果获取阶段：然后协调节点根据doc id从各个节点拉取实际的文档数据。 ，最后返回给客户端倒排索引。
在搜索引擎中，每个文档都有一个对应的文档ID，文档内容被表示为一组关键词。例如，对文档1进行分词，提取20个关键词。
每个关键词都会记录它在文档中出现的次数和位置。那么，倒排索引就是关键词（词段）到文档ID的映射。
每个关键字对应一系列文件，关键字出现在这些文件中。如果文档如下： DocIdDoc1 谷歌地图之父跳槽到 Facebook2 谷歌地图之父加入 Facebook 3 谷歌地图创始人 Lars 离开谷歌加入 Facebook 4 谷歌地图之父跳槽 Facebook 与 Wave 取消有关项目5 谷歌地图之父Lars加入社交网站Facebook 对文档进行分片后，我们得到如下的倒排索引。
WordIdWord————1 Google 2 地图 3 父亲 4 跳槽 5 Facebook 6 Join 7 Founder 8 Russ 9 Leave 10 用 es 提高查询效率 文件系统缓存 写入 es 的数据实际上是写入磁盘文件。查询时，操作系统会自动将磁盘文件中的数据缓存到文件系统缓存中。
ES搜索引擎严重依赖底层文件系统缓存。如果给文件系统缓存更多的内存，请尝试使内存能够容纳所有 id。
段文件索引数据文件，那么你搜索的时候，基本都会用到内存，而且性能会很高。如果用磁盘的话，肯定要秒，搜索性能肯定是秒级的，1秒，5秒，10秒。
但如果使用filesystem cache，也就是纯内存，那么一般来说，性能比磁盘高一个数量级，基本都是毫秒级的，从几毫秒到几百毫秒不等。如果你想充分利用文件系统缓存空间，你只需要存储一些常用的检索字段。
其他不太常用的字段存储在mysql或hbase中。常用的是使用es+hbase架构来写入es。
数据最好小于或等于或稍大于ES的文件系统缓存的内存容量。那么你从es中检索可能需要20ms，然后根据es返回的id查询hbase将需要30ms。
检查20条数据也可能需要30ms。如果1T数据全部存储在ES中，每次查询需要5~10s。
数据预热：如果数据太大，远远超出文件系统缓存，可以使用数据预热。比如拿微博来说，你可以把一些平时很多人查看的大V数据，提前在后台自己做一下。
在这个系统中，每隔一段时间，其后端系统就会搜索热数据并将其刷新到文件系统缓存中。当用户稍后真正查看热门数据时，直接从内存中搜索，速度非常快。
或者对于电子商务，您可以在后台针对一些浏览次数最多的产品（例如iPhone 8）的热门数据创建一个程序，并每1分钟主动访问一次，然后将其刷新到文件系统缓存中。对于那些你认为比较热、人们经常访问的数据，最好构建一个专门的缓存预热子系统，也就是说每隔一段时间就提前访问一下热数据，以便数据能够进入文件系统缓存。
这样下次别人访问的时候表现就会更好。冷热分离es可以做类似mysql的水平拆分，即对访问量很少且频率很低的数据单独写一个索引，然后对访问频繁的热点数据写一个单独的索引。
最好将冷数据写入一个索引，然后将热数据写入另一索引。这样可以保证热数据预热后，尽量将它们保留在文件系统os缓存中，防止冷数据被刷新。
失去。文档模型设计对于MySQL来说，我们经常会有一些复杂的相关查询。
es怎么玩？ es中尽量不要使用复杂的相关查询。一旦使用，性能一般都不是很好。
最好先在Java系统中完成关联，将关联数据直接写入es中。搜索时，不需要使用es的搜索语法来完成join等关联搜索。
文档模型设计非常重要。有很多操作。
不要试图仅在搜索时执行各种复杂而混乱的操作。 es 能支持的操作就这么多。
不要考虑用es来做一些不好操作的事情。如果有这样的操作，尽量在设计和编写文档模型时完成。
另外，一些过于复杂的操作，例如连接/嵌套/父子搜索等，应尽量避免，因为性能会很差。分页性能优化 ES分页有点棘手，为什么？例如，如果每页有10条数据，并且要查询第1页，那么实际上会将每个分片上存储的先前数据检查到协调节点。
如果你有5个分片，那么就有一条数据，然后协调节点对这条数据进行一些合并和处理，然后得到页面上最终的10条数据。它是分布式的。
如果要查第1页的10条数据，不可能从5个分片中每个分片查2条数据吧？最后在协调节点合并成10条数据？你必须检查每个分片的数据，然后根据你的需求进行排序、过滤等，最后再次分页以获取第一页的数据。当你翻页时，翻得越深，每个分片返回的数据就越多，协调节点处理的时间就越长，这是非常令人沮丧的。
所以当你用es进行分页时，你会发现越往后翻就越慢。解决办法是：不允许深度分页（深度分页性能很低），类似于app中不断一页一页下拉的推荐商品。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-06
06-18
06-18
06-21
06-17
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用