一次 ElasticSearch 搜索优化

最新推荐文章于 2023-12-26 20:03:55 发布
最新推荐文章于 2023-12-26 20:03:55 发布
阅读量265 收藏
点赞数
原文链接：http://www.cnblogs.com/hapjin/p/10541500.html
版权

一次 ElasticSearch 搜索优化

1. 环境

ES6.3.2，索引名称 user_v1，5个主分片，每个分片一个副本。分片基本都在11GB左右，GET _cat/shards/user

715283-20190316113406569-1762495464.png

一共有3.4亿文档，主分片总共57GB。

715283-20190316113418261-18239606.png

Segment信息：curl -X GET "221.228.105.140:9200/_cat/segments/user_v1?v" >> user_v1_segment

user_v1索引一共有404个段：

cat user_v1_segment | wc -l

404

处理一下数据，用Python画个直方图看看效果：

sed -i '1d' file # 删除文件第一行

awk -F ' ' '{print $7}' user_v1_segment >> docs_count # 选取感兴趣的一列(docs.count 列)

with open('doc_count.txt') as f:
    data=f.read()
docList = data.splitlines()
docNums = list(map(int,docList))
import matplotlib.pyplot as plt
plt.hist(docNums,bins=40,normed=0,facecolor='blue',edgecolor='black')

大概看一下每个Segment中包含的文档的个数。横坐标是：文档数量，纵坐标是：segment个数。可见：大部分的Segment中只包含了少量的文档(\(0.5*10^7\))

715283-20190316113433749-1138442329.png

修改refresh_interval为30s，原来默认为1s，这样能在一定程度上减少Segment的数量。然后先force merge将404个Segment减少到200个：

POST /user_v1/_forcemerge?only_expunge_deletes=false&max_num_segments=200&flush=true

但是一看，还是有312个Segment。这个可能与merge的配置有关了。有兴趣的可以了解一下 force merge 过程中这2个参数的意义：

  • ​ merge.policy.max_merge_at_once_explicit
  • ​ merge.scheduler.max_merge_count

执行profile分析：

1，Collector 时间过长，有些分片耗时长达7.9s。关于Profile 分析，可参考：profile-api

2，采用HanLP 分词插件，Analyzer后得到Term，居然有"空格Term"，而这个Term的匹配长达800ms！

来看看原因：

POST /_analyze
{
"analyzer": "hanlp_standard",
"text":"人生 如梦"
}

分词结果是包含了空格的：

{
  "tokens": [
    {
      "token": "人生",
      "start_offset": 0,
      "end_offset": 2,
      "type": "n",
      "position": 0
    },
    {
      "token": " ",
      "start_offset": 0,
      "end_offset": 1,
      "type": "w",
      "position": 1
    },
    {
      "token": "如",
      "start_offset": 0,
      "end_offset": 1,
      "type": "v",
      "position": 2
    },
    {
      "token": "梦",
      "start_offset": 0,
      "end_offset": 1,
      "type": "n",
      "position": 3
    }
  ]
}

那实际文档被Analyzer了之后是否存储了空格呢？

于是先定义一个索引，开启term_vector。参考store term-vector

PUT user
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 0
  },
  "mappings": {
    "profile": {
      "properties": {
        "nick": {
          "type": "text",
          "analyzer": "hanlp_standard",
          "term_vector": "yes", 
          "fields": {
            "raw": {
              "type": "keyword"
            }
          }
        }
      }
    }
  }
}

然后PUT一篇文档进去：

PUT user/profile/1
{
  "nick":"人生 如梦"
}

查看Term Vector：docs-termvectors

GET /user/profile/1/_termvectors
{
"fields" : ["nick"],
"offsets" : true,
"payloads" : true,
"positions" : true,
"term_statistics" : true,
"field_statistics" : true
}

发现存储的Terms里面有空格。

{
  "_index": "user",
  "_type": "profile",
  "_id": "1",
  "_version": 1,
  "found": true,
  "took": 2,
  "term_vectors": {
    "nick": {
      "field_statistics": {
        "sum_doc_freq": 4,
        "doc_count": 1,
        "sum_ttf": 4
      },
      "terms": {
        " ": {
          "doc_freq": 1,
          "ttf": 1,
          "term_freq": 1
        },
        "人生": {
          "doc_freq": 1,
          "ttf": 1,
          "term_freq": 1
        },
        "如": {
          "doc_freq": 1,
          "ttf": 1,
          "term_freq": 1
        },
        "梦": {
          "doc_freq": 1,
          "ttf": 1,
          "term_freq": 1
        }
      }
    }
  }
}

