隨著業務的發展和持續執行，系統會產生大量的資料，資料的增長伴隨而來的是對資料庫的考驗，在達到一定的資料量之後資料庫的訪問效能就會持續下降，為了系統的穩定執行，得要麼提高資料庫訪問效能，要麼把資料限定在一定的量上。前者會導致it系統的不斷投入，投入產出比不高，且早晚會達到系統的瓶頸，後者需要拋棄舊的資料，從歷史資料的完整性上來說也是我們不願意看到的。
如果暫時沒有上分析性資料倉儲的需求，那麼做冷熱資料的分離就是乙個比較好的解決辦法。將熱資料剝離開來，保證熱資料的讀寫效能，冷資料相對來說訪問量少，可以降低服務等級，這樣就減少在it方面因為資料量增長帶來的投入。
我們一般有兩種方式來區分冷熱資料：
本文主要討論前一種情況的冷熱資料分離，對於後一種情況，要結合業務來處理，很難有普適的方案。
對於冷資料，根據不同的應用場景建議使用不同的方式來處理。通常資料只是備份，但在偶然的情況下需要查詢指定的資料，這種查詢有可能數天到數月才發生一次。
對於這種情況，推薦直接使用oss來儲存冷資料，然後在需要查詢的時候啟動執行乙個rds例項並匯入資料，查詢完成後銷毀rds例項，此方案優點是成本非常低，但在使用的時候會比較繁瑣。
下面以rds mysql版為例來說明如何處理。啟動乙個ecs，在其上部署定時任務，任務步驟包括：
冷資料經常被查詢，比如每天不同時間段都有人在查詢資料，這個時候如果每次查詢都重複啟動資料庫或者匯入資料的操作就太過繁瑣，此時建議以下兩個方案備選（下面也都以rds mysql版為主資料庫來做示例）。建立冷/熱資料庫，熱庫僅保留短時間的資料，超出的資料定時批量移到冷庫中。應用系統內部做好區分，熱資料可以直接通過應用系統訪問，如果需要訪問冷資料則需要走冷庫查詢。
熱庫面對大量的高頻查詢寫入請求，因此配置高規格的rds，冷庫的資料查詢頻率一般非常低，可以配置低規格的rds並提供大儲存容量。例如對某種應用熱rds使用8核16g記憶體200g磁碟空間的話，那麼根據冷資料訪問的頻度和效能要求，冷rds可以用1核2g、2核4g記憶體等低規格的例項，並提供最大到2t的儲存空間。
冷熱rds方式部署簡單，但資料庫儲存在rds的內部儲存上，成本還是相對比較高。另外單個rds還是有磁碟空間上限的限制，最高只能到2t。如果想要降低成本或者需要更高的儲存空間，除了採用分布式資料庫外（分布式資料庫成本也會比較高），可以考慮用以下另一種方式。冷資料從rds mysql版轉存到rds postgresql版上，並用oss_ext擴充套件外掛程式把資料以外部表的方式存入oss，使用oss的低廉成本和無限空間的特性來儲存大量的冷資料，並且可以通過postgresql直接查詢。
準備工作
轉儲冷資料
執行乙個ecs，在上面部署定時任務，任務包括以下內容：
查詢冷資料
本文提供了三種冷熱資料分離的方案，可以根據應用系統的特徵和需求選取其中一種，也可以對系統中的不同資料使用不同的方案，甚至對於不同時間段的同樣資料使用多種方案，比如短期的冷資料可能還會有一定的訪問，可以使用冷熱rds方式，長期基本不怎麼訪問的冷資料直接匯出放到oss上，可以進一步提高靈活性和降低使用成本。
《完》
如何做資料產品？
1 產品給誰用？資料給誰看？使用者分幾類？不同類使用者訴求有無差別？2 ta為什麼要看資料？看完之後做什麼？要說清楚給使用者設計的資料產品在解決什麼問題，到底要給使用者看哪些資料？在實際的操作過程中，可能面臨理解不一的情況。這裡需要統一資料口徑，要保證使用者對資料概念的理解和你的理解是一樣的，這是資...
如何做資料的分類？
常見的資料分類方式有2種，一種是按照資料所屬的類別進行層次分類，一種是採用關鍵字或者標籤的方式進行分類。到底哪種方式好呢？我想本身並不應該有明顯的界限，如果資料本身就不叫有層次劃分如 生物學中的種 屬 科 目等層次的分類，那麼採用層次分模擬較好 一般而言採用關鍵字的方式比較有彈性，使資料可以隸屬為多...
如何做資料的分類？
常見的資料分類方式有2種，一種是按照資料所屬的類別進行層次分類，一種是採用關鍵字或者標籤的方式進行分類。到底哪種方式好呢？我想本身並不應該有明顯的界限，如果資料本身就不叫有層次劃分如 生物學中的種 屬 科 目等層次的分類，那麼採用層次分模擬較好 一般而言採用關鍵字的方式比較有彈性，使資料可以隸屬為多...