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