Kibana笔记

• 根据id查询

GET index_1/doc/1

• 全文检索

GET index_1/doc/_search

GET index_1/doc/_search
{
　　"query": {
　　　　"match_all": {

　　　　}
　　}
}

• 模糊查询

GET index_1/doc/_search?q=hello

• 插入、修改

POST /index_1/doc/1
{
　　"test":"hello haha",
　　"first_name" : "John",
　　"last_name" : "Smith",
　　"age" : 25,
　　"about" : "I love to go rock climbing",
　　"interests": [ "sports", "music" ]
}

• 聚合查询

GET /index_1/doc/_search

{

　　"aggs": {

　　　　"别名": {

　　　　　　"terms": { "field": "字段名" }

　　　　}

　　　}

}

• 开启对分词字段的聚合

PUT index_1/_mapping/doc/
{
　　"properties": {
　　　　"字段名": {
　　　　"type": "text",
　　　　"fielddata": true
　　　　}
　　}
}

• 查询所有姓"Smith"的人最大共同点

GET /index_1/doc/_search

{

　　"query": {

　　　　"match": {

　　　　　　"last_name": "smith"

　　　　}

　　},

　　"aggs": {

　　　　"all_interests": {

　　　　　　"terms": {

　　　　　　　　"field": "interests"

　　　　　　}

　　　　}

　　}

}

正排索引

使用id找内容

记录文档 Id 到文档内容、单词的关联关系

正排表是以文档的ID为关键字，表中记录文档中每个字的位置信息，查找时扫描表中每个文档中字的信息直到找出所有包含查询关键字的文档。

正排表结构如图1所示，这种组织方法在建立索引的时候结构比较简单，建立比较方便且易于维护;因为索引是基于文档建立的，若是有新的文档加入，直接为该文档建立一个新的索引块，挂接在原来索引文件的后面。若是有文档删除，则直接找到该文档号文档对应的索引信息，将其直接删除。但是在查询的时候需对所有的文档进行扫描以确保没有遗漏，这样就使得检索时间大大延长，检索效率低下。

尽管正排表的工作原理非常的简单，但是由于其检索效率太低，除非在特定情况下，否则实用性价值不大。

倒排索引

使用内容找id

记录单词到文档 id 的关联关系，包含：

单词词典（Term DicTionary）：记录所有文档的单词，一般比较大

倒排索引（Posting List）：记录单词倒排列表的关联信息

倒排表以字或词为关键字进行索引，表中关键字所对应的记录表项记录了出现这个字或词的所有文档，一个表项就是一个字表段，它记录该文档的ID和字符在该文档中出现的位置情况。

由于每个字或词对应的文档数量在动态变化，所以倒排表的建立和维护都较为复杂，但是在查询的时候由于可以一次得到查询关键字所对应的所有文档，所以效率高于正排表。在全文检索中，检索的快速响应是一个最为关键的性能，而索引建立由于在后台进行，尽管效率相对低一些，但不会影响整个搜索引擎的效率。
倒排表的结构图如图2：

正排索引是从文档到关键字的映射（已知文档求关键字），倒排索引是从关键字到文档的映射（已知关键字求文档）。

DocId：文档 id，文档的原始信息

TF：单词频率，记录该词再文档中出现的次数，用于后续相关性算分

Position：位置，记录 Field 分词后，单词所在的位置，从 0 开始

Offset：偏移量，记录单词在文档中开始和结束位置，用于高亮显示等

Basics：

　　Stack：栈，先进后出

　　Queues：队列

　　Lists

Sorting排序：

　　Bubble Sort（冒泡排序）

　　Selection Sort（选择排序）

　　Insertion Sort（插入排序）

　　Merge Sort（归并排序）

　　Quick Sort（快排）