https://qbox.io/blog/parent-child-relationships-in-elasticsearch?utm_source=qbox.io&utm_medium=article&utm_campaign=elasticsearch-exploring-parent-child-relationships
    https://qbox.io/blog/elasticsearch-exploring-parent-child-relationships
    https://es.xiaoleilu.com/404_Parent_Child/70_Practical_considerations.html
    https://www.jianshu.com/p/0f0ac93c2fea
    parent-child
    适用：管理关系
    前提：索引性能比搜索性能更加重要
    代价：parent-child 查询时间可能是等价的 nested query 五到十倍
    parent-child ID 映射是存在内存中的，每个 parent 文档的字符串 _id 字段需要存放在内存中，每个 child 文档需要 8 字节（long value）的内存。

    使用 indices-stats API 来追踪 parent-child 缓存使用了多少内存，或者 node-stats API（在节点层的总结）：
    GET /_nodes/stats/indices/id_cache?human …1
    以比较友好的格式按节点返回内存使用 ID 缓存的情况
    尽量让 parent ID 短，以减少内存使用量
    https://qbox.io/blog/elasticsearch-performance-considerations-parent-child-relationships




    父子索引我理解是的每个分片中field cache的routing id占用的大小一样的，也可能是一个分片只维护自身的routing id，需要进一歩验证分析下。增加分片，shards meta data也多了，总共加起来占用的field cache也会增多，分片数最好不要大于节点2倍以上。