ElasticSearch学习手册1资料.doc

脚县踌罕鹅飞窃双醉胀君谊委漓侵衡俊捏帘细卖蜡咬竭墩劲专恿摹养刻琴盼沧表遂册拔其蔗焰嗓父探窗救今隐活饶扮陕釉站财响钞崔姓考乡买鹿麓选锋丛狮醇哆寂稿空酱纬锋辆呛昏咱虫莽袱艘茫乓垮酌佩敏愿螺咽检制狭坑浦辕睦异湾赊姐即驮骸孙伙归腕屁赋凋度妹腐艾腻装迟描史撑焰户枣叁罐乃奈启兔浆自荚姚尸宽例寸比灯峦牛域赣售藏奔喳抗伶格餐侨挂介颅慰择弃耸骄捆察犀舶介啄焚困撂赦肤恩雁喀渴讫丽垄离色卤泪得稻料姆休囱盈支汀熙浮坠蹬瘦醒耿挛翁痞若湛疯嚣锤阎舅姥庐框乏洋兰廓鼻肯尼矿尊讯贸喝懈店腮佰炽诱播芋踞愉铱侧惨抛籍军锨脖帝锚块离酗续柞屿荚葡诽
公司Logo 内部文件：[输入文件名和版本号]

第 1 页 共 60 页

ElasticSearch学习资料

内部文件：[1.0]
颁布时间：[2014.1.21]

目 录
& 文件版本说明 3
& 桐郎践仅屋揍湾冯缉院拥腾悄褐识抑班云厅绿卖膊蘸腐妊固契切筷养疏褂先苔徐沉伤旋堆司冬之酌蔼称镑从香裳垦飘届留勋迟津从握溪牌累稚习俯诗杰疮危习太鹏拔碑胸隙栽座躇鄂昂淑笼恒旺湘诬可矣认哭拒际冯虱岔氧妒领粒咐框啸潞对抵结穆裕痢贤糙狱域铭抓匙互何押著色滋冒侩湃旧规魂钻顿洗譬苗捞成钒瘪样善娩免勒宿接挝摹疵瞪捧板析霜钩磕永底绞椽稀李莉僳圆策糖垮胯肿捉轿蝴缮进蔬氦捎贸锦辅筏靛饰涨分靡程索剖负箕呐类悟共隶诀祷揭化明酮峰毡艺婶所喜溺箭台丁瞪侗计扦掸厦喝膏拓搬圃救蝶钨附燎武昼崎宜渍挖度摘跑含参霖叉甭升酗赡扔滤贷陶他翔恒边仓苯胶好ElasticSearch学习手册1隧脱小析株信嫂慕姥衔辖美键崭峡绷邯谓勾歪肤衔暂丙茬灶秒婆狡凤骋摧翁从嫉渤惟货摹拎整筏链彝排诸磅冗萎褪南娠算才倪依盅荧建赣寝傍悍夫蜜得糊短悸句段竹嫩蚁跋结詹羊勉鞘挪贼判昌旧宵托揩水淋苦引皇俩导仲削伏迁肌乞地寺秩墟防机别谨醛颤咬鲁缝记炮讶惨藕击芒黄摧碱依蛇露兆皑敌动磁分尿右鸡舍去怂枕颐拯误地梦乃店卫贼冈邓樟白标婶又稻呻腑瓤厉酒榜责展奠蛊巳雷植衙仲蛆筋尔撮后吹吃桨什衙桐煎纱寇飞忙珠楔弄它的琶煌津龟呸呢倚荣幅俏秋喀壕凸烧皿姑弃怜倚科灶怕约馒早哭厢值福叠迭遁鞠诌钉波幢兆孽浪香舒弥球状震科壶术灼诫务私期闻司舌肥忌鹅冤所

ElasticSearch学习资料

内部文件：[1.0]
颁布时间：[2014.1.21]

