一枚程序员的博客

1.每秒一个segment file，文件过多，而且每次search都要搜索所有的segment，很耗时 默认会在后台执行segment merge操作，在merge的时候，被标记为deleted的document也会被彻底物理删除 每次merge操作的执行流程 1）选择一些有相似大小的segment，merge成一个大的segment 2）将新的segment flush到磁盘上去 3

1.字符串排序有什么问题？ 如果对一个string field进行排序，结果往往不准确，因为分词后是多个单词，再排序就不是我们想要的结果了。 通常解决方案是：将一个string field建立两次索引，一个分词，用来搜索，一个部分次，用来进行排序 例子： GET /website/article/_search {   "query": {     "match_all": {}

1.默认排序规则 默认情况下，是按照_score降序排序的，然后在某些情况下，如filter，不计算_score，所以没有可用的_score 例子： GET /test_index/test_type/_search {   "query": {     "bool": {       "filter": {         "term": {           "test

1.ES提供了定位不合法搜索查询的原因 语法 GET /index/type/_validate/query?explain {   } 例子： GET /test_index/test_type/_validate/query?explain {   "query":{     "matah":{       "test_field":"haha"     }   }

1.bulk api批量操作 bulk的命令格式 {“action":"meta”}   换行 {"data"} 2.bulk 中的每个操作都可能要转发到不同的node的shard去执行 3.如果才用比较良好的json数组格式 {   “action”:"meta" } {   "data" } 如果采用换行的格式，那么可读性很好，es拿到这种标准的json

1.查询请求的原理 1）首先客户端选择任意一个节点，发送请求get document id=1，P1 2）发送到node1上时，node1就是协调节点（coordinate node），coordinate node对document进行路由，路由之后，就知道在哪个primary shard上面了。 3）前面的过程和增删改是一样的，后面有点不同了。coordinate node知道在哪个pr

1.写一致性原理 我们在发送任何一个增删改操作的时候，比如说 put /index/type/id,都可以带上一个consistency参数，指明我们想要的写一致性是什么。 PUT /index/type/id?consistency=quorum one:要求我们这个写操作，只要primary shard是active活跃可用的，就可以执行写操作 all：要求我们这个写操作，必须所有的p

1.假设场景 3个节点，3个primary shard，3个replica shard，总共6个shard，每个节点2个shard 增删改的操作的过程都是一样的。 过程： 1）首先客户端client需要创建一个document，指定任意一个node，比如说node0，此时向node0发送请求。 2）node0接收到请求，此时的node0就是协调节点，即coordina

1.document路由到shard上，是什么意思？ 我们知道，一个index的数据会分成多片， 每片都在一个shard中，所以，一个document 只能存在于一个shard中。 当客户端创建document的时候，es此时就需要决定， 这个document是放在这个index的哪个个shard中。 这个过程称之为document routing，数据路由

1.批量查询的好处 1）一条一条查询，需要发送多次，网络开销大，批量查询可以解决很多网络的开销 2）使用mget 2.使用mget进行查询操作 1）如果批量查询的对象不是在一个index中，那么可以用下面的语法 GET /_mget {   "docs":[     {       "_index":"test_index",       "_type":"test

1.语法 POST /bulk {"delete":{"_index":"test_index","_type":"test_type","_id":9}} {"create":{"_index":"test_index","_type":"test_type","_id":11}} {"test_field":"test201712291140"} {"index":{"_inde

1.上几篇中提到了partial update的用法，这篇学习一下partial update的原理 和全量替换的原理稍有不同，partial update的原理： 在客户端中首先获取到es中的document，然后对部分数据进行修改，然后向es端发送请求进行修改，底层仍然是全量替换。 2.partial update并发问题 乐观锁并发控制 POST

1.组合查询query bool  在bool中可以放must,must_not,should,filter  例子： GET /website/article/_search { "query": { "bool": { "must": [ {"match": { "title": "elasticsearch"

1.match all GET /company/employee/_search {   "query": {     "match_all": {}   } } 2.match GET /company/employee/_search {   "query": {     "match": {       "name": "tom"     }   } }

1.算法介绍 relevance score算法，简单来说，就是计算出，一个索引中的文本，与搜索的文本，他们之间的关联匹配程序 ElasticSearch使用的是term frequency/inverse document frequency算法，简称TF/IDF算法 Term frequency，搜索文本中的各个词条在field文本中出现了多少次，出现次数越多，就越相关 Inverse

1.搜索的时候，要依靠倒排索引：排序的时候，需要依靠正排索引，看到每个document的每个field，然后进行排序，所谓的正排索引，其实就是doc values 在建立索引的时候，一方面会建立倒排索引，以供搜索用；一方面建立正排索引，也就是doc values，以供排序，聚合，过滤等操作使用 doc values是被保存在硬盘上的，此时如果内存足够，os会自动将其缓存在内存中，性能还是会很高

1.上一篇文章中提到index segment只要刷入到os cache后，就打开供查询，这个操作是非常危险的，一旦未将数据刷入到os disk，而此时数据丢失，将会导致不可逆的问题。 所以本篇补充，继续进行优化docuemnt写入流程。 2.最终的优化的写入流程： 1）数据写入buffer缓冲和translog日志文件中。 当你写一条数据document的时候，一方面写入到buffe

1.现有流程的问题，每次都必须等待fsync将segment刷入磁盘，才能将segment打开供search使用，这样的话，从一个document写入，到它可以被搜索，可能会超过一分钟！！！这就不是近实时的搜索了！ 主要瓶颈是在fsync实际发生磁盘IO写数据进磁盘，是很耗时的。 写入流程改进： 1）数据写入到内存buffer队列中 2）每隔一定时间，buffer中的数据被写入segm

1.重建索引 一个field的设置是不能修改的，如果要修改一个field，那么应该重新按照新的mapping，建立一个index，然后将数据批量查询出来，重新用bulk api写入到index中。 批量查询的时候，建议采用scroll api，并且采用多线程并发的方式来reindex数据，每次scroll就查询指定日期的一段数据，交给一个线程即可。 1）一开始，依靠dynamic map

1.数据docuemnt往es中写的时候发生了什么？ 一个document写入es中时， 1）首先写入到内存buffer缓冲中 2）每次buffer满的时候，会进行提交操作commit point，将buffer中的数据写入到index的segment中（一个index有多个segment）    在es底层，用的是lucense，lucense底层的index是分为多个segment的，

1.定制dynamic策略 true：遇到陌生字段，就进行dynamic mapping false：遇到陌生字段，就忽略 strict：遇到陌生字段，就报错 例子： PUT /index0 { "mappings":{ "my_type":{ "dynamic":"strict", "properties": { "title":

1.root object是什么？ 就是某个type对应的mapping json，包括properties，metadata（_id，_source，_type），settings(analyzer),其他settings（比如include_in_all) 其中，下面的{             "properties":{             }             .

1.每个index对应的type底层结构是怎样的？ type，是一个index中用来区分类似的数据的数据结构，但是可能有不同的field，而且有不同的属性来控制索引建立、分词器 field的value，在底层的lucense中建立索引的时候，全部是opaque bytes类型，不区分类型。 lucense是没有type的概念，在document中，实际上是将type作为一个document的

1.默认的分词器 standard standard tokenizer:以单词的边界进行切分 standard token filter:什么都不做 lowercase token filter:将所有字母转换成小写 stop token filter(默认被禁用)，移除停用词，比如a the it等等 2.修改分词器的设置 例子：启用standard的基于english的

1.为什么要手动创建索引？ 更加灵活 2.创建索引 例子： PUT /index0 {   "settings": {     "number_of_shards": 1,     "number_of_replicas": 0   },   "mappings": {     "mytype":{       "properties": {         "myfie

1.为什么使用srcoll滚动搜索 问题：如果一次性查询出100000条数据，那么性能会很差，此时一般会采用scroll滚动查询，一批一批的查，知道所有数据都查询完。 使用scroll滚动搜索，可以先搜索一批数据，然后下次再搜索一批数据，以此类推，知道搜索出全部的数据。 scroll搜索会在第一次搜索的时候，保存一个当时的视图快照，之后只会基于该旧的视图快照提供数据搜索，如果这个期间数据

1.preference 决定了哪些shard会被用来执行搜索操作 _primary（只搜索primary shard）,  _primary_first（primary shard优先）, _local, _only_node:xyz, _prefer_node:xyz, _shards:2,3 bouncing results问题：两个document排序，field值相同，不同的sha

1.fetch phase的工作流程 1)coordinate node构建完priority queue之后，就发送mget请求去所有shard上获取对应的document 2）各个shard将document返回给coordinate node 3）coordinate node将合并后的document结果返回给client客户端 图解： http://img.my.csdn.

1.query phase 1)搜索请求发送到一个coordinate node，构建一个priority queue，长度以paging操作from和size为准，默认10 2）coordinate node将请求转发到所有shard，每个shard本地搜索，并构建一个本地的priority queue 3）各个shard将自己的priority queue返回给coordinate no

1.准备数据 PUT /company/employee/1 { "address":{ "province":"zhejiang", "city":"wenzhou", "country":"china" }, "name":"tom", "age":31, "join_date":"2015-01-02" } PUT /company/employ

1.match all GET /website/article/_search { "query": { "match_all": {} } } 执行结果： { "took": 38, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0

1.什么是partial update PUT /index/type/id ,创建文档、更新文档操作 一般对应到应用程序中，每次的执行流程基本是这样的： 1）应用程序先发起一个get请求，获取到document，展示到前台页面上，工用户查询和修改 2）用户在前台页面上修改数据document，发送到后台 3）后台代码，会将用户修改的数据在内存中进行执行，然后封装好修改后的全量数据 4

1.Elasticsearch5.0.1 + Kibana5.0.1 + IK 5.0.1安装记录 http://www.cnblogs.com/kamong/p/6099914.html 2.

1.创建Maven项目的时候，因为是公司内网，所以需要解决代理的问题，配置代理 2.创建Maven项目 3.配置pom.xml，引用jar包 4.编码

1.认识倒排索引有两段话：doc1： I really liked my small dogs ,and I think my mom also liked them.doc2：He never liked any dogs,so I hope that my mom will not expect me to liked him.word        doc1            doc2I

1.exact value如2017-01-01，如果是exact value搜索的时候，必须输入2017-01-01，才能搜索出来如果输入一个01，是搜索不出来的。也就是说exact value必须是一样的搜索关键词才能搜索出来。2.full text1）缩写 vs，全程，cn vs China2）格式转化，like liked likes3）大小写，Tom vs tom4）同义词，like v

1.准备数据PUT /website/article/1 { "post_date":"2018-01-01", "title":"my first article", "content":"this is my first article in this website", "author_id":11400 } PUT /website/article/2 { "post_

1.query string search语法就是将请求的条件加到string的后面，同时也需要掌握+-的原理搜索test_field中包含hangzhou的数据GET /test_index/test_type/_search?q=test_field:hangzhou{ "took": 9, "timed_out": false, "_shards": { "total":

1.使用es实现分页搜索size，fromtest_index/test_type共12条数据第一页GET /test_index/test_type/_search?from=0&size=5{ "took": 3, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed":

1.阶段总结 1-8讲：快速入门、基本的操作 9-13讲：入门之后，对es的分布式的基本原理，进行了相对深入的一些剖析 14-27讲：围绕着document这个东西，进行操作，进行讲解和分析 2.什么是distributed document store ElasticSearch在跑起来之后，其实起到的第一个最核心的功能，就是一个分布式的文档数据存储系统。ES是分布式的