最近，项目组布置了一个任务。项目中使用了基于solr的全文搜索。但是Solr搜索云项目不稳定，不能经常查询数据，需要手动全量同步。而且是其他团队维护的，依赖太强，导致Solr服务出现问题，我们的项目基本瘫痪，因为所有依赖的查询都没有结果数据。所以考虑开发一个适配层，如果Solr搜索出现问题，会自动切换到新的搜索ES。其实这个问题可以通过设计Solr集群或者服务容错来解决。但是先不管自身设计的合理性，领导需要开发，所以我走上了搭建ES服务的道路，从头开始，因为之前没有接触过ES，所以通过这个系列记录一下自己的开发过程.本文整体内容大致如下：图片由ReyCG精心绘制并提供什么是全文搜索什么是全文搜索引擎？百度百科中的定义：全文搜索引擎是目前广泛使用的主流搜索引擎。其工作原理是计算机索引程序扫描文章中的每一个词，为每一个词建立索引，标明该词在文章中的编号和位置。当用户查询时，检索程序使用预先建立的索引Search，并将搜索结果反馈给用户的检索方法。这个过程类似于通过词典中的搜索词表查找单词的过程。从定义上，我们已经可以对全文检索的思想有一个大概的了解。更详细的解释，还是从生活中的数据说起吧。我们生活中的数据一般分为两种：结构化数据：指格式固定或长度有限的数据，如数据库、元数据等。非结构化数据：非结构化数据也可称为全文数据，指的是到变长或无固定格式的数据，如邮件、Word文档等。当然有些地方还会有第三种：半结构化数据，如XML、HTML等，可以处理为结构化数据，也可以从纯文本中提取出来，作为非结构化数据进行处理。根据这两种数据分类，搜索也分为结构化数据搜索和非结构化数据搜索两种。对于结构化数据，我们一般可以通过关系型数据库（MySQL、Oracle等）的表进行存储和查找，也可以建立索引。对于非结构化数据，即全文数据的检索主要有两种方式：顺序扫描全文检索顺序扫描：也可以通过文本名称知道其通用的检索方式，即按顺序查询特定的关键词扫描方式。比如给你一张报纸，让你找出报纸上出现“RNG”字样的地方。你肯定需要把报纸从头到尾扫一遍，然后标出这个关键词出现在哪些版块，出现在什么地方。这种方法无疑是最耗时、效率最低的。如果报纸的排版字体很小，而且版面很多，甚至是多份报纸，眼睛扫一眼就差不多够用了。全文检索：非结构化数据的顺序扫描很慢，能否优化？想办法让我们的非结构化数据有一定的结构还不够吗？将非结构化数据中的部分信息提取出来，重新组织起来，使其具有一定的结构，然后对具有一定结构的数据进行搜索，从而达到比较快速搜索的目的。这种方法构成了全文检索的基本思想。这部分信息是从非结构化数据中提取出来，然后重新组织的，我们称之为索引。以阅读报纸为例。我们要关注英雄联盟S8全球总决赛的消息。如果我们都是RNG的粉丝，如何快速找到RNG新闻的报纸和版块呢？全文搜索的方法是提取所有报纸所有栏目中的关键词，如“EDG”、“RNG”、“FW”、“战队”、“英雄联盟”等。然后对这些关键词进行索引，通过索引，我们可以对应到该关键词出现的报纸和版块。注意目录搜索引擎之间的区别。为什么要用全文搜索引擎之前有同事问我，为什么要用搜索引擎？我们所有的数据都存在于数据库中，Oracle、SQLServer等数据库也可以提供查询检索或聚类分析功能。直接通过数据库查询不就行了吗？确实，我们的大部分查询功能都可以通过数据库查询得到。如果查询效率低下，我们还可以通过建立数据库索引、优化SQL等方式来提高效率，甚至可以通过引入缓存来加快数据的返回速度。如果数据量较大，可以分库分表分担查询压力。那么，为什么要费心使用全文搜索引擎呢？我们主要从以下几个方面来分析：数据类型的全文索引搜索支持非结构化数据的搜索，可以更好、更快速地搜索大量存在的任意词或词组的非结构化文本。比如谷歌、百度网站搜索，它们都是根据网页中的关键字生成索引，当我们在搜索时输入关键字，它们会返回所有匹配该关键字的网页，即索引；还有常见的项目在应用程序日志中搜索等等。对于这些非结构化的数据文本，关系数据库搜索并没有得到很好的支持。索引维护一般在传统数据库中实现，全文搜索很差，因为一??般没有人使用数据清单的文本字段。全文搜索需要扫描整个表。如果数据量很大，即使优化SQL的语法也收效甚微。索引建立起来了，但是维护起来也很麻烦。将为插入和更新操作重建索引。何时使用全文搜索引擎：要搜索的数据对象是大量的非结构化文本数据。档案记录达数十万或数百万甚至更多。支持大量基于文本的交互式查询。需要非常灵活的全文搜索查询。对高度相关的搜索结果有特殊的需求，但没有可用的关系数据库可以满足这一需求。对不同记录类型、非文本数据操作或安全事务处理的需求相对较少的情况。Lucene、Solr、ElasticSearch？目前主流的搜索引擎大概有：Lucene、Solr、ElasticSearch。图片的索引是基于倒排索引的。什么是倒排索引？维基百科：倒排索引（英文：Invertedindex），也常被称为反向索引、放置文件或反向文件，是一种索引方法，用于在全文搜索下存储文档中的一个词或一个存储位置的映射文件集。它是文档检索系统中最常用的数据结构。LuceneLucene是一个完全用Java编写的Java全文搜索引擎。Lucene不是一个完整的应用程序，而是一个代码库和API，可以方便地用于为应用程序添加搜索功能。Lucene通过简单的API提供强大的功能：可扩展的高性能索引：在现代硬件上超过150GB/小时。RAM要求小，只有1MB堆。增量索引与批量索引一样快。索引大小约为索引文本大小的20-30%。强大、准确、高效的搜索算法：排名搜索：首先返回最佳结果。许多强大的查询类型：短语查询、通配符查询、邻近查询、范围查询等。现场搜索（例如标题、作者、内容）。按任何字段排序。具有合并结果的多索引搜索。允许同时更新和搜索。结果的灵活分面、突出显示、连接和分组。快速、内存高效且容错的建议。可插入排名模型，包括向量空间模型和OkapiBM25。可配置的存储引擎（编解码器）。跨平台解决方案：在Apache许可下作为开源软件提供，允许您在商业和开源程序中使用Lucene。100%-纯Java。可用的其他编程语言的实现是索引兼容的。Apache软件基金会：从Apache软件基金会获得Apache社区对开源软件项目的支持。但Lucene只是一个框架。要充分利用它的功能，需要使用Java，在程序中集成Lucene。要理解它的工作原理需要大量的学习和理解，而熟练使用Lucene确实非常复杂。SolrApacheSolr是建立在名为Lucene的Java库之上的开源搜索平台。它以用户友好的方式提供ApacheLucene的搜索功能。近十年的行业参与者，它是一个成熟的产品，拥有强大而广泛的用户社区。它提供分布式索引、复制、负载平衡查询以及自动故障转移和恢复。如果部署和管理得当，它可以成为一个高度可靠、可扩展和容错的搜索引擎。Netflix、eBay、Instagram和亚马逊(CloudSearch)等许多互联网巨头都使用Solr，因为它能够索引和搜索多个站点。主要功能列表包括：全文搜索突出显示的分面搜索实时索引动态集群数据库集成的NoSQL功能和丰富的文档处理（例如Word和PDF文件）ElasticSearchElasticsearch是开源的（Apache2许可），RESTful搜索建立在ApacheLucene库引擎之上。Elasticsearch在Solr推出几年后推出。它提供了一个分布式的、具有多租户能力的全文搜索引擎，带有HTTP网络接口(REST)和无模式的JSON文档。Elasticsearch的官方客户端库支持Java、Groovy、PHP、Ruby、Perl、Python、.NET和Javascript。分布式搜索引擎包含一个索引，可以将其划分为分片，每个分片可以有多个副本。每个Elasticsearch节点可以有一个或多个分片，它的引擎也可以充当协调器，将操作委托给正确的分片。Elasticsearch通过近乎实时的搜索进行扩展。它的主要特点之一是多租户。主要功能列表包括：分布式搜索多租户分析搜索分组聚合E??lasticsearchvsSolr的选择由于Lucene的复杂性，一般很少将其作为搜索的首选，排除一些需要自己开发的公司搜索框架，底层需要依赖Lucene。那么这里我们重点说说哪个更好呢？它之间有什么不同？你应该使用哪一个？Image历史比较ApacheSolr是一个成熟的项目，拥有庞大而活跃的开发和用户社区，以及Apache品牌。Solr于2006年首次开源，长期以来一直主导着搜索引擎领域，是任何需要搜索功能的人的首选引擎。它的成熟转化为丰富的功能，而不仅仅是简单的文本索引和搜索；例如分面、分组、强大的过滤、可插入的文档处理、可插入的搜索链组件、语言检测等等。Solr在搜索领域占据主导地位多年。然后，在2010年左右，Elasticsearch成为市场上的另一种选择。当年，它远没有Solr那么稳定，没有Solr的功能深度、思想份额、品牌等。Elasticsearch虽然年轻，但也有自己的一些优势。Elasticsearch基于更现代的原则构建，面向更现代的用例，旨在更轻松地处理大型索引和高查询率。此外，由于它还很年轻，没有可与之协作的社区，因此它可以自由前进，而无需与其他人（用户或开发人员）达成任何共识或合作、向后兼容性或任何其他更成熟的软件通常必须处理的事情。因此，它在Solr之前暴露了一些非常流行的特性（例如，近实时搜索，英文：NearReal-TimeSearch）。从技术上讲，NRT搜索的强大功能确实来自Lucene，这是Solr和Elasticsearch使用的底层搜索库。具有讽刺意味的是，由于Elasticsearch首先公开了NRT搜索，因此人们将NRT搜索与Elasticsearch联系在一起。尽管Solr和Lucene都是同一个Apache项目的一部分，但人们首先会期望Solr具有如此苛刻的功能。功能差异比较这两种搜索引擎都是流行的、高级的开源搜索引擎。它们都是围绕核心底层搜索库Lucene构建的，但又有所不同。像所有事物一样，每个事物都有其优点和缺点，并且每个事物都可以根据您的需求和期望而变得更好或更坏。Solr和Elasticsearch都在快速发展，废话不多说，让我们来看看它们的区别列表：图片了解更多：http://solr-vs-elasticsearch.com/综合比较此外，我们将从下面我们从两个方面来分析一下：①近几年的流行趋势我们来看看这两款产品的谷歌搜索趋势。GoogleTrends显示Elasticsearch与Solr相比有很大的吸引力，但这并不意味着ApacheSolr已经死了。尽管有些人可能不这么认为，但Solr仍然是最受欢迎的搜索引擎之一，拥有强大的社区和开源支持。图②安装配置Elasticsearch相对于Solr，安装方便，非常轻量级。此外，您可以在几分钟内启动并运行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，您首先需要了解正确的用例和未来的需求，总结它们的每个属性。请牢记以下几点：由于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中依赖于ApacheZooKeeper，ZooKeeper超成熟，超广泛使用等等，但它仍然是另一个活跃的部分。也就是说，如果您正在使用Hadoop、HBase、Spark、Kafka或其他一些较新的分布式软件，您可能已经在组织中的某个地方运行了ZooKeeper。虽然Elasticsearch内置了一个名为Xen的类似ZooKeeper的组件，但ZooKeeper更擅长防止Elasticsearch集群中有时会出现的可怕的脑裂问题。公平地说，Elasticsearch开发人员意识到了这个问题，并一直致力于改进Elasticsearch的这一方面。如果您喜欢监控和指标，那么Elasticsearch会让您如痴如醉。这玩意的指标比除夕夜你挤在时代广场的任何人都多！Solr公开了关键指标，但远不及Elasticsearch。总之，两者都是功能丰富的搜索引擎，如果设计和实施得当，它们可以提供或多或少相同的性能。
