1 什么是全文索引
全文检索：对非结构化数据顺序扫描很慢，我们是否可以进行优化？把我们的非结构化数据想办法弄得有一定结构不就行了吗？
将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。
这种方式就构成了全文检索的基本思路。这部分从非结构化数据中提取出的然后重新组织的信息，我们称之索引。
还以读报纸为例，我们想关注英雄联盟 S8 全球总决赛的新闻，假如都是 RNG 的粉丝，如何快速找到 RNG 新闻的报纸和版块呢？
全文检索的方式就是，将所有报纸中所有版块中关键字进行提取，如"EDG"，"RNG"，"FW"，"战队"，"英雄联盟"等。
然后对这些关键字建立索引，通过索引我们就可以对应到该关键词出现的报纸和版块。注意区别目录搜索引擎。
2 为什么要用全文搜索搜索引擎
之前，有同事问我，为什么要用搜索引擎？我们的所有数据在数据库里面都有，而且 Oracle、SQL Server等数据库里也能提供查询检索或者聚类分析功能，直接通过数据库查询不就可以了吗？
确实，我们大部分的查询功能都可以通过数据库查询获得，如果查询效率低下，还可以通过建数据库索引，优化 SQL 等方式提升效率，甚至通过引入缓存来加快数据的返回速度。
如果数据量更大，就可以分库分表来分担查询压力。那为什么还要全文搜索引擎呢？我们主要从以下几个原因分析：
2.1 数据类型
全文索引搜索支持非结构化数据的搜索，可以更好地快速搜索大量存在的任何单词或单词组的非结构化文本。
例如 Google，百度类的网站搜索，它们都是根据网页中的关键字生成索引，我们在搜索的时候输入关键字，它们会将该关键字即索引匹配到的所有网页返回；还有常见的项目中应用日志的搜索等等。
对于这些非结构化的数据文本，关系型数据库搜索不是能很好的支持。
2.2 索引的维护
一般传统数据库，全文检索都实现的很鸡肋，因为一般也没人用数据库存文本字段。
进行全文检索需要扫描整个表，如果数据量大的话即使对 SQL 的语法优化，也收效甚微。
建立了索引，但是维护起来也很麻烦，对于 insert 和 update 操作都会重新构建索引。
2.3 什么时候使用全文搜索引擎
搜索的数据对象是大量的非结构化的文本数据。
搜索文件记录量达数百万个甚至更多。
支持大量基于交互式文本的查询。
需要非常灵活的全文搜索查询。
对高度相关的搜索结果有特殊需求，但是没有可用的关系数据库可以满足。
对不同记录类型、非文本数据操作或安全事务处理的需求相对较少的情况。
3 Solr
Solr是一个独立的企业搜索服务器，具有类似REST的API。您通过JSON，XML，CSV或二进制文件将文档放入其中（称为“索引”）。您可以通过HTTP GET查询它并接收JSON，XML，CSV或二进制结果。
高级全文搜索功能。Solr支持Lucene，可在任何数据类型中实现强大的匹配功能，包括短语，通配符，连接，分组等功能
基于标准的开放接口-XML，JSON和HTTP。Solr使用您使用的工具快速构建应用程序
综合管理界面。Solr附带内置的响应式管理用户界面，可以轻松控制Solr实例
易于监控。需要更深入了解您的实例？Solr通过JMX发布大量度量数据
高度可扩展和容错。Solr基于经过实战考验的Apache Zookeeper，可以轻松扩展和缩小。Solr开箱即用于复制，分发，重新平衡和容错。
灵活，适应性强，配置简单。Solr's旨在满足您的需求，同时简化配置
近实时索引。Solr利用Lucene的近实时索引功能确保您在想要查看内容时看到您的内容
可扩展插件架构。Solr发布了许多定义明确的扩展点，可以轻松插入索引和查询时插件。当然，由于它是Apache许可的开源，您可以更改您想要的任何代码！
4 Elasticsearch
速度。Elasticsearch 很快。快到不可思议。
可扩展性。可以在笔记本电脑上运行。也可以在承载了 PB 级数据的成百上千台服务器上运行。原型环境和生产环境可无缝切换；无论 Elasticsearch 是在一个节点上运行，还是在一个包含 300 个节点的集群上运行，您都能够以相同的方式与 Elasticsearch 进行通信。
它能够水平扩展，每秒钟可处理海量事件，同时能够自动管理索引和查询在集群中的分布方式，以实现极其流畅的操作。
弹性。硬件故障。网络分割。Elasticsearch为您检测这些故障并确保您的集群（和数据）的安全性和可用性。通过跨集群复制功能，辅助集群可以作为热备份随时投入使用。Elasticsearch运行在一个分布式的环境中，从设计之初就考虑到了这一点，目的只有一个，让您永远高枕无忧。
灵活性。数字、文本、地理位置、结构化数据、非结构化数据。应用搜索、安全分析、指标或日志分析只是全球众多公司利用Elasticsearch解决各种挑战的冰山一角。
操作的乐趣。享受更多成功的时刻，告别垂头丧气的失落简单的事情就该简单做。我们确保 Elasticsearch在任何规模下都能够易于操作，而无需在功能和性能方面做出牺牲。
HADOOP 和 SPARK。您可以使用 Elasticsearch-Hadoop (ES-Hadoop) 连接器，利用 Elasticsearch的实时搜索和分析功能处理您的大数据。这是两大领域最大优势的融合。
5 ElasticSearch vs Solr
5.1数据源
Solr接受来自不同来源的数据，包括XML文件，逗号分隔符（CSV）文件和从数据库中的表提取的数据以及常见的文件格式（如Microsoft Word和PDF）。
Elasticsearch 还支持其他来源的数据，例如ActiveMQ，AWS SQS，DynamoDB（Amazon NoSQL），FileSystem，Git，JDBC，JMS，Kafka，LDAP，MongoDB，neo4j，RabbitMQ，Redis，Solr和Twitter。还有各种插件可用。
5.2搜索
Solr专注于文本搜索，而Elasticsearch则常用于查询、过滤和分组分析统计，Elasticsearch背后的团队也努力让这些查询更为高效。
因此当比较两者时，对那些不仅需要文本搜索，同时还需要复杂的时间序列搜索和聚合的应用程序而言，毫无疑问Elasticsearch是最佳选择。
5.3索引
两者都支持使用停用词和同义词来匹配文档。
在Solr中，索引间进行join必须是单个分片和其他节点上的副本集进行关联来搜索文档间关系（例如SQL连接）。而Elasticsearch提供更高效的has_children和top_children查询来检索这样的相关文档。
5.4可扩展性和分布式
Elasticsearch非常易于扩展，拥有足够多的需要大集群的使用案例。
Solr 基于Apache ZooKeeper也实现了类似ES的分布式部署模式。ZooKeeper是成熟和广泛使用的独立应用程序。
相对比，Elasticsearch有一个内置的类似ZooKeeper的名为Zen的组件，通过内部的协调机制来维护集群状态。
可以说Elasticsearch天生就是分布式的，是转为云而设计，是分布式首选。
5.5社区
Solr有一个广泛的开源社区。任何人都可以贡献给Solr，新的Solr开发人员或代码提交者只能根据功能选择。
Elasticsearch在技术上是开源的，所有贡献者都可以访问源代码，用户可以进行更改并提供。但最终的变化由Elastic（运行Elasticsearch和其他软件的公司）的员工确认和完成。因此，Elasticsearch更多地由单个公司驱动，而不是整个社区。
Solr贡献者和提交者跨越多个组织，而Elasticsearch提交者仅来自Elastic。还有人指出，Solr的强大社区有一个健康的项目管道和许多知名公司参与。这些成员还通过在整个开发和工程过程中做出贡献来投资该平台。
两者都有很好的用户群和丰富的开发人员社区，但ElasticSearch相较于Solr更新。 Solr已经存在了更长的时间，所以它的生态系统是发达的，拥有更大的用户群。
6一句话总结
但是如果你已经在使用solr了，请继续使用它，因为迁移到Elasticsearch并不会带来具体的优势。如果你刚开始使用全文索引，推荐ES，Elasticsearch由于其易用性而在较新的开发人员中更受欢迎。