学会这个ES数据建模指南，还需要啥MySQL？( 二 ) 题记我在做Elasticsearch相关咨询

"registration_status":"在营（开业）企业",
"approval_date":"201X年04月13日",
"registration_number":"191XX160066933968XC",
"establishment_time":"200X年12月03日",
"address":"北京市黄河XX路西首育青小区",
"register_capital":3000,
"business_starttime":"20XX年12月03日",
"registration_authority":"北XX工商行政管理局",
"company_type":"其他有限责任公司",
"enttype":1190,
"enttypename":"法定代表人:",
"pripid":"1XXX102201305305801X",
"uniscid":"1XXX160066933968XC"
}
相比于MySQL中一个字段一个字段地敲定，这样操作确实节省了很多时间。但随着后续数据量激增，副作用便会很快显现出来。该处理方式的弊端：首先是极大地浪费了存储空间，所有字符串类型数据都存储为text+keyword组合类型，这种很多业务字段都是非必须的；其次字符串类型默认分词standard ，无法满足中文精细化分词检索的需求。
接下来，结合我自己工作中早期系统的一个案例，我们做进一步分析。
5个数据节点集群（5个分片， 1个副本），微博数据每日增量5000W+（增量存储150GB），核心数据磁盘10TB左右，很明显该系统面临存储上限问题。
我们当时就上述业务数据规划了一个大索引，比如微博数据一个索引，微信数据一个索引。但微博索引最多只能存储20天左右的数据，然后就得走删除索引数据的操作。由于1个索引只能通过delete_by_query删除部分数据，而delete_by_query的特点是版本号更新的逻辑删除，实际效果是越删数据量越大，磁盘占用率激增。加上是线上环境，压力之大，处理难度之大，经历过你就知道有多苦。
这也是很多大厂在面试候选人的时候，尤其偏爱数据建模能力强的工程师的主要原因之一。
比如下图是美团对大数据开发高级工程师的岗位要求，第一条就是“深入理解业务，对业务服务流程进行合理的抽象和建模。 ”

文章图片
从以上两个反例，以及这条招聘信息中便可以窥探出数据建模的重要性。下面我们具体说说如何做数据建模。
二、Elasticsearch如何数据建模？
在做数据建模之前，会先进行架构设计，架构环节涉及选型、集群规划、节点角色划分。
本文涉及的建模倾向于索引层面、数据层面的建模。为了让你学完即可应用到工作中，我会结合项目实战进行讲解。
1、基于业务角度建模
Elasticsearch适用范围非常广，包括电商、快递、日志等各行各业。涉及索引层面的设计，和业务贴合紧密。
其一：业务一定要细分。
分成哪几类数据，每类数据归结为一个索引还是多个索引，这是产品经理、架构师、项目经理要讨论敲定的问题。比如大数据类的数据，可以按照业务数据分为微博索引、微信索引、Twiiter索引、Facebook索引等。
其二：多个业务类型需不需要跨索引检索？
跨索引检索的痛点是字段不统一、不一致，需要写非常复杂的bool组合查询语句来实现。为了避免这种情况，最好的方式就是提前建模。每一类业务数据的相同或者相似字段，采取统一建模的方式。
下面我们举一个实际的例子加以分析。微博、微信、Twitter、Facebook都有的字段，可以设计如下：

文章图片
这样设计的好处是：字段统一，写查询DSL无需特殊处理，非常快捷方便。所以，在设计阶段，多个业务索引数据要尽可能地“求同存异” 。具体来说：求同指的是相同或者相近含义字段，一定要统一字段名、统一字段类型；存异指的则是特定业务数据特有字段类型，可以独立设计字段名称和类型。