Mac杀进程

先找出端口对应的进程PID

Lsof -i: 8013

Kill 13344

再次查询，就没了。

ps axu | grep “想查询的进程”，若没有|后面的则查询全部

1
2
3
4

@Modifying
  @Query(value = "update Stu s set s.name = :#{#stu.name}, s.age = :#{#stu.age}, " +
          "s.alias = :#{#stu.alias} where s.id = :#{#stu.id}")
  int updatePayState2(@Param("stu") Stu stu);

1

:#{pageable.getPageNumber}* :#{pageable.getPageSize}

QueryParameterSetter$ErrorHandling - Silently ignoring

同样的问题。基本上问题是由于查询参数。在“选择”子句中没有出现在计数查询中。

1

tf(t in d) = √frequency

词 t 在文档 d 的词频（ tf ）是该词在文档中出现次数的平方根。

将参数 index_options 设置为 docs 可以禁用词频统计及词频位置，这个映射的字段不会计算词的出现次数，对于短语或近似查询也不可用。要求精确查询的 not_analyzed 字符串字段会默认使用该设置。

search_analyzer：设置搜索时的分词器，默认跟analyzer是一致的

比如index时用standard+ngram，搜索时用standard用来完成自动提示功能

“search_analyzer”: “ik”

similarity：默认时TF/IDF算法，指定一个字段评分策略，仅仅对字符串型和分词类型有效

“similarity”: “BM25”

字符串类型ElasticSearch对字符串拥有两种完全不同的搜索方式. 你可以按照整个文本进行匹配, 即关键词搜索(keyword search), 也可以按单个字符匹配, 即全文搜索(full-text search).

Text：
会分词，然后进行索引
支持模糊、精确查询
不支持聚合

keyword：
不进行分词，直接索引
支持模糊、精确查询
支持聚合

text用于全文搜索的, 而keyword用于关键词搜索.

type: keyword或者text

分片（shard）

Mapping表示中保存了定义索引中字段（Field）的存储类型、分词方式、是否存储等信息，有点类似于关系数据库（如MySQL）中的表结构信息。类似c t r l+D

一个索引的Mapping一旦创建，若已经存储了数据，就不可修改了。

Analyzer表示的是字段分词方式的定义。

一个Analyzer通常由一个Tokenizer和零到多个Filter组成,

在Elasticsearch中，默认的标准Analyzer包含一个标准的Tokenizer和三个Filter，

即Standard Token Filter、Lower CaseToken Filter和Stop Token Filter。

字段（field）

文档中包含零个或者多个字段，字段可以是一个简单的值（例如字符串、整数、日期），也可以是一个数组或对象的嵌套结构。

字段类似于关系数据库中表的列。每个字段都对应一个字段类型，例如整数、字符串、对象等。字段还可以指定如何分析该字段的值。

来源字段（source field）

默认情况下，你的原文档将被存储在_source这个字段中，当你查询的时候也是返回这个字段。

这允许你可以从搜索结果中访问原始的对象，这个对象返回一个精确的JSON字符串，

这个对象不显示索引分析后的其他任何数据。

ID是一个文件的唯一标识，如果在存库的时候没有提供ID，系统会自动生成一个ID，文档的index/type/id必须是唯一的。

别名是索引之上得抽象，非常强大和灵活。别名的生命周期是存于集群状态之中，由主节点管理。

相当于指针？

这意味着，如果有一个称为idaho的别名，指向了名为土豆的索引，

那么负载就是集群状态映射中额外的键，将名称idaho映射为具体的索引名称-土豆。

这就意味着，和额外的索引相比，别名更加轻量级，维护数千个别名都不会负面地影响集群。

不过，我们反对创建数十万甚至是上百万的别名，因为到了这个临界点，即使最小的单个映射条目都会引起集群状态膨胀为一个很大的规模。

由于每次集群状态发生变化时，整个状态都需要发送到每个节点，所以创建一个新集群状态的操作将耗费更长的时间

在实际应用中，我们也不应该向单个索引持续写入数据，知道它的分片巨大无比。

