海量数据是否有必要全部存到 nosql，还是说只是文本部分存到 nosql

今天看了京东的评论存储方案，发现虽然数据量十分庞大，但是京东还是用了 mysql 结合 hbase。有点疑问为什么不全用 hbase 或者全用 mysql 呢
为什么要把文本的数据存到 hbase 里面呢，如果说 mysql 扛不住可以全放到 hbase 里面既然 mysql 分表了扛得住把文本数据家个字段往 mysql 存不就可以去掉 hbase 了吗。

以下是应用的文章

``京东的商品评论目前已达到数十亿条，每天提供的服务调用也有数十亿次，而这些数据每年还在成倍增长，而数据存储是其中最重要的部分之一，接下来就介绍下京东评论系统的数据存储是如何设计的。

整体数据存储包括基础数据存储、文本存储、数据索引、数据缓存几个部分。

基础数据存储

基础数据存储使用 mysql，因用户评论为文本信息，通常包含文字、字符等，占用的存储空间比较大，为此 mysql 作为基础数据库只存储非文本的评论基础信息，包括评论状态、用户、时间等基础数据，以及图片、标签、点赞等附加数据。而不同的数据又可选择不同的库表拆分方案，参考如下：

评论基础数据按用户 ID 进行拆库并拆表；

图片及标签处于同一数据库下，根据商品编号分别进行拆表；

其它的扩展信息数据，因数据量不大、访问量不高，处理于同一库下且不做分表即可。

因人而异、因系统而异，根据不同的数据场景选择不同存储方案，有效利用资源的同时还能解决数据存储问题，为高性能、高可用服务打下坚实基础。

文本存储

文本存储使用了 mongodb、hbase，选择 nosql 而非 mysql，一是减轻了 mysql 存储压力，释放 msyql，庞大的存储也有了可靠的保障；二是 nosql 的高性能读写大大提升了系统的吞吐量并降低了延迟。存储的升级过程尝试了 cassandra、mongodb 等分布式的 nosql 存储，cassandra 适用于写多读少的情况，而 mongodb 也是基于分布式文件存储的数据库，介于关系型数据库与非关系型数据库之间，同时也是内存级数据库，mongo 写性能不及 cassandra，但读写分离情况下读性能相当不错，因此从应用场景上我们选择了 mongodb。mongodb 确实不错，也支持了系统稳定运行了好几年。

但从今后的数据增长、业务扩增、应用扩展等多方面考虑，hbase 才是最好的选择，它的存储能力、可靠性、可扩展性都是毋庸置疑的。选择了 hbase，只需要根据评论 ID 构建 Rowkey，然后将评论文本信息进行存储，查询时只需要根据 ID 便能快速读取评论的文本内容，当然也可将评论的其它字段信息进行冗余存储，这样根据评论 ID 读取评论信息后不用再从 mysql 进行读取，减少数据操作，提升查询性能。``