然后再执行profile 查询分析：

GET user/profile/_search?human=true
{
  "profile":true,
  "query": {
    "match": {
      "nick": "人生 如梦"
    }
  }
}

发现Profile里面居然有针对 空格Term 的查询！！！（注意 nick 后面有个空格）

            "type": "TermQuery",
            "description": "nick: ",
            "time": "58.2micros",
            "time_in_nanos": 58244,

profile结果如下：

 "profile": {
    "shards": [
      {
        "id": "[7MyDkEDrRj2RPHCPoaWveQ][user][0]",
        "searches": [
          {
            "query": [
              {
                "type": "BooleanQuery",
                "description": "nick:人生 nick:  nick:如 nick:梦",
                "time": "642.9micros",
                "time_in_nanos": 642931,
                "breakdown": {
                  "score": 13370,
                  "build_scorer_count": 2,
                  "match_count": 0,
                  "create_weight": 390646,
                  "next_doc": 18462,
                  "match": 0,
                  "create_weight_count": 1,
                  "next_doc_count": 2,
                  "score_count": 1,
                  "build_scorer": 220447,
                  "advance": 0,
                  "advance_count": 0
                },
                "children": [
                  {
                    "type": "TermQuery",
                    "description": "nick:人生",
                    "time": "206.6micros",
                    "time_in_nanos": 206624,
                    "breakdown": {
                      "score": 942,
                      "build_scorer_count": 3,
                      "match_count": 0,
                      "create_weight": 167545,
                      "next_doc": 1493,
                      "match": 0,
                      "create_weight_count": 1,
                      "next_doc_count": 2,
                      "score_count": 1,
                      "build_scorer": 36637,
                      "advance": 0,
                      "advance_count": 0
                    }
                  },
                  {
                    "type": "TermQuery",
                    "description": "nick: ",
                    "time": "58.2micros",
                    "time_in_nanos": 58244,
                    "breakdown": {
                      "score": 918,
                      "build_scorer_count": 3,
                      "match_count": 0,
                      "create_weight": 46130,
                      "next_doc": 964,
                      "match": 0,
                      "create_weight_count": 1,
                      "next_doc_count": 2,
                      "score_count": 1,
                      "build_scorer": 10225,
                      "advance": 0,
                      "advance_count": 0
                    }
                  },
                  {
                    "type": "TermQuery",
                    "description": "nick:如",
                    "time": "51.3micros",
                    "time_in_nanos": 51334,
                    "breakdown": {
                      "score": 888,
                      "build_scorer_count": 3,
                      "match_count": 0,
                      "create_weight": 43779,
                      "next_doc": 1103,
                      "match": 0,
                      "create_weight_count": 1,
                      "next_doc_count": 2,
                      "score_count": 1,
                      "build_scorer": 5557,
                      "advance": 0,
                      "advance_count": 0
                    }
                  },
                  {
                    "type": "TermQuery",
                    "description": "nick:梦",
                    "time": "59.1micros",
                    "time_in_nanos": 59108,
                    "breakdown": {
                      "score": 3473,
                      "build_scorer_count": 3,
                      "match_count": 0,
                      "create_weight": 49739,
                      "next_doc": 900,
                      "match": 0,
                      "create_weight_count": 1,
                      "next_doc_count": 2,
                      "score_count": 1,
                      "build_scorer": 4989,
                      "advance": 0,
                      "advance_count": 0
                    }
                  }
                ]
              }
            ],
            "rewrite_time": 182090,
            "collector": [
              {
                "name": "CancellableCollector",
                "reason": "search_cancelled",
                "time": "25.9micros",
                "time_in_nanos": 25906,
                "children": [
                  {
                    "name": "SimpleTopScoreDocCollector",
                    "reason": "search_top_hits",
                    "time": "19micros",
                    "time_in_nanos": 19075
                  }
                ]
              }
            ]
          }
        ],
        "aggregations": []
      }
    ]
  }

