web产品最重要的核心单元无疑是数据,而主流的存储容器则是Mysql,对于快速增长的数据,其性能可能会呈指数级的递减,为解决该问题,主流的做法基本是水平和垂直拆分,根据数据的特性将数据进行库和表级的拆分,实际上的理论还是数据分割,但是终有一天你会发现单表的数据还是越来越大,也许你可以说我再拆分,可拆分的代价可能就是部署多次方的辅库.存储容量可能会让你很吃惊,而且这样的做法有没有人真正去想有用吗?很多人说,我们用缓存去解决,可是缓存就是无形中增加了一层,缓存的设计很重要,更新,颗粒度对一个系统的稳定性是非常重要的,另外缓存的大小你有没有考虑过.所以我们有没有办法从DB层进行一些分析,Mysql作为一个优秀的软件,再没有合理的分析的基础上不应该去质疑它,也不应该想着如何去替代它.

     web产于基于数据,那么处理方式也应该基于数据,你有没有分析过你的产品形态是什么,数据性质是什么?最近针对我们的文章数据进行了一些统计(相信具有一定代表性),PV百万的用户不到很少(相对于总注册用户来说).但是总pv占了64%.文章大概11G的存储空间.解释下:我们一半的webserver在为很少一部分人服务,但是他们占的流量却能吓死人,但是他们的文章才11G,我相信大部分人明白了,假如我对于这些用户的数据进行剥离,重点为他们服务,那我相信性能和容量成本将进一步降低.

     这就是所谓的冷热数据分离,很明显将热数据剥离出去,核心保证其的性能,而相对来说冷数据访问量少,服务等级减低,也可以想象能节省多少的容量.假如我将这些数据放入到内存,那么性能会提升多少呢.

     冷热数据的拆分没有很多难度和技巧,但是仔细分析下还是有很多事情需要去做,毕竟做事情的目的是保证结果是合理和有效的.性能和维护性是要平衡的.

    (1)有没有想过这些pv高的人是什么样的人,他的文章更新频率是什么样的.

    (2)对于热数据需要分库分表吗,怎么分才合理,是否会影响query cache,对于活跃数据来说,需要多少个辅库来支撑千万级的访问,对于这些访问和数据特性来说,支持大并发的瓶颈在哪儿(磁盘I/O,CPU?)

    (3)冷热数据迁移策略和如何区分冷热数据,这样的拆分可能需要手动的,以及未来是否需要自动拆分

    (4)一涉及到冷热数据的分离,就可能去要区分用户,那么数据的serverid如何设计,是否会成为瓶颈

    (5)是否能够明确DB是制约性能的核心问题?实施后是否有提升?提升了多少.

    (6)我们是按照pv来区分冷热数据的,再基于具有一级页面缓存的基础上,区分冷热数据的分析方法是否合理.

    这些用户的访问对于实际后端的访问频率是多少?

    (7)对于活跃数据我们是否需要建立脱离于DB的二级缓存,或者对于活跃数据是否通过SSD这样的设计进行硬件提升

    (8)很实际的一个问题,冷数据的数据量还是非常庞大的,只是他们的访问量少了一点,那么如何优化这些用户的访问呢,二级缓存?是否涉及到归档数据的设计,它解决的问题是什么.

    (9)如何有效提升DB的query cache.

建议继续学习：

1. 浅析http协议、cookies和session机制、浏览器缓存    (阅读：15931)
2. 分布式缓存系统 Memcached 入门    (阅读：14788)
3. 强制刷新本地 DNS 缓存记录    (阅读：9309)
4. Buffer和cache的区别是什么？    (阅读：6849)
5. php缓存与加速分析与汇总    (阅读：6416)
6. Web应用的缓存设计模式    (阅读：6563)
7. 浏览器缓存机制    (阅读：5836)
8. 缓存设计的一些思考    (阅读：5784)
9. 使用memc-nginx和srcache-nginx构建高效透明的缓存机制    (阅读：5760)
10. 系统架构的一些思考    (阅读：5705)