Elasticsearch技术

已于 2022-10-19 14:58:05 修改
阅读量893 收藏 4
点赞数 2
文章标签： elasticsearch 搜索引擎 大数据
于 2022-07-25 23:47:52 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_43703196/article/details/125697126
版权

文章目录

一、谈一下Elasticsearch的理解？

1、Elasticsearch的基本概念

  • 基本概念表(对标MySQL)

    概念描述
    index索引等同于MySQL的数据库，存储数据
    type类型等同于MySQL的表结构
    document文档等同于MySQL中的一行数据
    Filed字段Field是Elasticsearch的最小单位，一个document里面有多个field
    shard 分片单台机器无法存储大量数据，es可以将一个索引中的数据切分为多个shard，分布在多台服务器上存储。有了shard就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能；
    replica 副本任何一个服务器随时可能故障或宕机，此时 shard 可能会丢失，因此可以为每个 shard 创建多个 replica 副本

2、什么是倒排索引？

  • Elasticsearch是一个分布式全文检索引擎，底层基于Lucene的倒排索引技术，在底层采用了分段的存储模式，使它在读写时几乎完全避免了锁的出现，大大提升了读写性能，能够实现比关系型数据库更快的过滤与检索，可以近乎实时的进行存储与检索数据；

    索引结构原理优缺点
    正排索引 传统的正排索引(forward index)：是以文档ID(key)作为关键字，正排表中记录文档中每个词项(term)的出现次数与位置信息(value)；

     当搜索时，扫描表中的每个文档中的词项(term)信息，直到找出所有包含了查询关键字的文档，然后返回搜索结果；    		优点： 索引结构简单易维护，删除或建立某个文档索引非常方便；

    缺点： 检索某个关键词时，需要遍历全部的文档，以确保没有遗漏，使得检索时间大大延长，检索效率低；
    倒排索引 倒排索引(invert index)：以词项(term)作为关键字(key)进行索引，倒排表中记录出现了该关键字的文档ID(包括关键字的位置情况)；总结来说：就是把文档ID对应到关键词的映射，转换为了关键词到文件ID的映射；

     当搜索某个关键词key时，
     ① ES首先会将搜索关键词进行分词(规范化和去重)，切分成多个词项(term)；
     ② 然后对于每个词项(term)，查询得到对应的倒排表(Posting List)；再对每个词项的倒排表进行合并或者取交集等操作，获得查询结果；
     ③ 最后对查询结果进行相关性打分 ，进行排序后返回搜索结果；    		优点： 查询的时候能够一次性查询到关键字对应的全部文档，查询效率比正向索引高的多；虽然倒排表不易建立与维护，但是这个过程是在后台进行的，因此不会影响整个搜索引擎的查询效率；

    缺点： 倒排表不易建立与维护；

  • 正排索引结构

    “文档1”的ID > 单词1：出现次数，出现位置列表；单词2：出现次数，出现位置列表；…………。
    “文档2”的ID > 此文档出现的关键词列表。
    在这里插入图片描述

  • 倒排索引结构

    “关键词1”：“文档1”的ID，“文档2”的ID，…………。
    “关键词2”：带有此关键词的文档ID列表。
    在这里插入图片描述

3、什么是全文检索

  • 全文检索与数据查询的区别

    检索类型定位查询方式相关度排序数据结构
    数据查询数据查询侧重高效、安全的存储普通的数据查询是SQL语句实现模糊查询(like)，按照磁盘页的进行遍历查询，随机IO次数多，效率差；有明确的查询边界条件，结果没有相关度排序B+树
    全文检索全文检索侧重准确、方便的搜索全文检索是直接定位关键词所在磁盘页的位置，然后直接读取；全文检索对查询到的结果进行了相关性排序，没有明显的边界条件FST(有限状态转移机)，变种字典树，共享前缀也能共享后缀

