solr和es（elasticsearch）

本文目录

• elasticsearch
• Linux里面es和Solr区别是什么
• elasticsearch，solr对比各自有哪些优缺点
• Lucene、Elasticsearch、Solr区别

elasticsearch

首先准备环境
ElasticSearch***隐藏网址***
logstash***隐藏网址***
kibana***隐藏网址***
ik***隐藏网址***

ElasticSearch 是一个实时分布式搜索和分析引擎，主要用于全文搜索，结构化搜索，分析以及将这三者混合使用。
Lucene 是一个全文检索引擎的架构。

ElasticSearch vs Solr 总结

（1）es基本是开箱即用，非常简单。Solr安装略微复杂一丢丢，可关注（ solr6.6教程-基础环境搭建(一) ）

（2）Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能。

（3）Solr 支持更多格式的数据，比如JSON、XML、CSV，而 Elasticsearch 仅支持json文件格式。

（4）Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供，例如图形化界面需要kibana友好支撑

（5）Solr 查询快，但更新索引时慢（即插入删除慢），用于电商等查询多的应用；

ES建立索引快（即查询慢），即实时性查询快，用于facebook新浪等搜索。

Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。

（6）Solr比较成熟，有一个更大，更成熟的用户、开发和贡献者社区，而 Elasticsearch相对开发维护者较少，更新太快，学习使用成本较高。

ik分词器：
ik提供了两个分词算法：ik_smart和ik_max_word,其中ik_smart为最少切分，ik_max_word为最细粒度切分。

ik_smart：

ik_max_word：

ik分词器可以增加自己的配置，自己配置词典。

Linux里面es和Solr区别是什么

1.查询性能不同。当实时建立索引的时候,solr会产生io阻塞,而es则不会,es查询性能要高于solr;

2.检索效率不同。在不断动态添加数据的时候,solr的检索效率会变的低下,而es则没有什么变化;

3.管理方式不同。Solr利用zookeeper进行分布式管理,而es自身带有分布式系统管理功能。Solr一般都要部署到web服务器上;

4.文件格式不同。Solr支持更多的格式数据,而es仅支持json文件格式;

elasticsearch，solr对比各自有哪些优缺点

从两个方面对ElasticSearch和Solr进行对比，从关系型数据库中的导入速度和模糊查询的速度。
单机对比
1. Solr 发布了4.0-alpha，试了一下，发现需要自己修改schema，好处是它自带一个data importer。在自己的计算机上测试了一下，导入的性能大概是：14分钟导入 3092730 条记录，约合 3682条/秒。
2. 3百万条记录的情况下，模糊查询和排序基本都在1秒内返回
3. 刚才的测试，是每个field单独存储，现在修改了一下配置文件，增加了一个copyField，所有的field都拷贝一份到text这个field里面去，导入的性能大概是：19分钟导入了3092730 条记录，约合 2713条/秒
4. 3百万条记录的情况下，针对text的模糊查询基本在1秒内返回，但是针对所有记录的排序，大概要2~3秒
5. 使用 elasticsearch 0.19.8，缺省配置，用单任务导入，导入性能是：20分钟导入了3092730 条记录，约合2577条/秒
6. 3百万条记录的情况下，查询基本上在1秒内返回，但是模糊查询比较慢，第一次要10秒，后来大概要1~3秒。加上排序大概需要5秒，整体排序基本100ms
查询及排序的指令：
{
"query": {
"query_string": {
"query": "*999*"
}
},
"sort": [
{
"TIME_UP": {
"order": "asc"
}
}
]
}
7. Es0.19.8，用两个任务导入，导入性能是：13分钟导入了3092730 条记录，约合3965条/秒
8. Solr全部建好索引后，占用磁盘空间是1.2G，es占用磁盘空间是4G
单机对比2
在一台Intel i7，32G内存的机器上，重新跑这两个的对比。不过有个重大的区别在于，Solr是在这台性能很好的机器上跑，而es的导入进程则是在一台Intel 四核 2.5G，4G内存的机器上跑的，也许会有性能的差异。ES版本0.19.8，Solr版本4.0-ALPHA。
1. Solr的导入性能：3400万条记录，用时62分钟，平均9140条/秒，占用空间12.75G
2. 使用 *999* 这样的模糊查询，3秒以内返回，稍长一点的查询条件 *00100014*，也是2~3秒返回
3. Es的导入性能（设置Xmx为10G）：3400万条记录，用时40分钟，平均14167条/秒，占用空间33.26G，客户端采用4个并发。
4. 使用 *999* 这样的模糊查询，9秒返回，稍长一点的查询条件 *00100014*，11.8秒返回
5. 如果不是针对所有字段查询，而是针对某个特定字段，比如 SAM_CODE: *00100014*，那么也是1秒以内返回。
6. 结论：es的查询效率也可以很高，只是我们还不会用。
7. 结论2：es有个设置是把所有字段放一块的那个，缺省是放一起，但是不知道为什么没起到应有的作用。
备注：
1. Solr第一次的那个内存使用的是缺省设置，这次改为10G，结果导入性能反而变差了，400万条记录，用了8分钟，平均8333条/秒，不知道为什么。
2. 改回缺省的内存配置，导入速度仍然慢。
3. 重启Linux，用10G的内存配置，再导入，5030万条记录，用时92分，约9112条/秒，说明导入速度和内存配置没有大差别
4. 在10G配置的情况下，检索速度也差别不大。
5. 为了搞清楚lucene4.0和solr4.0的进步有多大，下载了solr3.6.1，所幸的是4.0的配置文件在3.6.1上也可以用，所以很快就搭起来进行测试，导入性能为：3400万条记录，用时55分钟，约10303条/秒，占用空间13.85G。查询性能：*999*第一次11.6s，*00100014* 27.3s，相比4.0ALPHA的结果（5000万结果当中，*999*第一次2.6s，*00100014*第一次2.5s）来说，慢了很多，与es的性能差不多，因此，也许lucene4.0真的对性能有大幅提升？
集群对比：
采用4台同样配置（Intel i7，32G内存）的Centos 6.3组成的集群，进行对比。
1. 首先是es，很方便的就组成了一个Cluster，等上一个3400万条的Index全部均衡负载之后进行测试，导入到另外一个Index当中。
2. 导入性能：8500万条记录，用时72分钟，约为19676条/秒。在前5千万条记录导入时的速度在2万/条以上，初始的速度在2.2万/条。占用空间78.6G（由于有冗余，实际占用空间为157.2G）
3. 查询性能：
*999*第一次13.5秒，第二次19.5秒，第三次7.4秒，第四次7.1秒，第五次7.1秒
*00100014*第一次17.2秒，第二次16.6秒，第三次17.9秒，第四次16.7秒，第五次17.1秒
SAM_CODE:*999*，0.8s，1.3s，0.02s，0.02s，0.02s
SAM_CODE: *00100014*，0.1s，0.1s，0.02s，0.03s，0.05s
4. Solr4.0-ALPHA，SolrCloud的配置还算简单，启动一个ZooKeeper，然后其他三台机器访问这个地址，就可以组成一个Cloud：
机器1： nohup java -Xms10G -Xmx10G -Xss256k -Djetty.port=8983 -Dsolr.solr.home="./example-DIH/solr/" -Dbootstrap_confdir=./example-DIH/solr/db/conf/ -Dcollection.configName=xabconf3 -DzkRun -DnumShards=4 -jar start.jar &
其他机器：nohup java -Xms10G -Xmx10G -Dsolr.solr.home="./example-DIH/solr/" -DzkHost=192.168.2.11:9983 -jar start.jar &
但是在执行 data import 的时候，频繁出现 OutOfMemoryError: unable to create new native thread。查了很多资料，把Linux的ulimit当中的nproc改成10240，把Xss改成256K，都解决不了问题。暂时没有办法进行。
结论
1. 导入性能，es更强
2. 查询性能，solr 4.0最好，es与solr 3.6持平，可以乐观的认为，等es采用了lucene4之后，性能会有质的提升
3. Es采用SAM_CODE这样的查询性能很好，但是用_all性能就很差，而且差别非常大，因此，个人认为在目前的es情况下，仍然有性能提升的空间，只是现在还没找到方法。

