• <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>
  • sql索引從入門到精通(十億行數據測試報告)(3)

    發表于:2012-02-14來源:未知作者:娃娃點擊數: 標簽:sql
    海量的數據處理問題,這是一 項艱巨而復雜的任務。原因有以下幾個方面: 一、 數據量過大,數據中什么情況都可能存在。如果說有10條數據,那么大不

      海量的數據處理問題,這是一 項艱巨而復雜的任務。原因有以下幾個方面:

      一、 數據量過大,數據中什么情況都可能存在。如果說有10條數據,那么大不了每條逐一檢查,人為處理,如果有上百條數據,也可以考慮,如果數 據上到千萬級別,甚至過億,那不是手工能解決的了,必須通過工具或者程序進行處理,在海量的數據中,什么情況都可能存在,例如,數據中某處格式出了問題。 尤其在程序處理時,前面還能正常處理,突然到了某個地方問題出現了,程序終止了。

      二、 軟硬件要求高,系統資源占用率高。對海量的數據進行處 理,除了好的方法,最重要的就是合理的使用工具,合理分配系統資源。一般情況、如果處理的數據過TB級,小型機是要考慮的,普通的機子如果有好的方法可以考慮,不過也必須加大CPU的內存,就象面對著千軍萬馬,光有勇氣沒有一兵 一卒是很難取勝的。

      三、 要求很高的處理方法和技巧。這也是本文的寫作目的所在,好的處理方法是一位工程師長期工作經驗 的積累,也是個人的經驗的總結。沒有通用的處理方法,但有通用的原理和規則。

      那么處理海量數據有哪些經驗和技巧?我把我所知道的羅列一下,一共大家參考:

      選擇優秀的數據庫 工具

      現 在的數據庫工具廠家比較多,對海量數據的處理對所使用的數據庫工具要求比較高,一般使用Oracle或者DB2,微軟的SQL Server2005性能也不錯。另外在BI領域:數據庫,數據倉庫,多維數據庫,數據挖掘等相關工具也要進行選擇,象好的ELT工具和好的OLAP工具都十分必要,例如Informatic,Eassbase等。筆者在實際數據分析項目中,對每天6000萬條的日志數據進行處理,使用SQL Server 2000需要花費6小時,而使用SQL Server 2005則只需要花費3小時。

      編寫優良的程序代碼

      處理數據離不開優秀的程序代碼,尤其在進行復雜數據處理時,必須使用程序。好的程序代 碼對數據的處理至關重要,這不僅僅是數據處理準確度的問題,更是數據處理效率的問題。良好的程序代碼應該包含好的算法,處理流程、效率和異常處理機制等。

      對海量數據進行分去操作

      對海量數據進行分區操作十分必要,例如針對按年份存取的 數據,我們可以按年進行分區,不同的數據有不同的分區方式,不過處理機制大體相同。例如SQL Server的數據庫分區時將不同的數據存于不同的文件組下,而不同的文件組存于不同的磁盤分區下,這樣將數據分散開,減少磁盤I/O,減少系統負荷,而且還可以將日志、索引等放于 不同的分區下。

      建立廣泛的索引

      對海量的數據處理,對大表建立索引是必行的。建立索引 要考慮到具體情況,例如針對大表的分組、排序等字段,都要建立相應索引,還可以建立復合索引,對經常插入的表則建立索引要小心,筆者在處理數據時曾經在一 個ETL流程中,當插入表時,首先刪除索 引,然后插入完畢,建立索引,并實施聚合操作,聚合完成后,再次插入前還是刪除索引,所以索引要用到好的時機,索引的填充因子和聚集,非聚集索引都要考 慮。

      建立緩存機制

      當數據量增加時,一般 的處理工具都要考慮到緩存問題,緩存大小設置的好差也關系到數據處理的成敗,例如,筆者在處理2億條數據聚合操作時,緩存設置為100000條/Buffer,這對于這個級別的數據量是可行的。

      加大虛擬內存

      如果系統資源有限,內 存提示不足,則可以靠增加虛擬內存來解決。筆者在實際項目中曾經遇到針對18億條的數據進行處理,內存為1GB1個P4 2.4G的CPU, 對這么大的數據量進行聚合操作是有問題的,提示內存不足,筆者采用了加大虛擬內存的方式來解決,在6塊磁盤分區上分別建立了6個4096M的磁盤分區,用于虛擬內存,這樣虛擬內存則增加為4096*6+1024=25600 M,解決了數據處理中的內存不足問題。

      分批處理

      海量數據處理難因數量 大,那么解決海量數據處理難的問題其中一個技巧是減少數據量??梢詫A繑祿峙幚?,然后處理后的數據再進行合并操作,這樣逐個擊破,有利于小數據量的 處理,不至于面對大數量帶來的問題,不過這種方法也要因時因勢進行,如果不允許需要拆分數據,還需要另想辦法。不過一般的數據按天、按月、按年等存儲的, 都可以采用先分后合的方法,對數據進行分開處理。

      使用臨時表和中間表

      數據量增加時,處理中要考慮提前匯總。這樣做的目的是化整為零,大表變小表,分塊處理完成后, 再利用一定的規則進行合并,處理過程的臨時表的使用和中間結果的保存都非常重要,如果對于超海量的數據,大表處理不了,只能拆分為多個小表。如果處理過程 中需要多步匯總操作,可按匯總步驟一步步來,不要一條語句完成一口氣吃掉一個胖子。

      優化查詢SQL語句

      對海量數據進行查詢處 理過程中,查詢的SQL語句的性能對查詢效 率的影響是非常大的,編寫高效優良的SQL腳本和存儲過程是數據庫工作人員的職責,也是檢驗數據庫工作人員水平的一個標準,在對SQL語句的編寫過程中例如減少關聯,少用或不用游標, 設計好高效的數據庫表結構等都十分必要。筆者在工作中試著對1億行的數據使用游標,進行3小時沒有出結果,這時一定要改用程序處理了

      石油文本格式進行處理

      對一般的數據處理可以使用數據庫,如果對復雜的數據處 理,必須借助程序,那么在程序操作數據庫和程序操作文本之間選擇,是一定要選擇程序操作文本的,原因為:程序操作文本速度快;對文本進行處理不容易出錯; 文本的存儲不受限制等。例如一般的海量的網絡日志都是文本格式或者csv格式(文本格式),對它進行處理牽扯到數據清洗,是要利用程序進行處理的,而不建議導入數據庫在做清洗。

      定制強大的清洗規 則和出錯處理機制

      海量數據中存在著不一致性,極有可能出現某處的瑕疵。 例如同樣的數據中的時間字段,有的可能為非標準的時間,出現的原因肯能是應用程序的錯誤,系統的錯誤等,這是在進行數據處理時,必須制定強大的數據清洗規 則和出錯處理機構。

      建立視圖或者物化視圖

      視圖中的數據來源于基表,對海量數據的處理,可以將數據按一定的規劃分散到各個基表中,查詢或 處理過程中可以基于視圖進行,這樣分散了磁盤I/O,正如10根繩子吊著一根柱子和一根繩子吊著一根柱子的區別。

    原文轉自:http://www.kjueaiud.com

    老湿亚洲永久精品ww47香蕉图片_日韩欧美中文字幕北美法律_国产AV永久无码天堂影院_久久婷婷综合色丁香五月

  • <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>