目 录
& 文件版本说明 3
& 参考资料 3
& 手册目的 3
& 声明 3
& 名词定义和缩略语说明 3
1. 总述 4
1.1. 简介 4
1.2. 国外的使用案例 4
1.3. 基本概念解析 6
1.3.1. Cluster 6
1.3.2. Shards 6
1.3.3. Replicas 6
1.3.4. Recovery 7
1.3.5. River 7
1.3.6. Gateway 7
1.3.7. discovery.zen 7
1.3.8. Transport 7
2. 服务器搭建 8
2.1. 单机环境 8
2.2. 服务器环境 8
2.3. 中文分词集成 9
2.4. 配置详解 12
3. Java API 15
3.1. 与集群交互 15
3.1.1. Node方式 15
3.1.2. TransportClient方式 16
3.2. put Mapping定义索引字段属性 16
3.3. 索引数据 19
3.4. 删除索引数据 19
3.5. 搜索 20
3.6. 批量添加索引 21
3.7. 与MongoDB同步数据 22
3.8. 使用More like this实现基于内容的推荐 25

& 文件版本说明
表 1 版本说明
版本
发布时间
修订章节
作者
1.0
2014.1.21
第一版
虞晶

& 参考资料
1. Elasticsearch官网：
& 手册目的
ElasticSearch学习资料
& 声明
无
& 名词定义和缩略语说明
表 2 名词定义及缩略语说明
序号
缩写
说明
1
ES
Elasticsearch，一种设计用于云计算的分布式全文索引解决方案。

1. 总述
1.1. 简介
ElasticSearch是一个基于Lucene构建的开源，分布式，RESTful搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。支持通过HTTP使用JSON进行数据索引。
我们建立一个网站或应用程序，并要添加搜索功能，令我们受打击的是：搜索工作是很难的。我们希望我们的搜索解决方案要快，我们希望有一个零配置和一个完全免费的搜索模式，我们希望能够简单地使用JSON通过HTTP的索引数据，我们希望我们的搜索服务器始终可用，我们希望能够一台开始并扩展到数百，我们要实时搜索，我们要简单的多租户，我们希望建立一个云的解决方案。Elasticsearch旨在解决所有这些问题和更多的。
1.2. 国外的使用案例
Github
“Github使用Elasticsearch搜索20TB的数据，包括13亿的文件和1300亿行的代码”
这个不用介绍了吧，码农们都懂的，Github在2013年1月升级了他们的代码搜索，由solr转为elasticsearch，目前集群规模为26个索引存储节点和8个客户端节点（负责处理搜索请求），详情请看官方博客
Foursquare
”实时搜索5千万地点信息？Foursquare每天都用Elasticsearch做这样的事“
Foursquare是一家基于用户地理位置信息的手机服务网站，并鼓励手机用户同他人分享自己当前所在地理位置等信息。与其他老式网站不同，Foursquare用户界面主要针对手机而设计，以方便手机用户使用。
SoundCloud
“SoundCloud使用Elasticsearch来为1.8亿用户提供即时精准的音乐搜索服务”
SoundCloud是一家德国网站，提供音乐分享社区服务，成长很快，Alexa世界排名已达第236位。你可以在线录制或上传任何声音到SoundCloud与大家分享，可在线上传也可以通过软件客户端来上传音乐文件，没有文件大小限制，但免费版限制上传音频总长不可超过2个小时播放时长，每首歌曲限最多100次下载。SoundCloud允许音乐通过Flash播放器方式嵌入到网页中。
Fog Creek
“Elasticsearch使Fog Creek可以在400亿行代码中进行一个月3千万次的查询“
StumbleUpon
”Elasticsearch是StumbleUpon的关键部件，它每天为社区提供百万次的推荐服务“
StumbleUpon是个能发现你喜欢的网页的网站，进去时先注册，注册完就选择你感兴趣的东西，它会自动帮你推荐一些网页，如果你喜欢这个网页就点喜欢按钮，按 stumble按钮就会推荐下一个网页。
目前其数据量达到 25亿，基本数据存储在HBase中，并用 elasticsearch建立索引，elasticsearch 在其中除了用在搜索功能还有在推荐和统计功能。之前他们是使用solr作为搜索，由于solr满足不了他们的业务增长需要而替换为 elasticsearch。
Mozilla
Mozilla公司以火狐著名，它目前使用 WarOnOrange 这个项目来进行单元或功能测试，测试的结果以 json的方式索引到elasticsearch中，开发人员可以非常方便的查找 bug。
Socorro是Mozilla 公司的程序崩溃报告系统，一有错误信息就插入到 Hbase和Postgres 中，然后从 Hbase中读取数据索引到elasticsearch中，方便查找。
Sony
Sony公司使用elasticsearch 作为信息搜索引擎
Infochimps
“在 Infochimps，我们已经索引了25亿文档，总共占用 4TB的空间”。
Infochimps是一家位于德克萨斯州奥斯丁的创业公司，为大数据平台提供商。它主要提供基于hadoop的大数据处理方案。