4、为什么Elasticsearch/Lucene检索比MySQL快？

  • 或者问为什么不用MySQL作为全文检索引擎？

    MySQLLucene
    磁盘IO层面Mysql只有term dictionary这一层，以B+树的数据结构存储在磁盘中，由于数据存储在B+树的叶子节点中，因此检索一个term词项需要若干次的随机磁盘IO，代价昂贵Lucene底层基于倒排索引技术，在term dictionary的基础上添加了term index来加速检索，term index以树的形式(FST)缓存在内存中。首先在内存term index中查到对应的term dictionary的磁盘块block位置之后，再去磁盘上找term，大大减少了磁盘随机IO的次数；
    数据结构层面B+树（存储在磁盘）FST（存储在内存），一种变种字典树，不但能共享前缀还能共享后缀；不但能判断查找的key是否存在，还能给出响应的输出(posting list)；他在时间复杂度与空间复杂度上都做到了最大程度的优化，使得Luence能够将term dictionary的信息完全加载到内存，以根据读内存快速的定位到term所在的磁盘block位置；
    磁盘存储层面磁盘页(16KB)以磁盘块分block的形式进行存储，每个block内部利用公共前缀压缩，可以比b+tree更加节约磁盘空间
    读写层面多次随机磁盘IO先读内存定位后，再去磁盘找，IO次数少
    应用层面① 使用MySQL进行全文检索时，很容易因为左前缀原则等造成索引失效；

    ②使用MySQL进行全文检索的查询结果相关性差，并且无法与其它属性相关联；    		倒排索引技术，更快的查询，且能够通过倒排表posting list进行排序打分，能够给出相关性；

5、Elasticsearch/Lucene倒排索引技术？

  • 倒排索引总结性回答

    倒排索引结构位置优势数据结构
    Term Index
    (词项索引)    		内存作用： 提高检索速度，term index以变种字典树(FST)的数据结构在内存中存储Term dictionary的信息；检索数据时，先从内存中读取Term在磁盘块中的位置，然后磁盘IO直接去读，大大减少磁盘IO次数FST(有限状态转移机)，存储在内存中

    ① 一种变种字典树，不但能共享前缀还能共享后缀；不但能判断查找的key是否存在，还能给出响应的输出(posting list)；

    ② 它在时间复杂度与空间复杂度上都做到了最大程度的优化，使得Luence能够将Term dictionary的信息完全加载到内存，以根据读内存快速的定位到Term所在的磁盘block位置；
    Term Dictionary
    (词典)    		磁盘块(公共前缀压缩的block)作用： 在磁盘中，以公共前缀压缩的block存储由字典序排序后的全部Term，可以用二分查找（logN）次磁盘查找得到目标Term，然后通过指针找到指向的Posting List；×
    Posting List
    (倒排表)    		磁盘(FOR) / 内存(RBM)作用： Posting List是一个int的数组，每个词项都对应着一个倒排表，其中存储着包含该词项的全部文档id集合

    有了倒排表后，使得我们一次性能查得到包含该Term的全部文档id集合，无需像正排索引一样，遍历全部的文档，大大提高了检索的效率；    		1) 在磁盘中，Posting List 经过FOR压缩算法后，基于block(具体是比特位)存放的；

    2) 若Posting List被缓存到了内存中，是以Roaring Bitmap的数据结构进行存储的；

     ① 当block中的元素(short)小于4096个时(即8kb = 65536个比特位)时，使用的数据结构是short[]；

     ②当block中的元素个数小于4096个时，使用的数据结构是BitSet；

    倒排索引结构：
    在这里插入图片描述

