【ES】Elasticsearch的特点/优点 为什么比MySQL快?

本文探讨了Elasticsearch作为分布式搜索引擎与传统关系型数据库MySQL在存储、架构、性能和易用性等方面的区别,重点讲解了Elasticsearch的全文检索优势和比MySQL快的原因,包括分词搜索和分布式特性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Elasticsearch的特点

Elasticsearch 是一个分布式、RESTful 风格的搜索和数据分析引擎。
优势:
1)分布式的文件存储,每个字段都被索引且可用于搜索。
2)分布式的实时分析搜索引擎,海量数据下近实时秒级响应。
3)简单的restful api,天生的兼容多语言开发。
4)易扩展,处理PB级结构化或非结构化数据。(pb指petabyte,1PB=1024TB)

Elasticsearch和MySQL的区别

1)在存储上,es是document格式的存储,mysql是行格式的,所以es并不需要显式定义字段,而mysql需要。
2)在架构上,es天然就是分布式的,可以很容易的横向扩容,mysql不行。
3)在针对场景下,es无法做到实时,而mysql可以,因此mysql的OLTP (Online Transactional Processing,联机事务处理)对于es而言需要额外考虑下场景是否适用,可以认为es同时具有oltp和olap的特点,但两边都不是特别突出。
4)在数据存储量及性能上,mysql由于其索引实现(innodb为例)导致在数据量大到一定级别后会出现性能衰减;而es只要给足足够内存就没太大问题。插入速度上如果正确的配置mysql其性能并不低,当然相对于正常状态es而言还是差了一个到多个量级(es>mongo>mysql)。查询速度这个主要看索引和数量,在需要复杂关联查询的时候建议优先考虑mysql。
资源开销上,当数据量上去了后如果为了维持性能的话,es吃内存的能力绝对可以傲视群雄,但毕竟没有不吃草就能跑的快的马儿。
5)易用性上当然是mysql>es。其实刨掉全文检索场景,mysql(5.6以后)加上良好的设计就能很好的支持绝大部分需求了。

6)Elasticsearch会对所有输入的文本进行处理,建立索引放入内存中,从而提高搜索效率。在这一点上ES要优于MySQL的B+树的结构,MySQL需要将索引放入磁盘,每次读取需要先从磁盘读取索引然后寻找对应的数据节点,但是ES能够直接在内存中就找到目标文档对应的大致位置,最大化提高效率。
并且在进行组合查询的时候MySQL的劣势更加明显,它不支持复杂的组合查询比如聚合操作,即使要组合查询也要事先建好索引,但是ES就可以完成这种复杂的操作,默认每个字段都是有索引的,在查询的时候可以各种互相组合。

Elasticsearch比MySQL快的原因

对比:
1)基于分词后的全文检索:例如select * from test where name like ‘%张三%’,对于mysql来说,因为索引失效,会进行全表检索;对es而言分词后,每个字都可以利用FST高速找到倒排索引的位置,并迅速获取文档id列表,大大的提升了性能,减少了磁盘IO。
2)精确检索:进行精确检索,有些时候可能mysql要快一些,当mysql的非聚合索引引用上了聚合索引,无需回表,则速度上可能更快;es还是通过FST找到倒排索引的位置比获取文档id列表,再根据文档id获取文档并根据相关度进行排序。但是es还有个优势,就是es即天然的分布式能够在大量数据搜索时可以通过分片降低检索规模,并且可以通过并行检索提升效率,用filter时,更是可以直接跳过检索直接走缓存。

如果MySQL走索引,谁比较快?

进行精确检索,有些时候可能mysql要快一些,当mysql的非聚合索引引用上了聚合索引,无需回表,则速度上可能更快;es通过FST找到倒排索引的位置比获取文档id列表,再根据文档id获取文档并根据相关度进行排序。但是es还有个优势,就是es即天然的分布式能够在大量数据搜索时可以通过分片降低检索规模,并且可以通过并行检索提升效率,用filter时,更是可以直接跳过检索直接走缓存。

参考

https://zhuanlan.zhihu.com/p/137574234

### Elasticsearch 的数据存储与查询机制 Elasticsearch 并未依赖任何外部关系型数据库作为其底层存储,而是基于 Apache Lucene 构建[^1]。Lucene 是一个高性能、全功能的全文搜索引擎库,它提供了索引搜索的核心能力。Elasticsearch 将文档以 JSON 格式存储,并通过倒排索引的方式加速查询过程。 当用户向 Elasticsearch 发起查询请求时,实际操作的是内部维护的 Lucene 索引结构。这些索引分布在多个分片上,而每个分片本质上是一个独立的 Lucene 索引实例。因此,可以说 Elasticsearch 的数据来源是其自身的分布式索引体系,而非其他类型的底层数据库。 对于某些场景下提到的 MySQL ES 联合使用的案例[^3],这通常是指业务逻辑层面的设计决策。例如,应用可能将元数据保存到 MySQL 中以便于事务管理,同时利用 Elasticsearch 存储并速检索大量非结构化或半结构化的监控日志数据。但这并不意味着 Elasticsearch 自身会使用 MySQL 或其他传统意义上的数据库来完成核心功能——它的所有主要操作仍然围绕着内置的 Lucene 引擎展开。 ```python from elasticsearch import Elasticsearch # 创建连接对象 es_client = Elasticsearch(["http://localhost:9200"]) # 示例:执行简单匹配查询 response = es_client.search( index="example_index", body={ "query": { "match": { "field_name": "search_term" } } } ) print(response['hits']['total']) ``` 上述代码展示了如何通过 Python 客户端访问 Elasticsearch 进行基本查询。值得注意的是,这里的 `index` 参数指定的就是 Elasticsearch 内部由 Lucene 支撑的具体目标集合名称,而不是指向某个第三方 SQL 表格或者记录集。 #### 数据流概述 - **写入流程**: 文档被提交给特定索引后,经过分析器处理转化为适合建立倒排索引的形式。 - **读取/查询流程**: 用户发起 API 请求到达对应节点;协调节点分配任务至相关分片所在物理机器上的工作进程;最终汇总结果返回前端展示层。 综上所述,尽管可以在架构设计里混合多种持久化技术共同服务于复杂需求环境下的不同侧重点[^2],但从纯粹的技术角度看,Elasticsearch 查询的数据完全来源于自己掌控范围内的 Lucene 倒排索引文件群组。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

锥栗

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值