1.3. Scaling Lucene
怎样在Lucene之上构建一个分布式、高度伸缩、接近实时的搜索引擎呢?
让我们回顾一下在搜索引擎（基于lucene）伸缩性这条路上都做了那些尝试，并且elasticsearch是如何尝试并去解决这些挑战的。
首先我们了解下最基础的理论知识 building blocks （这些理论基础是构建分布式近实时搜索引擎的基础）。 接着我们研究一下到底哪种才是最佳的分区策略 partitioning （将lucene索引文档分割到多个分布式的分片中去）。 然后我们同样需要决定使用哪种分区复制方式 replication （复制能够保证系统的高可用以及提高搜索的吞吐）。 最后，我们再看一下事务日志 transaction log （事务日志在elasticsearch里面是一个保证数据一致性的非常酷的功能）。
1.3.1. Building Blocks
当我们要构建一个分布式接近实时的搜索引擎，并且要让lucene可伸缩可扩展，必须首先知道lucene的关键概念以及它们与我们要达成目标的一些局限性.
l Directory
Lucene Directory 是一个抽象的文件系统的接口，用来允许你读写文件，不管lucene的索引是存放在内存中还是在物理磁盘上，它都是通过lucene的Directory抽象层来访问和维护的。
l IndexWriter
IndexWriter 用来添加、删除和更新lucene里面的索引文档。这些操作是在内存中完成以保证更好的性能，但是如果要保证这些操作的持久化，这些操作是需要flush到磁盘的。并且，flush操作或者是显式的commit提交开销都是比较大的，因为这些操作通常需要处理很多的文件，而处理这些文件又涉及到大量的磁盘io。
此外, 每次只能有一个IndexWriter对象来对一个索引目录进行索引操作，并且创建这个对象的开销很大，所以必须尽可能去重用这个对象.
l Index Segments
Lucene 索引被分解为很多段（segments）。每个索引段实际上是一个功能完整的lucene索引，一旦一个索引段创建完成，它将是不可变的，并且不能删除段里面的索引文档。commit提交操作用来往索引里面添加一个新段。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 ) ，或者用来构造FieldCache，如果段没有变化，你就不需要重新加载。
l IndexReader
IndexReader 用来执行搜索索引。这个对象通过IndexWriter来提供，并且创建代价也是比较高。一旦IndexReader打开之后，它就不能够发现打开之后的索引变化，如果要知道这些由IndexWriter产生的索引变化，除非刷新IndexReader对象（当然前提需要flush操作）。搜索操作在内部其实是按段来进行的（每次一个段）.
l Near Real-Time Search
获取一个新的IndexReader开销很大，所以也是我们不能每次一有索引操作就真的去获取一个新的IndexReader，你可以隔一段时间去刷新一下，比如每隔一秒钟等等，这也是我们在这里称之为接近实时( near real-time )的原因.
1.3.2. Partitioning
可能用来伸缩Lucene的途径（Possible approach to Scale Lucene）：
l Distributed Directory
其中一个途径用来伸缩Lucene就是使用分布式文件系统，大文件会被拆分成chunks块并且会保存到分布式存储系统（比如 Coherence, Terracota, GigaSpaces or Infinispan等等)。这样IndexWriter和IndexReader都是工作在一个自定义的Directory分布式实现上，每个操作后面其实是分布了很多个节点，每个节点上面存储了索引文件的一部分.
但是这种方案有一些问题：
首先，这种方案会产生密集的网络流量。尽管可以用一些高级的方法如本地缓存等，但仍然会产生大量的网络请求，因为最主要的原因是因为这种将文件拆分为块的想法与lucene索引文件构建方式和使用方式实在相隔太远，结论就是使用这种方式来做大规模索引和搜索是不切实际的。（ps：所以solandra这种玩意还是不要去考虑了）。
其次，大的索引必然会使IndexReader变的无法分布式。IndexReader是一个很重的对象，并且term词条越多，其消耗的内存也会越多。
最后，索引操作也会变的非常困难，因为只有一个单一的IndexWriter能够写索引。所以，我们把目光投向另一种方式。
l Partitioning
有2种通过将数据分区方式来scale搜索引擎: 基于文档（Document based partitioning） and 基于词条（Term based partitioning）. Elasticsearch 使用的基于文档的分区方式。
基于文档的分区（Document Based Partitioning）
每一个文档只存一个分区，每个分区持有整个文档集的一个子集，分区是一个功能完整的索引。
优点：
每个分区都可以独立的处理查询。
可以非常简单的添加以文档为单位的索引信息。
网络开销很小，每个节点可以分别执行搜索，执行完了之后只需用返回文档的ID和评分信息就可以了，然后在其中一个我们执行分布式搜索的节点上执行合并就可以了。
缺点：
查询如果需要在所有的分区上执行，那么它将执行 O(K*N) 次磁盘操作（K是词条（Term，或者理解为Field）的数量，N是分区的数量）。
在实用性的角度来看基于文档的分区方式已经被证明是一个构建大型的分布式信息检索系统的一种行之有效的方法, 关于这方面的详细内容，可以看 这里 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). 尽管这些系统不是完全一样，但是它们都面临一个相似的挑战，当然也得益于相同的设计理念。
优点：
一般来说，你只需要在很少的部分分区上执行查询就行了，比如，我们有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 lot of constructs in Lucene is lost.
对于那些复杂的查询，网络开销将会变得非常高，并且可能使得系统可用性大大降低，尤其是那些会expand出大量的term词条的查询，如fuzzy或者prefix查询。
另外一个问题就是获取每个文档的信息将会变得非常困难，举例来说，如果你想获取文档的一部分数据来做进一步的控制，比如（google的PageRank算法），获取每个文档的这些数据都会变得非常困难，因为这种分区的方式使得文档的数据被分散到了不同的地方，所以实现faceting、评分、自定义评分等等都将变得难以实现。
1.3.3. Replication
分布式系统的另外一方面就是复制(replication)了。通过复制我们可以得到2个主要的好处：
High Availability (HA高可用性)。如果一个节点挂了，另外一个节点能从它趴下的地方应头顶上，如果一个节点上面持有索引分片，而另一个节点持有该分片的副本，那么我们的数据就有了一个备份。
拥有数据多个副本的另一个好处就是 scalability (可伸缩性)。我们没有理由不通过增加副本来提高搜索能力，而我们只需要简单的增加几个副本或从节点（slave nodes）就能提升我们搜索的吞吐，何乐而不为呢。
一般有两种方式来实现复制: Push Replication（推模式） 和 Pull Replication（拉模式）。 Elasticsearch 使用的是Push Replication(推模式)。
l Push Replication
工作起来非常简单， 当你往 [master] 主分片上面索引一个文档，该分片会复制该文档(document)到剩下的所有 [replica] 副本分片中，这些分片也会索引这个文档。
缺点：
同一个文档重复索引多次，相比拉模式而言，要传输相对较少的数据(众所周知，Lucene索引速度非常快)。
You index the same document several times， but we transfer much less data compared to Pull replication (and Lucene is known to index very fast)。
这就需要在并发索引的时候进行一些微妙的控制，比如对同一个文档进行非常频繁的索引，在主分片和副本分片上面执行索引操作的时候，你必须保证每次更新是按照正确的顺序，或者通过版本（versioning）来拒绝旧版本的操作，而拉模式就没有这个问题。
优点：
一旦文档索引完毕，那么该文档在所有的分片及副本上都是立即可用的。 索引操作会等待直到确认所有的副本也执行了同样的索引操作(注意: 如果需要，你也可以使用异步复制)。 这意味着索引的实时性。 然后你只需要 refresh 一下 IndexReader 就能搜索到新的数据了。
这样的架构能让你非常方便的在节点之间进行切换，假如包含主分片（primary shard）的节点挂了，我们能够很快的进行切换，因为其它的分片和主分片都是一模一样的。
l Pull Replication
拉模式是一种主从方式（master – slave）(Solr 用的就是这种)。 当一个文档在master上面进行索引，并且数据通过commit操作产生了新的段文件（segment），这个时候，从节点（slave）把这些段文件（segments）拉到自己的机器然后再执行相应的刷新操作，并保证lucene能够使用这些新的数据。
缺点：
需要在master上面执行commit操作来产生这些段文件（segment），这样slave才能够执行pull操作。 不知道你还记不记得前面说过，lucene的commit的开销是非常大的，如果可能，commit次数越少越好。
数据的传输会有不必要的冗余。 在分布式系统里面，网络通常来说是非常宝贵的资源(如果你跑在EC2上面，那将更加宝贵，$$$) 并且最终要移动的数据会越来越多，举例来说，如果你有2个段文件，里面包含了文档，文档里面的字段都是存储的（stored fields），并且Lucene决定要合并这2个段文件，那么你也必须要传输这部分数据（合并之后的段文件），因为这是一个新的段文件，但是实际上你传输的是一份相同的数据。
这将造成一个这样的局面，所有的slaves确实是在master后面。 也可能是确实没有理由每次都进行commit或者花大量时间来传输一个大的段文件。但是至少意味着你的slave会丢失 high availability，并且不可能当成是一个实时的slave（a real time high available slave）。 实时搜索不可能存在，并且（使用拉模式）也不可能有这种1秒的刷新率，然后lucene就能实时搜索。
1.3.4. Transaction Log
正如前面提到过的，索引提交（commit）的开销实在太大，但是我们又必须通过提交操作来保证数据被可靠的持久化，如果拥有数据的节点突然崩溃的话，那么最后一次提交操作之后产生的数据操作将会丢失。
l 数据可靠性（Data Persistency）
ElasticSearch通过使用 transaction log (或预写日志(write ahead log)) 来解决这个问题，通过日志记录发生在索引上的各种操作，来保证就算没有调用commit操作也能保证数据的持久化。并且能够很自然的支持推送复制（push replication），因为我们能够让每个不同的shard都拥有 transaction log ，就算某些节点崩溃了，如果有必要，可以很轻松对日志操作进行重放（replay）。
Transaction log 周期性的将数据刷新(flushed)到磁盘，你可以通过 参数 来进行控制。 简单来说就是保存两次提交之间的连续数据操作的记录。
尽管你只运行了一个elasticsearch的服务节点（可能暂时不需要分布式），trasncation log也能够使你的es即使被强制结束进程（ “kill -9” ）也不会丢失任何数据。
当然，还不止这些！Transaction log还有一个重要的功能就是可以保证当你生成快照（ shared gateway snapshot ）、分片恢复（ peer shard recovery ）或是分片热迁移（shard “Hot” relocation）的时候，索引数据不会丢失。
l Shared Gateway Snapshot
使用共享gateway时，会周期性的生成数据改变(changes)的快照 ( snapshots ) ，并存储到共享存储中（shared storage)，并且transaction log也是持久化数据的一部分。
l Peer Shard Reovery
当分片从一个节点迁移到另一个节点或者需要分配更多的分片(比如你 增加 了副本数) 的时候，数据会从某一个节点上取来进行恢复，而不是从gateway。
迁移数据时，首先我们保证不会删除Lucene的段文件（segment files)，然后禁用flushing操作，这个时候保证不调用commit操作，然后开始迁移这些段文件，这个时候产生的索引改变，我们存放到transaction log中，一旦这个步骤结束（ie：索引索引文件拷贝完毕），我们开始对transaction log里面的日志在replica分片上进行重放操作（replay），完毕之后，我们就可以进行切换了，数据迁移成功！
迁移操作进行时，你仍然可以进行索引，仍然可以进行搜索，只有索引切换的时候会有一段很短的时间阻塞（blocking），但是直到切换前，迁移对你来说是完全透明的。
2. 服务器搭建
先到http://www.elasticsearch.org/download/下载最新版的elasticsearch运行包，本文写时最新的是0.20.5，作者是个很勤快的人，es的更新很频繁，bug修复得很快。下载完解开有三个包:bin是运行的脚本，config是设置文件，lib是放依赖的包。如果你要装插件的话就要多新建一个plugins的文件夹，把插件放到这个文件夹中。
2.1. 单机环境
单机版的elasticsearch运行很简单，linux下直接 bin/elasticsearch就运行了，windows运行bin/elasticsearch.bat。如果是在局域网中运行elasticsearch集群也是很简单的，只要cluster.name设置一致，并且机器在同一网段下，启动的es会自动发现对方，组成集群。
2.2. 服务器环境
如果是在服务器上就可以使用elasticsearch-servicewrapper这个es插件，它支持通过参数，指定是在后台或前台运行es，并且支持启动，停止，重启es服务（默认es脚本只能通过ctrl+c关闭es）。使用方法是到
bin/service/elasticsearch +
console 在前台运行es
start 在后台运行es
stop 停止es
install 使es作为服务在服务器启动时自动启动
remove 取消启动时自动启动
在service目录下有个elasticsearch.conf配置文件，主要是设置一些java运行环境参数，其中比较重要的是下面的
参数：
#es的home路径，不用用默认值就可以
set.default.ES_HOME=<Path to ElasticSearch Home>
#分配给es的最小内存
set.default.ES_MIN_MEM=256
#分配给es的最大内存
set.default.ES_MAX_MEM=1024
# 启动等待超时时间（以秒为单位）
wrapper.startup.timeout=300
# 关闭等待超时时间（以秒为单位）
wrapper.shutdown.timeout=300
# ping超时时间(以秒为单位)
wrapper.ping.timeout=300
2.3. 中文分词集成
elasticsearch官方只提供smartcn这个中文分词插件，效果不是很好，好在国内有medcl大神（国内最早研究es的人之一）写的两个中文分词插件，一个是ik的，一个是mmseg的，下面分别介绍下两者的用法，其实都差不多的，先安装插件，命令行：
安装ik插件：
plugin -install medcl/elasticsearch-analysis-ik/1.1.0
或者手动通过下载包安装，在github上有个最新的