6、具体介绍一下Posting List压缩算法？

  • 1）为什么要压缩Posting List呢？

    原因解释如何实现
    节省磁盘空间与CPU① 节省磁盘空间： 全文检索动辄亿万级别的数据，倒排表需要非常大的磁盘空间存储，利用FOR压缩算法可以大幅度的优化磁盘空间；

    ② 节省CPU： 由于block是根据公共前缀压缩的，因此有压缩成本，之前没有FOR算法压缩磁盘空间是，使用的block磁盘块多，压缩成本也就高；现在有了FOR磁盘压缩算法，使用的block就少了，压缩成本也就降低了，而且此时若结合跳表skip list的方法进行Posting List的合并与交集操作，不仅跳过了遍历的成本，也跳过了压缩这些block的成本，从而节省了CPU    		FOR压缩算法
    内存缓存考虑将经常被访问的热点Term对应的倒排表(Posting List)利用合适的数据结构(RoaringBitMap)缓存到内存中，直接读内存不读磁盘，加快全文检索效率RoaringBitMap数据结构

  • 2）Posting List压缩算法

    层面压缩方式步骤
    磁盘FOR
    (压缩算法)    		① 差值计算： 将Posting List按照升序排序后，相邻两个文档ID进行差值(delta)计算；

    ② 划分block： 将delta数字中的差值结果拆分为多个block，每个block有256个Doc Id；

    ③ bit编码存储： 计算每个block中最大的delta数字需要多少bit位进行存储；并且将最大bit位数放入block头部，使用该bit数来编码所有block内所有delta数字；
    内存RoaringBitMap
    (数据结构)    		核心压缩思想： 与其保存100个0，占用100个bit。还不如保存0一次，然后声明这个0重复了100遍；

    ① 将Postting List按照升序排序；

    ② 解压每个数字表示为(N / 65536，N % 65536)；

    ③ 按照 N / 65536(高位) 进行划分block磁盘块，相同结果的划分到一个磁盘块中；

    ④ 将每个block进行编码：
      1) 若block中元素个数小于4096个(稀疏)，则用short[]进行保存(随着数据的增加占用的空间也增加)；
      2) 若block中元素大于4096个(稠密)，则用bitSet(固定占8kb的空间，不随数据的增加而增加)进行保存；
  • 2.1）FOR压缩算法（磁盘压缩）

    本压缩算法是完全基于磁盘的，不需要任何内存。

    为了高效对posting list 计算交集和并集，需要posting list有序。排序后，我们就能利用有序性进行delta-encoding即差值压缩。其压缩方式叫做 Frame Of Reference（FOR）编码。示例如下：
    在这里插入图片描述
      1、差值计算： 将数字计算差值存放

      2、划分 block： 将1中结果拆分为多个block，每个Block有256个Doc Id(示意图只画了3个方便展示)，以便按各个Block最大值分别按不同bit数表示从而有效压缩

      3、bit位编码： 根据最大值，比如第一个block最大值是227，则需要8个bit存放（2^8 = 256足够存放最大值227），所以每个值都用8bit存放就肯定够了；第二个block最大值30，需要5个bit存放（2^5 = 32足够存放最大值30），所以每个值都用5bit存放就肯定够了。将最大bit位数放入Block头部，然后使用该bit数来编码所有Block内所有delta数字。这就是所谓Frame Of Reference (FOR)。

  • 考虑到频繁出现的term（所谓low cardinality的值），比如gender里的男或者女。如果有1百万个文档，那么性别为男的posting list里就会有50万个int值。用Frame of Reference编码进行压缩可以极大减少磁盘占用。这个优化对于减少索引尺寸有非常重要的意义。当然mysql b-tree里也有一个类似的posting list的东西，但是未经过这样压缩的。

  • 举例说明FOR压缩： 对于73、300、302这3个数，原来73需要占用7个bit位(即128)，300和302需要占用9个bit位(即512)，分别存储他们一共需要25个bit位(4个Byte)；经过FOR压缩后，先计算差值，得到0、227、2，他们被分到同一个block中，227是最大差值，那么227占用8个bit位(即256)，那么就将8标记在该block磁盘头部，73和2都用8个bit位存储，只需要24bit位(3个Byte)，数越大，压缩节省的空间越明显；

  • 因为这个Frame of Reference的编码是有解压缩成本的。所以如果利用skip list，除了跳过了遍历的成本，也跳过了解压缩这些压缩过的block的过程，从而节省了cpu。

  • 为什么需要内存压缩？如何选择数据结构？

    在全文检索中，存在很多关键词term对应的posting List是超级热点的，比如：“个”、“的”这种，因此Luence全文检索引擎考虑将这个热点词汇在磁盘中对应的Posting List缓存到内存中，以加快检索效率；

    但是由于全文检索的数据是亿万级别的，可能对应的Posting List超级大，因此我们需要找到一个合适的数据结构来压缩这些数据，使得将Posting List缓存到内存这件事情变得可能。同时，考虑到联合查询，比如：查询TremA and TermB 或者 TremA or TermB，因此如何高效的对Posting List进行取交集与取并集操作，也成为了一个需要考虑的问题。

    综上分析，我们需要找到一个内存结构，具有以下两个特点：

     ① 能够大幅度压缩Posting List的内存占用；
     ② 能够高效的对Posting List进行取交集与取并集操作；

  • 根据以上分析，我们选择三种数据结构进行讨论：

    数据结构原理优缺点使用场景
    BitMapBitMap底层是int(32bit)，一个int就能放32个数优点：
     ① 查询速度快，O(1)的查询复杂度；
     ② 节约空间，能够用少量空间存储大量的非重复数字；

    缺点：
     BitMap不适合存储稀疏数据，会超级浪费空间；比如，一个Posting List ={1,9999}，为了表示这两个数，BitMap就需要用9999个bit位表示这两个数；    		与BitSet一致
    BitSetBitSet底层是long(64bit)，它实现了一个按需增长的位向量，位 set 的每个组件都有一个boolean值；两个BitSet之间可进行位运算(逻辑与、逻辑或、逻辑异或)等操作；给BitSet1个GB的空间，能够大约存储85亿个数

    优缺点：
     与BitMap相比，能够快速的进行逻辑运算操作；其它的优缺点一样；    		① 海量数据的统计工作，比如日志分析、用户数统计等；

    ② Bloom Filter(布隆过滤器)；

    ③ 快速去重 + 快速查询O(1)；
    RoaringBitMap
    (压缩位图索引)    		RoaringBitMap底层结构：

    ① short[] keys：key = N / 65536


    ② Container[] values：value = N % 65536

    ③ int size：包含了有效key和values中有效数据对的数量；    		解决了BitMap与BitSet存储稀疏数组时浪费空间的弊端；

    压缩思想：与其重复写100遍0，不如声明0重复了100遍；    		RBM是BitSet和BitMap的进阶版，集万千优点于一身；
  • 2.2）Roaring Bitmap（内存压缩）

    1）Roaring Bitmap的底层数据结构

    在这里插入图片描述

    数据结构计算作用
    short[] keyskey = N / 65536表示N这个值放在第key个Container中
    Container[] valuesvalue = N % 65536表示N这个值放在第key个文档中的第value个位置上

    有两种类型：① 若元素个数 < 4096：Array Container；② 若元素个数 > 4096：
    int sizesize = keys.length = values.length表示keys和values的长度

    2）Container的类型有两种：

    容器类型底层描述数据的插入与查找
    Array Container最多占用4096个short(8kb)用于存放稀疏数据，因为元素少于4096个时，存多少个数据，就占用多少个short；比如存10个数据，就只占10个short，即160个bit；而BitmapContainer的固定长度为1024个long(8kb)，所以当数据少于4096个(8kb)时，默认用Array Container;二分查找(Array Container 是有序的)
    BitmapContainer固定占用1024个long(8kb)用于存放稠密数据，当元素个数大于4096时，Array Container自动转移为BitmapContainer，改为用位图索引存储；直接根据(N%65536)的计算结果定位插入与查询的索引

    3）⭐Array Container插入例子

    下面我们具体看一下Array Container中数据如何被存储的，例如，0x00020032（十进制131122）放入一个 RBM 的过程如下图所示：

      Step1： 计算 key = 131122 / 65536 = 2，应该插入到2号区域；

      Step2： 计算 value = 131122 % 65536 = 50，此时判断容器内部元素的个数是否大于4096个；

      Step3： 发现2号区域的Container元素只有4个，插入完才5个，那么直接插入到Array Container中；
    在这里插入图片描述

    4）⭐BitMapContainer插入例子

    下面我们具体看一下BitMapContainer中数据如何被存储的，例如，0xFFFF3ACB（十进制4294916811）放入一个 RBM 的过程如下图所示：

      Step1： 计算 key = 4294916811 / 65536 = 2，应该插入到65536号区域；

      Step2： 计算 value = 4294916811 % 65536 = 15051，此时判断容器内部元素的个数是否大于4096个；

      Step3： 发现2号区域的Container已经是位图了(大于4096)，那么直接标记15051索引处为1，即表示插入成功；

    在这里插入图片描述

