冷热数据 -- 系统架构 -- IT技术博客大学习 -- 共学习共进步！

您现在的位置：首页 --> 系统架构 --> 冷热数据

冷热数据

浏览:5133次出处信息

这一周在考虑冷热数据的二期，分析了多个维度的数据，感觉有点乱，记录一下。

我们的后端存储主要依赖于数据库(博文)，一般根据业务和功能进行分库/分表的拆分，来保持数据库实例的大小.在现实中遇到一系列的问题：

1)文章信息,包括文章内容都存储在一块.所以单个数据库记录非常的大.

2)理论上来说当数据库量越来越大的时候,理论上可以分库分表进行进一步分摊,但是实际上这个操作影响极大,包括程序的调整,服务的暂停.从目前我们的情况来看,已经不太建议使用。

3)假如你做容量规划,会发现2011年文章的增长量将会达到原有存储的一半,所以存储优化实在必行。

同时数据库实例还会导致数据库备份，查询性能降低等一些列问题。提供一个数字，目前我们单个表数据库记录数已经达到120万。

所谓的冷热拆分是依托于业务形态而产生的一个词。数据访问有这样一些情况：

1)大部分访问集中在小部分的用户身上。

2)数据库记录集越大，则部分查询性能极低（比如某个用户最有一页的文章列表）。

3)一般数据库设计和应用无大问题的情况下,数据库的查询性能普遍还是不错的,真正影响数据库性能的是长耗时.就是部分查询时间比较长,一般来说减少这部分时间也是数据库优化的关键点.

针对上述的特点可以得出一个结论,假如我们将部分查询量的多的用户迁移到另外的数据库实例，那么得到的好处是?这部分用户数据存储量小,查询显然快,这是典型以空间换速度的应用场景.能通过这样的一个操作,解决大部分活跃用户访问博客的问题.

继续思考下去,如何定义冷热数据,目前我是按照自己的原有经验对数据进行采集和分析的,实际上未来这完全可以通过自动化的分析系统定义冷热数据。

因为增加了用户的冷热标识，从程序的角度来看，必然增加了一个逻辑判断过程，目前主流的做法通过轻量级的存储系统来存储这标识。也有通过proxy的做法对用户的访问进行透明化处理。这个查询对系统也存在一定的消耗。目前我们的主流程序都要查询用户表，而用户彪已经区别了冷热用户，所以不存在额外查询。

下面描述一下，我如何通过数据分析来定位所谓的冷热:

1)首先根据用户的PV来区分冷热用户,将100万以上的用户的数据导入到热库。这些用户的更新量还是比较频繁的。但是由于系统采取静态化的技术架构，所以PV高不一定代表数据库的查询多。所以通过这一维度具体得出来的结果就是：第一这些用户的数据库访问比列没有想象的高,第二是部分用户虽然PV很高，但是其实已经很久没有更新了，或者最新的PV增量很低。这是最大的数据分析误区。

2)博主访问采取的架构(Control)是直接查询后端数据库，所以统计了一周的博主访问日志，排重后抽取了前500的用户数据进行了分析。这部分用户更新量比较高，且PV一般在1万到10万之间，也许这些代表了真正意义上的草根用户。

后来根据用户被关注数指标，积分指标也抽样分析了相关数据。基本上都是PV在1万到10万之间。从这个意义上来看，假如我将这部分用户的数据导入到热库来看,从长期来看尤其用户增长量是比较迅猛的.可能将来这个热库反而成为一个瓶颈。

最后还是没有完全得出一个结论来说，如何区分冷热数据库。这是一个不断摸索的过程。

可能有些人会问，一般通过Cache来解决数据库访问的热度问题，其实到目前来看，我觉得这是不通角度的问题。当数据量增长越来越快后，数据库本身的存储模式也相当重要。同时即使使用缓存，本身的缓存设计和容量也是非常重要的。包括增加了一层额外的开销。

从长期来看，数据库本身解决的问题包括：

1)数据库的存储设计，考虑后续的延展性。

2)数据库的组织方式,解决长耗时。包括索引优化及其他相关事情。

3)数据存储，备份。

4)数据逻辑控制层。