一次數據庫優化的對話


 

那天夜里的時候,我去十三哥屋里找他,他正在敲代碼。平時我找他, 都是談技術,畢竟都是程序員,除了這一點,其它的共同愛好,我們也沒有。

 

不過這一次,不是談技術。房子要到期了,我是要問他,是繼續合租,還是各尋它途。 他說要去北方,他女朋友在北方。這點我理解,我要去東南,我女朋友在東南。

 

租房的事情談過后,他向我揚揚眉,有個好東西,說要告訴我。 我知道,他在炫耀,他想裝逼,他有准備。 我想用嘲笑,壓制他的炫耀,但我沒有,而是故做平靜的說:說說看。

 

他說他們公司,遇到一個問題,一個 mongodb 的數據庫,查詢時間太長。 我點點頭,表示讓他繼續。他說之前還好,數據量比較少,這段時間業務很好, 數據開始增多,查詢經常超時。我皺下眉,表示一下困惑。他繼續說, 索引也加了,能優化的都優化了,仍然超時。我看着他,沒有表情,等着他繼續。 他停頓了一下,然后問我,你覺得怎么辦?我說我想想。

 

我不說話,看着屋頂。他笑着看着我,看着我苦苦的思索,等待着我的答案。 我低下頭,沒有說答案,而是問向他,他們是怎么解決的。

 

他說那天下午,他們老大找到他,講了相同的事情,問了相同的問題,他也沒有回答。 他的老大笑笑,說可以"分表"啊。之前的表里面,放着所有的記錄,數據快到六百萬時, 出現了查詢超時,如果按照業務划分,可以分成十幾個表,每個業務的數據,只放到自己的表里, 每個表的數據,都會降低很多。 他們建了新表,舊表保持原樣,只在舊表增加,不再進行查詢,查詢操作,都轉移到了新表。 新表的字段,也由舊表的九個,變為現在的四個,這四個是必須的,多余的全部去除。 他們分表過后,效果確實很好,每次都不超時。

 

他看着我,表情透着滿足,那是學到新知識后的表情。

 

我繼續問他,他們的業務有多少,他說十八個。我說那就是十八個表,他說是的。 我又問他,數據最多的業務,占總數據的多少,他說大概一半。 我繼續問,如果說,我說如果,你們公司很牛逼,所有業務都增長加倍, 目前最好的業務,以后的數據量,可能和現在的總數據量一樣,那時候該怎么辦?

 

他皺皺眉,說確實也是個問題。

 

我問他,查詢時的條件,是什么數據類型,他說三十六位的字符串,類似 MD5。 我說可以對這個字段做 HASH ,散列到多個表,比如 128 個表,如果 HASH 函數選的比較好, 結果比較隨機,那么每個表的數據,也會比較隨機,表里的數據就會比較平均, 這樣就能讓表里的數據,降低兩個數量級。而且業務改變了,也不影響表的結構。

 

他說看起來,這樣倒也行。

 

他問我,這方法,是從哪里看到的,我說自己想到的。他說別吹牛逼,快點告訴我。 我說我也忘了,這是我自己想到的,還是從哪里看到的。不過現在,這知識已經和我融為一體,那就是我的了。

 

十三哥戲謔的看着我,說:你又開始裝逼了......


同步發表:http://www.fengbohello.top/blog/p/split-table

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM