Elasticsearch系列---数据建模实战

概要

本篇以实际案例为背景，介绍不同技术组件对数据建模的特点，并以ES为背景，介绍常用的联合查询的利弊，最后介绍了一下文件系统分词器path_hierarchy和嵌套对象的使用。

数据模型对比

实际项目中，电商平台系统常见的组合Java、Mysql和Elasticsearch，以基础的部门-员工实体为案例。

JavaBean类型定义

如果是JavaBean类型，会这样定义

public class Department {
	private Long id;
	private String name;
	private String desc;
	private List userIds;
}

public class Employee {
	private Long id;
	private String name;
	private byte gender;
	private Department dept;
}

数据库模型定义

如果是关系型数据库(mysql)，会这样建表

create table t_department (
	id bigint(20) not null auto_increment,
	name varchar(30) not null,
	desc varchar(80) not null,
	PRIMARY KEY (`id`)
)

create table t_employee (
	id bigint(20) not null auto_increment,
	name varchar(30) not null,
	gender tinyint(1) not null,
	dept_id bigint(20),
	PRIMARY KEY (`id`)
)

依据数据库三范式设计表，每个实体设计成独立的表，用主外键约束进行关联，按照现有的数据表规范，已经不再使用外键约束了，外键约束放在应用层控制。

ES文档数据模型

如果es的文档数据模型，会这样设计document

{
	"deptId": 1,
	"deptname": "CEO办公室",
	"desc":"这一个有情怀的CEO",
	"employee":[
		{
			"userId":1,
			"name":Lily,
			"gender":0
		},
		{
			"userId":2,
			"name":Lucy,
			"gender":0
		},
		{
			"userId":3,
			"name":Tom,
			"gender":1
		}
	]
}

es更类似面向对象的数据模型，将所有关联的数据放在一个document里。

JOIN查询

我们以博客网站为案例背景，建立博客网站中博客与用户的数据模型。

将用户与博客分别建立document，分割实体，类似数据库三范式，并使用关键field（userId）建立依赖关系

先建立两个实体document，放一条示例数据

PUT /blog/user/1
{
  "id":1,
  "username":"Lily",
  "age":18
}

PUT /website/article/1
{
  "title":"my frist blog",
  "content":"this is my first blog, thank you",
  "userId":1
}

需求：要查询用户名Lily发表的博客
步骤：1）查询用户document，根据名字Lily查询到它的userId；
2）根据第一步查询返回的userId，重新组装请求报文，查询博客docuement
示例报文：

GET /blog/user/_search
{
  "query": {
    "match": {
      "username.keyword": "Lily"
    }
  }
}

GET /website/article/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "terms": {
          "userId": [
            "1"
          ]
        }
      }
    }
  }
}

以上步骤叫做应用层Join实现关联查询

• 优点：结构清晰明了，数据不冗余，维护方便。
• 缺点：应用层join，如关联的数据过多，查询性能很低。

适用场景：两层join，第一层document查询基本上能做到精准查询，返回的结果数很少，并且第二层数据量特别大。如案例中的场景，根据名称找userId，返回的数据相对较少，第二层的查询性能就比较高，第二层数据属于业务数据类型，数据量肯定特别大。

适度冗余减少应用层Join查询

普通查询

接上面案例，修改博客document，将username冗余到该document中，如：

PUT /website/article/2
{
  "title":"my second blog",
  "content":"this is my second blog, thank you",
  "userInfo": {
    "id":1,
    "username":"Lily"
  }
}

查询时直接指定username:

GET /website/article/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "term": {
          "userInfo.username.keyword": "Lily"
        }
      }
    }
  }
}

• 优点：一次查询即可，性能较高
• 缺点：若冗余的字段有更新，维护非常麻烦

适合场景：适当的冗余比较有必要，可以减小join查询，关系型数据库设计也经常有冗余数据的优化，只要挑选冗余字段时要注意尽量选变更可能性小的字段，避免查询一时爽，更新想撞墙这种事情发生。

数据冗余设计后聚合分组查询

造点测试数据进去

PUT /website/article/3
{
  "title":"my third blog",
  "content":"this is my third blog, thank you",
  "userInfo": {
    "id":2,
    "username":"Lucy"
  }
}

PUT /website/article/4
{
  "title":"my 4th blog",
  "content":"this is my 4th blog, thank you",
  "userInfo": {
    "id":2,
    "username":"Lucy"
  }
}

分组查询：Lily发表了哪些博客，Lucy发表了哪些博客

GET website/article/_search
{
  "size": 0,
  "aggs": {
    "group_by_username": {
      "terms": {
        "field": "userInfo.username.keyword"
      },
      "aggs": {
        "top_articles": {
          "top_hits": {
            "size": 10,
            "_source": {
              "includes": "title"
            }
          }
        }
      }
    }
  }
}

文件搜索

文件类型的数据有个很大的特点：有目录层次关系。如果我们有对文件搜索的需求，可以这个建立索引：

PUT /files
{
  "settings": {
    "analysis": {
      "analyzer": {
        "paths": {
          "tokenizer":"path_hierarchy"
        }
      }
    }
  }
}

PUT /files/_mapping/file
{
  "properties": {
    "name": {
      "type": "keyword"
    },
    "path": {
      "type": "keyword",
      "fields": {
        "tree": {
          "type": "text",
          "analyzer": "paths"
        }
      }
    }
  }
}

