Lucene和elasticsearch
Lucene定义
Lucene是一个全文搜索框架，本质是给搜索内容定位。
Lucene是一个高性能、可伸缩的信息搜索(IR)库。它可以为你的应用程序添加索引和搜索能力。Lucene是用java实现的、成熟的开源项目，是著名的Apache Jakarta大家庭的一员，并且基于Apache软件许可 [ASF, License]。同样，Lucene是当前非常流行的、免费的Java信息搜索(IR)库。
优点：
（1）索引文件格式独立于应用平台。Lucene定义了一套以8位字节为基础的索引文件格式，使得兼容系统或者不同平台的应用能够共享建立的索引文件。
（2）在传统全文检索引擎的倒排索引的基础上，实现了分块索引，能够针对新的文件建立小文件索引，提升索引速度。然后通过与原有索引的合并，达到优化的目的。
（3）优秀的面向对象的系统架构，使得对于Lucene扩展的学习难度降低，方便扩充新功能。
（4）设计了独立于语言和文件格式的文本分析接口，索引器过接受Token流完成索引文件的创立，用户扩展新的语言和文件格式，只需要实现文本分析的接口。
（5）已经默认实现了一套强大的查询引擎，用户无需自己编写代码即可使系统可获得强大的查询能力，Lucene的查询实现中默认实现了布尔操作、模糊查询（Fuzzy Search[11]）、分组查询等等。
ElasticSearch定义
ElasticSearch是一个基于Lucene的搜索服务器，是一个实时的分布式搜索和分析引擎。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。它可以帮助你用前所未有的速度去处理大规模数据，可以用于全文搜索，结构化搜索以及分析，也可以将这三者进行组合。
Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
主要特性
1、 通过es可以轻松地使用lucene的搜索功能，并搜索数据。
2、 在lucene提供的功能之上，es添加了其自己的高级功能，从缓存到实时性分析。
3、 多个索引可以单独搜索、也可以同时搜索，还可以将不同类型的文档放入不同的索引。
4、像es的名字一样，具有灵活性。默认它就是集群化的（即使在单台服务器上运行，也称为集群），并且总是可以添加更多的服务器用于增加容量或容错性。如果负载较低，可以很容易地从集群中移除服务器降低成本。
倒排索引
倒排索引（Inverted index），常被称为反向索引、置入档案或反向档案，是一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据结构。通过倒排索引，可以根据单词快速获取包含这个单词的文档列表。倒排索引主要由两个部分组成：“单词词典”和“倒排文件”。
单词词典(Lexicon)：搜索引擎的通常索引单位是单词，单词词典是由文档集合中出现过的所有单词构成的字符串集合，单词词典内每条索引项记载单词本身的一些信息以及指向“倒排列表”的指针。
倒排文件(Inverted File)：所有单词的倒排列表往往顺序地存储在磁盘的某个文件里，这个文件即被称之为倒排文件，倒排文件是存储倒排索引的物理文件。
倒排索引有两种不同的反向索引形式：
一条记录的水平反向索引（或者反向档案索引）包含每个引用单词的文档的列表。
一个单词的水平反向索引（或者完全反向索引）又包含每个单词在一个文档中的位置。
后者的形式提供了更多的兼容性（比如短语搜索），但是需要更多的时间和空间来创建。
现代搜索引擎的索引都是基于倒排索引。相比“签名文件”、“后缀树”等索引结构，“倒排索引”是实现单词到文档映射关系的最佳实现方式和最有效的索引结构。
ElasticSearch与Solr优缺点对比
Elasticsearch
优点
Elasticsearch是分布式的。不需要其他组件，分发是实时的，被叫做”Push replication”。
Elasticsearch 完全支持 Apache Lucene 的接近实时的搜索。
处理多租户不需要特殊配置，而Solr则需要更多的高级设置。
Elasticsearch 采用 Gateway 的概念，使得完备份更加简单。
各节点组成对等的网络结构，某些节点出现故障时会自动分配其他节点代替其进行工作。
缺点
只有一名开发者（当前Elasticsearch GitHub组织已经不只如此，已经有了相当活跃的维护者）
还不够自动（不适合当前新的Index Warmup API）
Solr
优点
Solr有一个更大、更成熟的用户、开发和贡献者社区。
支持添加多种格式的索引，如：HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。
Solr比较成熟、稳定。
不考虑建索引的同时进行搜索，速度更快。
缺点
建立索引时，搜索效率下降，实时索引搜索效率不高。
Elasticsearch与Solr的比较
(1).Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。
(2).Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能;
(3).Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式；
(4).Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供；
(5).Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。
(6).Solr有一个更大、更成熟的用户、开发和贡献者社区。比较成熟、稳定。
(7).Solr支持添加多种格式的索引，如：HTML、PDF、微软 Office 系列软件格式以及 JSON、XML、CSV 等纯文本格式。
(8).Solr如果不考虑建索引的同时进行搜索，速度更快。
当单纯的对已有数据进行搜索时，Solr更快
当实时建立索引时, Solr会产生io阻塞，查询性能较差 。
实时建立索引 Elasticsearch具有明显的优势
随着数据量的增加，Solr的搜索效率会变得更低，而Elasticsearch却没有明显的变化。
随数据量的增加 搜索效率会变得更低
综上所述，Solr的架构不适合实时搜索的应用。
ElasticSearch分布式架构
Elasticsearch对复杂分布式机制的透明隐藏特性
（1）Elasticsearch是一套分布式的系统，分布式是为了对应大数据量，ES隐藏了复杂的分布式机制，也符合了开箱即用的特点。
（2）分片机制（我们之前随随便便就将一些document插入到es集群中了，我们并不知道数据是怎么进行分片的，数据到哪个shard中了，这是ES内部帮我们做好的，他隐藏了复杂的实现，我们直接用就好了）
（3）cluster discovery （集群发现机制，我们之前在做那个集群status从yellow到green的实验里，直接启动了第二个es进程，那个进程作为一个node自动就发现了集群，并加入了进去，还接受了部分数据，replica shard）
（4）shard负载均衡（举例：假设现在有3个节点，总共有25个shard要分配到3个节点上去，ES会自动进行均匀分配，以保证每个节点的均衡的读写负载请求）
垂直扩容与水平扩容
（1）垂直扩容：采购更强大的服务器，成本非常高昂，而且会有瓶颈。
（2）水平扩容：业界经常采用的方案，采购越来越多的普通服务器，性能比较一般，但是很多普通服务器组织在一起，就能构成强大的计算和存储能力。
假设：6 台服务器，每台容纳 1 T数据，数据量马上要增长到 8 T，这时候两个扩容方案：
（1）垂直扩容：重新购置两台服务器，每台服务器的容量是 2 T，替换掉老的两台服务器，那么现在是 6 台服务器，总容量就是 4 * 1T + 2 * 2T = 8T
（2）水平扩容：重新购置两台服务器，每台服务器的容量是 1 T，直接加入到集群中去，那么现在是 8 台服务器，总容量就是 8 * 1T = 8T（业界几乎都采用这种方式）
数据 rebalance
总有某些节点的负载会重一些，承载的数据量和请求量会大一些。当增加或者减少节点时数据 rebalance，以保持负载均衡。
master节点
一个es集群中总会有一个node是master节点：
- 管理es集群的元数据：比如说索引的创建和删除、维护索引元数据；节点的增加和移除、维护集群的数据
- 默认情况下，会自动选择出一台节点作为master节点
- master节点不承载所有的请求，所以不会是单点瓶颈
节点平等的分布式架构
（1）节点对等，每个节点都能接收所有的请求
（2）自动请求路由：任何一个节点接收到请求后，都可以把这个请求自动路由到相关节点上去处理该请求。
（3）响应收集：最原始节点会从其他节点接收响应数据，然后把这些数据返回给客户端。
列举通过curl操作ElasticSearch的命令
1、创建索引库：
curl -XPUT http://192.168.9.11:9200/myindex/
2、新建：指定配置
curl -XPUT ‘http://192.168.239.3:9200/test2/’ -d’{“settings”:{“number_of_replicas”:2}}’
3、创建document：
curl -XPOST http://192.168.9.11:9200/myindex/employee -d ’
{
“first_name” : “bin”,
“last_name” : “tang”,
“age” : 33,
“about” : “I love to go rock climbing”,
“interests”: [ “sports”, “music” ]
}’
4、更新document：
curl -XPUT http://192.168.9.11:9200/myindex/employee/1 -d ’
{
“first_name” : “bin”,
“last_name” : “pang”,
“age” : 30,
“about” : “I love to go rock climbing”,
“interests”: [ “sports”, “music” ]
}’
5、根据document的id来查询数据：
curl -XGET http://192.168.9.11:9200/myindex/employee/1?pretty
6、根据field来查询数据：
curl -XGET http://192.168.239.3:9200/myindex/employee/_search?q=first_name=“bin”
7、根据field来查询数据：match
curl -XGET http://192.168.239.3:9200/myindex/book/_search -d ’
{
“query”:
{“match”:
{“name”:“hadoop”}
}
}’
8、对多个field发起查询：multi_match
curl -XGET http://192.168.239.3:9200/myindex/employee/_search -d ’
{
“query”:
{“multi_match”:
{
“query”:“John”,
“fields”:[“last_name”,“first_name”],
“operator”:“or”
}
}
}’
详述elasticsearch搜索项目的工作流程
1、使用分词组件给搜索关键字分词
2、搜索索引，搜索引擎拿着这些拆出来的词去索引文件找对应的词，由于索引文件是有序的，一旦找到就停止向下找，然后获取该词对应的整个文档链表
3、链表合并，对包含关键词的链表进行合并操作，得到包含这些词的所有文档id，最终就得到id文档。最后进行搜索结果相关度排序，使用特定的相关度排序算法，根据词在文档出现的频率和我们提交的排序条件等计算，最终把这些文档id排序，排序好后默认获取前10条文档id，如果用户有提交查询数量，那么就获取用户提交的数量，最后通过文档id查询出整个文档返回给用户
437
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
