1、ElasticSearch 学习资料内部文件：1.0颁布时间：2014.1.21公司 Logo 内部文件：输入文件名和版本号第 1 页 共 60 页目 录 文件版本说明 3 参考资料 3 手册目的 3 声明 3 名词定义和缩略语说明 31. 总述 41.1. 简介 41.2. 国外的使用案例 41.3. 基本概念解析 61.3.1. Cluster.61.3.2. Shards61.3.3. Replicas.61.3.4. Recovery .71.3.5. River71.3.6. Gateway 71.3.7. discovery.zen 71.3.8. Transport.72. 服务
2、器搭建 82.1. 单机环境 82.2. 服务器环境 82.3. 中文分词集成 92.4. 配置详解 123. Java API.153.1. 与集群交互 153.1.1. Node 方式 .153.1.2. TransportClient 方式 163.2. put Mapping 定义索引字段属性 163.3. 索引数据 19公司 Logo 内部文件：输入文件名和版本号第 2 页 共 60 页3.4. 删除索引数据 193.5. 搜索 203.6. 批量添加索引 213.7. 与 MongoDB 同步数据 223.8. 使用 More like this 实现基于内容的推荐 .25公司 L
3、ogo 内部文件：输入文件名和版本号第 3 页 共 60 页 文 件 版 本 说 明表 1 版本说明版本 发布时间 修订章节 作者1.0 2014.1.21 第一版 虞晶 参 考 资 料1. Elasticsearch 官网：http:/ 手 册 目 的ElasticSearch 学习资料 声 明无 名 词 定 义 和 缩 略 语 说 明表 2 名词定义及缩略语说明序号 缩写 说明1 ES Elasticsearch，一种设计用于云计算的分布式全文索引解决方案。公司 Logo 内部文件：输入文件名和版本号第 4 页 共 60 页1. 总述1.1.简介ElasticSearch 是一个基于 Lu
4、cene 构建的开源，分布式，RESTful 搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。支持通过 HTTP 使用JSON 进行数据索引。我们建立一个网站或应用程序，并要添加搜索功能，令我们受打击的是：搜索工作是很难的。我们希望我们的搜索解决方案要快，我们希望有一个零配置和一个完全免费的搜索模式，我们希望能够简单地使用 JSON 通过 HTTP 的索引数据，我们希望我们的搜索服务器始终可用，我们希望能够一台开始并扩展到数百，我们要实时搜索，我们要简单的多租户，我们希望建立一个云的解决方案。Elasticsearch 旨在解决所有这些问题和更多的。1.2.国外的
5、使用案例Github“Github 使用 Elasticsearch 搜索 20TB 的数据，包括 13 亿的文件和 1300 亿行的代码”这个不用介绍了吧，码农们都懂的，Github 在 2013 年 1 月升级了他们的代码搜索，由solr 转为 elasticsearch，目前集群规模为 26 个索引存储节点和 8 个客户端节点（负责处理搜索请求） ，详情请看官方博客 https:/ 5 千万地点信息？Foursquare 每天都用 Elasticsearch 做这样的事“Foursquare 是一家基于用户地理位置信息的手机服务网站，并鼓励手机用户同他人分享自己当前所在地理位置等信息。与
6、其他老式网站不同，Foursquare 用户界面主要针对手机而设计，以方便手机用户使用。SoundCloud“SoundCloud 使用 Elasticsearch 来为 1.8 亿用户提供即时精准的音乐搜索服务”SoundCloud 是一家德国网站，提供音乐分享社区服务，成长很快，Alexa 世界排名已达第 236 位。你可以在线录制或上传任何声音到 SoundCloud 与大家分享，可在线上传也可公司 Logo 内部文件：输入文件名和版本号第 5 页 共 60 页以通过软件客户端来上传音乐文件，没有文件大小限制，但免费版限制上传音频总长不可超过 2 个小时播放时长，每首歌曲限最多 100
7、次下载。SoundCloud 允许音乐通过 Flash 播放器方式嵌入到网页中。Fog Creek“Elasticsearch 使 Fog Creek 可以在 400 亿行代码中进行一个月 3 千万次的查询“StumbleUpon”Elasticsearch 是 StumbleUpon 的关键部件，它每天为社区提供百万次的推荐服务“StumbleUpon 是个能发现你喜欢的网页的网站，进去时先注册，注册完就选择你感兴趣的东西，它会自动帮你推荐一些网页，如果你喜欢这个网页就点喜欢按钮，按 stumble按钮就会推荐下一个网页。目前其数据量达到 25 亿，基本数据存储在 HBase 中，并用 el
8、asticsearch 建立索引，elasticsearch 在其中除了用在搜索功能还有在推荐和统计功能。之前他们是使用 solr 作为搜索，由于 solr 满足不了他们的业务增长需要而替换为 elasticsearch。MozillaMozilla 公司以火狐著名，它目前使用 WarOnOrange 这个项目来进行单元或功能测试，测试的结果以 json 的方式索引到 elasticsearch 中，开发人员可以非常方便的查找 bug。Socorro 是 Mozilla 公司的程序崩溃报告系统，一有错误信息就插入到 Hbase 和Postgres 中，然后从 Hbase 中读取数据索引到 el
9、asticsearch 中，方便查找。SonySony 公司使用 elasticsearch 作为信息搜索引擎Infochimps“在 Infochimps，我们已经索引了 25 亿文档，总共占用 4TB 的空间” 。Infochimps 是一家位于德克萨斯州奥斯丁的创业公司，为大数据平台提供商。它主要提供基于 hadoop 的大数据处理方案。公司 Logo 内部文件：输入文件名和版本号第 6 页 共 60 页1.3.Scaling Lucene怎样在 Lucene 之上构建一个分布式、高度伸缩、接近实时的搜索引擎呢?让我们回顾一下在搜索引擎（基于 lucene）伸缩性这条路上都做了那些尝试，
10、并且elasticsearch 是如何尝试并去解决这些挑战的。首先我们了解下最基础的理论知识 building blocks （这些理论基础是构建分布式近实时搜索引擎的基础） 。 接着我们研究一下到底哪种才是最佳的分区策略 partitioning （将lucene 索引文档分割到多个分布式的分片中去） 。 然后我们同样需要决定使用哪种分区复制方式 replication （复制能够保证系统的高可用以及提高搜索的吞吐） 。 最后，我们再看一下事务日志 transaction log （事务日志在 elasticsearch 里面是一个保证数据一致性的非常酷的功能） 。1.3.1. Buildi
11、ng Blocks当我们要构建一个分布式接近实时的搜索引擎，并且要让 lucene 可伸缩可扩展，必须首先知道 lucene 的关键概念以及它们与我们要达成目标的一些局限性. DirectoryLucene Directory 是一个抽象的文件系统的接口，用来允许你读写文件，不管 lucene的索引是存放在内存中还是在物理磁盘上，它都是通过 lucene 的 Directory 抽象层来访问和公司 Logo 内部文件：输入文件名和版本号第 7 页 共 60 页维护的。 IndexWriterIndexWriter 用来添加、删除和更新 lucene 里面的索引文档。这些操作是在内存中完成以保证
12、更好的性能，但是如果要保证这些操作的持久化，这些操作是需要 flush 到磁盘的。并且，flush 操作或者是显式的 commit 提交开销都是比较大的，因为这些操作通常需要处理很多的文件，而处理这些文件又涉及到大量的磁盘 io。此外, 每次只能有一个 IndexWriter 对象来对一个索引目录进行索引操作，并且创建这个对象的开销很大，所以必须尽可能去重用这个对象. Index SegmentsLucene 索引被分解为很多段（segments） 。每个索引段实际上是一个功能完整的 lucene索引，一旦一个索引段创建完成，它将是不可变的，并且不能删除段里面的索引文档。commit 提交操作
13、用来往索引里面添加一个新段。lucene 内部会来对这些段进行合并，所以我们必须要有策略来控制这些合并(MergePolisy, MergeScheuler, etc)。Because segments need to be kept at bay they are being merged continuously by internal Lucene processes (MergePolisy, MergeScheuler, etc)。因为段是不可变的，所以用来做缓存（caching）是一个很好的选择，你可以加载所有的 term 词条并且创建一个跳跃列表（ skip lists ) ，或
14、者用来构造 FieldCache，如果段没有变化，你就不需要重新加载。 IndexReaderIndexReader 用来执行搜索索引。这个对象通过 IndexWriter 来提供，并且创建代价也是比较高。一旦 IndexReader 打开之后，它就不能够发现打开之后的索引变化，如果要知道这些由 IndexWriter 产生的索引变化，除非刷新 IndexReader 对象（当然前提需要 flush 操作） 。搜索操作在内部其实是按段来进行的（每次一个段）. Near Real-Time Search获取一个新的 IndexReader 开销很大，所以也是我们不能每次一有索引操作就真的去获取一
15、个新的 IndexReader，你可以隔一段时间去刷新一下，比如每隔一秒钟等等，这也是我们在这里称之为接近实时( near real-time )的原因.公司 Logo 内部文件：输入文件名和版本号第 8 页 共 60 页1.3.2. Partitioning可能用来伸缩 Lucene 的途径（ Possible approach to Scale Lucene）： Distributed Directory其中一个途径用来伸缩 Lucene 就是使用分布式文件系统，大文件会被拆分成 chunks块并且会保存到分布式存储系统（比如 Coherence, Terracota, GigaSpace
16、s or Infinispan 等等)。这样 IndexWriter 和 IndexReader 都是工作在一个自定义的 Directory 分布式实现上，每个操作后面其实是分布了很多个节点，每个节点上面存储了索引文件的一部分.但是这种方案有一些问题：首先，这种方案会产生密集的网络流量。尽管可以用一些高级的方法如本地缓存等，但仍然会产生大量的网络请求，因为最主要的原因是因为这种将文件拆分为块的想法与lucene 索引文件构建方式和使用方式实在相隔太远，结论就是使用这种方式来做大规模索引和搜索是不切实际的。 （ps：所以 solandra 这种玩意还是不要去考虑了） 。其次，大的索引必然会使 I
17、ndexReader 变的无法分布式。IndexReader 是一个很重的对象，并且 term 词条越多，其消耗的内存也会越多。最后，索引操作也会变的非常困难，因为只有一个单一的 IndexWriter 能够写索引。所以，我们把目光投向另一种方式。 Partitioning有 2 种通过将数据分区方式来 scale 搜索引擎: 基于文档（ Document based partitioning） and 基于词条（Term based partitioning ）. Elasticsearch 使用的基于文档的分区方式。基于文档的分区（Document Based Partitioning）每
18、一个文档只存一个分区，每个分区持有整个文档集的一个子集，分区是一个功能完整的索引。优点：每个分区都可以独立的处理查询。可以非常简单的添加以文档为单位的索引信息。网络开销很小，每个节点可以分别执行搜索，执行完了之后只需用返回文档的 ID 和评分信息就可以了，然后在其中一个我们执行分布式搜索的节点上执行合并就可以了。公司 Logo 内部文件：输入文件名和版本号第 9 页 共 60 页缺点：查询如果需要在所有的分区上执行，那么它将执行 O(K*N) 次磁盘操作（K 是词条（Term ，或者理解为 Field）的数量， N 是分区的数量） 。在实用性的角度来看基于文档的分区方式已经被证明是一个构建大型
19、的分布式信息检索系统的一种行之有效的方法, 关于这方面的详细内容，可以看 这里 talk by Jeffrey Dean (Google)。基于词条的分区（Term Based Partitioning）每个分区拥有一部分词条，词条里面包含了整个 index 的文档数据。一些基于词条分区的系统，如 Riak Search (built on top of Riak key-value store engine) 或是 Lucandra/Solandra (on top of Cassandra). 尽管这些系统不是完全一样，但是它们都面临一个相似的挑战，当然也得益于相同的设计理念。优点：一般来
20、说，你只需要在很少的部分分区上执行查询就行了，比如，我们有 5 个 term 词条的查询，我们将至多命中 5 个分区，如果这 5 个 term 词条都保存同一个分区中，那么我们只需用访问一个分区即可，而不管我们是不是实际上有 50 个分区。另外一个优势就是对应 K 个 Term 词条的查询，你只需用执行 O(K) 次磁盘查找（假设我们使用的优化过的实现） 。缺点：最主要的问题是 Lucene Segment 概念里面固有的很多结构都将失去。The main problem is that whole notion of Lucene Segment which is inherent to a
21、 lot of constructs in Lucene is lost.对于那些复杂的查询，网络开销将会变得非常高，并且可能使得系统可用性大大降低，尤其是那些会 expand 出大量的 term 词条的查询，如 fuzzy 或者 prefix 查询。另外一个问题就是获取每个文档的信息将会变得非常困难，举例来说，如果你想获取文档的一部分数据来做进一步的控制，比如（google 的 PageRank 算法） ，获取每个文档的这些数据都会变得非常困难，因为这种分区的方式使得文档的数据被分散到了不同的地方，所以实现 faceting、评分、自定义评分等等都将变得难以实现。公司 Logo 内部文件：输
22、入文件名和版本号第 10 页 共 60 页1.3.3. Replication分布式系统的另外一方面就是复制(replication)了。通过复制我们可以得到 2 个主要的好处：High Availability (HA 高可用性)。如果一个节点挂了，另外一个节点能从它趴下的地方应头顶上，如果一个节点上面持有索引分片，而另一个节点持有该分片的副本，那么我们的数据就有了一个备份。拥有数据多个副本的另一个好处就是 scalability (可伸缩性)。我们没有理由不通过增加副本来提高搜索能力，而我们只需要简单的增加几个副本或从节点（slave nodes）就能提升我们搜索的吞吐，何乐而不为呢。一般
23、有两种方式来实现复制: Push Replication（推模式） 和 Pull Replication（拉模式） 。 Elasticsearch 使用的是 Push Replication(推模式)。 Push Replication工作起来非常简单， 当你往 master 主分片上面索引一个文档，该分片会复制该文档(document)到剩下的所有 replica 副本分片中，这些分片也会索引这个文档。缺点：同一个文档重复索引多次，相比拉模式而言，要传输相对较少的数据(众所周知，Lucene 索引速度非常快 )。You index the same document several time
24、s， but we transfer much less data compared to Pull replication (and Lucene is known to index very fast)。这就需要在并发索引的时候进行一些微妙的控制，比如对同一个文档进行非常频繁的索引，在主分片和副本分片上面执行索引操作的时候，你必须保证每次更新是按照正确的顺序，或者通过版本（versioning）来拒绝旧版本的操作，而拉模式就没有这个问题。优点：一旦文档索引完毕，那么该文档在所有的分片及副本上都是立即可用的。 索引操作会等待直到确认所有的副本也执行了同样的索引操作(注意: 如果需要，你也可以
25、使用异步复制)。 这意味着索引的实时性。 然后你只需要 refresh 一下 IndexReader 就能搜索到新的数据了。这样的架构能让你非常方便的在节点之间进行切换，假如包含主分片（primary 公司 Logo 内部文件：输入文件名和版本号第 11 页 共 60 页shard）的节点挂了，我们能够很快的进行切换，因为其它的分片和主分片都是一模一样的。 Pull Replication拉模式是一种主从方式（master slave ）(Solr 用的就是这种) 。 当一个文档在 master上面进行索引，并且数据通过 commit 操作产生了新的段文件（ segment） ，这个时候，从节
26、点（slave ）把这些段文件（ segments）拉到自己的机器然后再执行相应的刷新操作，并保证 lucene 能够使用这些新的数据。缺点：需要在 master 上面执行 commit 操作来产生这些段文件（ segment） ，这样 slave 才能够执行 pull 操作。 不知道你还记不记得前面说过，lucene 的 commit 的开销是非常大的，如果可能，commit 次数越少越好。数据的传输会有不必要的冗余。 在分布式系统里面，网络通常来说是非常宝贵的资源(如果你跑在 EC2 上面，那将更加宝贵，$) 并且最终要移动的数据会越来越多，举例来说，如果你有 2 个段文件，里面包含了文档
27、，文档里面的字段都是存储的（stored fields） ，并且 Lucene 决定要合并这 2 个段文件，那么你也必须要传输这部分数据（合并之后的段文件） ，因为这是一个新的段文件，但是实际上你传输的是一份相同的数据。这将造成一个这样的局面，所有的 slaves 确实是在 master 后面。 也可能是确实没有理由每次都进行 commit 或者花大量时间来传输一个大的段文件。但是至少意味着你的slave 会丢失 high availability，并且不可能当成是一个实时的 slave（a real time high available slave） 。 实时搜索不可能存在，并且（使用拉模
28、式）也不可能有这种 1 秒的刷新率，然后 lucene 就能实时搜索。1.3.4. Transaction Log正如前面提到过的，索引提交（commit）的开销实在太大，但是我们又必须通过提交操作来保证数据被可靠的持久化，如果拥有数据的节点突然崩溃的话，那么最后一次提交操作之后产生的数据操作将会丢失。 数据可靠性（Data Persistency）ElasticSearch 通过使用 transaction log (或预写日志(write ahead log) 来解决这个问题，通过日志记录发生在索引上的各种操作，来保证就算没有调用 commit 操作也能保证数据公司 Logo 内部文件：输
29、入文件名和版本号第 12 页 共 60 页的持久化。并且能够很自然的支持推送复制（push replication） ，因为我们能够让每个不同的 shard 都拥有 transaction log ，就算某些节点崩溃了，如果有必要，可以很轻松对日志操作进行重放（replay） 。Transaction log 周期性的将数据刷新(flushed)到磁盘，你可以通过 参数 来进行控制。 简单来说就是保存两次提交之间的连续数据操作的记录。尽管你只运行了一个 elasticsearch 的服务节点（可能暂时不需要分布式） ，trasncation log 也能够使你的 es 即使被强制结束进程（ “
30、kill -9” ）也不会丢失任何数据。当然，还不止这些！Transaction log 还有一个重要的功能就是可以保证当你生成快照（ shared gateway snapshot ） 、分片恢复（ peer shard recovery ）或是分片热迁移（shard “Hot” relocation）的时候，索引数据不会丢失。 Shared Gateway Snapshot使用共享 gateway 时，会周期性的生成数据改变(changes)的快照 ( snapshots ) ，并存储到共享存储中（shared storage) ，并且 transaction log 也是持久化数据的一部
31、分。 Peer Shard Reovery当分片从一个节点迁移到另一个节点或者需要分配更多的分片(比如你 增加 了副本数) 的时候，数据会从某一个节点上取来进行恢复，而不是从 gateway。迁移数据时，首先我们保证不会删除 Lucene 的段文件（ segment files)，然后禁用flushing 操作，这个时候保证不调用 commit 操作，然后开始迁移这些段文件，这个时候产生的索引改变，我们存放到 transaction log 中，一旦这个步骤结束（ie：索引索引文件拷贝完毕） ，我们开始对 transaction log 里面的日志在 replica 分片上进行重放操作（ re
32、play） ，完毕之后，我们就可以进行切换了，数据迁移成功！迁移操作进行时，你仍然可以进行索引，仍然可以进行搜索，只有索引切换的时候会有一段很短的时间阻塞（blocking） ，但是直到切换前，迁移对你来说是完全透明的。2. 服务器搭建先到 http:/www.elasticsearch.org/download/下载最新版的 elasticsearch 运行包，本文写时最新的是 0.20.5，作者是个很勤快的人，es 的更新很频繁，bug 修复得很快。下载完解开有三个包:bin 是运行的脚本，config 是设置文件，lib 是放依赖的包。如果你要装插件的公司 Logo 内部文件：输入文件名
33、和版本号第 13 页 共 60 页话就要多新建一个 plugins 的文件夹，把插件放到这个文件夹中。2.1.单机环境单机版的 elasticsearch 运行很简单，linux 下直接 bin/elasticsearch 就运行了，windows运行 bin/elasticsearch.bat。如果是在局域网中运行 elasticsearch 集群也是很简单的，只要cluster.name 设置一致，并且机器在同一网段下，启动的 es 会自动发现对方，组成集群。2.2.服务器环境如果是在服务器上就可以使用 elasticsearch-servicewrapper 这个 es 插件，它支持通过
34、参数，指定是在后台或前台运行 es，并且支持启动，停止，重启 es 服务（默认 es 脚本只能通过 ctrl+c 关闭 es） 。使用方法是到 https:/ 下载 service 文件夹，放到 es 的 bin 目录下。下面是命令集合：bin/service/elasticsearch +console 在前台运行 esstart 在后台运行 esstop 停止 esinstall 使 es 作为服务在服务器启动时自动启动remove 取消启动时自动启动在 service 目录下有个 elasticsearch.conf 配置文件，主要是设置一些 java 运行环境参数，其中比较重要的是下面
35、的参数：#es 的 home 路径，不用用默认值就可以set.default.ES_HOME=#分配给 es 的最小内存set.default.ES_MIN_MEM=256#分配给 es 的最大内存set.default.ES_MAX_MEM=1024# 启动等待超时时间（以秒为单位）wrapper.startup.timeout=300# 关闭等待超时时间（以秒为单位）wrapper.shutdown.timeout=300# ping 超时时间(以秒为单位)公司 Logo 内部文件：输入文件名和版本号第 14 页 共 60 页wrapper.ping.timeout=3002.3.中文分词
36、集成elasticsearch 官方只提供 smartcn 这个中文分词插件，效果不是很好，好在国内有medcl 大神（国内最早研究 es 的人之一）写的两个中文分词插件，一个是 ik 的，一个是mmseg 的，下面分别介绍下两者的用法，其实都差不多的，先安装插件，命令行：安装 ik 插件：plugin -install medcl/elasticsearch-analysis-ik/1.1.0或者手动通过下载包安装，在 github 上有个最新的https:/ plugin -install /方式安装，这个真看人品，反正我是没装上。 ）下载后用 plugin -url file:/path
37、/to/plugin -install plugin-name 方式安装，没问题，安装成功。下载 ik 相关配置词典文件到 config 目录cd configwget http:/ -no-check-certificateunzip ik.ziprm ik.zip安装 mmseg 插件：bin/plugin -install medcl/elasticsearch-analysis-mmseg/1.1.0 下载相关配置词典文件到 config 目录cd config wget http:/ -no-check-certificate unzip mmseg.zip rm mmseg.zip
38、 分词配置ik 分词配置，在 elasticsearch.yml 文件中加上index:analysis: analyzer:ik:alias: ik_analyzer公司 Logo 内部文件：输入文件名和版本号第 15 页 共 60 页type: org.elasticsearch.index.analysis.IkAnalyzerProvider或index.analysis.analyzer.ik.type : “ik” 这两句的意义相同mmseg 分词配置，也是在在 elasticsearch.yml 文件中index: analysis: analyzer: mmseg: alias
39、: news_analyzer, mmseg_analyzer type: org.elasticsearch.index.analysis.MMsegAnalyzerProvider 或index.analysis.analyzer.default.type : “mmseg“ mmseg 分词还有些更加个性化的参数设置如下index: analysis: tokenizer: mmseg_maxword: type: mmseg seg_type: “max_word“ mmseg_complex: type: mmseg seg_type: “complex“ mmseg_simple:
40、 type: mmseg seg_type: “simple“ 这样配置完后插件安装完成，启动 es 就会加载插件。定义 mapping在添加索引的 mapping 时就可以这样定义分词器 “page“: “properties“: “title“: “type“:“string“, “indexAnalyzer“:“ik“, “searchAnalyzer“:“ik“ , “content“: “type“:“string“, “indexAnalyzer“:“ik“, 公司 Logo 内部文件：输入文件名和版本号第 16 页 共 60 页“searchAnalyzer“:“ik“ inde
41、xAnalyzer 为索引时使用的分词器，searchAnalyzer 为搜索时使用的分词器。java mapping 代码如下：XContentBuilder content = XContentFactory.jsonBuilder().startObject() .startObject(“page“) .startObject(“properties“) .startObject(“title“) .field(“type“, “string“) .field(“indexAnalyzer“, “ik“) .field(“searchAnalyzer“, “ik“) .endObjec
42、t() .startObject(“code“) .field(“type“, “string“) .field(“indexAnalyzer“, “ik“) .field(“searchAnalyzer“, “ik“) .endObject() .endObject() .endObject() .endObject() 定义完后操作索引就会以指定的分词器来进行分词。测试分词可用调用下面 api，注意 indexname 为索引名，随便指定一个索引就行了http:/localhost:9200/indexname/_analyze?analyzer=ik /启动节点 Node node =
43、nodeBuilder().node(); Client client = node.client(); /关闭节点 node.close(); 当你启动一个节点，它会自动加入同网段的 es 集群，一个前提就是 es 的集群名（cluster.name）这个参数要设置一致。默认的话启动一个节点，es 集群会自动给它分配一些索引的分片，如果你想这个节点仅仅作为一个客户端而不去保存数据，你就可以设置把 node.data 设置成 false 或 node.client 设置成 true。下面是例子：Node node = nodeBuilder().clusterName(clusterName)
44、.client(true).node(); 还有一种情况是你并不想把节点加入集群，只想用它进行单元测试时，就要启动一个“本地”的 es，这里“本地” 指的是在 jvm 的级别下运行，即两个不同的 es 节点运行在同公司 Logo 内部文件：输入文件名和版本号第 28 页 共 60 页一个 JVM 中时会组成一个集群。它需要把节点的 local 参数设置成 true，下面是例子：Node node = nodeBuilder().local(true).node(); 4.1.2. TransportClient 方式通过 TransportClient 这个接口，我们可以不启动节点就可以和 e
45、s 集群进行通信，它需要指定 es 集群中其中一台或多台机的 ip 地址和端口，例子如下：Client client = new TransportClient() .addTransportAddress(new InetSocketTransportAddress(“host1“, 9300) .addTransportAddress(new InetSocketTransportAddress(“host2“, 9300); client.close(); 如果你需要更改集群名（默认是 elasticsearch） ，需要如下设置：Settings settings = Immutabl
46、eSettings.settingsBuilder() .put(“cluster.name“, “myClusterName“).build(); Client client = new TransportClient(settings); 你可以设置 client.transport.sniff 为 true 来使客户端去嗅探整个集群的状态，把集群中其它机器的 ip 地址加到客户端中，这样做的好处是一般你不用手动设置集群里所有集群的ip 到连接客户端，它会自动帮你添加，并且自动发现新加入集群的机器。代码实例如下：Settings settings = ImmutableSettings.settingsBuilder() .put(“client.transport.sniff“, true).build(); TransportClient client = new TransportClient(settings);4.2.put Mapping 定义索引字段属性Mapping,就是对索引库中索引的字段名及其数据类型进行定义，类似于关系数据库中表建立时要定义字段名及其数据类型那样，不过 es 的 mapping 比数据库灵活很多，它可以动态
