关于后端:大文本的全文检索方案附件索引

一、简介

Elasticsearch附件索引是须要插件反对的性能，它容许将文件内容附加到Elasticsearch文档中，并对这些附件内容进行全文检索。本文将带你理解索引附件的原理和应用办法，并通过一个理论示例来阐明如何在Elasticsearch中索引和检索文件附件。

索引附件的外围原理是通过Ingest Attachment Processor将文件内容转换成Elasticsearch文档中的字段。该插件应用Apache Tika来提取文档中的附件内容，并将其转换为可索引的文本。

二、环境

version: '3.8'
services:
  cerebro:
    image: lmenezes/cerebro:0.8.3
    container_name: cerebro
    ports:
     - "9000:9000"
    command:
     - -Dhosts.0.host=http://eshot:9200
    networks:
     - elastic
  kibana:
    image: docker.elastic.co/kibana/kibana:8.1.3
    container_name: kibana
    environment:
      - I18N_LOCALE=zh-CN
      - XPACK_GRAPH_ENABLED=true
      - TIMELION_ENABLED=true
      - XPACK_MONITORING_COLLECTION_ENABLED="true"
      - ELASTICSEARCH_HOSTS=http://eshot:9200
      - server.publicBaseUrl=http://192.168.160.234:5601
    ports:
      - "5601:5601"
    networks:
      - elastic
  eshot:
    image: elasticsearch:8.1.3
    container_name: eshot
    environment:
      - node.name=eshot
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=eshot,eswarm,escold
      - cluster.initial_master_nodes=eshot,eswarm,escold
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - xpack.security.enabled=false
      - node.attr.node_type=hot
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - D:\zuiyuftp\docker\es8.1\eshot\data:/usr/share/elasticsearch/data
      - D:\zuiyuftp\docker\es8.1\eshot\logs:/usr/share/elasticsearch/logs
      - D:\zuiyuftp\docker\es8.1\eshot\plugins:/usr/share/elasticsearch/plugins
    ports:
      - 9200:9200
    networks:
      - elastic
  eswarm:
    image: elasticsearch:8.1.3
    container_name: eswarm
    environment:
      - node.name=eswarm
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=eshot,eswarm,escold
      - cluster.initial_master_nodes=eshot,eswarm,escold
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - xpack.security.enabled=false
      - node.attr.node_type=warm
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - D:\zuiyuftp\docker\es8.1\eswarm\data:/usr/share/elasticsearch/data
      - D:\zuiyuftp\docker\es8.1\eswarm\logs:/usr/share/elasticsearch/logs
      - D:\zuiyuftp\docker\es8.1\eshot\plugins:/usr/share/elasticsearch/plugins
    networks:
      - elastic
  escold:
    image: elasticsearch:8.1.3
    container_name: escold
    environment:
      - node.name=escold
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=eshot,eswarm,escold
      - cluster.initial_master_nodes=eshot,eswarm,escold
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - xpack.security.enabled=false
      - node.attr.node_type=cold
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - D:\zuiyuftp\docker\es8.1\escold\data:/usr/share/elasticsearch/data
      - D:\zuiyuftp\docker\es8.1\escold\logs:/usr/share/elasticsearch/logs
      - D:\zuiyuftp\docker\es8.1\eshot\plugins:/usr/share/elasticsearch/plugins
    networks:
      - elastic

# volumes:
#   eshotdata:
#     driver: local
#   eswarmdata:
#     driver: local
#   escolddata:
#     driver: local

networks:
  elastic:
    driver: bridge

三、装置 ingest-attachment 插件

首先创立一个解决文本的管道，指定读取文档中content字段的内容进行解决

PUT _ingest/pipeline/attachment
{
  "description" : "Extract attachment information",
  "processors" : [
    {
      "attachment" : {
        "field" : "content"
      }
    }
  ]
}

咱们的elasticsearch版本是8.1，所以默认还是没有内置的，须要手动增加一下，因为我是docker启动的，所以进入到docker容器外部，执行如下命令进行装置

./bin/elasticsearch-plugin install ingest-attachment

装置实现之后进行重启elasticsearch集群进行激活插件的启用

我这边是三个节点，在hot节点下装置实现之后只会在以后节点下有此插件

当初插件曾经装置好了，继续执行方才的定义文本处理通道进行创立

PUT _ingest/pipeline/attachment
{
  "description" : "Extract attachment information",
  "processors" : [
    {
      "attachment" : {
        "field" : "content"
      }
    }
  ]
}