7、具体介绍一下Term Index？

  • 1）为什么需要Term Index?

      由于term dictiona存储在磁盘中，但是磁盘的随机IO操作仍然是非常昂贵，所以应该尽量少读磁盘，有必要把一些数据缓存到内存里。但是整个term dictionary本身又太大了，无法完整地放到内存里。而且就算term字典里我们可以按照term进行排序，用一个二分查找就可以定为这个term所在的地址，但这样的复杂度是logN，在term很多，内存放不下的时候，效率还是需要进一步提升。于是就有了term index，具体的底层数据结构是FST(有限状态转移机)；

  • 2）FST(有限状态转移机)

    FST描述
    特点不但能共享前缀也能共享后缀，能够判断某个key存不存在，同时能够给出响应(Posting List)
    优点在范围查询、前缀搜索以及压缩率超级nb，使得我们能够最大程度的优化时间与空间复杂度，将term dictionary以term index的形式缓存到内存中
    缺点在单term的查询上可能相比hashMap没有明显优势

8、全文检索如何联合索引查询？—Posting List 如何取并集与交集？

  • 选择哪种方式，主要看是Posting List 有没有从磁盘缓存到内存中；

    Posting List 位置方式
    磁盘用skip list(跳表)的方式进行并集或交集运算，由于磁盘中的FOR算法，使用skip list 不仅跳过了遍历的成本，还跳过了解压block的成本，节省了cpu；
    内存就用BitSet的逻辑运算实现多个Posting List的并集与交集运算

