国精产品乱码一区一区三区四区,国产中文伊人

主頁 > 知識庫 > 數(shù)據(jù)庫 SQL千萬級數(shù)據(jù)規(guī)模處理概要

數(shù)據(jù)庫 SQL千萬級數(shù)據(jù)規(guī)模處理概要

1. 數(shù)據(jù)太多。放在一個表肯定不行。

比如月周期表。一個月1000萬，一年就1.2億，如此累計下去肯定不行的。所以都是基于一個周期數(shù)據(jù)一個表。甚至一個周期數(shù)據(jù)就要分幾個分表。主要是考慮實際的數(shù)據(jù)量而定。當(dāng)你創(chuàng)建一個新表時，可能這個表需要有索引，但是都要先取消索引，或者先建立表，導(dǎo)入數(shù)據(jù)后，再建立索引。

必要時處理完，統(tǒng)計完后，就備份到磁帶或者其他介質(zhì)。然后清掉。

從問題域來看，一個周期內(nèi)的數(shù)據(jù)關(guān)聯(lián)性最大。比如統(tǒng)計一個客戶某個帳期的話單總額，同比上月增幅，還有就是零話費(fèi)客戶等。如此種種，參照的數(shù)據(jù)不外乎本周期，或者兩個周期，甚至更多就是一個季度，或者半年的樣子（類似三個月連續(xù)零話費(fèi)，或者三個月連續(xù)欠費(fèi)未交之類的，保存量之類的報表可能會要一年的數(shù)據(jù)）。而且這樣的情況在數(shù)據(jù)挖掘或者高級管理報表中比較常見，一般營業(yè)部門使用的界面中，是不可能含有這樣的統(tǒng)計的。

所以數(shù)據(jù)按表分開，甚至于可以按數(shù)據(jù)庫分開，更便于管理。

大家要打消一種固有的思路，這些數(shù)據(jù)，跟環(huán)衛(wèi)工人處理垃圾一樣，是幾乎有點(diǎn)帶人工處置的多步驟方式，也就是不會作為常規(guī)數(shù)據(jù)（如客戶基本資料等）長期存在和頻繁使用的。所以我們可以改變思路，就是想盡辦法，在需要的時候，做最佳處理，而在不需要時，清理掉它。也就是說，比如分表，你可以分100個表，1000個表都可以。只要方便統(tǒng)計和得到所需數(shù)據(jù)即可。

view只是說你能在寫select語句時簡單一點(diǎn)，對速度沒有任何提高。

主要是，你的分表的方式能建立減少訪問所有數(shù)據(jù)，就能提高速度。比如你做某個統(tǒng)計，那些數(shù)據(jù)恰好在某個分表內(nèi)。舉例說，你有10個分部，而你統(tǒng)計id=1這個分部時，你恰好把數(shù)據(jù)放在第一個分表里，你就可以在存儲器內(nèi)通過判斷，只訪問第一個分表，從而提高統(tǒng)計速度。如果你的統(tǒng)計需要統(tǒng)計全部分表內(nèi)的數(shù)據(jù)，那處理速度還是一樣慢。

2. 假設(shè)每個表的數(shù)據(jù)在數(shù)十萬條，那統(tǒng)計起來是沒有任何瓶頸的。常規(guī)的數(shù)據(jù)庫都應(yīng)該沒任何問題。

3. 預(yù)處理的必要性。

有人問：我統(tǒng)計一千萬條數(shù)據(jù)匯總，要多久多久，能否提高。。。試想你把中國人所有的存款加總，需要多長時間吧？看看這個問題的規(guī)模，其實再復(fù)雜的數(shù)據(jù)庫dbms，我們說他都逃不過：找出符合條件的數(shù)據(jù)，一條一條的加總這個計算過程。暫且不提where條件了。預(yù)處理的必要性在于，如此規(guī)模的數(shù)據(jù)處理，本身就是一個非常耗時的過程，我們有必要提前，處理其結(jié)果到一個表內(nèi)，或者多個表里面。用戶查詢時，再顯示出來。比如說1000萬數(shù)據(jù)分10個分部，要看每個分部的應(yīng)收增長，那我們可以預(yù)先統(tǒng)計數(shù)據(jù)到分部費(fèi)用表中，則用戶端報表顯示時，就非?？?。如果任何數(shù)據(jù)匯總都要從原始數(shù)據(jù)去統(tǒng)計，那是不現(xiàn)實的。所以我們可以設(shè)置原始數(shù)據(jù)表，中間結(jié)果表，結(jié)果表，匯總表，月結(jié)表，期間表之類的東西。逐步統(tǒng)計歸屬。

另外要提的是，這樣的動作肯定非常耗時，而且！這樣的數(shù)據(jù)如果由服務(wù)器的存儲過程定期定時執(zhí)行的話，處理的規(guī)模就只有一次，任何客戶端，都只從結(jié)果表里產(chǎn)生報表。如果不用此方法，任何客戶端報表都從原始數(shù)據(jù)產(chǎn)生，理論上是可以，但是這樣的千萬條數(shù)據(jù)匯總的處理會做N次。而且時間上也是不容許的。