在下面的定义中指定的attachment的过滤字段是content，所以咱们在写入elasticsearch索引内容时，文件的内容须要保留到content字段中

四、增加测试数据

上面咱们创立一个保存文档详细信息的索引，比方文件题名，类型，文件内容等字段

PUT /zfc-doc-000003
{
  "mappings": {
    "properties": {
      "id":{
        "type": "keyword"
      },
      "title":{
        "type": "text",
        "analyzer": "ik_max_word"
      },
      "content": {
        "type": "text",
        "analyzer": "ik_max_word"
      }
    }
  }
}

通过下面两步的操作之后咱们的测试环境就算搭建实现了，上面就能够进行大文本内容的读取测试了，首先咱们还是筹备几个测试的文本文件，比方txt，doc，pdf等类型的纯文本文件

上面应用python脚本写入索引内容，首先装置一下elasticsearch的相干依赖

pip install elasticsearch

上面是读取文件夹C://Users//zuiyu//Documents//mydoc//20230806//demo//1下的所有文本文件保留到elasticsearch的索引zfc-doc-000003中的python脚本，保留为txt.py前面会用到

import os
from elasticsearch import Elasticsearch
import base64

# 定义Elasticsearch客户端连贯
es = Elasticsearch("http://localhost:9200")

# 定义索引名称
index_name = "zfc-doc-000003"

# 定义文件夹门路
folder_path = "C://Users//zuiyu//Documents//mydoc//20230806//demo//1"

# 遍历文件夹下的所有文件
for root, dirs, files in os.walk(folder_path):
    for filename in files:
        # 构建文件的残缺门路
        file_path = os.path.join(root, filename)

        # 读取文件内容，并以字节类型（bytes-like）返回
        with open(file_path, "rb") as file:
            file_content = file.read()

        # 应用base64.b64encode()函数将文件内容转换为base64编码
        base64_content = base64.b64encode(file_content).decode("utf-8")

        # 构建索引文档
        document_body = {
            "title": filename,  # 应用文件名作为文档题目
            "content": base64_content  # 将base64编码后的内容保留到字段 "content" 中
        }

        # 执行索引操作，并指定pipeline为 "attachment"
        es.index(index=index_name, body=document_body, pipeline="attachment")

print("所有文件已胜利保留到Elasticsearch索引中。")

该脚本中须要留神的点有如下三个

1、elasticsearch服务器地址

2、须要读取的文件夹地址

3、保留的索引名称与保留文本内容的字段名称

4、指定创立的pipeline

C://Users//zuiyu//Documents//mydoc//20230806//demo//1文件夹下有三个文件用来做测试，他们的文本内容别离如下图所示

其中为了不便测试，1.txt与2.txt仅有一句话

上面执行python脚本txt.py保留到elasticsearch的zfc-doc-000003中，并指定应用pipeline为attachment

python txt.py

脚本执行胜利之后的截图如下图所示，输入所有文件已胜利保留到Elasticsearch索引中。即为胜利导入

上面咱们进行检索验证，因为下面咱们创立的索引中，文本内容是保留到content字段中的，所以咱们对content字段进行分词检索（content应用的是ik分词器，不是很理解的能够参考之前的文章进行一下装置）

1、首先检索条件是内容，预期后果是返回第一个文档与第三个文档

2、再次检索mysql，返回第一个文档

通过下面两个小例子，能够验证进去的论断就是，咱们在文本内容过大须要对内容进行检索时，能够应用提前指定的pipeline进行预处理

五、设置读取文本范畴

在Elasticsearch中，Ingest Attachment Processor插件的indexed_chars参数默认值是100000，示意将文本内容的前100000保留在索引字段中

如果将其设置为-1，Elasticsearch会保留所有文本内容。这可能会导致索引文档过大，对性能和资源造成影响，特地是当解决大文本时。

为了防止索引文档过大的问题，咱们能够依据理论状况设置indexed_chars参数，将其设置为较小的值，限度保留的字符数。这样能够减小索引文档的大小，升高Elasticsearch的累赘。

如果限度保留的字符数为50000，能够如下设置：

PUT _ingest/pipeline/attachment
{
  "description": "Pipeline for processing attachments",
  "processors": [
    {
      "attachment": {
        "field": "content",
        "indexed_chars": 50000
      }
    }
  ]
}

这样，只有前50000个字符会被保留在content字段中，而超过这个字符数的局部则会被截断，不会保留在索引中。