二、Elasticsearch索引文档(不是修改是建立)与搜索的过程

1、Elasticsearch索引文档流程

在这里插入图片描述

  • Elasticsearch写入文档，建立一个新索引的流程

    步骤描述
    Step1客户端发送写数据的请求，ES为数据分配一个文档ID；请求可以随机发往任意节点，该节点成为协调节点；
    Step2计算文档要写入哪个分片(sharding)，默认为 shard_ID = hash(文档_ID) % 分片的总数；ES也支持轮询法指定分片；
    Step3协调节点进行路由，将写数据请求转发给shard_ID所在的ES节点；
    Step4（先写内存）在内存中建立一个索引 (Index)，该Index在内存中会形成一个分段对象 (Segment)；
    Step5（再写日志） 然后将索引数据写到日志 (Translog) 与 sharding-备份分片；

    ① 在这个过程中，每隔1s，会将内存中的Segment刷新到系统文件缓存区，方便让用户快速的进行查询（因为用户查询直接访问内存或者磁盘，速度会变慢）；

    ② 当过了30min或者Translog日志中的数据超过了512M，那么系统文件缓存区中的Segment就会将数据刷写 (flush) 到磁盘中，刷写后内存的Segment将会被清除；如果磁盘中的Segment多了后，磁盘就会将这些Segment进行合并；
    Step6协调节点确保上述步骤都完成后，返回客户端写入成功的响应；
  • Step5：【数据保存的过程】：先内存Segment，再日志，然后刷到系统缓存区，达到写磁盘条件则写入磁盘，清除内存缓存；达到磁盘Segment合并阈值，则合并；
    在这里插入图片描述

2、Elasticsearch搜索流程

  • ES搜索过程：Query then Fetch（查询后取回）

    步骤描述
    Step1客户端发送查询请求(关键词key)，可以发给任意节点，该节点成为协调节点；
    Step2协调节点将查询请求的key广播到每一个ES节点，这些节点的分片sharding就会各自处理查询请求；
    Step3每个分片根据key进行数据查询，具体步骤如下：

    ① 首先，根据ES指定的分词器，将查询关键词key进行分词 (规范化、去重)，分成多个词项term；

    ② 对于每一个词项term，分别根据内存中的term index (FST) 查询该包含了该term的文档在磁盘块block中的位置，同时输出倒排表Posting List；

    ③ 再对每个词项的倒排表进行合并或者取交集等操作，获得合并后的倒排表，进行打分排序（参考的是本分片中的信息）；
    Step4【① Query阶段 (轻量级)，每个分片通过查询倒排索引，返回的是文档ID集合，并不是数据】待到全部分片的查询全部结束后，将符合条件的查询结果数据放入一个队列中，并将这些数据的文档ID、节点信息、分片信息全部返回给协调节点；
    Step5【② Scroll分析 (经过轻量级的Query阶段后，免去了繁重的全局排序过程)】，由协调节点将所有的查询结果进行筛选 + 汇总 + 排序，丢弃一些数据；
    Step6【③ Fetch阶段 (重量级)，将筛选后的数据 (所有信息) 全部取回】，协调节点处理完毕后，向包含剩余文档ID的分片发送 get() 请求，对应的分片将数据返回给协调节点；待取回全部分片的数据后，协调节点将查询结果数据整合起来，返回给客户端；

    注意： Query Then Fetch 的搜索类型在文档相关性打分的时候参考的是本分片的数据，这样在文档数量较少的时候可能不够准确，DFS Query Then Fetch 增加了一个预查询的处理，询问 Term 和 Document的出现频率，这个评分更准确，但是性能会变差。

