Google,百度类的网站搜索,它们都是根据网页中的关键字生成索引,我们在搜索的时候输入关键字,它们会将该关键字即索引匹配到的所有网页返回;还有常见的项目中应用日志的搜索等等。对于这些非结构化的数据文本,关系型数据库搜索不是能很好的支持。
<br/>
一般传统数据库,全文检索都实现的很鸡肋,因为一般也没人用数据库存文本字段。进行全文检索需要扫描整个表,如果数据量大的话即使对 SQL 的语法优化,也收效甚微。建立了索引,但是维护起来也很麻烦,对于 insert 和 update 操作都会重新构建索引。
<br/>
基于以上原因可以分析得出,在一些生产环境中,使用常规的搜索方式,性能是非常差的:
* 搜索的数据对象是大量的非结构化的文本数据。
* 文件记录量达到数十万或数百万个甚至更多。
* 支持大量基于交互式文本的查询。
* 需求非常灵活的全文搜索查询。
* 对高度相关的搜索结果的有特殊需求,但是没有可用的关系数据库可以满足。
对不同记录类型、非文本数据操作或安全事务处理的需求相对较少的情况。为了解决结构化数据搜索和非结构化数据搜索性能问题,我们就需要专业,健壮,强大的全文搜索引擎。
<br/>
这里说到的全文搜索引擎指的是目前广泛应用的主流搜索引擎。它的工作原理是计算机索引程序<mark>通过扫描文章中的每一个词,对每一个词建立一个索引,指明该词在文章中出现的次数和位置,当用户查询时,检索程序就根据事先建立的索引进行查找,并将查找的结果反馈给用户的检索方式</mark>。这个过程类似于通过字典中的检索字表查字的过程。
- Elasticsearch是什么
- 全文搜索引擎
- Elasticsearch与Solr
- 数据结构
- 安装Elasticsearch
- Linux单机安装
- Windows单机安装
- 安装Kibana
- Linux安装
- Windows安装
- es基本语句
- 索引操作
- 文档操作
- 映射操作
- 高级查询
- es-JavaAPI
- maven依赖
- 索引操作
- 文档操作
- 高级查询
- es集群搭建
- Linux集群搭建
- Windows集群搭建
- 核心概念
- 索引(Index)
- 类型(Type)
- 文档(Document)
- 字段(Field)
- 映射(Mapping)
- 分片(Shards)
- 副本(Replicas)
- 分配(Allocation)
- 系统架构
- 分布式集群
- 单节点集群
- 故障转移
- 水平扩容
- 应对故障
- 路由计算
- 分片控制
- 写流程
- 读流程
- 更新流程
- 多文档操作流程
- 分片原理
- 倒排索引
- 文档搜索
- 动态更新索引
- 近实时搜索
- 持久化变更
- 段合并
- 文档分析
- 内置分析器
- 分析器使用场景
- 测试分析器
- 指定分析器
- 自定义分析器
- 文档处理
- 文档冲突
- 乐观并发控制
- 外部系统版本控制
- es优化
- 硬件选择
- 分片策略
- 合理设置分片数
- 推迟分片分配
- 路由选择
- 写入速度优化
- 批量数据提交
- 优化存储设备
- 合理使用合并
- 减少Refresh的次数
- 加大Flush设置
- 减少副本的数量
- 内存设置
- 重要配置
- es常见问题
- 为什么要使用Elasticsearch
- master选举流程
- 集群脑裂问题
- 索引文档流程
- 更新和删除文档流程
- 搜索流程
- ES部署在Linux时的优化方法
- GC方面ES需要注意的点
- ES对大数据量的聚合实现
- 并发时保证读写一致性
- 字典树
- ES的倒排索引
- Spring Data Elasticsearch
- 环境搭建
- 索引操作
- 文档操作