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.