而在实际的生产环境中，空格Term的查询耗时480ms，而一个正常词语（"微信"）的查询，只有18ms。如下在分片[user_v1][3]上的profile分析结果：

 "profile": {
    "shards": [
      {
        "id": "[8eN-6lsLTJ6as39QJhK5MQ][user_v1][3]",
        "searches": [
          {
            "query": [
              {
                "type": "BooleanQuery",
                "description": "nick:微信 nick:  nick:黄色",
                "time": "888.6ms",
                "time_in_nanos": 888636963,
                "breakdown": {
                  "score": 513864260,
                  "build_scorer_count": 50,
                  "match_count": 0,
                  "create_weight": 93345,
                  "next_doc": 364649642,
                  "match": 0,
                  "create_weight_count": 1,
                  "next_doc_count": 5063173,
                  "score_count": 4670398,
                  "build_scorer": 296094,
                  "advance": 0,
                  "advance_count": 0
                },
                "children": [
                  {
                    "type": "TermQuery",
                    "description": "nick:微信",
                    "time": "18.4ms",
                    "time_in_nanos": 18480019,
                    "breakdown": {
                      "score": 656810,
                      "build_scorer_count": 62,
                      "match_count": 0,
                      "create_weight": 23633,
                      "next_doc": 17712339,
                      "match": 0,
                      "create_weight_count": 1,
                      "next_doc_count": 7085,
                      "score_count": 5705,
                      "build_scorer": 74384,
                      "advance": 0,
                      "advance_count": 0
                    }
                  },
                  {
                    "type": "TermQuery",
                    "description": "nick: ",
                    "time": "480.5ms",
                    "time_in_nanos": 480508016,
                    "breakdown": {
                      "score": 278358058,
                      "build_scorer_count": 72,
                      "match_count": 0,
                      "create_weight": 6041,
                      "next_doc": 192388910,
                      "match": 0,
                      "create_weight_count": 1,
                      "next_doc_count": 5056541,
                      "score_count": 4665006,
                      "build_scorer": 33387,
                      "advance": 0,
                      "advance_count": 0
                    }
                  },
                  {
                    "type": "TermQuery",
                    "description": "nick:黄色",
                    "time": "3.8ms",
                    "time_in_nanos": 3872679,
                    "breakdown": {
                      "score": 136812,
                      "build_scorer_count": 50,
                      "match_count": 0,
                      "create_weight": 5423,
                      "next_doc": 3700537,
                      "match": 0,
                      "create_weight_count": 1,
                      "next_doc_count": 923,
                      "score_count": 755,
                      "build_scorer": 28178,
                      "advance": 0,
                      "advance_count": 0
                    }
                  }
                ]
              }
            ],
            "rewrite_time": 583986593,
            "collector": [
              {
                "name": "CancellableCollector",
                "reason": "search_cancelled",
                "time": "730.3ms",
                "time_in_nanos": 730399762,
                "children": [
                  {
                    "name": "SimpleTopScoreDocCollector",
                    "reason": "search_top_hits",
                    "time": "533.2ms",
                    "time_in_nanos": 533238387
                  }
                ]
              }
            ]
          }
        ],
        "aggregations": []
      },

由于我采用的是HanLP分词，用的这个分词插件elasticsearch-analysis-hanlp，而采用ik_max_word分词却没有相应的问题，这应该是分词插件的bug，于是去github上提了一个issue，有兴趣的可以关注。看来我得去研究一下ElasticSearch Analyze整个流程的源码以及加载插件的源码了 ::(

以上是一个空格Term造成的查询性能问题。在Profile分析时，还发现，使用SSD的Collector time比机械硬盘快10倍左右。

分片[user_v1][0] 的 Collector time长达7.6秒，而这个分片所在机器的磁盘是机械硬盘。而上面那个分片[user_v1][3]所在的磁盘是SSD，Collector time只有730.3ms。可见SSD与机械硬盘的在Collector time上相差10倍 。下面是分片[user_v1][0]的profile查询分析：

{
        "id": "[wx0dqdubRkiqJJ-juAqH4A][user_v1][0]",
        "searches": [
          {
            "query": [
              {
                "type": "BooleanQuery",
                "description": "nick:微信 nick:  nick:黄色",
                "time": "726.1ms",
                "time_in_nanos": 726190295,
                "breakdown": {
                  "score": 339421458,
                  "build_scorer_count": 48,
                  "match_count": 0,
                  "create_weight": 65012,
                  "next_doc": 376526603,
                  "match": 0,
                  "create_weight_count": 1,
                  "next_doc_count": 4935754,
                  "score_count": 4665766,
                  "build_scorer": 575653,
                  "advance": 0,
                  "advance_count": 0
                },
                "children": [
                  {
                    "type": "TermQuery",
                    "description": "nick:微信",
                    "time": "63.2ms",
                    "time_in_nanos": 63220487,
                    "breakdown": {
                      "score": 649184,
                      "build_scorer_count": 61,
                      "match_count": 0,
                      "create_weight": 32572,
                      "next_doc": 62398621,
                      "match": 0,
                      "create_weight_count": 1,
                      "next_doc_count": 6759,
                      "score_count": 5857,
                      "build_scorer": 127432,
                      "advance": 0,
                      "advance_count": 0
                    }
                  },
                  {
                    "type": "TermQuery",
                    "description": "nick: ",
                    "time": "1m",
                    "time_in_nanos": 60373841264,
                    "breakdown": {
                      "score": 60184752245,
                      "build_scorer_count": 69,
                      "match_count": 0,
                      "create_weight": 5888,
                      "next_doc": 179443959,
                      "match": 0,
                      "create_weight_count": 1,
                      "next_doc_count": 4929373,
                      "score_count": 4660228,
                      "build_scorer": 49501,
                      "advance": 0,
                      "advance_count": 0
                    }
                  },
                  {
                    "type": "TermQuery",
                    "description": "nick:黄色",
                    "time": "528.1ms",
                    "time_in_nanos": 528107489,
                    "breakdown": {
                      "score": 141744,
                      "build_scorer_count": 43,
                      "match_count": 0,
                      "create_weight": 4717,
                      "next_doc": 527942227,
                      "match": 0,
                      "create_weight_count": 1,
                      "next_doc_count": 967,
                      "score_count": 780,
                      "build_scorer": 17010,
                      "advance": 0,
                      "advance_count": 0
                    }
                  }
                ]
              }
            ],
            "rewrite_time": 993826311,
            "collector": [
              {
                "name": "CancellableCollector",
                "reason": "search_cancelled",
                "time": "7.8s",
                "time_in_nanos": 7811511525,
                "children": [
                  {
                    "name": "SimpleTopScoreDocCollector",
                    "reason": "search_top_hits",
                    "time": "7.6s",
                    "time_in_nanos": 7616467158
                  }
                ]
              }
            ]
          }
        ],
        "aggregations": []
      },

结论

查询不仅仅与Segment数量、Collector time等有关，还与索引的mapping定义，查询方式(match、filter、term……)有关，可用Profile API分析查询性能问题。另外也有一些压测工具，比如：esrally

对于中文而言，还要注意 query string 被Analyze成各个token之后，到底是针对了哪些Token查询，这个可以通过term vector进行测试，但生产环境一般不会开启term vector。因此，中文分词算法对搜索命中会有影响。

而至于搜索排序，可先用explain API 分析各个Term的得分，然后也可考虑ES的Function Score功能，针对某些特定的field做调节(field_value_factor)，甚至可以用机器学习模型优化搜索排序(learning to rank)

关于ElasticSearch查询效率的提升一些思考：

  1. FileSystem cache 要足够（堆外内存 vs 堆外内存），数据分布要合理(冷热分离)
  2. 索引设计要合理（多字段、Analyzer、Index shard数量）、Segment数量(refresh interval 配置)
  3. 查询语法要合适（term、match、filter），可通过搜索参数调优(terminate_after提前返回、timeout查询响应超时)
  4. profile分析

参考资料

转载于:https://www.cnblogs.com/hapjin/p/10541500.html

weixin_30628801
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
max_result_window会影响es性能_Elasticsearch 最佳性能优化
weixin_42300721的博客
11-30 1313
本文转自: http://wangnan.tech/post/elkstack-es03/，作者: Ghost Stories侵删。批量提交在 CRUD 章节，我们已经知道 ES 的数据写入是如何操作的了。喜欢自己动手的读者可能已经迫不及待的自己写了程序开始往 ES 里写数据做测试。这时候大家会发现：程序的运行速度非常一般，即使 ES 服务运行在本机，一秒钟大概也就能写入几百条数据。这种...
基于Elasticsearch的搜索优化
奋斗中的小小酥
02-26 4310
高吞吐量查询优化因业务扩展，es 内数据不断增多，查询压力也不断增大，直至已经严重影响用户体验，故需进行彻底整改。在整改过程中，经过不断尝试，关于 ES 查询方面总结为以下几点：升级ES随着用户量的增加，必不可少的采取了加机器、换SSD等措施，同时升级es，ES6.0性能较之前会有大幅提升。自定义分词器因业务原因，例如“美的”这类特殊词汇的监测等等，改造了分词器，变成了单字分词。但单字分词，有利有...
ES搜索性能优化
harleylau的博客
03-02 5101
在项目中有用到Elastic Search来进行数据的索引和搜索工作。在一开始接手的时候，搜索接口的耗时在六七百毫秒，相对一般的接口来说是一个比较耗时的操作了。 在后期的优化和学习过程中，对ES的特性和原理进行初步的了解，并对ES的搜索性能进行了优化，将搜索接口的耗时降低到了平均150ms左右，性能提高了将近5倍。 虽然是个很小的改动，但效果确实显著，记录一下中间具体的过程。 初始ES搜索的概...
Linq多表左外连接left join查询
戴翔的技术博客
12-14 6233
左外连接会检索出LEFT JOIN左表中的所有行，而不管右表是否有匹配项。 今天的一个项目中，需要将classlist表与其他3张表进行连接查询，且classlist表中某列为空的数据也需要查询出来，这就需要进行LEFT JOIN（左外连接查询），且项目使用的是Entity Framework框架，因此，可以使用Linq语句进行左外连接查询。 通过左连接4张表（klc_classlist、klc_object 、klc_student 、klc_license ）进行查询，语句如下： // linq语句多表
ElasticSearch中profile API的使用
不见其长，日有所长
03-29 5983
1. 前言 profile API 是 Elasticsearch 5.x 的一个新接口。通过这个功能，可以看到一个搜索聚合请求，是如何拆分成底层的 Lucene 请求，并且显示每部分的耗时情况。 2. profile API 使用 可以通过在 query 部分上方提供 “profile: true” 来启用Profile API。 GET /ljjtest/book/_search { "p...
ES慢查询分析——性能提升6 倍
Angus
12-26 2576
生产环境频繁报警。查询跨度91天的数据，请求耗时已经来到了30+s。报警的阈值为5s。经过问题排查，提供了优化方案。最后请求时间降到5s内。
ElasticSearch优化
ll谢安生的博客
02-23 1256
目录： 1.ElasticSearch生产集群配置优化 2.Spark整合Elasticsearch优化 ElasticSearch生产集群配置优化 集群主机（节点）配置相近 集群中主机最好配置相近，集群的性能符合木桶定律，即集群的查询性能是由集群中性能最差的主机决定的。 建议使用SSD硬盘替换传统的机械硬盘 ES对IO的性能要求比较高。 ES内存配置不要超过32G 指定的堆内存可以是节点总内存的...
Elasticsearch进阶（一）写入性能基准测试写入性能优化
03-01
进入正题之前，解决之前的一个疑问：Elasticsearch集群是否已经正确工作？截图时，只上传过一次小测试数据（143万条），设置为：从图中可以看出，ip10节点上设置的数据目录：data1和data2目录工作正常，但是数据相同...
Elasticsearch 存储方式和管理优化细节1
08-03
Elasticsearch 是一个分布式搜索引擎，其数据存储方式和管理优化对于高效检索和稳定运行至关重要。在Elasticsearch中，数据存储的基本单位是段（segment），每个段都是一个倒排索引，由Lucene生成。每次数据写入后，...
ElasticSearch写入原理及优化.docx
09-01
Elasticsearch（ES）是一种流行的分布式搜索引擎和分析引擎，它以高效、实时的特性而闻名。本文主要探讨了Elasticsearch的写入、读取、检索数据的底层原理以及性能调优策略。 **Elasticsearch 写入数据流程** 1. ...
elasticsearch-jdbc-2.3.3.0-dist.zip
03-10
《Elasticsearch-JDBC连接MySQL实现大数据搜索》 在当今的大数据时代，高效的数据检索与分析成为了企业核心竞争力的一部分。Elasticsearch作为一个强大的开源搜索引擎，以其分布式、实时、灵活的特性，广泛应用于...
基于Elasticsearch Java API的参考手册
04-29
4. **搜索_after**：滚动查询的优化版，基于上一次查询的结果继续获取下一批数据。 5. **多搜索(Multi Search)**: 在一个请求中同时执行多个独立的搜索请求，节省网络开销。 6. **监听(Lifecycle)**: 监听索引生命...
es修改排序_【02】把 Elasticsearch 当数据库使：过滤和排序
weixin_30320081的博客
12-23 373
使用 https://github.com/taowen/es-monitor 可以用 SQL 进行 elasticsearch 的查询。本章介绍简单的文档过滤条件exchange='nyse'SQL$ cat << EOF | ./es_query.py http://127.0.0.1:9200select * from symbol where exchange='nyse' l...
【Elasticsearch系列】elasticsearch wildcard 慢查询原因分析(深入到源码!!!)
我活在当下，我巨他妈勇敢。
09-05 795
大家好，我是蓝胖子，前段时间线上elasticsearch集群遇到多次wildcard产生的性能问题， elasticsearch wildcard 一直是容易引发elasticsearch 容易宕机的一个风险点， 但究竟它为何消耗cpu呢？又该如何理解elasticsearch profile api的返回结果呢？在探索了部分源码后，我将在这篇文章一一揭晓答案。
(三)ElasticSearch实战基础教程(ElasticSearch入门)
张三博客
02-24 457
7. URI 详解 7.1 通过URI query 实现搜索 GET /companyinfo/_search?q=公司&df=entName&from=0&size=1&timeout=1s { "profile":"true" } q 指定查询语句,使用Query String Syntax df 默认字段，不指定时会对所有字段进行查询 Sort 排序/ from 和 size 用于分页 Profile 可以查看查询是如何被执行的 7.2 Query Stri.
Elasticsearch性能优化
Ghost Stories
02-08 1244
目录 批量提交 gateway 集群状态维护 缓存 字段数据 curator profiler 批量提交 在 CRUD 章节，我们已经知道 ES 的数据写入是如何操作的了。喜欢自己动手的读者可能已经迫不及待的自己写了程序开始往 ES 里写数据做测试。这时候大家会发现：程序的运行速度非常一般，即使 ES 服务运行在本机，一秒钟大概也就能写入几百条数据。 这种速度显然不...
Elastic对类似枚举数据的搜索性能优化
王卫东 博客
05-07 4550
上周，在某多多搬砖的一位朋友在微信上找我咨询，说他们公司一个ES集群从2.4升级到5.5以后，一个很简单的Query查询耗时突然从几十毫秒，变成800-1000毫秒，几十倍的性能下降！原始问题链接:# Why my search slow?这个查询非常简单，就是3个过滤条件求并集而已:{ "from": 0, "size": 10, "query": { ...
ElasticSearch学习_陶文5_【02】把 Elasticsearch 当数据库使：过滤和排序
wang_zhenwei的博客
03-08 959
使用 https://github.com/taowen/es-monitor 可以用 SQL 进行 elasticsearch 的查询。本章介绍简单的文档过滤条件 exchange='nyse' SQL $ cat 127.0.0.1:9200 select * from symbol where exchange='nyse' limit 1 EOF {"sector": "n
基于Springboot和Vue的图书借还管理系统源码 图书借还管理系统代码（高分毕设）
最新发布
07-28
图书借还管理系统源码（高分毕设），个人经导师指导并认可通过的98分毕业设计项目，主要针对计算机相关专业的正在做毕设的学生和需要项目实战练习的学习者。也可作为课程设计、期末大作业。包含全部项目源码[代码]、该项目可以直接作为毕设使用。项目技术栈：前端是vue，后端是springboot，项目代码都经过严格调试，代码没有任何bug！ 系统源码（高分毕设），个人经导师指导并认可通过的98分毕业设计项目，主要针对计算机相关专业的正在做毕设的学生和需要项目实战练习的学习者。也可作为课程设计、期末大作业。包含全部项目源码[代码]、该项目可以直接作为毕设使用。项目技术栈：前端是vue，后端是springboot，项目代码都经过严格调试，代码没有任何bug！ 系统源码（高分毕设），个人经导师指导并认可通过的98分毕业设计项目，主要针对计算机相关专业的正在做毕设的学生和需要项目实战练习的学习者。也可作为课程设计、期末大作业。包含全部项目源码[代码]、该项目可以直接作为毕设使用。项目技术栈：前端是vue，后端是springboot，项目代码都经过严格调试，代码没有任何bug！
深度解析Elasticsearch搜索与分片优化技巧
Elasticsearch 是一个开源的分布式搜索引擎，被广泛应用于大规模数据的实时搜索和分析中。在 Elasticsearch 中，搜索的过程可以分为两个阶段：query 阶段和 fetch 阶段。 在 query 阶段中，Elasticsearch 主要是...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值