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

[zhangfeiwudi]

今天看了京东的评论存储方案，发现虽然数据量十分庞大，但是京东还是用了 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 进行读取，减少数据操作，提升查询性能。``

[liprais]

hbase 跟 mysql 还是不能比的，虽然 mysql 也很烂

[virusdefender]

因为关系型数据库的特性，一些大字段会降低查询性能（主要是 io，和列存储对比），所以一般就是大字段没有筛选和聚合需要的扔出来，关系型数据库存储小字段。

[WuwuGin]

因为等到用 nosql 的时候又要去模拟关系型数据库就知错了。我觉得还是要看数据类型。

[zhangfeiwudi]

@virusdefender 如果说直接上 nosql 是不是很多关系型数据库的特性 无法使用 增加了业务复杂度，所以才会用 mysql 分表+ nosql 这种方案？