【黄啊码】什么是ElasticSearch？它会替代MySQL成为主流吗？如何优化？TP5如何接入ElasticSearch？

目录

什么是ElasticSearch？

ES和MySQL使用场景的比较

Elasticsearch和MySQL具体应用场景：

如何优化：

索引效率优化

批量提交

优化硬件、

减少副本数量

查询效率优化

路由

不带 routing 查询

Filter VS Query

大翻页

JVM 设置

TP5如何接入ElasticSearch？

什么是elasticsearch？

Elasticsearch 是一个分布式、高扩展、高实时的搜索与数据分析
引擎。它能很方便的使大量数据具有搜索、分析和探索的能力。充分利用Elasticsearch的水平伸缩性，能使数据在生产环境变得更有价值。

Elasticsearch 的实现原理主要分为以下几个步骤，首先用户将数据提交到Elasticsearch 数据库中，再通过分词控制器去将对应的语句分词，将其权重和分词结果一并存入数据，当用户搜索数据时候，再根据权重将结果排名，打分，再将返回结果呈现给用户

简而言之：Elasticsearch 则是一款分布式搜索和分析引擎。它可以帮助你快速搜索和分析海量数据，并提供了丰富的查询语言和可视化工具。Elasticsearch 也支持 ACID 事务，但这并不是它的主要功能。

然而，这并不意味着 Elasticsearch 就不能用于存储数据。实际上，Elasticsearch 可以作为一种 NoSQL 数据库来使用，允许你将非结构化数据存储在其中。但是，Elasticsearch 没有 Mysql 那样强大的数据模型和关系管理功能。因此，如果你需要一个用于存储和管理复杂数据模型的工具，mysql 可能更加适合。

ES和Mysql使用场景的比较

MySQL更擅长的是事务类型的操作，可以确保数据的安全和一致性；如果是有事务要求，如商品的下单支付等业务操作，无疑使用MySQL。

ES更擅长的是海量数据的搜索，分析和计算；如果是复杂搜索，无疑可以使用Elasticsearch。

两者是一个互补而不是替代的关系。

Elasticsearch和MySQL具体应用场景：

MySQL 可以用于存储和管理结构化数据，而 Elasticsearch 可以用于快速搜索和分析这些数据。在这种情况下，你可以将数据存储在 MySQL 中，并使用 Elasticsearch 对数据进行搜索和分析。这样，你就可以充分利用 MySQL 和 Elasticsearch 的优势，同时避免它们的劣势。

MySQL 和 Elasticsearch 联合使用，以提供更全面的功能。例如，可以使用 MySQL 存储和管理结构化数据，并使用 Elasticsearch 对数据进行搜索和分析。还可以使用 MySQL 的触发器和存储过程，在数据发生变化时自动将数据同步到 Elasticsearch 中。这样，就可以在 MySQL 和 Elasticsearch 之间建立联系，实现数据的双向同步。

如何优化：

索引效率优化

索引优化主要是在 Elasticsearch 插入层面优化，如果瓶颈不在这块，而是在产生数据部分，比如 DB 或者 hadoop 上，那么优化方向就需要改变下。同时，Elasticsearch 本身索引速度其实还是蛮快的，具体数据，我们可以参考官方的 benchmark 数据。

批量提交

当有大量数据提交的时候，建议采用批量提交。

比如在做 elk 过程中 ，Logstash indexer 提交数据到 Elasticsearch 中 ，batch size 就可以作为一个优化功能点。但是优化 size 大小需要根据文档大小和服务器性能而定。

像 Logstash 中提交文档大小超过 20MB ，Logstash 会请一个批量请求切分为多个批量请求。

如果在提交过程中，遇到 EsRejectedExecutionException 异常的话，则说明集群的索引性能已经达到极限了。这种情况，要么提高服务器集群的资源，要么根据业务规则，减少数据收集速度，比如只收集 Warn、Error 级别以上的日志。

优化硬件、

优化硬件设备一直是最快速有效的手段。

在经济压力能承受的范围下， 尽量使用固态硬盘 SSD。SSD 相对于机器硬盘，无论随机写还是顺序写，都较大的提升。
磁盘备份采用 RaiD0。因为 Elasticsearch 在自身层面通过副本，已经提供了备份的功能，所以不需要利用磁盘的备份功能，同时如果使用磁盘备份功能的话，对写入速度有较大的影响。
增加 Refresh 时间间隔
为了提高索引性能，Elasticsearch 在写入数据时候，采用延迟写入的策略，即数据先写到内存中，当超过默认 1 秒 （index.refresh_interval）会进行一次写入操作，就是将内存中 segment 数据刷新到操作系统中，此时我们才能将数据搜索出来，所以这就是为什么 Elasticsearch 提供的是近实时搜索功能，而不是实时搜索功能。

当然像我们的内部系统对数据延迟要求不高的话，我们可以通过延长 refresh 时间间隔，可以有效的减少 segment 合并压力，提供索引速度。在做全链路跟踪的过程中，我们就将 index.refresh_interval 设置为 30s，减少 refresh 次数。

同时，在进行全量索引时，可以将 refresh 次数临时关闭，即 index.refresh_interval 设置为 -1，数据导入成功后再打开到正常模式，比如 30s。

减少副本数量

Elasticsearch 默认副本数量为 3 个，虽然这样会提高集群的可用性，增加搜索的并发数，但是同时也会影响写入索引的效率。

