您需要NoSQL数据库才能像RDBMS一样工作,并且鉴于数据的大小,如果坚持下去,您的生活会变得简单得多,除非您期望指数增长:)另外,您也不会提及数据是否能够获得更新,这对于做出正确的决定非常重要.
话虽如此,您有很多选择,这里有一些:
>如果您可以等待结果:编写MapReduce任务进行扫描,排序并检索最前面的X行,那么每种类型是否真的需要超过1000页(20-50k行)?另一种选择是使用类似Hive的东西.
>如果您可以聚合数据并“减少”数据集:编写MapReduce任务以定期将最新的聚合数据导出到SQL表(它将处理查询).我已经做过几次了,它的工作原理很吸引人,但这取决于您的要求.
>如果您有足够的存储空间:编写MapReduce任务以为每个属性定期重新生成(或附加数据)一个新表(在行键中按其排序).您不需要多个表,只需在每种情况下的行键中使用前缀,或者,如果您不希望使用表并且查询不多,只需将排序后的数据写入csv文件并将其存储在HDFS,您的前端应用程序可以轻松读取它们.
>手动维护二级索引:该二级索引不会非常容忍架构更新和新属性,但对于接近实时的结果非常有用.为此,您必须将代码更新为也要使用良好的缓冲区写入辅助表,以帮助提高性能同时避免出现热点区域.考虑这种类型的行键:[4B SORT字段ID(4个字符)] [8B SORT字段值] [8B时间戳记],其中只有一列存储主表的行键.要检索按任何字段排序的数据,只需执行以下扫描即可:将SORT FIELD ID作为开始行,将起始排序字段值作为分页的枢轴(忽略它以获取第一页,然后设置最后一页)您将拥有主表的行键,并且只需对其执行一次multiget即可检索完整数据.请记住,您将需要一个小的脚本来扫描主表并将数据写入现有行的索引表.
>尽管您完全不喜欢此选项,但您可以依靠您提到的通过协处理器进行的任何自动二级索引.