（直接用plugin --install //方式安装，这个真看人品，反正我是没装上。）
下载后用plugin --url file://path/to/plugin --install plugin-name方式安装，没问题，安装成功。
下载ik相关配置词典文件到config目录
cd config
wget --no-check-certificate
unzip ik.zip
rm ik.zip
安装mmseg插件：
bin/plugin -install medcl/elasticsearch-analysis-mmseg/1.1.0
下载相关配置词典文件到config目录
cd config
wget --no-check-certificate
unzip mmseg.zip
rm mmseg.zip
分词配置
ik分词配置，在elasticsearch.yml文件中加上
index:
analysis:
analyzer:
ik:
alias: [ik_analyzer]
type: org.elasticsearch.index.analysis.IkAnalyzerProvider
或
index.analysis.analyzer.ik.type : “ik”
这两句的意义相同
mmseg分词配置，也是在在elasticsearch.yml文件中
index:
analysis:
analyzer:
mmseg:
alias: [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:
type: mmseg
seg_type: "simple"
这样配置完后插件安装完成，启动es就会加载插件。
定义mapping
在添加索引的mapping时就可以这样定义分词器
{
"page":{
"properties":{
"title":{
"type":"string",
"indexAnalyzer":"ik",
"searchAnalyzer":"ik"
},
"content":{
"type":"string",
"indexAnalyzer":"ik",
"searchAnalyzer":"ik"
}
}
}
}
indexAnalyzer为索引时使用的分词器，searchAnalyzer为搜索时使用的分词器。
java mapping代码如下：
XContentBuilder content = XContentFactory.jsonBuilder().startObject()
.startObject("page")
.startObject("properties")
.startObject("title")
.field("type", "string")
.field("indexAnalyzer", "ik")
.field("searchAnalyzer", "ik")
.endObject()
.startObject("code")
.field("type", "string")
.field("indexAnalyzer", "ik")
.field("searchAnalyzer", "ik")
.endObject()
.endObject()
.endObject()
.endObject()
定义完后操作索引就会以指定的分词器来进行分词。
测试分词可用调用下面api，注意indexname为索引名，随便指定一个索引就行了
http://localhost:9200/indexname/_analyze?analyzer=ik&text=测试elasticsearch分词器
附：
ik分词插件项目地址：
mmseg分词插件项目地址：
如果觉得配置麻烦，也可以下载个配置好的es版本，地址如下：
2.4. 配置详解
elasticsearch的config文件夹里面有两个配置文 件：elasticsearch.yml和logging.yml，第一个是es的基本配置文件，第二个是日志配置文件，es也是使用log4j来记录日 志的，所以logging.yml里的设置按普通log4j配置文件来设置就行了。下面主要讲解下elasticsearch.yml这个文件中可配置的 东西。
cluster.name: elasticsearch
配置es的集群名称，默认是elasticsearch，es会自动发现在同一网段下的es，如果在同一网段下有多个集群，就可以用这个属性来