Lucene、Elasticsearch、Solr区别

Lucene：一个开源的搜索库
Engine：屏蔽 Lucene 操作细节的抽象层
Http：对外提供 restful api，让不同开发语言的应用都可以接入

Elasticsearch是用 Java 开发的，但它却不是只支持Java语言，因为它支持RESTful方式调用，那理论上它是支持所有开发语言的

理解∶因为索引可以去掉重复的词，汉语常用的字和词大概等于 字典+词典；常用的英文在牛津词典也有收录；如果用计算机的速度查询 字典+词典+牛津词典这些内容是非常快的；但是用这些字典、词典组成的文章却是千千万万不计其数；
倒排索引的大小最多也就是 字典+词典。所以通过查询索引，再通过索引和文档的关联关系找到文档速度比较快。
顺序扫描法则是直接去逐个查询那些不计其数的文章就算是计算的速度也会很慢。

主分片数
即 blog 索引的数据，会被分散到 3 个分片里面，起到控制每个分片里文档数量个数的作用，提供查询和搜索效率，可以理解为 Mysql 里的分表。
副本分片
副本分片只是一个主分片的拷贝，作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。

因为对于单节点的架构来说，进行冗余备份就毫无意义的，只会浪费内存和磁盘。

1、Solr ：2004年诞生。ES：2010年诞生。ES 更新【功能越强大】
2、Solr有一个更大、更成熟的用户、开发和贡献者社区
3、当实时建立索引的时候，Solr会产生IO阻塞，而ES则不会，实时建立索引时，ES性能要高于Solr 。
在不断动态添加数据的时候，solr的检索效率会变的低下，而es则没有什么变化。
4、Solr利用zookeeper进行分布式管理，而es自身带有分布式系统管理功能。Solr一般都要部署到web服务器上，比如tomcat。启动tomcat的时候需要配置tomcat与solr的关联。【Solr 的本质 是一个动态web项目】
5、Solr支持更多的格式数据，而es仅支持json文件格式。
6、Solr是传统搜索应用的有力解决方案，但是es更适用于新兴的实时搜索应用。单纯的对已有数据进行检索的时候，solr效率更好，高于es。
7、Solr官网提供的功能更多，而es本身更注重于核心功能，高级功能多由第三方插件。