×

elasticsearch 开源 c

elasticsearch（elasticsearch 是开源的吗）

admin admin 发表于2022-09-07 08:44:26 浏览204 评论0

抢沙发发表评论

本文目录

elasticsearch 是开源的吗


Elasticsearch是什么 Elasticsearch是一个高度可扩展的开源全文搜索和分析引擎。它可以在很短的时间内存储，搜索和分析大量的数据。它通常作为具有复杂搜索场景情况下的核心发动机。我们举几个例子来说明Elasticsearch能做什么？ 当你经营一家网上商店，你可以让你的客户搜索你卖的商品。在这种情况下，你可以使用Elasticsearch来存储您的整个产品目录和库存信息，为客户提供精准搜索，可以为客户推荐相关商品。 当你想收集日志或者交易数据的时候，要分析和挖掘这些数据，寻找趋势，统计，总结，或异常。在这种情况下，你可以使用LogStash 或者其他工具来进行收集数据，当这些数据存储到Elasticsearch中 。你可以搜索和汇总这些数据，找到任何你感兴趣的信息。 当 你运行一个价格提醒的平台，可以给客户提供一些规则，如我有兴趣购买一个特定的电子设备，当商品的价格在未来一个月内的价格低于多少钱的时候通知我。在这 种情况下，你可以把供应商的价格，把他们定期存储到Elasticsearch中，使用定时器过滤的能力来匹配客户的需求，当查询到价格低于客户设定的值 后给客户发送一条通知。 当你有 商业智能分析的需求时，你希望快速调查，分析和可视化，并有大量的数据（千万条记录）的时候。在这种情况下，你可以使用Elasticsearch来存储 你的数据，然后用Kibana建立自定义的仪表板或者任何你熟悉的语言开发展示界面，您可以使用Elasticsearch的聚合功能来执行复杂的商业智 能与数据查询。 对于码农来说，比较有名的案例是github，gihtub 的搜索是基于 Elasticsearch 构建的，在 github.com/search 页面，你可以检索项目、用户、issue、pull request，还有代码。共有 40-50个 索引库，分别用于索引网站需要跟踪的各种数据。虽然只索引项目的主分支(master)，但这个数据量依然巨大，20亿索引文档，30TB的索引文件。 Elasticsearch的核心概念 下面介绍Elasticsearch的几个核心概念，准实时索引(Near Realtime)，集群(cluster),节点(node), 索引(index),类型(type),文档(document),分片和复制(shards Replicas)。 准实时索引(Near Realtime) Elasticsearch是准实时搜索平台。这意味着有轻微的延迟（通常为1秒）就可以从入库建索引文件到已经进行关键字搜索。 集群(cluster) 集 群是由一个或多个节点组成，对外提供服务，对外提供索引和搜索功能。在所有节点，一个集群有一个唯一的名称默认为“Elasticsearch”。此名称 是很重要的，因为每个节点只能是群集的一部分，当该节点被设置为相同的名称时，就会自动加入群集。当需要有多个集群的时候，要确保每个集群的名称不能重复，否则，节点可能会加入错误的群集。请注意，一个节点只能加入一个集群。此外，您还可以拥有多个独立的集群，每个集群都有其不同的集群名称。例如，在开发过程中，你可以建立开发集群库和测试集群库，分别为开发，测试服务。 节点(node) 一 个节点是一个逻辑上独立的服务，它是群集的一部分，可以存储数据，并参与集群的索引和搜索功能。就像集群一样，一个节点也有唯一的名字，默认是一个随机的 和机器相关的名称，在启动的时候分配。如果你不想要的默认值，你可以定义任何你想要的节点名。这个名字在管理中很重要，在网络中 Elasticsearch群集通过节点名称进行管理和通信。一个节点可以被配置为加入一个特定的群集。默认情况下，每个节点会加入名为Elasticsearch的集群中，这意味着如果你在网络上启动多个节点，如果网络畅通，他们能彼此发现并自动加入一个名为Elasticsearch的集群中。在一个单一的集群中，你可以拥有多个你想要的节点。当网络没有集群运行的时候，只要启动任何一个节点，这个节点会默认生成一个新的集群，这个集群会有一个节点。 索引(index) 索引是有点结构的文档集合。例如，可以有一个客户数据的索引，另一个是产品目录的索引，还有一个订单数据的索引。一个索引是一个名称（必须是全部小写），这个名字是用来指在执行索引、搜索、更新和删除操作时对文档的索引。在一个单一的集群中，您可以定义多个你想要的索引。 类型(type) 在 索引中，可以定义一个或多个类型。类型是索引的逻辑分区。在一般情况下，一种类型被定义为具有一组公共字段的文档。例如，让我们假设你运行一个博客平台， 并把所有的数据存储在一个索引中。在这个索引中，您可以定义一个类型为用户数据，另一种类型为博客数据，另一种类型的数据。 文档(document) 文档是可以被索引的基本单位。例如，你可以有一个的客户文档，有一个产品文档，还有一个订单的文档。文档是以JSON（JavaScript Object Notation）格式存储的。在一个索引中，您可以存储多个的文档。请注意，虽然在一个索引中有多分文档，但这些文档的结构是一致的，并在第一次存储的时候指定。 分片(shards) 一个索引可以存储很大的数据，这些空间可以超过一个节点的物理存储的限制。例如，十亿个文档占用磁盘空间为1TB。仅从单个节点搜索可能会很慢，还有一台物理机器也不一定能存储这么多的数据。为了解决这一问题，Elasticsearch将索引分解成多个分片。当你创建一个索引，你可以简单地定义你想要的分片数量。每个分片本身是一个全功能的、独立的单元，可以托管在集群中的任何节点。 分片主要有两个很重要的原因是： 1、它允许你水平分割扩展你的数据。 2、它允许你分配和并行操作（可能在多个节点上）从而提高性能和吞吐量 这些很强大的功能对用户来说是透明的，你不需要做什么操作，系统会自动处理。 复制(Replicas) 复制是一个非常有用的功能，不然会有单点问题。当网络中的某个节点出现问题的时候，复制可以对故障进行转移，保证系统的高可用。因此，Elasticsearch允许你创建一个或多个拷贝，你的索引分片就形成了所谓的副本或副本分片。 复制是重要的，主要的原因有： 1、它提供了高可用性，当节点失败的时候不受影响。需要注意的是，一个复制的分片不会存储在同一个节点中。 2、它允许您扩展您的搜索量，提高并发量，因为搜索可以在所有副本上并行的执行。 总结一下，每个索引可以拆分成多个分片。索引可以复制零个或者多个分片。一旦复制，每个索引就有了主分片和复本分片。分片的数量和副本的数量可以在创建索引时定义。当创建索引后，你可以随时改变副本的数量，但你不能改变分片的数量。 默认情况下，每个索引分配5个分片和1个副本，这意味着你的集群节点至少要有两个节点，你将拥有5个主要的分片和5个副本分片共有10个分片。

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 怎么读


