9月27日，阿里云HBase发布了冷存储特性。用户可以在购买云HBase实例时选择冷存储作为一个附加的存储空间，并通过建表语句指定将冷数据存放在冷存储介质上面，从而降低存储成本。冷存储的存储成本仅为高效云盘的1/3，适用于数据归档、访问频率较低的历史数据等各种场景。
阿里云HBase是基于Apache HBase深度优化的全托管、PB级、千万级QPS随机读写的云数据库，其在物联网、车联网、用户画像、历史数据存储、AI人工智能、Feeds等场景有广泛的应用。自产品发布以来，我们一直在努力优化，为用户提供更高的性能和更低的成本。此次发布的冷存储特性，针对冷数据存储的场景，可以在保证数据随时可访问及不低于云盘的写入性能的前提下，大幅降低用户的存储成本。
适用场景
一般随着业务的发展，HBase中存储的数据量会逐渐变大。在这些数据中，业务最关心的，最常访问的，往往是某些特定范围的数据，比如说最近7天的数据，业务对这类数据访问频次高，延迟要求高，即所谓的热数据。而其他的数据，一般访问量极少，性能要求不高, 但这类数据往往数据量大，即冷数据。如果能把冷热数据分离开，把热数据存储在性能更好的介质中，而把庞大的冷数据放到成本更低的介质中，从而实现把更多优质资源用来提高热数据的读写性能，同时节省存储成本的目的。
通常来说，冷数据具有如下特点：
1 数据量大，因此对成本更敏感。
2 较低的访问频率，因此可以容忍更低的访问qps和更高的访问延时，但是大多数场景下都要求随时可以访问。
3 写入tps并不低。无论是历史数据还是归档数据，他们的写入速度其实都和热数据相当。
基于以上这些特点，HBase冷存储在优化成本的同时，提供了和高效云盘相当的写入性能，并保证数据随时可访问。当然，作为优化成本的代价，冷存储上HBase的读操作qps较低，延时（在不命中缓存情况下）也比云盘要高一些。
下表对HBase上的冷存储和高效云盘两种形态做了比较。可以看出，冷存储在冷数据场景下有极大的优势。
| 存储介质 | 冷存储 | 高效云盘 |
| 存储成本(元/GB/月) | 0.2 | 0.7 |
| 单机最大支持数据量 | 11TB | 8TB |
| 起步购买量 | 800GB | 800GB |
| 扩容最小单位 | 1GB | 1GB |
| 机型要求 | 无要求 | 无要求 |
| 写入性能 | 较好（具体数据和机型有关） | 较好（具体数据和机型有关） |
| 查询性能 | 较差（具体数据和机型有关） | 较好（具体数据和机型有关） |
大幅降低存储成本
只看存储成本的话，冷存储的成本不到高效云盘的1/3，由于冷数据的量通常都比较大，存储介质的成本占大头，因此即使考虑到计算资源的成本不变，整体上成本仍然有很大幅度的下降。
以某车联网应用为例：拥有10万台车， 每台车每30秒上传7K的包，数据半年后就很少访问了，但是有时会有查询历史数据的需求，所以这部分冷数据又不能删除。有了云HBase的冷存储特性，就可以把半年之前的数据放在冷存储上面节约存储成本，半年内的数据仍然放在高效云盘保证热数据的高效访问。
我们以3年的存储 ( 约2P)来估算成本，见下图。
可见，对于冷热数据混合的场景，通过把冷数据存放在冷存储上面可以大幅降低存储成本。对于纯冷数据的场景（例如归档数据），节省的成本就更加可观了。
写入性能与云盘相当
测试环境：
HDFS 6台8核32G DataNode
HBase 1台8核32G RegionServer
每台ECS挂载4块300G 高效云盘valueSize=100B
threads=120
测试结果：
无需代码改动，轻松搞定冷数据
冷存储可以独立购买，作为一个附加存储空间使用。购买冷存储介质后，可以在建表时候中指定把表创建在冷存储上（即冷表），默认是创建在云盘介质上（即热表）。HBase会根据表的属性将数据放在对应的存储介质上面，这个细节对应用是透明的，应用不需要关心表的数据存储在哪里，都是通过hbase的API对表进行读写操作，因此访问冷数据的代码不需要做任何改动。
注意事项
1.冷存储的__读IOPS__能力很低，所以冷表只适合存储冷数据。
2.写入吞吐上，冷表和基于高效云盘的热表相当，可以放心写入数据。
3.建议平均每个core节点管理冷数据不要超过10T。如果是同时有冷热表的集群，需要看region数量来衡量。
原文链接
本文为云栖社区原创内容，未经允许不得转载。