如果想独自设定某个文档的取值范畴，也能够在索引的文档中指定字段值，举例如下

PUT _ingest/pipeline/attachment_max
{
  "description" : "Extract attachment information",
  "processors" : [
    {
      "attachment" : {
        "field" : "content",
        "indexed_chars": 6,
        "indexed_chars_field" : "max_size",
      }
    }
  ]
}
PUT /zfc-doc-000005
{
  "mappings": {
    "properties": {
      "id":{
        "type": "keyword"
      },
      "title":{
        "type": "text",
        "analyzer": "ik_max_word"
      },
      "content": {
        "type": "text",
        "analyzer": "ik_max_word"
      }
    }
  }
}
POST zfc-doc-000005/_doc?pipeline=attachment_max
{
  "id":"10",
"content":"5Litc2FkZ+eahOmqhOWCsuWIu+W9leacuuWNoea0m+aWr+Wkp+iSnOS7t+agvOWWgOS7gOinieW+l+aWr+WNoeaLiemjkuWNjg==",
  "max_size":10
}
POST zfc-doc-000005/_doc?pipeline=attachment_max
{
  "id":"11",
  "content":"5Litc2FkZ+eahOmqhOWCsuWIu+W9leacuuWNoea0m+aWr+Wkp+iSnOS7t+agvOWWgOS7gOinieW+l+aWr+WNoeaLiemjkuWNjg=="
}
GET zfc-doc-000005/_search
{
  "query": {
    "term": {
      "id": {
        "value": "11"
      }
    }
  }
}

应用"indexed_chars_field" : "max_size",指定文档中的字段，依据文档中的max_size字段来决定要取多少文本索引到字段中，如果文档中没有指定max_size则应用pipeline中指定的indexed_chars大小

六、移除二进制源文本

除了应用上述指定读取文本文件的指定长度，还能够应用另一个参数 "remove_binary": true管制来判断是否保留二进制编码的文本

PUT _ingest/pipeline/attachment_max
{
  "description" : "Extract attachment information",
  "processors" : [
    {
      "attachment" : {
        "field" : "content",
        "remove_binary": true
      }
    }
  ]
}

remove_binary 设置为true即不保留原始二进制文本，只会保留解析之后的后果，这种解决形式能够大大的缩小存储空间

七、长处

轻量化索引文档：应用Ingest Attachment Processor解决文本内容时，只会将文本的元数据（例如文件门路或URL）以及转换后的attachment类型的内容保留在索引文档中，而不是保留整个文本内容。这样能够显著减小索引文档的大小，节俭存储空间，并进步索引和检索的性能。
全文搜寻性能：通过Pipeline中的Ingest Attachment Processor解决文本内容后，Elasticsearch能够反对全文搜寻性能，能够对文本进行全文检索，查找蕴含指定关键词的文档。
灵便的数据处理：Pipeline机制容许在文本内容存储到Elasticsearch之前进行预处理。能够通过Pipeline增加其余处理器来进行数据转换、清理或提取。
易于保护和扩大：应用Pipeline能够将数据处理逻辑与索引操作解耦，使代码构造更清晰，易于保护和扩大。如果当前有其余数据处理需要，只须要批改Pipeline而不须要批改索引操作。
能够实现附件类型：应用Ingest Attachment Processor能够将文本内容转换为attachment类型，这是Elasticsearch内置的一种非凡数据类型，反对对文档内容的索引和全文检索。

八、毛病

存储需要：尽管应用attachment类型能够减小索引文档的大小，然而依然须要在Elasticsearch中存储文本内容的转换后果。对于大量大文本内容的状况，仍须要较大的存储空间，并且最好应用"remove_binary": true移除二进制文本。
内存耗费：在解决大文本内容时，Ingest Attachment Processor须要将文本内容暂存到内存中进行解决，因而会耗费较多的内存资源。如果解决大量大文本，可能导致内存压力减少，影响性能。
解决性能：尽管应用Pipeline能够在索引之前进行预处理，但Ingest Attachment Processor的处理速度依然会受到限制。在解决大量大文本内容时，可能导致处理速度较慢，影响索引性能。
不适用于实时场景：因为Ingest Attachment Processor解决文本内容须要较多的计算和存储资源，实用于离线或批处理的场景。对于实时索引或对性能要求较高的场景，可能须要思考其余计划。
不反对所有文件类型：尽管attachment类型反对多种文件类型，但仍有一些非凡文件类型可能不受反对。在应用Pipeline中的Ingest Attachment Processor解决文本内容时，须要留神文件类型的兼容性。
额定的配置和保护：应用Pipeline须要额定的配置和保护，须要定义处理器、设置参数等
依赖插件：Ingest Attachment Processor是Elasticsearch的一个插件，须要确保插件的版本与Elasticsearch版本兼容