elasticsearch

英式音标：[ɪˈlæstɪk] [sɜːtʃ]

美式音标：[ɪˈlæstɪk] [sɝtʃ]

elastic

英 [ɪˈlæstɪk]   美 [ɪˈlæstɪk]  

n.橡皮圈(或带);松紧带。

adj.橡皮圈(或带)的;有弹性的;有弹力的;灵活的;可改变的;可伸缩的。

If you have varicose veins, consider wearing elastic support hose. 

如果患了静脉曲张，可以考虑穿弹力护腿袜。

扩展资料

search的用法：

search的基本意思是“搜查”,指怀着发现某物的希望而认真、深入地寻找或调查,多指搜索、检查犯罪的人或违禁的、丢失的东西。强调所用的努力及其彻底性,含有对立或不满的意味,用于比喻可表示“冥思苦想”等。-开源

search既可用作及物动词,也可用作不及物动词。用作及物动词时,其后可跟人、房屋、衣袋等名词或代词作宾语。

search的目的物常用for引出,而搜寻的地方常用介词through引出。

search用作名词时,意思是“寻找”“找寻”,指仔细寻找某人或事物的动作,既可作可数名词,又可作不可数名词。指一次具体的寻找时,可加不定冠词a。


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节点与外部通讯使用的端口。它是


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情况下，仍然有性能提升的空间，只是现在还没找到方法。
-c

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情况下，仍然有性能提升的空间，只是现在还没找到方法。
-开源

elasticsearch怎么读


elasticsearch

英式音标：[ɪˈlæstɪk] [sɜːtʃ]

美式音标：[ɪˈlæstɪk] [sɝtʃ]

elastic

英 [ɪˈlæstɪk]   美 [ɪˈlæstɪk]  

n.橡皮圈(或带);松紧带。

adj.橡皮圈(或带)的;有弹性的;有弹力的;灵活的;可改变的;可伸缩的。

If you have varicose veins, consider wearing elastic support hose. 

如果患了静脉曲张，可以考虑穿弹力护腿袜。

扩展资料

search的用法：

search的基本意思是“搜查”,指怀着发现某物的希望而认真、深入地寻找或调查,多指搜索、检查犯罪的人或违禁的、丢失的东西。强调所用的努力及其彻底性,含有对立或不满的意味,用于比喻可表示“冥思苦想”等。-开源

search既可用作及物动词,也可用作不及物动词。用作及物动词时,其后可跟人、房屋、衣袋等名词或代词作宾语。

search的目的物常用for引出,而搜寻的地方常用介词through引出。

search用作名词时,意思是“寻找”“找寻”,指仔细寻找某人或事物的动作,既可作可数名词,又可作不可数名词。指一次具体的寻找时,可加不定冠词a。


kibana配置elasticsearchurl选项 怎么才能配置灵活


elasticsearch.url需要指定一个一个es节点 比如 173.15.0.1:9200
访问es前面挂一个nginx，由nginx帮你做es节点的故障检测和切换
es 集群；kibana.yml配置
# The Elasticsearch instance to use for all your queries.
elasticsearch.url: “
-开源

如何可视化读取elasticsearch 的日志


为了支持高可用性与高伸缩性，Elasticsearch本身就是分布式设计的。从顶层的角度来说，Elasticsearch在索引（或者集合） 中保存文档（或者数据记录），每个集合又分解为多个小块，称为分片。索引越大，所需要分配的分片越多（不必担心会创建过多的分片，它的开销很小）。取决于 Elasticsearch的设置和规模，分片会在集群中均匀地平均分布，有两个原因： 出于冗余方面的原因：默认情况下，Elasticsearch为每个分片都准备了一份拷贝，一旦某个节点停机了，备份的分片就能接替它的位置。 出于性能方面的原因：每个查询都发生在某个索引上，并且会在多个分片中并行运行，这种工作流方式是改善性能的关系所在。如果感觉运行速度缓慢，只需简单地在集群中加入新的机器，Elasticsearch就会自动地将分片与查询进行分布到新添加的机器上。 这种方式让使用Elasticsearch的组织可以自由选择进行纵向扩展（如果节点运行缓慢就升级硬件）或者横向扩展（如果集群整体速度慢就加入更多的节点）。
-c

elasticSearch使用，java开发


看看我写的教程吧：

//这个地址可以找到：http://www.sojson.com/tag_elasticsearch.html