本文目录
- solr redis对比 Solr vs.Elasticsearch谁是开源搜索引擎王者
- elasticsearch的实时搜索性能为什么比solr好
- 全文搜索引擎与目标索引类搜索引擎有什么区别
- elatiscserch和solr哪个好
- 一般来说，搜索功能是用 elasticsearch 或者 solr 来实现的吗
- elasticsearch和solar的区别
- solr和elasticsearch对比，有啥差别吗
- 自动网页搜索技术和全文检索技术的区别
- sphinx和solr哪个更适合php站点
solr redis对比 Solr vs.Elasticsearch谁是开源搜索引擎王者
Elasticsearch是一个实时的分布式搜索和分析引擎。它可以帮助你用前所未有的速度去处理大规模数据。
它可以用于全文搜索，结构化搜索以及分析，当然你也可以将这三者进行组合。
Elasticsearch是一个建立在全文搜索引擎 Apache Lucene™ 基础上的搜索引擎，可以说Lucene是当今最先进，最高效的全功能开源搜索引擎框架。
elasticsearch的实时搜索性能为什么比solr好
对比性能其实很不好回答，因为没有我还不知道有 benchmark做了很深入的，而且没有偏见的性能对比。
就实时搜索而言(Near
Real Time Search), feature 实现主要是lucene layer. Elasticsearch 比 SOLR
提前实现这个feature。但是现在Solr 也进步了不少，性能差别并没有很大，毕竟底层都是用lucene 和JVM的嘛。
但是因为实现不一样，feature 和 feature 之前性能差别肯定也还是有的。但是不同的use
case，性能对比结果也是不一样。而且两个产品都有很多参数可以调试， 结果也就更不一样了。
就我个人的理解，毕竟
elasticsearch 是2010 年后 才出现的项目，设计和实现上也更加考究，也更容易上手。 Solr的主要问题是直到 solr
cloud, 一直并没有 很好的scale 和 做分布式的办法。SolrCloud release之后 bug 又很多。
加之就
Elastic 这个产品 Stack 而言，search engine
是一块基石。本身产品内部设计架构强调模块化，使得用户很容易在上面搭建自己的扩展插件 (aws plugin 啥的)。然后 Kibana前台UI 和
Logstash 又给产品找来了很多眼球。我想这是Elasticsearch 现在更流行的原因吧。
全文搜索引擎与目标索引类搜索引擎有什么区别
一、指代不同
1、全文搜索引擎：通过从互联网上提取的各个网站的信息（以网页文字为主）而建立的数据库中，检索与用户查询条件匹配的相关记录，然后按一定的排列顺序将结果返回给用户。
2、目标索引类搜索引擎：是以网页形式提供查找网络资源的一种网络信息检索工具。
二、特点不同
1、全文搜索引擎：以各类数据如文本、声音、图像等为对象，提供按数据的内容而不是外在特征来进行的信息检索，其特点是能对海量的数据进行有效管理和快速检索。
2、目标索引类搜索引擎：使用自动索引软件来搜集和标记网页资源，并将这些资源存入数据库。当用户输入检索的关键词后，它在数据库中找出与该词匹配的记录，并按相关程序排序后显示输出。
三、影响不同
1、全文搜索引擎：是搜索引擎的核心技术，同时也是电子商务网站的支撑技术。全文检索技术可应用于企业信息网站、媒体网站、政府站点、商业网站、数字图书馆和搜索引擎中。
2、目标索引类搜索引擎：由自动索引软件生成数据库，所收录的网络资源范围广、速度快、更新及时，但因缺乏人工干预，准确性较差。这类检索工具适用于查找特定的信息以及专指性强或不易明确分类的具体问题，例如百度搜索引擎。
参考资料来源：百度百科-索引型搜索引擎
参考资料来源：百度百科-全文搜索引擎
elatiscserch和solr哪个好
ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
Solr是一个独立的企业级搜索应用服务器，它对外提供类似于Web-service的API接口。用户可以通过
一般来说，搜索功能是用 elasticsearch 或者 solr 来实现的吗
从两个方面对ElasticSearch和Solr进行对比，从关系型数据库中的导入速度和模糊查询的速度。
单机对比
1.
Solr
发布了4.0-alpha，试了一下，发现需要自己修改schema，好处是它自带一个data
importer。在自己的计算机上测试了一下，导入的性能大概...
elasticsearch和solar的区别
存储整个文档的。 比如你的对象user 有Username 和 age 两个属性， 那么， 默认_source 会存储这两个属性的值。 excludes是不包括的属性？ updated_at是属性字段么？ 貌似ES里没有updated_at这个属性吧。。。
solr和elasticsearch对比，有啥差别吗
从两个方面对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情况下，仍然有性能提升的空间，只是现在还没找到方法。
自动网页搜索技术和全文检索技术的区别
就是以数据诸如文字，声音，图像等为主要内容，以检索文献资料的内容而不是外表特征的一种检索技术·
主要该系统有TRS系统·天宇系统·等
与其他搜索引擎相比，全文搜索引擎的显著特点是它能够以文中任何一个有检索意义的词作为检索入口，而且取得的检索结果是原始文献，而不是文献线索
随着计算机产业的发展，以计算机存储设备为载体的电子信息愈来愈多，这些信息大致可分为两类：结构化数据和非结构化数据，结构化数据指的是诸如企业财务帐目和生产数据、学生的分数数据等等，非结构化数据的则是一些文本数据、图象声音等多媒体数据等等。据统计，非结构化数据占有整个信息量的80%以上。对于结构化数据，用RDBMS（关系数据库管理系统）技术来管理是目前最好的一种方式。但是由于RDBMS自身底层结构的缘故使得它管理大量非结构化数据显得有些先天不足，特别是查询这些海量非结构化数据的速度较慢。而通过全文检索技术就能高效地管理这些非结构化数据。
经过几年的发展，全文检索从最初的字符串匹配程序已经演进到能对超大文本、语音、图像、活动影像等非结构化数据进行综合管理的大型软件。由于内涵和外延的深刻变化，全文检索系统已成为新一代管理信息系统的代名词，衡量全文检索系统的基本指标也逐渐形成规范。
首先，我们关注的是查全率，即系统在进行某一检索时，检索出的相关资料量与系统资料库中相关资料总量的比率。查准率则是保证我们找到最有用资料的一个关键，是系统在进行某一检索时，检索出的有用资料数量与检索出资料总量的比率。检索速度或者说响应时间是提高工作效率的保障，指的是从提交检索课题到查出资料结果所需的时间。最基本的检索速度是应该达“千万汉字，秒级响应“。还有诸如收录范围（所查找的范围）、用户负担（用户在检索过程中付出精力的总和）、输出形式 （输出信息表现形式）等指标也是衡量全文检索系统优劣的要素。
搜索引擎应该是全文检索技术最主要的一个应用。目前，搜索引擎的使用已成为排在收发电子邮件之后的第二大互联网应用技术。搜索引擎起源于传统的信息全文检索理论，即计算机程序通过扫描每一篇文章中的每一个词，建立以词为单位的到排文件，检索程序根据检索词在每一篇文章中出现的频率和每一个检索词在一篇文章中出现的概率，对包含这些检索词的文章进行排序，最后输出排序的结果。全文检索技术是搜索引擎的核心支撑技术。
一个好的检索引擎是一个理想站点的关键。很多人在访问一个站点时喜欢使用站点检索，站点检索应是分类目录导航和全文检索的完美结合，具体包括以下几个方面：
分类目录导航的关键是检索范围，检索范围的限制能使得检索结果不会太多、太滥；
全文检索对于站点检索是必不可少的，在通常情况下能够帮助人们很快地找到所要的网页；
有时利用分类目录导航和全文检索还很难定位到所要的信息，这时就要组合检索辅助；
必须有相关排序功能，因为当检索结果太多时，用户不可能一一浏览，大多数用户只浏览前面几条，没有相关排序，可能准确的检索结果排在后面，用户不能浏览到，而排在前面的检索结果却相关性很少，造成用户的错觉。
此外，我们还要考虑HTML/XML的特殊性、支持大量并发用户突发访问、Web站点的动态特性、要求索引维护效率很高等方面。
目前的技术实现有Lucene，Solr，ElasticSearch等。全文检索过程分为索引、搜索两个过程：
索引(Indexing)
从关系数据库中、互联网上、文件系统采集源数据(要搜索的目标信息)，源数据的来源是非常广泛的。
将源数据采集到一个统一的地方，例如存储系统，要创建索引，将索引创建到一个索引库（文件系统）中，从源数据库中提取关键信息，从关键信息中抽取一个一个词，词和源数据是有关联的。也即创建索引时，词和源数据有关联，索引库中记录了这个关联，如果找到了词就说明找到了源数据（
sphinx和solr哪个更适合php站点
## ES 缺点
基于java，会有一些java的常见问题需要注意，比如gc
单纯执行速度上比C写的sphinx慢
## sphinx 优点
纯粹，没有什么花哨的其他功能
C写的，速度快
新版本加了分布式索引、动态更新索引等功能
## 下面列举Es比sphinx优秀的部分
1、部署简单，虽然sphinx部署也挺简单，但是在书写配置的时候，你会发现，sphinx的配置是要写好后，重启sphinx，而Elasticsearch针对某个索引的配置，是可以动态写入的。
2、调试简单，sphinx有命令行工具可以调试，而Elasticsearch使用的是
