网站后台排版,wordpress uncode,深圳网站制作公司价位,用qq邮箱做网站转载自 全文搜索#xff01;收藏这篇Solr ElasticSearch 长文就可以搞定 摘自#xff1a;JaJian博кē Java后端技术编者说#xff1a;文章从浅到深#xff0c;描述了什么是全文搜索#xff0c;为什么要使用全文搜索#xff0c;Solr和ElasticSearch的发展和比较。文章比…转载自 全文搜索收藏这篇Solr ElasticSearch 长文就可以搞定 摘自JaJian博кē Java后端技术编者说文章从浅到深描述了什么是全文搜索为什么要使用全文搜索Solr和ElasticSearch的发展和比较。文章比较长建议各位架构师朋友直接跳到结尾处收藏Solr和ElasticSearch的比较图和结论部分为以后自己公司的架构选型提供参考。 正文
最近项目组安排了一个任务项目中用到了基于 Solr 的全文搜索但是该 Solr 搜索云项目不稳定经常查询不出来数据需要手动全量同步。
而且它还是其他团队在维护依赖性太强导致 Solr 服务一出问题我们的项目也基本瘫痪因为所有的依赖查询都无结果数据了。
所以考虑开发一个适配层如果 Solr 搜索出问题自动切换到新的搜索 ES。其实可以通过 Solr 集群或者服务容错等设计来解决该问题。
但是先不考虑本身设计的合理性领导需要开发所以我开始踏上了搭建 ES 服务的道路从零开始因为之前完全没接触过 ES所以通过本系列来记录下自己的开发过程。
本篇文章的总体内容大致如下图 由 ReyCG 精心绘制并提供 什么是全文搜索
什么是全文搜索引擎百度百科中的定义
全文搜索引擎是目前广泛应用的主流搜索引擎。它的工作原理是计算机索引程序通过扫描文章中的每一个词对每一个词建立一个索引指明该词在文章中出现的次数和位置当用户查询时检索程序就根据事先建立的索引进行查找并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。
从定义中我们已经可以大致了解全文检索的思路了为了更详细的说明我们先从生活中的数据说起。
我们生活中的数据总体分为两种
1、结构化数据指具有固定格式或有限长度的数据如数据库元数据等。
2、非结构化数据非结构化数据又可称为全文数据指不定长或无固定格式的数据如邮件Word 文档等。
当然有的地方还会有第三种半结构化数据如 XMLHTML 等当根据需要可按结构化数据来处理也可抽取出纯文本按非结构化数据来处理。
根据两种数据分类搜索也相应的分为两种结构化数据搜索和非结构化数据搜索。
对于结构化数据我们一般都是可以通过关系型数据库(MySQLOracle 等)的 table 的方式存储和搜索也可以建立索引。
对于非结构化数据也即对全文数据的搜索主要有两种方法
1、顺序扫描
2、全文检索
顺序扫描通过文字名称也可了解到它的大概搜索方式即按照顺序扫描的方式查询特定的关键字。
例如给你一张报纸让你找到该报纸中“RNG”的文字在哪些地方出现过。你肯定需要从头到尾把报纸阅读扫描一遍然后标记出关键字在哪些版块出现过以及它的出现位置。
这种方式无疑是最耗时的最低效的如果报纸排版字体小而且版块较多甚至有多份报纸等你扫描完你的眼睛也差不多了。
全文检索对非结构化数据顺序扫描很慢我们是否可以进行优化把我们的非结构化数据想办法弄得有一定结构不就行了吗
将非结构化数据中的一部分信息提取出来重新组织使其变得有一定结构然后对此有一定结构的数据进行搜索从而达到搜索相对较快的目的。
这种方式就构成了全文检索的基本思路。这部分从非结构化数据中提取出的然后重新组织的信息我们称之索引。
还以读报纸为例我们想关注英雄联盟 S8 全球总决赛的新闻假如都是 RNG 的粉丝如何快速找到 RNG 新闻的报纸和版块呢
全文检索的方式就是将所有报纸中所有版块中关键字进行提取如EDGRNGFW战队英雄联盟等。
然后对这些关键字建立索引通过索引我们就可以对应到该关键词出现的报纸和版块。注意区别目录搜索引擎。 为什么要用全文搜索搜索引擎
之前有同事问我为什么要用搜索引擎我们的所有数据在数据库里面都有而且 Oracle、SQL Server 等数据库里也能提供查询检索或者聚类分析功能直接通过数据库查询不就可以了吗
确实我们大部分的查询功能都可以通过数据库查询获得如果查询效率低下还可以通过建数据库索引优化 SQL 等方式提升效率甚至通过引入缓存来加快数据的返回速度。
如果数据量更大就可以分库分表来分担查询压力。那为什么还要全文搜索引擎呢我们主要从以下几个原因分析
数据类型
全文索引搜索支持非结构化数据的搜索可以更好地快速搜索大量存在的任何单词或单词组的非结构化文本。
例如 Google百度类的网站搜索它们都是根据网页中的关键字生成索引我们在搜索的时候输入关键字它们会将该关键字即索引匹配到的所有网页返回还有常见的项目中应用日志的搜索等等。
对于这些非结构化的数据文本关系型数据库搜索不是能很好的支持。
索引的维护
一般传统数据库全文检索都实现的很鸡肋因为一般也没人用数据库存文本字段。
进行全文检索需要扫描整个表如果数据量大的话即使对 SQL 的语法优化也收效甚微。
建立了索引但是维护起来也很麻烦对于 insert 和 update 操作都会重新构建索引。
什么时候使用全文搜索引擎
1、搜索的数据对象是大量的非结构化的文本数据。
2、文件记录量达到数十万或数百万个甚至更多。
3、支持大量基于交互式文本的查询。
4、需要非常灵活的全文搜索查询。
5、对高度相关的搜索结果有特殊需求但是没有可用的关系数据库可以满足。
6、对不同记录类型、非文本数据操作或安全事务处理的需求相对较少的情况。 LuceneSolrElasticSearch
现在主流的搜索引擎大概就是LuceneSolrElasticSearch。 它们的索引建立都是根据倒排索引的方式生成索引何谓倒排索引
维基百科倒排索引英语Inverted index也常被称为反向索引、置入档案或反向档案是一种索引方法被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据结构。
Lucene
Lucene 是一个 Java 全文搜索引擎完全用 Java 编写。Lucene 不是一个完整的应用程序而是一个代码库和 API可以很容易地用于向应用程序添加搜索功能。Lucene 通过简单的 API 提供强大的功能
可扩展的高性能索引
1、在现代硬件上超过 150GB /小时。
2、小 RAM 要求只有 1MB 堆。
3、增量索引与批量索引一样快。
4、索引大小约为索引文本大小的 20-30。
强大准确高效的搜索算法
1、排名搜索首先返回最佳结果。
2、许多强大的查询类型短语查询通配符查询邻近查询范围查询等。
3、现场搜索例如标题作者内容。
4、按任何字段排序。
5、使用合并结果进行多索引搜索。
6、允许同时更新和搜索。
7、灵活的分面突出显示连接和结果分组。
8、快速内存效率和错误容忍的建议。
9、可插拔排名模型包括矢量空间模型和 Okapi BM25。
10、可配置存储引擎编解码器。
跨平台解决方案
1、作为 Apache 许可下的开源软件提供 允许您在商业和开源程序中使用 Lucene。
2、100-pure Java。
3、可用的其他编程语言中的实现是索引兼容的。
Apache 软件基金会
1、获得 Apache 软件基金会提供的开源软件项目的 Apache 社区的支持。
2、但是 Lucene 只是一个框架要充分利用它的功能需要使用 Java并且在程序中集成 Lucene。
3、需要很多的学习了解才能明白它是如何运行的熟练运用 Lucene 确实非常复杂。
Solr
Apache Solr 是一个基于名为 Lucene 的 Java 库构建的开源搜索平台。它以用户友好的方式提供 Apache Lucene 的搜索功能。
作为一个行业参与者已近十年它是一个成熟的产品拥有强大而广泛的用户社区。
它提供分布式索引复制负载平衡查询以及自动故障转移和恢复。如果它被正确部署然后管理得好它就能够成为一个高度可靠可扩展且容错的搜索引擎。
很多互联网巨头如 NetflixeBayInstagram 和亚马逊CloudSearch都使用 Solr因为它能够索引和搜索多个站点。
主要功能列表包括
1、全文搜索
2、突出
3、分面搜索
4、实时索引
5、动态群集
6、数据库集成
7、NoSQL 功能和丰富的文档处理例如 Word 和 PDF 文件
ElasticSearch
Elasticsearch 是一个开源Apache 2 许可证基于 Apache Lucene 库构建的 RESTful 搜索引擎。
Elasticsearch 是在 Solr 之后几年推出的。它提供了一个分布式多租户能力的全文搜索引擎具有 HTTP Web 界面REST和无架构 JSON 文档。
Elasticsearch 的官方客户端库提供 JavaGroovyPHPRubyPerlPython.NET 和 Javascript。
分布式搜索引擎包括可以划分为分片的索引并且每个分片可以具有多个副本。
每个 Elasticsearch 节点都可以有一个或多个分片其引擎也可以充当协调器将操作委派给正确的分片。
Elasticsearch 可通过近实时搜索进行扩展。其主要功能之一是多租户。主要功能列表包括
1、分布式搜索
2、多租户
3、分析搜索
4、分组和聚合 Elasticsearch vs Solr 的选择
由于 Lucene 的复杂性一般很少会考虑它作为搜索的第一选择排除一些公司需要自研搜索框架底层需要依赖 Lucene。
所以这里我们重点分析哪一个更好它们有什么不同你应该使用哪一个 历史比较
Apache Solr 是一个成熟的项目拥有庞大而活跃的开发和用户社区以及 Apache 品牌。
Solr 于 2006 年首次发布到开源长期以来一直占据着搜索引擎领域并且是任何需要搜索功能的人的首选引擎。
它的成熟转化为丰富的功能而不仅仅是简单的文本索引和搜索如分面分组强大的过滤可插入的文档处理可插入的搜索链组件语言检测等。
Solr 在搜索领域占据了多年的主导地位。然后在 2010 年左右Elasticsearch 成为市场上的另一种选择。
那时候它远没有 Solr 那么稳定没有 Solr 的功能深度没有思想分享品牌等等。
Elasticsearch 虽然很年轻但它也自己的一些优势Elasticsearch 建立在更现代的原则上针对更现代的用例并且是为了更容易处理大型索引和高查询率而构建的。
此外由于它太年轻没有社区可以合作它可以自由地向前推进而不需要与其他人用户或开发人员达成任何共识或合作向后兼容或任何其他更成熟的软件通常必须处理。
因此它在 Solr 之前就公开了一些非常受欢迎的功能(例如接近实时搜索英文Near Real-Time Search)。
从技术上讲NRT 搜索的能力确实来自 Lucene它是 Solr 和 Elasticsearch 使用的基础搜索库。
具有讽刺意味的是因为 Elasticsearch 首先公开了 NRT 搜索所以人们将 NRT 搜索与 Elasticsearch 联系在一起。
尽管 Solr 和 Lucene 都是同一个 Apache 项目的一部分但是人们会首先期望 Solr 具有如此高要求的功能。
特征差异比较
这两个搜索引擎都是流行的先进的的开源搜索引擎。它们都是围绕核心底层搜索库 Lucene 构建的但它们又是不同的。
像所有东西一样每个都有其优点和缺点根据您的需求和期望每个都可能更好或更差。
Solr 和 Elasticsearch 都在快速发展所以话不多说先来看下它们的差异清单 了解更多http://solr-vs-elasticsearch.com/
综合比较
另外我们再从以下几个方面来分析下
①近几年的流行趋势
我们查看一下这两种产品的 Google 搜索趋势。谷歌趋势表明与 Solr 相比Elasticsearch 具有很大的吸引力但这并不意味着 Apache Solr 已经死亡。
虽然有些人可能不这么认为但 Solr 仍然是最受欢迎的搜索引擎之一拥有强大的社区和开源支持。 ②安装和配置
与 Solr 相比Elasticsearch 易于安装且非常轻巧。此外您可以在几分钟内安装并运行 Elasticsearch。
但是如果 Elasticsearch 管理不当这种易于部署和使用可能会成为一个问题。
基于 JSON 的配置很简单但如果要为文件中的每个配置指定注释那么它不适合您。
总的来说如果您的应用使用的是 JSON那么 Elasticsearch 是一个更好的选择。
否则请使用 Solr因为它的 schema.xml 和 solrconfig.xml 都有很好的文档记录。
③社区
Solr 拥有更大更成熟的用户开发者和贡献者社区。ES 虽拥有的规模较小但活跃的用户社区以及不断增长的贡献者社区。
Solr 是真正的开源社区代表。任何人都可以为 Solr 做出贡献并且根据优点选出新的 Solr 开发人员也称为提交者。
Elasticsearch 在技术上是开源的但在精神上却不那么重要。任何人都可以看到来源任何人都可以更改它并提供贡献但只有 Elasticsearch 的员工才能真正对 Elasticsearch 进行更改。
Solr 贡献者和提交者来自许多不同的组织而 Elasticsearch 提交者来自单个公司。
④成熟度
Solr 更成熟但 ES 增长迅速我认为它稳定。
⑤文档
Solr 在这里得分很高。它是一个非常有据可查的产品具有清晰的示例和 API 用例场景。
Elasticsearch 的文档组织良好但它缺乏好的示例和清晰的配置说明。 总结
那么到底是选择 Solr 还是 Elasticsearch有时很难找到明确的答案。无论您选择 Solr 还是 Elasticsearch首先需要了解正确的用例和未来需求总结它们的每个属性。
记住下面这些要点
1、由于易于使用Elasticsearch 在新开发者中更受欢迎。但是如果您已经习惯了与 Solr 合作请继续使用它因为迁移到 Elasticsearch 没有特定的优势。
2、如果除了搜索文本之外还需要它来处理分析查询Elasticsearch 是更好的选择。
3、如果需要分布式索引则需要选择 Elasticsearch。对于需要良好可伸缩性和性能的云和分布式环境Elasticsearch 是更好的选择。
4、两者都有良好的商业支持咨询生产支持整合等。
5、两者都有很好的操作工具尽管 Elasticsearch 因其易于使用的 API 而更多地吸引了 DevOps 人群因此可以围绕它创建一个更加生动的工具生态系统。
6、Elasticsearch 在开源日志管理用例中占据主导地位许多组织在 Elasticsearch 中索引它们的日志以使其可搜索。虽然 Solr 现在也可以用于此目的但它只是错过了这一想法。
7、Solr 仍然更加面向文本搜索。另一方面Elasticsearch 通常用于过滤和分组分析查询工作负载而不一定是文本搜索。
8、Elasticsearch 开发人员在 Lucene 和 Elasticsearch 级别上投入了大量精力使此类查询更高效(降低内存占用和 CPU 使用)。
9、因此对于不仅需要进行文本搜索而且需要复杂的搜索时间聚合的应用程序Elasticsearch 是一个更好的选择。
10、Elasticsearch 更容易上手一个下载和一个命令就可以启动一切。Solr 传统上需要更多的工作和知识但 Solr 最近在消除这一点上取得了巨大的进步现在只需努力改变它的声誉。
11、在性能方面它们大致相同。我说“大致”因为没有人做过全面和无偏见的基准测试。对于 95 的用例任何一种选择在性能方面都会很好剩下的 5 需要用它们的特定数据和特定的访问模式来测试这两种解决方案。
12、从操作上讲Elasticsearch 使用起来比较简单它只有一个进程。Solr 在其类似 Elasticsearch 的完全分布式部署模式 SolrCloud 中依赖于 Apache ZooKeeperZooKeeper 是超级成熟超级广泛使用等等但它仍然是另一个活跃的部分。
13、也就是说如果您使用的是 HadoopHBaseSparkKafka 或其他一些较新的分布式软件您可能已经在组织的某个地方运行 ZooKeeper。
14、虽然 Elasticsearch 内置了类似 ZooKeeper 的组件 Xen但 ZooKeeper 可以更好地防止有时在 Elasticsearch 集群中出现的可怕的裂脑问题。
15、公平地说Elasticsearch 开发人员已经意识到这个问题并致力于改进 Elasticsearch 的这个方面。
16、如果您喜欢监控和指标那么使用 Elasticsearch您将会进入天堂。这个东西比新年前夜在时代广场可以挤压的人有更多的指标Solr 暴露了关键指标但远不及 Elasticsearch 那么多。
总之两者都是功能丰富的搜索引擎只要设计和实现得当它们或多或少都能提供相同的性能。