巨大的索引会在数据老化后难以删除，以——id为单位删除文档不会立即释放空间

删除doc只在lucene分段合并时才会真正从磁盘中删除。

即使手工触发分段合并，仍会引起较高的I/O压力，

并且可能因为分段巨大导致合并过程中磁盘空间不足（分段大小大于此片可用空间的一半）

因此，另外一个有用的特性是：在不同的索引创建窗口。比如，如果为数据创建了每日索引，你可能期望一个滑动窗口覆盖过去一周的数据，别名就称为last-7-days.然后，每天创建新的每日索引时，将其加入别名，同时删除第8天前的旧索引。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

[
    {
        "path": "title",
        "weight": null,
        "sortType": null,
        "filterType": "MUST",
        "filterCondition": "1",
        "isReturn": true
    },
    {
        "path": "titleSeg",
        "weight": "3",
        "sortType": "TFIDF",
        "filterType": "MUST_NOT",
        "filterCondition": "2",
        "isReturn": false
    },
    {
        "path": "contents.content",
        "weight": null,
        "sortType": null,
        "filterType": null,
        "filterCondition": null,
        "isReturn": true
    },
    {
        "path": "contents.contentSeg",
        "weight": "2",
        "sortType": "TFIDF",
        "filterType": null,
        "filterCondition": null,
        "isReturn": false
    },
    {
        "path": "source",
        "weight": "1",
        "sortType": "TFIDF",
        "filterType": null,
        "filterCondition": null,
        "isReturn": true
    },
    {
        "path": "tagIds",
        "weight": "5",
        "sortType": "TFIDF",
        "filterType": null,
        "filterCondition": null,
        "isReturn": false
    },
    {
        "path": "date",
        "weight": null,
        "sortType": null,
        "filterType": null,
        "filterCondition": null,
        "isReturn": true
    }
]

搜索策略配置：策略名称，索引映射的主键ID，strategy配置项，sort_script排序脚本，排序脚本参数，type 策略类型 策略类型

（0：默认（计分方式用TF-IDF或者constant[忽略TF-IDF评分]）

1：自动补全-Completion；

2：自动补全-terms；

3：自动补全-Completion-版本控制；

4：自动补全-terms-版本控制）

创建ES索引时，一般指定2种配置信息：settings、mappings。

settings 与数据存储有关（几个分片、几个副本）

而mappings 是数据模型，类似于MySQL中的表结构定义。定义字段的属性

在Mapping信息中指定每个字段的类型，ElasticSearch支持多种类型的字段(field datatypes)，

比如String、Numeric、Date…其中String又细分成为种：keyword 和 text。

在创建索引时，需要定义字段并为每个字段指定类型，示例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

PUT my_index
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 0
  },
  "mappings": {
    "_doc": {
      "_source": {
        "enabled": true
      },
      "properties": {
        "title": {
          "type": "text",
          "norms": false
        },
        "overview": {
          "type": "text",
          "norms": true
        },
        "body": {
          "type": "text"
        },
        "author": {
          "type": "keyword",
          "norms": true
        },
        "chapters": {
          "type": "keyword",
          "norms": false
        },
        "email": {
          "type": "keyword"
        }
      }
    }
  }
}

为什么 keyword 类型的字段默认关闭 norms 呢？keyword 类型的string 可理解为：Do index the field, but don’t analyze the string value，也即：keyword 类型的字段是不会被Analyzer “分析成” 一个个的term的，它是一个single-token fields，因此也就不需要字段长度(fieldNorm)、tfNorm（term frequency Norm）这些归一化因子了。

索引中的策略数组是每个策略的数组，

数据归一化和两种常用的归一化方法

数据标准化（归一化）处理是数据挖掘的一项基础工作，不同评价指标往往具有不同的量纲和量纲单位

这样的情况会影响到数据分析的结果，为了消除指标之间的量纲影响，需要进行数据标准化处理，解决数据指标之间的可比性。

原始数据经过数据标准化处理后，各指标处于同一数量级，适合进行综合对比评价。