背景：
- 有时候需要将数据库中的数据迁移至ES中，那么数据库中的库、表、记录、列属性应该如何对应于ES中的index/type/document/field呢？
- 将表结构相似且数据量相当的table放在相同的index下，每个table占用该index下一个type
- 由于同一个index下所有type下的文档统一存放在相同的shard上，所以表结构不相似的table不要放在同一个index下，
- 例如，如果两个table根本没有相同的字段，那么若是硬要将这两个table存成同一个index下的两个type，则会造成存储空间的浪费，如果两个表格数据量相当，则该index下的shard中会有将近一半的存储空间是被浪费掉的
- 表结构相似但是数据量相差较大的（有的十几万，有的上千万）table，也不应该放在同一index下
- 并且由于ES索引一旦创建之后就不能再更改其主分片（primary shards）数目，所以数据迁移之前最好根据数据量大小尽量预估出适当的分片数量，为将来的水平扩展做好准备
- 理论上对同一个索引，单机上的shards个数最好不要超过两个，这样每个查询尽可能并行
- 但因为ES中shards的个数是确定了就没办法再调整的，所以如果考虑到数据会高速增长，一开始分配多些也可以。
- 但太多的shards通常是不推荐的，ES管理起来也有开销。
- 确定分片数量（或者每个分片大小）的最佳实践方法。
- 使用和计划在生产环境中使用的配置接近的一台服务器搭建一个单节点的ES集群。
- 在这个ES集群中创建和生产环境中所要求的配置相同（指字段的数量、类型、内容分析器等等）的索引，但这个索引只有一个分片，并且复制系数为0。
- 自用这个ES集群使用真实的数据建立索引。
- 根据生产环境所要求的并发量、响应时间、检索要求、聚合要求等进行搜索测试。
当服务出现不满足生产要求时（主要指性能相关的指标）即可得出每个分片的可承载数据量，结合整体的数据量评估进而推算出需要的分片数量。
设计过程：
- step1，分析数据库中tables的结构，找出结构相似的tables, 并且查看他们的数据量大小，分析哪些tables可以放在同一index下
- 结构相似且数据量相当的tables可以放在同一个index下
- step2，将可以放在同一个index下的tables存放在同一个index下，每个table对应于该index下一个type
- step3，将剩下的其他tables存成单独的index(由于该类型index下只有一个table，所以该类型index下只有一个type)
- step5，计算每个索引下所有tables相加的总的数据量，预估该索引下需要的主分片数目
- step6，根据搜索需求设计每个type对应的映射（_mapping），包括每个字段的索引类型、分析器等等