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

本文目录

• elasticsearch，solr对比各自有哪些优缺点
• elasticsearch 9300 9200有什么区别
• Elasticsearch的架构是什么样的
• 搜索引擎 Elasticsearch 好在哪里，为什么 Wikimedia 打算要用它
• elasticsearch 可以二次开吗
• 哪位大师帮帮忙，使用elasticsearch的facet统计功能实现统计

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“: }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.75G2. 使用 *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.02sSAM_CODE: *00100014*，0.1s，0.1s，0.02s，0.03s，0.05s4. 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情况下，仍然有性能提升的空间，只是现在还没找到方法。

elasticsearch 9300 9200有什么区别

一、elasticsearch 9300 9200的协议不同：

1、9200作为Http协议，主要用于外部通讯。

2、9300作为Tcp协议，jar之间就是通过tcp协议通讯。

3、ES集群之间是通过9300进行通讯。

二、elasticsearch 9300 9200的端口不同：

1、9200 端口

9200 是 HTTP 协议的 RESTful 接口。

2、9300 端口

9300 是 TCP 通讯端口，集群间和 TCPClient 都走得它。

三：两端口的作用不同。

具体的作用如下：

9200 是ES节点与外部通讯使用的端口。它是

Elasticsearch的架构是什么样的

Elasticsearch是由Shay Banon发起的一个开源搜索服务器项目，2010年2月发布。迄今，该项目已发展成为搜索和数据分析解决方案领域的主要一员，广泛应用于声名卓著或鲜为人知的搜索应用程序。此外，由于其分布式性质和实时功能，许多人把它作为文档数据库。Elasticsearch架构简单介绍如下。索引索引（index）是Elasticsearch对逻辑数据的逻辑存储，所以它可以分为更小的部分。你可以把索引看成关系型数据库的表。然而，索引的结构是为快速有效的全文索引准备的，特别是它不存储原始值。如果你知道MongoDB，可以把Elasticsearch的索引看成MongoDB里的一个集合。如果你熟悉CouchDB，可以把索引看成CouchDB数据库索引。Elasticsearch可以把索引存放在一台机器或者分散在多台服务器上，每个索引有一或多个分片（shard），每个分片可以有多个副本（replica）。文档存储在Elasticsearch中的主要实体叫文档（document）。用关系型数据库来类比的话，一个文档相当于数据库表中的一行记录。当比较Elasticsearch中的文档和MongoDB中的文档，你会发现两者都可以有不同的结构，但Elasticsearch的文档中，相同字段必须有相同类型。这意味着，所有包含title字段的文档，title字段类型都必须一样，比如string。文档由多个字段组成，每个字段可能多次出现在一个文档里，这样的字段叫多值字段（multivalued）。每个字段有类型，如文本、数值、日期等。字段类型也可以是复杂类型，一个字段包含其他子文档或者数组。字段类型在Elasticsearch中很重要，因为它给出了各种操作（如分析或排序）如何被执行的信息。幸好，这可以自动确定，然而，我们仍然建议使用映射。与关系型数据库不同，文档不需要有固定的结构，每个文档可以有不同的字段，此外，在程序开发期间，不必确定有哪些字段。当然，可以用模式强行规定文档结构。从客户端的角度看，文档是一个JSON对象（关于JSON格式的更多内容，参见

搜索引擎 Elasticsearch 好在哪里，为什么 Wikimedia 打算要用它

首先ES是基于Lucene这个非常成熟的索引方案，另加上一些分布式的实现：集群，sharding，replication等。ES的优势主要可以看以下几个方面：1. 横向可扩展性：只需要增加一台服务器，做一点儿配置，启动一下ES进程就可以并入集群；2. 分片机制提供更好的分布性：同一个索引分成多个分片（sharding），这点类似于HDFS的块机制；分而治之的方式来提升处理效率，相信大家都不会陌生；3. 高可用：提供复制（replica）机制，一个分片可以设置多个复制，使得某台服务器宕机的情况下，集群仍旧可以照常运行，并会把由于服务器宕机丢失的复制恢复到其它可用节点上；这点也类似于HDFS的复制机制（HDFS中默认是3份复制）；当然，也要知道其不足之处：1. 各节点的一致性问题：其默认的机制是通过多播机制，同步元数据信息，但是在比较繁忙的集群中，可能会由于网络的阻塞，或者节点处理能力达到饱和导致各节点元数据不一致——也就是所谓的脑裂问题，这样会使集群处于不一致状态。目前并没有一个彻底的解决方案来解决这个问题，但是可以通过将工作节点与元数据节点分开的部署方案来缓解这种情况。2. 没有细致的权限管理机制，也就是说，没有像MySQL那样的分各种用户，每个用户又有不同的权限。所以在操作上的限制需要自己开发一个系统来完成；总结：不过从优势与不足的对比看，我看还是瑕不掩瑜，是值得一试的技术。

elasticsearch 可以二次开吗

你好

elasticsearch是可以二次开的

• 理解二次评分

  二次评分是指重新计算查询返回文档中指定个数文档的得分，es会截取查询返回的前N个，并使用预定义的二次评分方法来重新计算他们的得分

• 二次评分查询结构

  从最简单的查询入手：match_all查询类型，返回索引中所有文档，每个返回的文档的得分都是1.0，这样可以充分体现二次评分对查询返回文档集的影响

• 小结

  有时候，我们需要显示查询结果，并且使得页面上靠前文档的顺序能受到一些额外的规则控制，但遗憾的是，我们并不能通过二次评分来实现，也许有些读者会想到window-size参数，然而实际上这个参数与返回列表中靠前文档并无关系，他只是制定了每个分片应该返回的文档数，而且window_size不能小于页面大小

  二次评分功能并不能与排序一起使用，这是因为排序发生在二次评分之前，所以排序没有考虑后续新计算出来的文档得分

希望对你有帮助

哪位大师帮帮忙，使用elasticsearch的facet统计功能实现统计

使用elasticsearch的facet统计功能实现统计1，节省机器及运维成本：数据仍给opensearch，访问突增、数据突增系统上修改下配额，其他一概不关心。神马宕机、分布式、双集群、扩容、网络异常统统与我无关；2，收录数据自由控制：想收录什么内容就收录什么内容，完全自由控制，分钟级生效（很快到秒级）；3，阿里云数据自动对接：OSS已经上线，ODPS\RDS稳步开发中，其他产品陆续都会支持。opensearch自动获取数据，一份数据多个场景使用，别提多省心了；4，应用结构自定义：搜索schema自主定义，什么字段、什么类型、什么可搜索、什么筛选，系统上任意配置；5，灵活而丰富的排序策略：内置丰富的排序特征，支持到表达式级别，