關於大資料的處理的一些經驗

1.資料庫的技術上，目前我們公司在研究hadoop分層資料庫，具體瞭解不多；外面流行的NoSql非關係型資料庫，像亞馬遜、Google還有一些日本企業都有自己的NoSql資料庫；

2.傳統關係型資料庫的最佳化，資料庫層的最佳化和上層使用的最佳化。

資料庫層：需要DBA進行最佳化，減少片段，進行分區等；

使用層的最佳化，即最佳化SQL

從外界因素來看影響SQL有：CPU、RAM、Network、Disk

CPU：SQL的大量order
by，大量group by，case when等都會很費CPU，需要CPU進行計算。是否可以使用匯總來減少此問題

RAM：尋找的資料量過大，導致記憶體資源佔用過多。

如無where的SQL，select
*的SQL，全表掃描等；

頻繁的update、insert都會影響記憶體，每次對SQL的解析都需要一定的時間和空間。採用綁定變數。

Network：過多的DB串連，頻繁的DB開關，跨庫的關聯，大量資料的匯出，複雜的SQL等。

Disk：

大資料量的表，建立索引，保證索引的有效性；

減少大表的insert和delete，會造成磁碟片段，導致磁碟指標的不連續性；

大表的insert和delete會造成索引的失效，必要時先去掉索引再操作增刪改；

索引其實是一張表，要保證其精簡

索引的建立，最好用在易排序欄位，如number，date等，勿varchar；

varchar欄位盡量保持長度的一致性，寧可多給出空間；

減少磁碟的讀取次數；

對大表禁止順序性的全表掃描，使用索引；

減少disdinct，用unionall代替union；

Not like，<>，全模糊like，is
null，is not null，not in都會使索引失效；

索引上不要使用任何函數，盡量在等號的另一頭使用函數；

SQL的書寫一致，減少解析時間；

選擇最佳的執行計畫，複雜的SQL，不如多個簡單的SQL；

減少嵌套子SQL，使用關聯查詢；

避免笛卡爾積串連；

避免使用*，資料庫需要對*進行一次匹配，會消耗資源，而且並不一定所有的欄位都要進行查詢或者寫入，寫入時表結構變化還會導致出錯，所以避免*；

全表刪除，不要使用delete，使用truncate；

全表分頁的效率較低，建議使用分步是分頁；

3.在資料讀取最佳化到一定程度後，代碼上也可以進行很大的最佳化。

避免過多的開裝箱，使用實值型別；

對參考型別的集合，多使用泛型；

避免迴圈嵌套，和無休止的遞迴；

避免迴圈中建立大對象；

對大對象的釋放；

4.邏輯上的最佳化

在需要查詢大量資料的時候，可以使用分頁；

分頁影響到一些表徵圖的產生時，可以藉助匯總，先展示匯總資訊和表徵圖，然後在進行詳情的切入；

時間空間的相互替換。

5.對常用資訊的本地化儲存，如QQ第一次載入很慢，但後面登陸會很快。