注意分词器path_hierarchy，会把/opt/data/log分成

/opt/

/opt/data/

/opt/data/log

插入一条测试数据

PUT /files/file/1
{
  "name":"hello.txt",
  "path":"/opt/data/txt/"
}

搜索案例

指定文件名，指定具体路径搜索

GET files/file/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "name": "hello.txt"
          }
        },
        {
          "match": {
            "path": "/opt/data/txt/"
          }
        }
      ]
    }
  }
}

/opt路径下的hello.txt文件（包含子目录）

GET files/file/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "name": "hello.txt"
          }
        },
        {
          "match": {
            "path.tree": "/opt/"
          }
        }
      ]
    }
  }
}

区别：path与path.tree的使用
path.tree是会分词的，并且指定分词器为path_hierarchy
path不分词，直接使用。

nested object数据类型

提出问题

用普通的object对象做数据冗余时，如果冗余的数据是一个数组集合类的，查询可能会出问题，例如：博客信息下面的评论，是一个集合类型

PUT /website/article/5
{
  "title": "清茶豆奶发表的一篇技术帖子",
  "content":  "我是清茶豆奶，大家要不要考虑关注一下Java架构社区啊",
  "tags":  [ "IT技术", "Java架构社区" ],
  "comments": [ 
    {
      "name":    "清茶",
      "comment": "有什么干货没有啊？",
      "age":     29,
      "stars":   4,
      "date":    "2019-10-29"
    },
    {
      "name":    "豆奶",
      "comment": "我最喜欢研究技术，真好",
      "age":     32,
      "stars":   5,
      "date":    "2019-10-30"
    }
  ]
}

需求：查询被29岁的豆奶用户评论过的博客

GET /website/article/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "comments.name.keyword": "豆奶"
          }
        },
        {
          "match": {
            "comments.age": "29"
          }
        }
      ]
    }
  }
}

根据这条演示数据，这个条件是查不到结果的，但实际却查出来这条数据，为什么？

原因：object类型底层数据结果，会将json进行扁平化存储，如上例子，存储结构将变成：

{
	"title":["清茶","豆奶","发表","一篇","技术","帖子"],
	"content": ["我","清茶","豆奶","大家","要不要","考虑","关注","一下","Java架构社区"],
	tags:["IT技术", "Java架构社区"],
	comments.name:["清茶","豆奶"],
	comments.comment:["有","什么","干货","没有啊","我","最喜欢","研究","技术","真好"],
	comments.age:[29,32],
	comments.stars:[4,5],
	comments.date:["2019-10-29","2019-10-30"]
}

这样"豆奶"和29就被命中了，跟预期的结果不一致。

解决办法

引入nested object类型，就可以解决这种问题。
修改mapping，将comments的类型改成nested object。
先删掉索引，再重新建立

PUT /website
{
  "mappings": {
    "article": {
      "properties": {
        "comments": {
          "type": "nested",
          "properties": {
            "name": {"type":"text"},
            "comment": {"type":"text"},
            "age":     {"type":"short"},
            "stars":   {"type":"short"},
            "date":  {"type":"date"}
          }
        }
      }
    }
  }
}

这样底层数据结构就成变成：

{
	"title":["清茶","豆奶","发表","一篇","技术","帖子"],
	"content": ["我","清茶","豆奶","大家","要不要","考虑","关注","一下","Java架构社区"],
	tags:["IT技术", "Java架构社区"],
	comments:[
		{
			"name":"清茶",
			"comment":["有","什么","干货","没有啊"],
			"age":29,
			"stars":4,
			"date":"2019-10-29"
		},
		{
			"name":"豆奶",
			"comment":["我","最喜欢","研究","技术","真好"],
			"age":32,
			"stars":5,
			"date":"2019-10-30"
		}
	]
}

再查询结果为空，符合预期。

聚合查询示例

求博客每天评论的平均星数

GET /website/article/_search
{
  "size": 0,
  "aggs": {
    "comments_path": {
      "nested": {
        "path": "comments"
      }, 
      "aggs": {
        "group_by_comments_date": {
          "date_histogram": {
            "field": "comments.date",
            "interval": "day",
            "format": "yyyy-MM-dd"
          }, 
          "aggs": {
            "stars_avg": {
              "avg": {
                "field": "comments.stars"
              }
            }
          }
        }
      }
    }
  }
}

响应结果(有删节)：

{
  "aggregations": {
    "comments_path": {
      "doc_count": 2,
      "group_by_comments_date": {
        "buckets": [
          {
            "key_as_string": "2019-10-29",
            "key": 1572307200000,
            "doc_count": 1,
            "stars_avg": {
              "value": 4
            }
          },
          {
            "key_as_string": "2019-10-30",
            "key": 1572393600000,
            "doc_count": 1,
            "stars_avg": {
              "value": 5
            }
          }
        ]
      }
    }
  }
}

小结

本篇以实际的案例为主，简单快速的介绍了实际项目中常用的数据联合查询，嵌套对象的使用等，很有实用价值，可以了解一下。

专注Java高并发、分布式架构，更多技术干货分享与心得，请关注公众号：Java架构社区
可以扫左边二维码添加好友，邀请你加入Java架构社区微信群共同探讨技术