ES单type属性个数的限制

大的问题没有，但是要考虑一下数据模型是否应该稍微设计一下，从而更高效的利用ES的资源。
 
问2个问题:
1. HBASE里的数据是否基本都有2000个字段?
2. 是否需要用到ES按字段做排序或者聚合计算?
 
如果需要通过ES做排序和聚合计算，那么就要用到doc values，而目前Lucene里doc values的实现是使用文档ID做为索引的，意味这为每条文档都要保留固定的存储空间。 如果HBASE里的数据非常稀疏，那么磁盘空间使用方面可能不够高效。 比如即使一个文档只有十几个字段，在doc values存储方面的空间消耗依然要付出2000个字段的代价。
 
因此如果hbase里数据已经很稠密了，多数文档差不多都是2000+字段的，那么也就只能全部放在一个type里索引了， 否则应该考虑不同类型的文档索引到不同的ES索引里面去。  
 
或者只需要用ES做索引，不需要按字段排序和做聚合，也可以关闭doc values。