九、总结

应用Pipeline中的Ingest Attachment Processor解决文本内容能够在不影响检索性能的前提下，优化索引文档的大小，进步索引和检索的性能，并灵便地解决和扩大数据。这是解决大文本内容时的一种高效和牢靠的形式。尽管Pipeline中的Ingest Attachment Processor解决大文本内容是一种高效和灵便的形式，但依然存在一些挑战和限度。在理论应用中，须要综合思考理论需要、资源限度和性能要求，抉择适合的解决计划。如果解决大量大文本或对性能要求较高，可能须要思考其余优化措施或计划。

十、须要留神的点

索引性能：解决大文本时，Pipeline的执行可能会占用较多的CPU和内存资源，特地是在解决多个大文本时。这可能会对Elasticsearch的索引性能和整体零碎性能造成影响。在解决大文本之前，倡议评估零碎的性能和资源利用状况，确保零碎有足够的资源来执行解决。
超时设置：Pipeline的执行可能须要肯定的工夫，尤其是在解决大文本时。如果Pipeline的执行工夫超过了Elasticsearch的默认超时设置，可能会导致工作失败。你能够通过设置timeout参数来缩短超时工夫，确保Pipeline有足够的工夫来执行。
错误处理：在Pipeline的处理过程中，可能会呈现各种谬误，例如文本解析谬误、索引失败等。你须要留神适当解决这些谬误，以防止工作失败导致整个操作中断。能够应用适当的异样解决机制，或者应用Elasticsearch的Bulk API来进行批量索引，确保局部文档解决失败时，不会影响其余文档的索引。
内存治理：解决大文本时，可能会产生较大的长期数据，须要留神内存的治理和及时开释。确保处理过程中不会产生内存透露或内存溢出问题。
文件门路安全性：如果应用文件门路来索引文本内容，须要留神文件门路的安全性。确保文件门路是非法的、可信的，并限度拜访范畴，防止可能的平安危险。
版本兼容性：应用Pipeline时，须要留神插件的版本与Elasticsearch的版本兼容性。确保应用的Pipeline插件与Elasticsearch版本兼容，并定期降级插件以放弃稳定性和安全性。

总的来说，解决大文本时，须要综合思考性能、资源利用、错误处理等方面的问题，正当设计和优化Pipeline的处理过程。在理论利用中，能够进行压力测试和性能测试，找到最合适的解决计划，确保零碎可能稳固高效地解决大文本内容。

参考链接

https://www.elastic.co/guide/en/elasticsearch/reference/8.9/a…

如果感觉本文对你有所帮忙欢送点赞评论转发珍藏。如果你想理解更多对于ES的骚操作，更多实战经验，欢送关注。

原文链接：

https://mp.weixin.qq.com/s?__biz=MzIwNzYzODIxMw==&mid=2247486041&idx=1&sn=08e3b981c512a8a24afd3778cd3f231a&chksm=970e11f3a07998e5f7bbe017409944e4b57a0d800b2a149f7c291091f5b2b32b6493c3586257#rd

本文由mdnice多平台公布

关于后端:大文本的全文检索方案附件索引

一、简介

二、环境

三、装置 ingest-attachment 插件

四、增加测试数据

五、设置读取文本范畴

六、移除二进制源文本

七、长处

八、毛病

九、总结

十、须要留神的点

参考链接

评论

发表回复取消回复

更多文章

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

深入解析：基于Delta的线性数据结构模型，打造高效富文本编辑器

轻松管理社交媒体：使用Automa插件实现一键拉黑功能

关于后端:大文本的全文检索方案附件索引

一、简介

二、环境

三、装置 ingest-attachment 插件

四、增加测试数据

五、设置读取文本范畴

六、移除二进制源文本

七、长处

八、毛病

九、总结

十、须要留神的点

参考链接

评论

发表回复 取消回复

更多文章

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

深入解析：基于Delta的线性数据结构模型，打造高效富文本编辑器

轻松管理社交媒体：使用Automa插件实现一键拉黑功能

发表回复取消回复