? ? ? ?隨著移動互聯網的蓬勃發展，大數據時代已經來臨。面對高流量高并發的要求挑戰。數據庫的性能往往成為了后段開發的重中之重。以下就此問題結合筆者的一些實踐談談庫表設計的一些思路。
1，使用中間件，這種中間件一般都是mysql的外層代理，比如my cat這種，其核心思路是代理真實的mysql instance 支持一些庫表路由策略，比如按ID取余，時間線切割等，中間件的好處是大大降低業務開發人員對數據庫的細節敏感度，可以專注于業務開發，但是中間件的維護的重任往往就交由運維去管理，或者一個單獨的中間件團隊。中小型公司往往難以承受。此外中間件也有一定的性能損失。
2，服務端分庫分表，這里的服務端是指需要連接數據庫的各個服務，各個服務按照自己的策略將多個數據源配置在自己的服務里面，依據自身的義務需求路由到不同的表和庫，這樣的設計去除了中間件的性能損耗，可以達到數據庫百分百性能的利用率，但是卻耦合了庫表路由策略，這些策略被寫死在各自的服務里，往往不能輕易改動。
?3，服務端表拆分，就分庫分表的策略而言目前比較流行的做法是按ID取余法和時間線分割法。ID取余說白了可以根據訂單ID％X ?散列到不同的表中這樣的分表策略對于分頁查詢支持度比較差，同時查詢的時候還需要攜帶分表策略所需要的ID。以mysql為例，如果單表支撐在一個億的量級，分十張表足以支撐10億數據量，這對絕大多數公司來說綽綽有余。此外我們也可以按照時間線分割的方法去拆表，以筆者所在的公司為例，一天的的數據流水量在千萬級別，這種量級如果采用取余法分表很快就將支撐不住，如果按照時間線切割一天一張表，那么就可以完美的解決未來數據量擴容的問題，不會存在數據量的上限，而且天然的存在冷熱分離的特性。除了當天的表其他表都是冷表。如果單天數據量再升一級又改如何處理呢？這里我們可以再次結合取余法，時間線分割的法存在單表性能壓力，比如高峰時段單表寫入壓力過大，查詢壓力可以通過主從解決，寫入卻不能。再回到取余法，取余法的特點是將同一時刻的單表寫入操作分擔到多個表上，這里就出現了壓力分擔的效果。那我們是否可以將取余法與時間線法結合使用呢，例如單天的時間線表數據量可能上億，高峰期并發寫入壓力很大，此時可以將單天的表按ID取余分拆成N個表，這樣寫入壓力頓時降低到1/n,同時單表數據量也大大降低，以一天1億的流水數據量來講，也不會存在絲毫壓力。
4，服務端庫拆分，分庫的策略更多的體現在不同的業務拆分上面，服務化的今天，一個企業內部幾十個服務已經不足為奇，一臺數據庫集中存放這些庫顯然有點力不從心，按照不同的業務將不同的庫拆分到不同的instance上是一種比較常見的做法。分庫也可以結合分表做取余拆表設計，比如將某個訂單表拆為8個庫，每個庫8張表。
5，痛點？分庫分表的拆分是為了應對大數據量高并發的情況，但是其本省存在著一定的局限性，回顧一下以上策略，是否發現拆的越細，查詢的時候越復雜呢？顯然一門技術的推出可能會解決當前的某個痛點，但是隨之而來的必然帶來一些痛苦，就像拆了東墻補了西墻一樣。很多時候需要結合自身的業務特點來抉擇。業務重點關注的指標我們可以堅持去遵守，其他方面有所弱化未嘗不可！