3、Elasticsearch更新与删除流程

  • 删除和更新都是写操作，但是由于 Elasticsearch 中的文档（底层是段Segment）是不可变的，因此不能被删除或者改动以展示其变更；所以 ES 利用 .del 文件 标记文档是否被删除，磁盘上的每个段都有一个相应的.del 文件

    操作描述
    更新将旧的文档标记为deleted状态，然后创建一个新的文档；
    删除文档其实并没有真的被删除，而是在 .del 文件中被标记为 deleted 状态。该文档依然能匹配查询，但是会在结果中被过滤掉；

  • 在内存缓存区中，每隔1s就产生一个Segment文件，当Segment文件达到一定阈值时，就会定期的执行merge操作，每次 merge 的时候，会将多个 segment 文件合并成一个，同时这里会将标识为 deleted 的 doc 给物理删除掉，不写入到新的 segment 中，然后将新的 segment 文件写入磁盘，这里会写一个 commit point ，标识所有新的 segment 文件，然后打开 segment 文件供搜索使用，同时删除内存中旧的 segment 文件；

三、并发情况下，Elasticsearch 如果保证读写一致？

  • 三种解决方案

    方案描述
    版本号机制读写冲突不是很大时，可以通过版本号机制，在应用层解决，只有当携带的版本号 > 当前实际版本号时，才能修改；
    针对写操作ES支持三种一致性级别：

    ① quorum： 只有当一半以上的分片可用时，才允许写操作（保证写操作能够同时写入、备份成功），这样用户查询备份分片节点时也能查询到一致的数据；

    ② one： 只要主分片数据保存成功，那么客户端就可以进行查询操作；

    ③ all： 最高的一致性级别，要求所有的分片数据全部写入成功后，用户才能进行查询操作；以确保用户一定能查询到刚写入的数据；
    针对读操作① 设置ES同步，阻塞直到主分片与备份分片都执行完写操作后才返回查询的数据；

    ② 设置搜索请求，强制客户端取主分片查询，确保是最新结果；

四、Elasticsearch 应用上的问题汇总

1、DocValues的作用：

  • 倒排索引也是有缺陷的，假如我们需要对数据做一些聚合操作，比如排序/分组时，lucene内部会遍历提取所有出现在文档集合的排序字段，然后再次构建一个最终的排好序的文档集合list，这个步骤的过程全部维持在内存中操作，而且如果排序数据量巨大的话，非常容易就造成solr内存溢出和性能缓慢。

  • DocValues 就是 ES 在构建倒排索引的同时，构建了正排索引，保存了docId到各个字段值的映射，可以看作是以文档为维度，从而实现根据指定字段进行排序和聚合的功能；

  • 另外doc Values 保存在操作系统的磁盘中，当docValues大于节点的可用内存，ES可以从操作系统页缓存中加载或弹出，从而避免发生内存溢出的异常，docValues远小于节点的可用内存，操作系统自然将所有Doc Values存于内存中（堆外内存），有助于快速访问。

2、text 和 keyword类型的区别?

  • 类型区别
    text类型分词，建立倒排索引；
    keyword类型不分词，只能通过精确值搜索到；

3、query 和 filter 的区别？

  • 类型区别
    query计算分值与相关度
    filter只判断是否满足查询条件，不会计算分值与相关度，且经过filter查询的结果可以被缓存到内存中，提高检索性能
