公司准备将消息中心由原先的mysql储存改为hbase，主要需求如下：
1.消息分为系统公告和个人消息，个人消息有不同的类别，每条消息有已读和未读状态。
2.查看消息时可以分别查看全部消息、系统公告和个人消息，其中个人消息可以分类别查看。也可以分已读和未读查看（按照时间排序）。
现在的消息表的设计是这样的：
rowkey = uid+is_read+msg_type+递减的timestamp，比如：22222222,1,3,8595702279104
column family只有一个message，用于存储消息内容
根据hbase的数据存储特性，数据按照rowkey的字典序排列，这样很容易按分类别查看数据，但查看全部消息就不能按照时间排序了，因为不同类别的消息都聚集在一起，如果把timestamp放到is_read前面，所有消息按时间排列，但不同类别的消息又分散了。都不能满足需求。（同一条数据分不同的rowkey存两次可以解决问题，但是增加了一倍的储存空间不太可取啊）
前端是通过thrift用php访问的，提供的接口真的很不灵活，请问有什么好的解决方案吗？还有就是hbase的存储性能怎么样，希望有使用经验的朋友们能介绍一下 :)
1.消息分为系统公告和个人消息，个人消息有不同的类别，每条消息有已读和未读状态。
2.查看消息时可以分别查看全部消息、系统公告和个人消息，其中个人消息可以分类别查看。也可以分已读和未读查看（按照时间排序）。
现在的消息表的设计是这样的：
rowkey = uid+is_read+msg_type+递减的timestamp，比如：22222222,1,3,8595702279104
column family只有一个message，用于存储消息内容
根据hbase的数据存储特性，数据按照rowkey的字典序排列，这样很容易按分类别查看数据，但查看全部消息就不能按照时间排序了，因为不同类别的消息都聚集在一起，如果把timestamp放到is_read前面，所有消息按时间排列，但不同类别的消息又分散了。都不能满足需求。（同一条数据分不同的rowkey存两次可以解决问题，但是增加了一倍的储存空间不太可取啊）
前端是通过thrift用php访问的，提供的接口真的很不灵活，请问有什么好的解决方案吗？还有就是hbase的存储性能怎么样，希望有使用经验的朋友们能介绍一下 :)
Select Language