ElasticSearch全文检索技术

目录

数据检索问题

大规模数据如何检索？

传统数据库的应对解决方案？

非关系型数据库的解决方案？

完全把数据放入内存怎么样？

全文检索技术

什么是全文检索？

全文检索场景

实时搜索与传统搜索

---

ElasticSearch分布式搜索原理解

1. 数据检索问题

   1. 大规模数据如何检索？

当系统数据量上了10亿、100亿条的时候，我们在做系统架构的时候通常会从以下角度去考虑：

1）用什么数据库好？(MySQL、sybase、Oracle、达梦、神通、MongoDB、Hbase…)

2）如何解决单点故障；(lvs、F5、A10、Zookeep、MQ)

3）如何保证数据安全性；(热备、冷备、异地多活)

4）如何解决检索难题；(数据库代理中间件：mysql-proxy、Cobar、MaxScale等;)

5）如何解决统计分析问题；(离线、近实时)

传统数据库的应对解决方案？

对于关系型数据，我们通常采用以下或类似架构去解决查询瓶颈和写入瓶颈：

解决要点：

1）通过主从备份解决数据安全性问题；

2）通过数据库代理中间件心跳监测，解决单点故障问题；

3）通过代理中间件将查询语句分发到各个slave节点进行查询，并汇总结果

4）通过分表分库解决读写效率问题

非关系型数据库的解决方案？

对于Nosql数据库，以redis为例，其它原理类似：

解决要点：

1）通过副本备份保证数据安全性；

2）通过节点竞选机制解决单点问题；

3）先从配置库检索分片信息，然后将请求分发到各个节点，最后由路由节点合并汇总结果

​​​​​​​完全把数据放入内存怎么样？

完全把数据放在内存中是不可靠的，实际上也不太现实，当我们的数据达到PB级别时，按照每个节点96G内存计算，

在内存完全装满的数据情况下，我们需要的机器是：1PB=1024T=1048576G

节点数=1048576/96=10922个

实际上，考虑到数据备份，节点数往往在2.5万台左右。成本巨大决定了其不现实！

从前面我们了解到，把数据放在内存也好，不放在内存也好，都不能完完全全解决问题。

全部放在内存速度问题是解决了，但成本问题上来了。 为解决以上问题，从源头着手分析，通常会从以下方式来寻找方法：

1、存储数据时按有序存储；

2、将数据和索引分离；

3、压缩数据；

全文检索技术： --- 检索的数据是一些非关系型数据，word,pdf,html

全文检索技术

什么是全文检索？

什么叫做全文检索呢？这要从我们生活中的数据说起。

我们生活中的数据总体分为两种：结构化数据和非结构化数据。

• 结构化数据：指具有固定格式或有限长度的数据，如数据库，元数据等。

> 对结构化数据的搜索： 如对数据库的搜索，用SQL语句。再如对元数据的搜索，如利用windows搜索对文件名，类型，修改时间进行搜索等。

• 非结构化数据：指不定长或无固定格式的数据，如 互联网数据、邮件，word文档等。

> 对非结构化数据的搜索： 如用Google和百度可以搜索大量内容数据。

对非结构化数据顺序扫描很慢，对结构化数据的搜索却相对较快，那么把我们的非结构化数据想办法弄得有一定结构不就行了吗？这就是全文检索的基本思路，也即将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。这部分从非结构化数据中提取出的然后重新组织的信息，我们称之索引 。

非结构化数据又一种叫法叫全文数据。

按照数据的分类，搜索也分为两种：

对非结构化数据也即全文数据的搜索主要有两种方法：顺序扫描法和反向索引法。

• 顺序扫描法：所谓顺序扫描法，就是顺序扫描每个文档内容，看看是否有要搜索的关键字，实现查找文档的功能，也就是根据文档找词。
• 反向索引法：所谓反向索引，就是提前将搜索的关键字建成索引，然后再根据索引查找文档，也就是根据词找文档。

这种先建立索引，再对索引进行搜索文档的过程就叫全文检索(Full-text Search)。

​​​​​​​全文检索场景

• 搜索引擎
• 站内搜索
• 系统文件搜索

实时搜索与传统搜索

通常来说，传统搜索都是一些“静态”的搜索，即用户搜索的只是从信息库里边筛选出来的信息。而百度推出的实时搜索功能，改变了传统意义上的静态搜索模式，用户对于搜索的结果是实时变化的。

举个例子，用户在搜索“华山”、“峨眉山”等景点时，实时观看各地景区画面。以华山景区为例，当用户在搜索框中输入“华山”时，点击右侧“实时直播——华山”，即可实时观看华山靓丽风景，并能在华山长空栈道、北峰顶、观日台三个视角之间切换。同时，该直播引入广受年轻人欢迎的“弹幕”模式，用户在观看风景时可以同时发表评论，甚至进行聊天互动。

1. 全文检索相关技术
2. Lucene：如果使用该技术实现，需要对Lucene的API和底层原理非常了解，而且需要编写大量的Java代码。
3. Solr：使用java实现的一个web应用，可以使用rest方式的http请求，进行远程API的调用。
4. ElasticSearch(ES)：可以使用rest方式的http请求，进行远程API的调用。
   1. Solr和ES的比较
      1. ElasticSearch vs Solr 检索速度

• 当单纯的对已有数据进行搜索时，Solr更快。

　

　　　　　　

　　

• 当实时建立索引时, Solr会产生io阻塞，查询性能较差, Elasticsearch具有明显的优势。

• 随着数据量的增加，Solr的搜索效率会变得更低，而Elasticsearch却没有明显的变化。

 

• 大型互联网公司，实际生产环境测试，将搜索引擎从Solr转到Elasticsearch以后的平均查询速度有了50倍的提升。

　

​​​​​​​

​​​​​​​Elasticsearch 与 Solr 的比较总结

• 二者安装都很简单；
• Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能;
• Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式；
• Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供；
• Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。

最终的结论：

Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。

所有文章都是以专栏系列编写，建议系统性学习，更容易成为架构师！
博主每天早晚坚持写博客给与读者价值提升，为了让更多人受益，请多多关照，如果觉得文章质量有帮助到你，请关注我的博客，收藏此文，持续提升，奥利给！
另外我不打算靠运营方式拿到博客专家的认证，纯纯的科技与狠活来征服读者，就看读者的感恩之心了，祝你好运连连。