关于拥有海量数据的电子商务网站的CRM系统建设底层存储实现的一点随想

最近在一直在研究hadoop的使用，主要是集中在数据仓库的应用这块。今天突然和一个业内的朋友聊起大型电子商务网站CRM系统建设的技术问题。CRM系统最基本的功能就是查询某个用户在我们网站进行的所有的操作，光这个需求，对于有千万级别用户的网站来说，设计起来就相当繁琐。比如查A用户在我们网站的所有交易订单记录，那么如果你是架构师，你会怎么设计?

通常的想法还是按照用户建分库，分表，把不同的用户段的订单存放在不同的库中，从而可以拆分库的目的，这样从一定程度上来说确实可以解决问题，但是治标不治本，随着网站的继续交易，总有一天分库也会达到查询能力的极限，到时候只有继续拆分库，这是一个痛苦的轮回。

今天我提出的是一个基于hbase的新思维，关于hbase的介绍请参考淘宝的博客http://www.tbdata.org/archives/1509。

我们可以在hbase中建一个用户表，rowkey为用户id，userinfo列簇，orderinfo列簇……其他列簇；

其中userinfo中存放用户的基本信息；

关键在于orderinfo列簇，在hbase的列簇中可以随意自定义列，我们可以把订单号作为列名，从而达到在一个列簇中存放用户的所有的订单信息；

示例数据如下：

rowkey	userinfo	orderinfo
201010100001	"id:201010100001" "name:张三" "sex:male" "age:19"	;"orderid0001:张三 2010年1月1日15：31 htc desire z 交易成功" "orderid0002:张三 2010年1月2日15：31 ipad2 交易成功"

这样就可以快速使用程序从hbase中查询某一个用户的详细历史信息，orderinfo中每一笔订单中的信息可以采用一些分隔符来分割订单的具体的字段信息，展示的时候利用程序解析还原成结构化的订单信息。

这还只是我很初步的一个思路，并没有经过实际验证是否可行，欢迎各位博友拍砖。