資料量與資料庫選型

先來一個資料量運算關係。

1 kilobyte kB = 1000 (103) byte
1 megabyte MB = 1 000 000 (106) byte
1 gigabyte GB = 1 000 000 000 (109) byte
1 terabyte TB = 1 000 000 000 000 (1012) byte
1 petabyte PB = 1 000 000 000 000 000 (1015) byte
1 exabyte EB = 1 000 000 000 000 000 000 (1018) byte
1 zettabyte ZB = 1 000 000 000 000 000 000 000 (1021) byte
1 yottabyte YB = 1 000 000 000 000 000 000 000 000 (1024) byte
1 nonabyte NB = 1 000 000 000 000 000 000 000 000 000 (1027) byte
1 doggabyte DB = 1 000 000 000 000 000 000 000 000 000 000 (1030) byte

    迄今為止似乎達到PB級別的就是大的系統了。（我們說的是結構化資料，因為非結構化資料，比如影片，一個電影好幾個GB這個不是一個數量級別的）以前有人問過資料量多大時候選什麼資料庫？其實就是為什麼時候選擇關係型資料庫什麼時候選擇大資料（hadoop）等。就我個人而言我覺得100TB到500T這個區間是單機、分散式共同的選擇。1PB以上單機資料庫不太適應。Oracle的exadata能不能搞好我沒試過，我本人僅僅有過單表100TB的處理經驗。沒做過的我不好說，但是單機100TB，對於Oracle MySQL PostgreSQL來說問題不大。但是我聽有人說過她們有300T甚至500T的Oracle。

     所以500TB以上的單機資料庫比較少。在這個以上可能就應該是分散式關聯式資料庫的天下了。你要問我那hadoop呢？那意思是現在的硬體條件下，基本不用他比用他效果更好。現在TiDB和OB兩個分散式的國內巨頭，如果有500TB左右資料量的可以考慮他們。TiDB排名更好一些。

    今天寫這個的想法是看到一個PG群裡說：  分散式資料庫第一定理：如果單機主從能解決你的問題，用單機主從。這個觀點我是支援的。前面已經說了，我覺得分散式挺好的，屬於高階路線解決方案。不過殺雞不能用牛刀。如果一個系統資料量太小，我見過最小資料量的系統，就是表比資料多。一個庫200個表，大部分是空的，有的表就幾條資料，加起來不到200條。聽起來是笑話是吧？這種excel不能搞嗎？如果多人就線上金山文件吧。我在之前的文章中也說過，好好寫SQL比起分庫分表的代價要小很多。

    如果真的經歷過一個單機資料庫被拆成N個資料庫該做微服務以後，有這兩個的對比的經歷的人可能能發現一個問題。就是機器多了，團隊人多了，互動多了，元件多了，技術棧多了，一致性差了，穩定性差了，效能低了，  成本高了。如果只有單機經歷或者只有分庫經歷沒有過對比的，是感受不到這裡的差異的。

   很多懂行的人都知道單機的架構其實除了擴充套件以外都不是問題。而一般的資料量單機是足以應付的。當然我這裡再次說，達到單機無法處理的還是要發揮出這個賽道的其他產品比如TiDB等等。

   有一次看朋友，一位朋友說他當年大概是16C  64G，SA他的硬碟的配置服務了全省的一個系統，其實我也差不多是這樣的。而現在你看我剛去京東上查了一下行情。要是20T資料不就是10塊硬碟搞定的事情嗎？10個插槽就行了。