記一次資料庫分表的初體驗！
業務前景
由於小編所在的公司是傳統型公司，而業務對接的確實像螞蟻貨運險這樣的大業務，從2017年中旬對接到公司的業務資料量大約一天150W左右資料，而去年的雙十一最高峰值則達到2000W一天的資料量！公司所入的資料量全部存在10多張不同業務的表中，而中途資料庫已經告警過幾次，顯然這樣的架構是不符合現在的交易規模的。。。預計今年雙十一的資料量會暴增2倍，也就是4000W左右一天。而為了提前預防這樣的爆表措施，老大提出了一次分表的優化！我一聽，當時激動的心情就像這樣：
優化方案
所以呢，有了需求就是幹！優化方案如下：
在不影響原來的10+張表相對應的業務邏輯基礎上，將其揉合成一張表，其中這張表所包含的欄位是10+張表所重要
重點實現思路
本次優化採用的是水平分表，水平分表的含義：分表之後的所有表結構都是相同的。
將上述Ant表分為每個季度16張表，也就是一共64張表，採用對貨運險中的保單號值進行hash計算，經算出來的值在進行相應的位運算，最終算出每筆交易落在哪個季度的哪個表中。
表名設定：
- 一年有四季度，故採用計算機中常用的索引表達，0 - 3來表示4個季度，0代表第一季度，1代表第二季度，2代表第三季度，3代表第四季度。
- 合成後的一張表對其進行拆分成16張表，同樣採用計算機中常用的索引表達，0 - 15,來表示16張表的索引值，比如0 代表分割後的第一張表，15代表分割後的第16張表。
有了以上兩個邏輯，可以得出的表名設定：Ant_0_0，代表第一季度的第一張表,Ant_1_2代表第二季度的第三張表，Ant_2_0代表第三季度的第一張表。。。以此類推。。。
實際上，此專案業務邏輯分為了兩部分，一部分是入庫邏輯，還有一部分是查詢邏輯。入庫邏輯部分採用python語言進行編寫(指令碼語言的好處：與螞蟻對接後直接讀取檔案進行sql拼接入庫，入庫週期較短，節省流程的耗時)；查詢部分是鑲嵌在web專案中的，所以是用java語言進行實現的。有了思路，一切都是浮雲了好吧~一個字幹！
部分重點程式碼實現
下面分別給出兩部分重點的程式碼實現思路。
python部分：
- 計算出對應的16張表所屬欄位：
- 獲取當前季度：
java部分：
- 計算出對應的16張表所屬欄位：
- 獲取當前季度：
總結
基本上述就是本次分表的設計主思路，可以看到，入庫和查庫，為了保證一致性，需要設計相同的演算法才可以保證資料一致，所以python版迎合了java版的hashcode演算法，最終入庫的同一筆交易可以在java中查到。其中還有一個程式設計上的小技巧，就是在求具體0 - 15的時候，當初編碼的時候沒有用求餘的方式，而採用了位運算，感興趣的同學可以看下jdk7中HashMap的實現原始碼，在計算時，是可以用位運算替代求餘操作的！優勢就在於位運算的速度比較快。。。
以上！就是最近了解到的新知識，感謝老大帶我初體驗了一波分表的操作！後來還問了相關的設計，在分庫分表上優先考慮分表，原因是分表相對分庫來說簡單，減少多筆資料對一個表的訪問壓力就是分表的核心。若有更好的想法，歡迎小夥伴們留言區探討！