這裡的時序資料泛指一切隨時間推移而不斷增長的資料，比如聯絡歷史、銀行交易記錄等。
對於資料庫來講，時序資料並沒有什麼特殊性，可以和普通資料一樣放在資料表中。不過，因為不斷增長，積累時間較長後，這種資料的量常常都會很大。乙個物理表的資料量太大時，就會影響查詢和計算的效能。
現代資料庫一般都提供有表分割槽（partition）的機制，就是把乙個大表縱向（按行）分成若干區段，分割槽規則由資料庫管理員來設定，對應用程式設計師來講是透明的，可以和不分割槽的表一樣訪問，資料庫會自動根據查詢條件決定讀取哪些分割槽的資料，這樣的介面體驗非常好。
不過，在實戰中，分割槽表的效果在某些場景下並不好，而且使用時也有些約束條件，並不總好用且能用的。結果，在實際業務中，我們常常會看到對於這種大資料採用手工物理分表的方案。
所謂物理分表，就是人為將乙個大表分成若干較小的物理資料表。因為時序資料的結構中一定會有乙個欄位來表示事件發生的時刻，而事件發生的數量一般來講也會按時間段相對平均分布（大多數情況會緩慢增長，但討論時可以忽略），所以最常用的方案就是按時間段來做分表，比如乙個月資料對應乙個分表，這種方式在金融、電信行業比較普遍。
物理分表並不是資料庫自動支援的方案，不能對應用程式做到透明，需要應用程式自己處理。在查詢資料時一般都會有時間段引數，應用程式可以根據這個引數計算出該查詢涉及哪些分表，然後將這些分表union起來拼到sql語句的from後面。查詢不涉及的時間段對應的分表不會被拼進來，這樣就可以有效減少資料遍歷的範圍，從而提高效能。
這個方案在單個資料庫時沒啥毛病，但是不是能推廣到多個資料庫的情況呢？
資料量再大下去，乙個資料庫也無法承受了，而某些場景下又不允許我們上一套分布式資料庫系統，畢竟分布式資料庫是個沉重的工程，不僅造價高，而且維護管理都要複雜不少。這時候，我們可以擺多個資料庫分別儲存資料，類似物理分表的方案，也按時間段把資料分拆到各個資料庫中，比如一年資料放入乙個資料庫中（一般來講多個庫會部署到多台機器上），這樣就能分攤查詢壓力了。
分庫分表mysql到hdfs
前面文章寫入如何將hdfs的資料分表插入mysql。這裡主要講解如何進行分庫分表抽取。需求 公司線上庫的一些資料量比較大的表是存在多庫多表的。數倉進行資料抽取的時候，需要將這些表統一抽取過來，然後進行合併到一張hive表。以前的方案 1 通過 mysqluldr2 這個工具將多表抽取到本地，user...
資料庫分庫分表
1 基本思想之什麼是分庫分表？從字面上簡單理解，就是把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。2 基本思想之為什麼要分庫分表？資料庫中的資料量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的資料量也會越來越大，相...
資料庫分庫 分表
分庫的優點是 實現簡單，庫與庫之間界限分明，便於維護，缺點是不利於頻繁跨庫操作，單錶資料量大的問題解決不了。分表的優點是 能解決分庫的不足點，但是缺點卻恰恰是分庫的優點，分表實現起來比較複雜，特別是分表規則的劃分，程式的編寫，以及後期的 資料庫拆分移植維護。實際應用中，一般網際網路企業的路線都是先分...