| 场景 | 单次查询条件 | 查询 方式 |
rowkey设计 | 建表 | 存在的问题 |
| 指标墙 | 时间、地域、指标都固定 | get | 指标 + 时间 + 子region | 三种场景一个表 | 第一种场景没问题 |
| 指标分析 | 地域、指标固定、时间范围查询 | scan+过滤器 | scan后有大量的数据需要过滤(多达数十万以上的数据)，直接影响查询效率 | ||
| 报表 | 时间、指标固定、指定父地域查询父子地域的指标 | scan+过滤器 |
| 场景 | 单次查询条件 | 查询 方式 |
rowkey设计 | rowkey前缀设计 | 建表 | 设计理由 |
| 指标墙 | 时间、地域、指标都固定 | get | 指标-地域-时间 | 地域+指标一起做hash | 两个场景用一个表 | rowkey是固定的用get能够快速返回 |
| 指标分析 | 地域、指标固定、时间范围查询 | scan | 地域、指标固定后，最大的时间范围就是365天，scan的数据很小，能快速返回 | |||
| 报表 | 时间、指标固定、指定父地域查询父子地域的指标 | scan | 指标-时间-父地域-子地域 | 时间+指标一起做hash | 单独一个表 | 1、时间、指标、父地域三者固定，scan来查子地域扫描的范围就少多了 (父地域下的子地域最多有几千个) 2、时间、指标、父地域三者固定，可以从前两个场景对应的表里用get快速 查出父地域的数据 |
原文链接：https://blog.csdn.net/KamRoseLee/article/details/84070349