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

题记
我在做Elasticsearch相关咨询和培训过程中，发现大家普遍更关注实战中涉及的问题，下面我选取几个常见且典型的问题，和大家一起分析一下。订单表、账单表父子文档可以实现类似SQL的左连接吗？通过canal同步到ES中，能否实现类似左连接的效果？具体应该如何建模？一个人管理1000家连锁门店，如何更高效地查询自己管辖的商品类目？企微一个人维护了1000个员工，如何快速查询自己管辖的员工信息？随着业务的增长，一个索引的字段数据不断膨胀（商品场景变化，业务一直加字段），有什么解决方法？一个索引字段个数设置为1500个，超出这个限制，会不会消耗CPU资源和造成写入堆积？日志诊断用于机器学习基线，需要将message分离出来，怎么在写入前搞定？
如果我们对上述实战问题进行归类，就都可以归结为Elasticsearch数据建模问题。
本文将以实战问题为基准，手把手带你实践Elasticsearch数据建模全流程，重点解析基于业务角度、数据量角度、Setting、Mapping ，以及复杂索引关联，这五个层面中涉及的数据建模实战问题，让你学完即可应用到工作中。
一、为什么要做数据建模？
我们选型传统的数据库，这里以MySQL为例，做数据存储前需要考虑的问题如下：数据库要不要做读写分离？分几张表存储？每个表的名是什么？每个表是按照业务划分吗？单表数据大了怎么搞？分库分表还是其他？每个表要有哪些字段？每个字段设置什么类型？如何设计合理的字段类型，才能保证节省存储？哪些字段需要建索引？哪些字段需要设置外键？表之间要不要建立关联？如何实现关联联动查询？关联查询可能会很慢？如何设计阶段优化建模才能提高响应速度？
以上这些疑问也均是数据建模问题。在MySQL中我们往往认为建模非常有必要，但反观Elasticsearch ， “上手快”这类先入为主的观念已根植在很多同学心中，使得大家忽略了Elasticsearch数据建模的重要性。
接下来，我们基于MySQL做数据存储需要考虑的问题，重新审视数据建模的定义，内容如下。数据模型是对描述数据、数据联系、数据语义和一致性约束进行标准化的抽象模型。数据建模是为存储在数据库中的资源创建和分析数据模型的过程。数据建模主要目的是表示系统内的数据类型、对象之间的关系及其属性。数据模型有助于了解需要哪些数据以及应如何组织数据。
到这里，相信你已经初步明晰了数据建模的重要性。但我还想提醒你的是， “一把梭用法，上来就是干”并不是捷径，尤其到了项目中后期，极易暴露出问题。经历的项目越多，你会发现建模的时间不能省。
下面我们具体分析一下为什么要数据建模？
相比于MySQL ， Elasticsearch有非常快捷的优势：
Elasticsearch支持动态类型检查和匹配。也就是说，当我们写入索引数据的时候，可以不提前指定数据类型，直接插入数据。
以类似天眼查、企查查的工商实战数据为例（已做脱敏处理），如果利用以下语句直接创建索引和写入一条数据，岂不是很快？
PUTcompany_index/_doc/1
{
"regist_id":1XX1600000000012,
"company_name":"北京XX长江创业投资有限公司",
"regist_id_new":"191XX160066933968XC",
"legal_representative":"徐X武",
"scope_bussiness":"创业投资业务；代理其他创业投资企业等机构或个人的创业投资业务；创业投资咨询业务；为创业企业提供管理服务业务；参与设立创业投资企业与企业投资管理顾问机(依法须经批准的项目，经相关部门批准后方可开展经营活)",