一、数据结构
es是文档型的存储方式,一条数据就是一个文档,对于用户来说就是一条JSON.
一个索引下面,有多个文档,一个文档里面有多个字段(灵活的,非结构化的,
也就是每个文档的字段都可以不一样)。
二、集群(Cluster)/节点(Node)/分片(Shards)/副本(Replicasedit)
集群:
实际上就是多个es实例,启动后,只要cluster.name是相同的,
相互之间网络关系也是通的,就是一个es集群。
节点:
实际上就是一个es实例,es的数据存储和搜索等功能都是通过这些具体的实例来实现的。
分片;
一个索引(index)里面的数据可能比较多,不适合单节点存储,索引设置分片,
不同的分片落在不同的节点上。实际上就是对索引数据的水平拆分,
分布方式以及如何将其文档聚合回搜索请求的机制完全由 Elasticsearch 管理,
对用户而言是透明的。
副本:
一个分片可以分为0-N个副本,不同的副本落在不同的节点上,
写入数据是从分片的主副本写入,然后同步到不同的节点的分片的从副本上,
所有的副本都可以进行查询。
小结:
一个es实例,会存在某些index(索引,相当于mysql的库)里面的文档数据过多,
造成单机瓶颈,因为es实例除了维护文档数据,还需要维护倒排索引等信息,
单机数据量过多会造成磁盘空间不够和搜索效率下降等问题。
所以引入了集群,多个es实例的cluster.name是相同的,就组成了一个集群。
一个集群内部,同一个index(索引,只是一个逻辑上的概念)数据,可以通过分片
将数据散落在不同的节点(物理节点,服务器)。就相当于对index里面的数据进行水平
拆分。
但是单个分片数据,有可能又有单点故障的问题,所以每个分片可以设置多个副本,散落在
不同的节点上。
类似于关系型数据库:数据库集群,假如有个用户表,我担心数据量过大,
我新建了多个用户表(即 Shard),将用户信息数据切分成多份,
然后根据某种规则分到这些用户表中,我又担心某个表会出现异常造成数据丢失,
我又将每个表分别备份了一次(即 Replica )。
三、倒排索引
实际上就是通过对文本的分词,生成这种形式的索引: 分词——>所有包含此分词的文档id/词频(Term出现的次数)/偏移量(offset)数组
倒排索引具体的样式:
1、Term(单词)
文本通过分词器分析之后,形成的多个单词
2、Term Dictionary(单词字典):
顾名思义,它里面维护的是Term,可以理解为Term的集合
3、Term Index(单词索引):
为了更快的找到某个单词,为单词建立索引
4、Posting List(倒排列表):
可以想成py里面的字典,单词就是key, value是一个数组,
这个数组里面是一系列的元组(文档id、词频(Term出现的次数)、偏移量(offset))
5、倒排索引的寻址过程
分词之后,会根据分出来的词生成一个term index(分词索引),查找的时候,
会先根据这个term index去找到Term Dictionary(分词字典)中的term,
再根据term找到对应的Posting List(倒排列表)
四、关键属性、字段说明
1、查询返回字段说明:
{
"took": 1, //整个搜索请求花费多少毫秒
"timed_out": false,
"_shards": {
//指示搜索了多少分片,以及搜索成功和失败的分片的计数
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
//用来实际搜索结果集
"total": 1, // 搜索返回条数
"max_score": 0.83355963, //搜索结果匹配度
"hits": [ //查询完整的数据 以_score降序排序
{
"_index": "test", //索引
"_type": "test", //类型
"_id": "xtoffH0BS_BXL2CbFNQ_", //索引数据id
"_score": 0.83355963, // 衡量文档与查询的匹配程度
"_source": {
// 结果原数据
"name": "新浪军事22"
}
}
]
}
}
2、创建索引
# 指定mapping创建方式
PUT translated_documents
{
"mappings": {
"translated_documents": {
#