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.
Tags: 數據 拆分 緩存 但是 有沒有 進行
文章來源：