在索引过程中，需要把更新的文档发到副本节点上，等副本节点生效后在进行返回结束。使用 Elasticsearch 做业务搜索的时候，建议副本数目还是设置为 3 个，但是像内部 ELK 日志系统、分布式跟踪系统中，完全可以将副本数目设置为 1 个。

查询效率优化

路由

当我们查询文档的时候，Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？它其实是通过下面这个公式来计算出来

shard = hash(routing) % number_of_primary_shards

routing 默认值是文档的 id，也可以采用自定义值，比如用户 id。

不带 routing 查询

在查询的时候因为不知道要查询的数据具体在哪个分片上，所以整个过程分为 2 个步骤

分发：请求到达协调节点后，协调节点将查询请求分发到每个分片上。
聚合: 协调节点搜集到每个分片上查询结果，在将查询的结果进行排序，之后给用户返回结果。
带 routing 查询
查询的时候，可以直接根据 routing 信息定位到某个分配查询，不需要查询所有的分配，经过协调节点排序。

向上面自定义的用户查询，如果 routing 设置为 userid 的话，就可以直接查询出数据来，效率提升很多。

Filter VS Query

Ebay 曾经分享过他们使用 Elasticsearch 的经验中说到：

Use filter context instead of query context if possible.
尽可能使用过滤器上下文（Filter）替代查询上下文（Query

Query：此文档与此查询子句的匹配程度如何？
Filter：此文档和查询子句匹配吗？
Elasticsearch 针对 Filter 查询只需要回答「是」或者「否」，不需要像 Query 查询一下计算相关性分数，同时 Filter 结果可以缓存。

大翻页

在使用 Elasticsearch 过程中，应尽量避免大翻页的出现。

正常翻页查询都是从 From 开始 Size 条数据，这样就需要在每个分片中查询打分排名在前面的 From + Size 条数据。协同节点收集每个分配的前 From + Size 条数据。协同节点一共会受到 N * （ From + Size ）条数据，然后进行排序，再将其中 From 到 From + Size 条数据返回出去。

如果 From 或者 Size 很大的话，导致参加排序的数量会同步扩大很多，最终会导致 CPU 资源消耗增大。

可以通过使用 Elasticsearch scroll 和 scroll-scan 高效滚动的方式来解决这样的问题。具体写法，可以参考  Elasticsearch: 权威指南 - scroll 查询

JVM 设置

32G 现象
Elasticsearch 默认安装后设置的堆内存是 1 GB。 对于任何一个业务部署来说， 这个设置都太小了。

比如机器有 64G 内存，那么我们是不是设置的越大越好呢？

其实不是的。

主要 Elasticsearch 底层使用 Lucene。Lucene 被设计为可以利用操作系统底层机制来缓存内存数据结构。 Lucene 的段是分别存储到单个文件中的。因为段是不可变的，这些文件也都不会变化，这是对缓存友好的，同时操作系统也会把这些段文件缓存起来，以便更快的访问。

如果你把所有的内存都分配给 Elasticsearch 的堆内存，那将不会有剩余的内存交给 Lucene。 这将严重地影响全文检索的性能。

标准的建议是把 50％ 的可用内存作为 Elasticsearch 的堆内存，保留剩下的 50％。当然它也不会被浪费，Lucene 会很乐意利用起余下的内存。

同时了解过 ES 的同学都听过过「不要超过 32G」的说法吧。

其实主要原因是 ：JVM 在内存小于 32 GB 的时候会采用一个内存对象指针压缩技术。

在 Java 中，所有的对象都分配在堆上，并通过一个指针进行引用。 普通对象指针（OOP）指向这些对象，通常为 CPU 字长 的大小：32 位或 64 位，取决于你的处理器。指针引用的就是这个 OOP 值的字节位置。

对于 32 位的系统，意味着堆内存大小最大为 4 GB。对于 64 位的系统， 可以使用更大的内存，但是 64 位的指针意味着更大的浪费，因为你的指针本身大了。更糟糕的是， 更大的指针在主内存和各级缓存（例如 LLC，L1 等）之间移动数据的时候，会占用更多的带宽.

所以最终我们都会采用 31 G 设置

-Xms 31g
-Xmx 31g

假设你有个机器有 128 GB 的内存，你可以创建两个节点，每个节点内存分配不超过 32 GB。 也就是说不超过 64 GB 内存给 ES 的堆内存，剩下的超过 64 GB 的内存给 Lucene

TP5如何接入ElasticSearch？

安装环境：window安装为列，Elasticsearch版本Elasticsearch7.14.1

官方下载地址 Download Elasticsearch | Elastic

下载后解压安装包

打开config->修改elasticsearch.yml

修改配置elasticsearch.yml允许外部访问

Http.cors.enabled: true http.cors.allow-origin: "*" http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE http.cors.allow-headers: "X-Requested-With, Content-Type, Content-Length, X-User"

运行es双击以下文件即可

5 、使用head可视化插件，解压直接双击即可，点击连接可以查看是否连接成功

看到以下页面恭喜你安装成功了

tp5安装es扩展使用即可

composer require elasticsearch/elasticsearch

client = ClientBuilder::create()->setHosts(['localhost:9200'])->build();        dump($this->client);    }} 

看到以下界面说明你成功完成了es和PHP配置es的安装完整流程

好了，今天的干货有点多，有问题的留个言，别忘了一键三连，下次我们还会再见！

我是黄啊码，码字的码，退。。。退。。。退。。。朝！ 

来源地址：https://blog.csdn.net/TiaoZhanJi_Xian/article/details/129137515