Kyire丶
关注
  • 2
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Elasticsearch技术点分享.ppt
02-01
Elasticsearch基本概念、内部底层原理、应用场景的介绍
【Elasticsearch】 之 Translog/FST/FOR/RBM算法
东方鲤鱼 博客
06-16 1576
es是近实时的存储搜索引，。近实时，并不能保证被立刻看到。数据被看到的时候数据已经作为一个提交点，被写入到了文件系统中（这个过程称为refresh）。因为一次写入的成本相对比较大，所以用攒一波批量提交的方式，写入性能会更好。不管这些数据都是在堆内存中还是在文件系统中（Filesystem Cache），如果发生断电，或者JVM的崩溃，则这部分数据一定会丢失。为了防止数据丢失，这部分数据会被写入到traslog中一份。
ES(ElasticSearch)技术栈简介
qq_50215015的博客
01-30 1300
ES(ElasticSearch)技术栈简介,读写原理
学习：Elasticsearch(1)，2024年最新挥泪整理面经
最新发布
afagagagaa的博客
04-15 510
这个节点的任务是广播查询请求到所有相关分片并将它们的响应整合成全局排序后的结果集合，这个结果集合会返回给客户端。发送上述HTTP请求后，Elasticsearch将返回一个包含所有索引的列表。每个索引的信息将以表格形式呈现，包括索引名称、文档数量、主分片数量、副本分片数量等。如果满足这些语句中的任意语句，将增加 _score ，否则，无任何影响。查询是用于在一个或多个字段中执行多字段匹配的查询类型。在上述示例中，每一行表示一个索引的信息。Doc Values 介绍？字符串排序与多字段？
ElasticSearch 及 相关技术
bald_man_cxx的博客
03-26 2676
一、ElasticSearch 相关概念 Elasticsearch是⾯向⽂档(document oriented)的，这意味着它可以存储整个对象或⽂档(document)。然 ⽽它不仅仅是存储，还会索引(index)每个⽂档的内容使之可以被搜索。在Elasticsearch中，你可以对⽂ 档（⽽⾮成⾏成列的数据）进⾏索引、搜索、排序、过滤。Elasticsearch⽐传统关系型数据库如下： Relational DB -> Databases -> Tables -> Rows -&
ElasticSearch架构介绍及原理解析
不积跬步无以致千里 不积小流无以成江海
03-02 4891
目录 简介 架构原理 基本概念与MySQL的对比 分片机制 document路由原理 集群发现机制 shard&replica规则 避免脑裂 负载均衡 相关配置 容错过程与选举机制 扩容机制 容错机制 Lucene 结构原理 ​ Lucene索引实现 DocValues 关于ES索引与检索分片 运行原理解析 倒排索引说明 检索倒排索引 分词器Analyzer 建立索引和类型 分片内文档写入流程场景 多个分片的文档写入场景 确定文档存储位置 同步
【Elasticsearch核心原理与索引分析】
weixin_42044174的博客
03-21 954
Elasticsearch：基于Lucene的搜索服务器，分布式全文搜索引擎ES核心概念：Index、Type、Document、Lucene。
ElasticSearch技术文档
07-17
Elasticsearch（简称ES）是一款开源的全文搜索引擎，基于Lucene构建，设计用于分布式、实时、可扩展的数据存储和搜索。它不仅提供了搜索功能，还支持数据分析和可视化，广泛应用于日志分析、监控、大数据处理等领域...
Elasticsearch 技术解析与实战.zip
07-25
前言 第1章 Elasticsearch入门 1 1.1 Elasticsearch是什么 1 1.1.1 Elasticsearch的历史 2 1.1.2 相关产品 3 1.2 全文搜索 3 1.2.1 Lucene介绍 4 1.2.2 Lucene倒排索引 4 1.3 基础知识 6 1.3.1 Elasticsearch术语及...
ElasticSearch技术文档V2.0.docx
12-13
**Elasticsearch技术文档V2.0概览** Elasticsearch是一种开源的全文搜索引擎，它以其分布式、实时、可扩展的特性，广泛应用于日志分析、监控、搜索和数据分析等领域。本技术文档针对Elasticsearch的初学者，旨在...
ElasticSearch技术文档.7z
11-13
Elasticsearch，简称ES，是一种基于Lucene的分布式、RESTful风格的搜索和数据分析引擎，被广泛应用于实时数据检索、大数据分析以及日志聚合等领域。它具有高度可扩展性、高可用性和容错性，使得它成为现代企业级应用...
深度剖析Elasticsearch核心倒排索引数据结构
BigData_Hubert的博客
08-16 2350
Elasticsearch 简介 Elasticsearch 是一个分布式、高扩展、高实时的搜索与数据分析引擎。Elasticsearch 建立在全文搜索引擎 Apache Lucene™ 基础上，通过 Lucene 的倒排索引技术实现比关系型数据库更快的过滤，从而很方便的使大量数据具有搜索、分析和探索的能力。 毫无疑问，Elasticsearch的底层核心是倒排索引。 Elasticsearch通过扩展服务器集群的方式，将数据以文档的形式，FST压缩的方式，分布式实时存储；同时为文件每一个字段添加倒排索引
ElasticSearch入门
文盲青年的博客
02-21 499
https://blog.csdn.net/achuo/article/details/87865141
【Elasticsearch】Elasticsearch中数据是如何存储的
九师兄
07-21 6286
1.概述 转载：Elasticsearch中数据是如何存储的 前言很多使用Elasticsearch的同学会关心数据存储在ES中的存储容量，会有这样的疑问：xxTB的数据入到ES会使用多少存储空间。这个问题其实很难直接回答的，只有数据写入ES后，才能观察到实际的存储空间。比如同样是1TB的数据，写入ES的存储空间可能差距会非常大，可能小到只有300~400GB，也可能多到6-7TB，为什么会造成这么大的差距呢？究其原因，我们来探究下Elasticsearch中的数据是如何存
elasticsearch介绍
ApexPredator的博客
07-04 1884
elasticsearch介绍
Elasticsearch常见问题
qq_41851726的博客
09-13 324
1-elasticsearch 的倒排索引是什么？ 是通过分词策略，形成了词和文章的映射关系表，这种词典+映射表 即为倒排索引。 倒排索引的底层实现是基于：FST（Finite State Transducer）数据结 构。 lucene 从 4+版本后开始大量使用的数据结构是 FST。 FST 有两个优点： 空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间； 查询速度快。O(len(str))的查询时间复杂度。 2-el...
Elastic Search
weixin_44463587的博客
12-14 1222
介绍 Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎,一个建立在全文搜索引擎 Apache Lucene(TM) 基础上的搜索引擎.当然 Elasticsearch 并不仅仅是 Lucene 那么简单，它不仅包括了全文搜索功能，还可以进行以下工作: 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。 实时分析的分布式搜索引擎。 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。 基本概念 关系数据库⇒数据库⇒表...
【Elasticsearch】es FST (Finite State Tranduer) 有限状态转换器
九师兄
07-10 1011
1.概述 FST 有限状态转换器 有一篇博客我有翻译到这篇博客。 参考：【elasticsearch】You AutoComplete Me FST数构建的树如下 演示网站地址：http://examples.mikemccandless.com/fst.py 自己可以输入一些参数查看生产的结果。 讲解视频请参考：https://www.bilibili.com/video/BV1jE411W7Lk?from=search&seid=4535470766244295290 2.FST 有限状.
Elasticsearch索引原理
跨语言，跨平台，跨应用
06-25 793
Elasticsearch索引原理 Elasticsearch最关键的就是提供强大的索引能力了。 Elasticsearch索引的精髓：一切设计都是为了提高搜索的性能。 另一层意思：为了提高搜索的性能，难免会牺牲某些其他方面，比如插入/更新，否则其他数据库不用混了。 PUT /megacorp/employee/1 { "name" : "John", "sex" : ...
Elasticsearch技术调研
01-09
根据提供的引用内容，以下是关于Elasticsearch技术调研的介绍： Elasticsearch是一个开源的分布式搜索和分析引擎，它构建在Apache Lucene库之上。它提供了一个分布式多租户的全文搜索引擎，可以实时地存储、检索和分析大规模数据。Elasticsearch具有高可用性、可扩展性和强大的搜索功能，适用于各种应用场景，包括日志分析、实时数据分析、全文搜索等。 在进行Elasticsearch技术调研时，可以关注以下几个方面： 1. 数据存储和索引：Elasticsearch使用倒排索引来加速搜索和过滤操作。它将数据存储在分片中，并使用主分片和副本分片来提供高可用性和容错性。 2. 分布式架构：Elasticsearch采用分布式架构，可以水平扩展以处理大规模数据。它使用分片和副本来实现数据的分布和冗余存储，提供高可用性和负载均衡。 3. 查询和搜索：Elasticsearch提供了丰富的查询语法和搜索功能，包括全文搜索、过滤、聚合等。它支持复杂的查询操作，并提供了相关性评分和高亮显示等功能。 4. 实时数据分析：Elasticsearch支持实时数据分析，可以对大规模数据进行聚合、统计和可视化。它提供了强大的聚合功能，可以对数据进行分组、求和、平均等操作。 5. 可视化和监控：Elasticsearch提供了Kibana工具，用于可视化和监控数据。Kibana可以连接到Elasticsearch集群，提供实时的数据可视化和仪表盘。 6. 安全性和权限控制：Elasticsearch提供了安全性和权限控制功能，可以对数据进行访问控制和身份验证。它支持基于角色的访问控制和SSL/TLS加密。 7. 故障恢复和容错性：Elasticsearch具有故障恢复和容错性，可以自动处理节点故障和数据丢失。它使用分片和副本来实现数据的冗余存储和自动恢复。 8. 扩展性和集成：Elasticsearch具有良好的扩展性和集成性，可以与其他工具和系统进行集成。它提供了丰富的API和插件机制，可以扩展其功能和集成其他系统。 以上是关于Elasticsearch技术调研的介绍，希望对您有帮助。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值