還有，這樣的統(tǒng)計過程最好是分開db進(jìn)行存放，而公用的數(shù)據(jù)比如客戶基本資料，最好拷貝一份到這個新db中來處理。這樣可以不干擾到正常的使用。

可以在晚上，或者另開db或者在另外的server上跑這個過程。處理完后，寫一個標(biāo)志告訴主db，則客戶端可以統(tǒng)計這些報表了。

4. 對單行數(shù)據(jù)做計算字段。舉個例子，比如一條記錄的產(chǎn)生時間是2009-01-01 12:00:00.001,如果你的統(tǒng)計剛好需要對某個時段進(jìn)行統(tǒng)計，那最好增加字段，比如hour字段，下一個批處理命令下去，取得小時數(shù)，然后再統(tǒng)計。

5. select語句中忌諱對column做函數(shù)。因為函數(shù)將導(dǎo)致查詢條件不走索引，而改走遍歷所有數(shù)據(jù)。這樣你就是查一條數(shù)據(jù)，也會遍歷所有數(shù)據(jù)，那豈不是可憐。

6. 條件盡量都是數(shù)字，也就是都用id，比如分部，鎮(zhèn)區(qū)，業(yè)務(wù)種類，接入類型，客戶地址，等等，都需要用到fk方式的編碼，主表里只用數(shù)字id，請記住是數(shù)字型id。整數(shù)型數(shù)字是計算最快的數(shù)據(jù)類型。如果金額極大，可以用decimal(小數(shù)=0）。varchar類型是效率很低的，不過好像有sql的md5算法，我想可以嘗試這個方法（我還沒試過）。

7. 索引，這個是海量數(shù)據(jù)查詢首要解決的問題。

沒有索引，就是遍歷。索引沒有覆蓋到，也會走遍歷。

8. 復(fù)雜的統(tǒng)計，用存儲器做分步處理，然后得到結(jié)果，同比一條select語句實現(xiàn)要輕松和明白得多。

而且對表的占用時間要短得多。當(dāng)然，很復(fù)雜的統(tǒng)計可能要用到條件判斷，循環(huán)等，一條select語句是無法處理的。多層的where中的子句也是效率低，容易占用表的寫法。

原則上，這里我所討論的問題都不是那種基于網(wǎng)站內(nèi)容管理的小case，主要對企業(yè)運(yùn)用而言。比如舉例說查一個“存量客戶增幅表”，問題都不是簡單到直接對比兩個月的話費(fèi)總額這么簡單，還得找出之前他的話費(fèi)如何，比如超過多少錢的才列入統(tǒng)計對象。所以，我的理解：復(fù)雜的問題，必須存儲過程。真正做過幾個項目才會明白，寫sql語句會比編程代碼還要多。真正的程序，其實是sql。

最后說一句，如果經(jīng)驗足夠豐富，寫出的統(tǒng)計過程，其執(zhí)行時間在數(shù)分鐘甚至幾個小時都是正常的。所以初學(xué)者應(yīng)該明白，數(shù)據(jù)量是與處理時間成正比的。如果平時處理幾條數(shù)據(jù)感覺很快，數(shù)據(jù)量猛然增加幾個數(shù)量級，不要認(rèn)為時間上還能優(yōu)化到幾秒鐘。

ERP里的MRP展開計算，通常能到幾個小時的。這都是正常的。(主要是物料多，bom多，計算步驟太多造成)

9. 補(bǔ)充一點(diǎn)。如果數(shù)據(jù)量超過我們標(biāo)題的千萬級，甚至幾十億數(shù)量級。那也不存在問題，還是分而治之的思路，就是把數(shù)據(jù)在多臺服務(wù)器上并行運(yùn)行。就好像為災(zāi)區(qū)捐款一樣，靠一個人的力量是不行的。人多力量大。類似數(shù)據(jù)分揀之類的，只需要原始數(shù)據(jù)和基本資料，還有一些計費(fèi)策略之類的。完全可以分布在多臺server上同時處理，也是必要的。主要根據(jù)你的數(shù)據(jù)量和單臺處理的速度以及你要求的總的處理時間而決定的。有人說select語句難道也需要分布？只能說，如果確實有必要，也能做到。比如你要返回所有話單異常的數(shù)據(jù)，那也可以從每臺執(zhí)行檢索，然后匯合到一起，我想是可以的。

總而言之：

一。合理設(shè)計表結(jié)構(gòu)，使得統(tǒng)計匯總最高效（包括fk設(shè)計和用數(shù)字id，不用varchar，索引設(shè)計，計算字段）；

二。合理分表，使得單表數(shù)據(jù)規(guī)模適當(dāng)；

三。用存儲器分多個步驟處理。

四。數(shù)據(jù)預(yù)先處理。

五。分布在多臺server上同時處理。

也就是分而治之與預(yù)處理。

標(biāo)簽：瀘州商洛廣西濟(jì)源撫順文山吉林玉溪

巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《數(shù)據(jù)庫 SQL千萬級數(shù)據(jù)規(guī)模處理概要》，本文關(guān)鍵詞數(shù)據(jù)庫,SQL,千萬,級,數(shù)據(jù),；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題，煩請?zhí)峁┫嚓P(guān)信息告之我們，我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。