㈠ 各類排序演算法，實現對海量數據排序額，怎麼做
由於數據范圍在1000萬，因此我們需要一個O(n)時間效率的演算法，然而所有基於比較的演算法最快只能達到O(nlgn)的時間效率，因此，所有的基於比較的演算法都無法達到要求。而數的范圍僅僅是2000000之內的整數，因此能開數組記錄。
這里有一個不基於比較的排序，叫計數排序，具體代碼實現以及備註：
void CountingSort(int a[], int b[], int n)
{
int c[100001], i, max = -MaxInt; //c[i]記錄i出現的次數
memset(c, 0, sizeof(c));
for (i = 1; i <= n; i++)
{
c[a[i]]++;
if (a[i] > max)
max = a[i];
}
for (i = 1; i <= max; i++) //c[i]記錄i現在該出現的位置
{
c[i] += c[i - 1];
}
for (i = n; i >= 1; i--)
{
b[c[a[i]]] = a[i]; //排序
c[a[i]]--; //更新
}
}
㈡ 海量數據排序，內存足夠大，用哪種排序演算法好為什麼
歸並排序和堆排序吧，最壞時間復雜度最低的兩個，個人感覺；你說了是內存足夠大，不考慮空間復雜度，如果考慮的話我覺得是堆排序
㈢ 如何進行海量數據排序,有哪些流行方法
你問的是關於對於海量數據排序的演算法？工具？
1 排序演算法：①就時間性能而言：數據序列基本正序(基本接近期望結果)時,直接插入排序、冒泡排序最好；數據序列基本逆序(基本與期望結果相反)時，歸並排序、堆排序較好，快速排序次之，冒泡排序、直接插入排序最差；數據序列分布比較隨機時的平均時間性能快速排序最佳；②就空間開銷而言，歸並排序的空間開銷最多；③就演算法復雜程度而言，冒泡排序、直接插入排序的實現最簡單；
2 排序工具：推薦使用資料庫系統，特別是Oracle、DB2、SQL Server等，容量大、速度快、功能強、安全性高，當然價格也上去了。流行的DBMS主要有Oracle、DB2、SQL Server、Sybase、MySql、VF、Access等，各有千秋。
㈣ 如何處理海量數據
在實際的工作環境下，許多人會遇到海量數據這個復雜而艱巨的問題，它的主要難點有以下幾個方面：
一、數據量過大，數據中什麼情況都可能存在。
如果說有10條數據，那麼大不了每條去逐一檢查，人為處理，如果有上百條數據，也可以考慮，如果數據上到千萬級別，甚至 過億，那不是手工能解決的了，必須通過工具或者程序進行處理，尤其海量的數據中，什麼情況都可能存在，例如，數據中某處格式出了問題，尤其在程序處理時， 前面還能正常處理，突然到了某個地方問題出現了，程序終止了。
二、軟硬體要求高，系統資源佔用率高。
對海量的數據進行處理，除了好的方法，最重要的就是合理使用工具，合理分配系統資源。一般情況，如果處理的數據過TB級，小型機是要考慮的，普通的機子如果有好的方法可以考慮，不過也必須加大CPU和內存，就象面對著千軍萬馬，光有勇氣沒有一兵一卒是很難取勝的。
三、要求很高的處理方法和技巧。
這也是本文的寫作目的所在，好的處理方法是一位工程師長期工作經驗的積累，也是個人的經驗的總結。沒有通用的處理方法，但有通用的原理和規則。
下面我們來詳細介紹一下處理海量數據的經驗和技巧：
一、選用優秀的資料庫工具
現在的資料庫工具廠家比較多，對海量數據的處理對所使用的資料庫工具要求比較高，一般使用Oracle或者DB2，微軟 公司最近發布的SQL Server 2005性能也不錯。另外在BI領域：資料庫，數據倉庫，多維資料庫，數據挖掘等相關工具也要進行選擇，象好的ETL工具和好的OLAP工具都十分必要， 例如Informatic，Eassbase等。筆者在實際數據分析項目中，對每天6000萬條的日誌數據進行處理，使用SQL Server 2000需要花費6小時，而使用SQL Server 2005則只需要花費3小時。
二、編寫優良的程序代碼
處理數據離不開優秀的程序代碼，尤其在進行復雜數據處理時，必須使用程序。好的程序代碼對數據的處理至關重要，這不僅僅是數據處理准確度的問題，更是數據處理效率的問題。良好的程序代碼應該包含好的演算法，包含好的處理流程，包含好的效率，包含好的異常處理機制等。
三、對海量數據進行分區操作
對海量數據進行分區操作十分必要，例如針對按年份存取的數據，我們可以按年進行分區，不同的資料庫有不同的分區方式，不 過處理機制大體相同。例如SQL Server的資料庫分區是將不同的數據存於不同的文件組下，而不同的文件組存於不同的磁碟分區下，這樣將數據分散開，減小磁碟I/O，減小了系統負荷， 而且還可以將日誌，索引等放於不同的分區下。
四、建立廣泛的索引
對海量的數據處理，對大表建立索引是必行的，建立索引要考慮到具體情況，例如針對大表的分組、排序等欄位，都要建立相應 索引，一般還可以建立復合索引，對經常插入的表則建立索引時要小心，筆者在處理數據時，曾經在一個ETL流程中，當插入表時，首先刪除索引，然後插入完 畢，建立索引，並實施聚合操作，聚合完成後，再次插入前還是刪除索引，所以索引要用到好的時機，索引的填充因子和聚集、非聚集索引都要考慮。
五、建立緩存機制
當數據量增加時，一般的處理工具都要考慮到緩存問題。緩存大小設置的好差也關繫到數據處理的成敗，例如，筆者在處理2億條數據聚合操作時，緩存設置為100000條/Buffer，這對於這個級別的數據量是可行的。
六、加大虛擬內存
如果系統資源有限，內存提示不足，則可以靠增加虛擬內存來解決。筆者在實際項目中曾經遇到針對18億條的數據進行處理， 內存為1GB，1個P42.4G的CPU，對這么大的數據量進行聚合操作是有問題的，提示內存不足，那麼採用了加大虛擬內存的方法來解決，在6塊磁碟分區 上分別建立了6個4096M的磁碟分區，用於虛擬內存，這樣虛擬的內存則增加為 4096*6 + 1024 =25600 M，解決了數據處理中的內存不足問題。
七、分批處理
海量數據處理難因為數據量大，那麼解決海量數據處理難的問題其中一個技巧是減少數據量。可以對海量數據分批處理，然後處 理後的數據再進行合並操作，這樣逐個擊破，有利於小數據量的處理，不至於面對大數據量帶來的問題，不過這種方法也要因時因勢進行，如果不允許拆分數據，還 需要另想辦法。不過一般的數據按天、按月、按年等存儲的，都可以採用先分後合的方法，對數據進行分開處理。
八、使用臨時表和中間表
數據量增加時，處理中要考慮提前匯總。這樣做的目的是化整為零，大表變小表，分塊處理完成後，再利用一定的規則進行合 並，處理過程中的臨時表的使用和中間結果的保存都非常重要，如果對於超海量的數據，大表處理不了，只能拆分為多個小表。如果處理過程中需要多步匯總操作， 可按匯總步驟一步步來，不要一條語句完成，一口氣吃掉一個胖子。
九、優化查詢SQL語句
在對海量數據進行查詢處理過程中，查詢的SQL語句的性能對查詢效率的影響是非常大的，編寫高效優良的SQL腳本和存儲 過程是資料庫工作人員的職責，也是檢驗資料庫工作人員水平的一個標准，在對SQL語句的編寫過程中，例如減少關聯，少用或不用游標，設計好高效的資料庫表 結構等都十分必要。筆者在工作中試著對1億行的數據使用游標，運行3個小時沒有出結果，這是一定要改用程序處理了。
十、使用文本格式進行處理
對一般的數據處理可以使用資料庫，如果對復雜的數據處理，必須藉助程序，那麼在程序操作資料庫和程序操作文本之間選擇， 是一定要選擇程序操作文本的，原因為：程序操作文本速度快；對文本進行處理不容易出錯；文本的存儲不受限制等。例如一般的海量的網路日誌都是文本格式或者 csv格式（文本格式），對它進行處理牽扯到數據清洗，是要利用程序進行處理的，而不建議導入資料庫再做清洗。
十一、定製強大的清洗規則和出錯處理機制
海量數據中存在著不一致性，極有可能出現某處的瑕疵。例如，同樣的數據中的時間欄位，有的可能為非標準的時間，出現的原因可能為應用程序的錯誤，系統的錯誤等，這是在進行數據處理時，必須制定強大的數據清洗規則和出錯處理機制。
十二、建立視圖或者物化視圖
視圖中的數據來源於基表，對海量數據的處理，可以將數據按一定的規則分散到各個基表中，查詢或處理過程中可以基於視圖進行，這樣分散了磁碟I/O，正如10根繩子吊著一根柱子和一根吊著一根柱子的區別。
十三、避免使用32位機子（極端情況）
目前的計算機很多都是32位的，那麼編寫的程序對內存的需要便受限制，而很多的海量數據處理是必須大量消耗內存的，這便要求更好性能的機子，其中對位數的限制也十分重要。
十四、考慮操作系統問題
海量數據處理過程中，除了對資料庫，處理程序等要求比較高以外，對操作系統的要求也放到了重要的位置，一般是必須使用伺服器的，而且對系統的安全性和穩定性等要求也比較高。尤其對操作系統自身的緩存機制，臨時空間的處理等問題都需要綜合考慮。
十五、使用數據倉庫和多維資料庫存儲
數據量加大是一定要考慮OLAP的，傳統的報表可能5、6個小時出來結果，而基於Cube的查詢可能只需要幾分鍾，因此處理海量數據的利器是OLAP多維分析，即建立數據倉庫，建立多維數據集，基於多維數據集進行報表展現和數據挖掘等。
十六、使用采樣數據，進行數據挖掘
基於海量數據的數據挖掘正在逐步興起，面對著超海量的數據，一般的挖掘軟體或演算法往往採用數據抽樣的方式進行處理，這樣 的誤差不會很高，大大提高了處理效率和處理的成功率。一般采樣時要注意數據的完整性和，防止過大的偏差。筆者曾經對1億2千萬行的表數據進行采樣，抽取出 400萬行，經測試軟體測試處理的誤差為千分之五，客戶可以接受。
還有一些方法，需要在不同的情況和場合下運用，例如使用代理鍵等操作，這樣的好處是加快了聚合時間，因為對數值型的聚合比對字元型的聚合快得多。類似的情況需要針對不同的需求進行處理。
海量數據是發展趨勢，對數據分析和挖掘也越來越重要，從海量數據中提取有用信息重要而緊迫，這便要求處理要准確，精度要高，而且處理時間要短，得到有價值信息要快，所以，對海量數據的研究很有前途，也很值得進行廣泛深入的研究。
㈤ 大數據常用的各種演算法
我們經常談到的所謂的 數據挖掘 是通過大量的數據集進行排序，自動化識別趨勢和模式並且建立相關性的過程。那現在市面的數據公司都是通過各種各樣的途徑來收集海量的信息，這些信息來自於網站、公司應用、社交媒體、移動設備和不斷增長的物聯網。
比如我們現在每天都在使用的搜索引擎。在自然語言處理領域，有一種非常流行的演算法模型，叫做詞袋模型，即把一段文字看成一袋水果，這個模型就是要算出這袋水果里，有幾個蘋果、幾個香蕉和幾個梨。搜索引擎會把這些數字記下來，如果你想要蘋果，它就會把有蘋果的這些袋子給你。
當我們在網上買東西或是看電影時，網站會推薦一些可能符合我們偏好的商品或是電影，這個推薦有時候還挺准。事實上，這背後的演算法，是在數你喜歡的電影和其他人喜歡的電影有多少個是一樣的，如果你們同時喜歡的電影超過一定個數，就把其他人喜歡、但你還沒看過的電影推薦給你。 搜索引擎和推薦系統 在實際生產環境中還要做很多額外的工作，但是從本質上來說，它們都是在數數。
當數據量比較小的時候，可以通過人工查閱數據。而到了大數據時代，幾百TB甚至上PB的數據在分析師或者老闆的報告中，就只是幾個數字結論而已。 在數數的過程中，數據中存在的信息也隨之被丟棄，留下的那幾個數字所能代表的信息價值，不抵其真實價值之萬一。 過去十年，許多公司花了大價錢，用上了物聯網和雲計算，收集了大量的數據，但是到頭來卻發現得到的收益並沒有想像中那麼多。
所以說我們現在正處於「 數字化一切 」的時代。人們的所有行為，都將以某種數字化手段轉換成數據並保存下來。每到新年，各大網站、App就會給用戶推送上一年的回顧報告，比如支付寶會告訴用戶在過去一年裡花了多少錢、在淘寶上買了多少東西、去什麼地方吃過飯、花費金額超過了百分之多少的小夥伴；航旅縱橫會告訴用戶去年做了多少次飛機、總飛行里程是多少、去的最多的城市是哪裡；同樣的，最後讓用戶知道他的行程超過了多少小夥伴。 這些報告看起來非常酷炫，又冠以「大數據」之名，讓用戶以為是多麼了不起的技術。
實際上，企業對於數據的使用和分析，並不比我們每年收到的年度報告更復雜。已經有30多年歷史的商業智能，看起來非常酷炫，其本質依然是數數，並把數出來的結果畫成圖給管理者看。只是在不同的行業、場景下，同樣的數字和圖表會有不同的名字。即使是最近幾年炙手可熱的大數據處理技術，也不過是可以數更多的數，並且數的更快一些而已。
在大數據處理過程中會用到那些演算法呢？
1、A* 搜索演算法——圖形搜索演算法，從給定起點到給定終點計算出路徑。其中使用了一種啟發式的估算，為每個節點估算通過該節點的較佳路徑，並以之為各個地點排定次序。演算法以得到的次序訪問這些節點。因此，A*搜索演算法是較佳優先搜索的範例。
2、集束搜索(又名定向搜索，Beam Search)——較佳優先搜索演算法的優化。使用啟發式函數評估它檢查的每個節點的能力。不過，集束搜索只能在每個深度中發現最前面的m個最符合條件的節點，m是固定數字——集束的寬度。
3、二分查找(Binary Search)——在線性數組中找特定值的演算法，每個步驟去掉一半不符合要求的數據。
4、分支界定演算法(Branch and Bound)——在多種最優化問題中尋找特定最優化解決方案的演算法，特別是針對離散、組合的最優化。
5、Buchberger演算法——一種數學演算法，可將其視為針對單變數較大公約數求解的歐幾里得演算法和線性系統中高斯消元法的泛化。
6、數據壓縮——採取特定編碼方案，使用更少的位元組數(或是其他信息承載單元)對信息編碼的過程，又叫來源編碼。
7、Diffie-Hellman密鑰交換演算法——一種加密協議，允許雙方在事先不了解對方的情況下，在不安全的通信信道中，共同建立共享密鑰。該密鑰以後可與一個對稱密碼一起，加密後續通訊。
8、Dijkstra演算法——針對沒有負值權重邊的有向圖，計算其中的單一起點最短演算法。
9、離散微分演算法(Discrete differentiation)。
10、動態規劃演算法(Dynamic Programming)——展示互相覆蓋的子問題和最優子架構演算法
11、歐幾里得演算法(Euclidean algorithm)——計算兩個整數的較大公約數。最古老的演算法之一，出現在公元前300前歐幾里得的《幾何原本》。
12、期望-較大演算法(Expectation-maximization algorithm，又名EM-Training)——在統計計算中，期望-較大演算法在概率模型中尋找可能性較大的參數估算值，其中模型依賴於未發現的潛在變數。EM在兩個步驟中交替計算，第一步是計算期望，利用對隱藏變數的現有估計值，計算其較大可能估計值;第二步是較大化，較大化在第一步上求得的較大可能值來計算參數的值。
13、快速傅里葉變換(Fast Fourier transform，FFT)——計算離散的傅里葉變換(DFT)及其反轉。該演算法應用范圍很廣，從數字信號處理到解決偏微分方程，到快速計算大整數乘積。
14、梯度下降(Gradient descent)——一種數學上的最優化演算法。
15、哈希演算法(Hashing)。
16、堆排序(Heaps)。
17、Karatsuba乘法——需要完成上千位整數的乘法的系統中使用，比如計算機代數系統和大數程序庫，如果使用長乘法，速度太慢。該演算法發現於1962年。
18、LLL演算法(Lenstra-Lenstra-Lovasz lattice rection)——以格規約(lattice)基數為輸入，輸出短正交向量基數。LLL演算法在以下公共密鑰加密方法中有大量使用：背包加密系統(knapsack)、有特定設置的RSA加密等等。
19、較大流量演算法(Maximum flow)——該演算法試圖從一個流量網路中找到較大的流。它優勢被定義為找到這樣一個流的值。較大流問題可以看作更復雜的網路流問題的特定情況。較大流與網路中的界面有關，這就是較大流-最小截定理(Max-flow min-cut theorem)。Ford-Fulkerson 能找到一個流網路中的較大流。
20、合並排序(Merge Sort)。
21、牛頓法(Newton's method)——求非線性方程(組)零點的一種重要的迭代法。
22、Q-learning學習演算法——這是一種通過學習動作值函數(action-value function)完成的強化學習演算法，函數採取在給定狀態的給定動作，並計算出期望的效用價值，在此後遵循固定的策略。Q-leanring的優勢是，在不需要環境模型的情況下，可以對比可採納行動的期望效用。
23、兩次篩法(Quadratic Sieve)——現代整數因子分解演算法，在實踐中，是目前已知第二快的此類演算法(僅次於數域篩法Number Field Sieve)。對於110位以下的十位整數，它仍是最快的，而且都認為它比數域篩法更簡單。
24、RANSAC——是「RANdom SAmple Consensus」的縮寫。該演算法根據一系列觀察得到的數據，數據中包含異常值，估算一個數學模型的參數值。其基本假設是：數據包含非異化值，也就是能夠通過某些模型參數解釋的值，異化值就是那些不符合模型的數據點。
25、RSA——公鑰加密演算法。較早的適用於以簽名作為加密的演算法。RSA在電商行業中仍大規模使用，大家也相信它有足夠安全長度的公鑰。
26、Schönhage-Strassen演算法——在數學中，Schönhage-Strassen演算法是用來完成大整數的乘法的快速漸近演算法。其演算法復雜度為：O(N log(N) log(log(N)))，該演算法使用了傅里葉變換。
27、單純型演算法(Simplex Algorithm)——在數學的優化理論中，單純型演算法是常用的技術，用來找到線性規劃問題的數值解。線性規劃問題包括在一組實變數上的一系列線性不等式組，以及一個等待較大化(或最小化)的固定線性函數。
28、奇異值分解(Singular value decomposition，簡稱SVD)——在線性代數中，SVD是重要的實數或復數矩陣的分解方法，在信號處理和統計中有多種應用，比如計算矩陣的偽逆矩陣(以求解最小二乘法問題)、解決超定線性系統(overdetermined linear systems)、矩陣逼近、數值天氣預報等等。
29、求解線性方程組(Solving a system of linear equations)——線性方程組是數學中最古老的問題，它們有很多應用，比如在數字信號處理、線性規劃中的估算和預測、數值分析中的非線性問題逼近等等。求解線性方程組，可以使用高斯—約當消去法(Gauss-Jordan elimination)，或是柯列斯基分解( Cholesky decomposition)。
30、Strukturtensor演算法——應用於模式識別領域，為所有像素找出一種計算方法，看看該像素是否處於同質區域( homogenous region)，看看它是否屬於邊緣，還是是一個頂點。
31、合並查找演算法(Union-find)——給定一組元素，該演算法常常用來把這些元素分為多個分離的、彼此不重合的組。不相交集(disjoint-set)的數據結構可以跟蹤這樣的切分方法。合並查找演算法可以在此種數據結構上完成兩個有用的操作：
查找：判斷某特定元素屬於哪個組。
合並：聯合或合並兩個組為一個組。
32、維特比演算法(Viterbi algorithm)——尋找隱藏狀態最有可能序列的動態規劃演算法，這種序列被稱為維特比路徑，其結果是一系列可以觀察到的事件，特別是在隱藏的Markov模型中。
㈥ 大數據分析工具詳盡介紹&數據分析演算法
大數據分析工具詳盡介紹&數據分析演算法
1、 Hadoop
Hadoop 是一個能夠對大量數據進行分布式處理的軟體框架。但是 Hadoop 是以一種可靠、高效、可伸縮的方式進行處理的。Hadoop 是可靠的，因為它假設計算元素和存儲會失敗，因此它維護多個工作數據副本，確保能夠針對失敗的節點重新分布處理。Hadoop 是高效的，因為它以並行的方式工作，通過並行處理加快處理速度。Hadoop 還是可伸縮的，能夠處理 PB 級數據。此外，Hadoop 依賴於社區伺服器，因此它的成本比較低，任何人都可以使用。
Hadoop是一個能夠讓用戶輕松架構和使用的分布式計算平台。用戶可以輕松地在Hadoop上開發和運行處理海量數據的應用程序。它主要有以下幾個優點：
⒈高可靠性。Hadoop按位存儲和處理數據的能力值得人們信賴。
⒉高擴展性。Hadoop是在可用的計算機集簇間分配數據並完成計算任務的，這些集簇可以方便地擴展到數以千計的節點中。
⒊高效性。Hadoop能夠在節點之間動態地移動數據，並保證各個節點的動態平衡，因此處理速度非常快。
⒋高容錯性。Hadoop能夠自動保存數據的多個副本，並且能夠自動將失敗的任務重新分配。
Hadoop帶有用 Java 語言編寫的框架，因此運行在 Linux 生產平台上是非常理想的。Hadoop 上的應用程序也可以使用其他語言編寫，比如 C++。
2、 HPCC
HPCC，High Performance Computing and Communications（高性能計算與通信）的縮寫。1993年，由美國科學、工程、技術聯邦協調理事會向國會提交了「重大挑戰項目：高性能計算與 通信」的報告，也就是被稱為HPCC計劃的報告，即美國總統科學戰略項目，其目的是通過加強研究與開發解決一批重要的科學與技術挑戰問題。HPCC是美國 實施信息高速公路而上實施的計劃，該計劃的實施將耗資百億美元，其主要目標要達到：開發可擴展的計算系統及相關軟體，以支持太位級網路傳輸性能，開發千兆 比特網路技術，擴展研究和教育機構及網路連接能力。
該項目主要由五部分組成：
1、高性能計算機系統（HPCS），內容包括今後幾代計算機系統的研究、系統設計工具、先進的典型系統及原有系統的評價等；
2、先進軟體技術與演算法（ASTA），內容有巨大挑戰問題的軟體支撐、新演算法設計、軟體分支與工具、計算計算及高性能計算研究中心等；
3、國家科研與教育網格（NREN），內容有中接站及10億位級傳輸的研究與開發；
4、基本研究與人類資源（BRHR），內容有基礎研究、培訓、教育及課程教材，被設計通過獎勵調查者-開始的，長期 的調查在可升級的高性能計算中來增加創新意識流，通過提高教育和高性能的計算訓練和通信來加大熟練的和訓練有素的人員的聯營，和來提供必需的基礎架構來支 持這些調查和研究活動；
5、信息基礎結構技術和應用（IITA ），目的在於保證美國在先進信息技術開發方面的領先地位。
3、 Storm
Storm是自由的開源軟體，一個分布式的、容錯的實時計算系統。Storm可以非常可靠的處理龐大的數據流，用於處理Hadoop的批量數據。Storm很簡單，支持許多種編程語言，使用起來非常有趣。Storm由Twitter開源而來，其它知名的應用企業包括Groupon、淘寶、支付寶、阿里巴巴、樂元素、Admaster等等。
Storm有許多應用領域：實時分析、在線機器學習、不停頓的計算、分布式RPC（遠過程調用協議，一種通過網路從遠程計算機程序上請求服務）、 ETL（Extraction-Transformation-Loading的縮寫，即數據抽取、轉換和載入）等等。Storm的處理速度驚人：經測 試，每個節點每秒鍾可以處理100萬個數據元組。Storm是可擴展、容錯，很容易設置和操作。
4、 Apache Drill
為了幫助企業用戶尋找更為有效、加快Hadoop數據查詢的方法，Apache軟體基金會近日發起了一項名為「Drill」的開源項目。Apache Drill 實現了 Google』s Dremel.
據Hadoop廠商MapR Technologies公司產品經理Tomer Shiran介紹，「Drill」已經作為Apache孵化器項目來運作，將面向全球軟體工程師持續推廣。
該項目將會創建出開源版本的谷歌Dremel Hadoop工具（谷歌使用該工具來為Hadoop數據分析工具的互聯網應用提速）。而「Drill」將有助於Hadoop用戶實現更快查詢海量數據集的目的。
「Drill」項目其實也是從谷歌的Dremel項目中獲得靈感：該項目幫助谷歌實現海量數據集的分析處理，包括分析抓取Web文檔、跟蹤安裝在Android Market上的應用程序數據、分析垃圾郵件、分析谷歌分布式構建系統上的測試結果等等。
通過開發「Drill」Apache開源項目，組織機構將有望建立Drill所屬的API介面和靈活強大的體系架構，從而幫助支持廣泛的數據源、數據格式和查詢語言。
5、 RapidMiner
RapidMiner是世界領先的數據挖掘解決方案，在一個非常大的程度上有著先進技術。它數據挖掘任務涉及范圍廣泛，包括各種數據藝術，能簡化數據挖掘過程的設計和評價。
功能和特點
免費提供數據挖掘技術和庫
100%用Java代碼（可運行在操作系統）
數據挖掘過程簡單，強大和直觀
內部XML保證了標准化的格式來表示交換數據挖掘過程
可以用簡單腳本語言自動進行大規模進程
多層次的數據視圖，確保有效和透明的數據
圖形用戶界面的互動原型
命令行（批處理模式）自動大規模應用
Java API（應用編程介面）
簡單的插件和推廣機制
強大的可視化引擎，許多尖端的高維數據的可視化建模
400多個數據挖掘運營商支持
耶魯大學已成功地應用在許多不同的應用領域，包括文本挖掘，多媒體挖掘，功能設計，數據流挖掘，集成開發的方法和分布式數據挖掘。
6、 Pentaho BI
Pentaho BI 平台不同於傳統的BI 產品，它是一個以流程為中心的，面向解決方案（Solution）的框架。其目的在於將一系列企業級BI產品、開源軟體、API等等組件集成起來，方便商務智能應用的開發。它的出現，使得一系列的面向商務智能的獨立產品如Jfree、Quartz等等，能夠集成在一起，構成一項項復雜的、完整的商務智能解決方案。
Pentaho BI 平台，Pentaho Open BI 套件的核心架構和基礎，是以流程為中心的，因為其中樞控制器是一個工作流引擎。工作流引擎使用流程定義來定義在BI 平台上執行的商業智能流程。流程可以很容易的被定製，也可以添加新的流程。BI 平台包含組件和報表，用以分析這些流程的性能。目前，Pentaho的主要組成元素包括報表生成、分析、數據挖掘和工作流管理等等。這些組件通過 J2EE、WebService、SOAP、HTTP、Java、JavaScript、Portals等技術集成到Pentaho平台中來。 Pentaho的發行，主要以Pentaho SDK的形式進行。
Pentaho SDK共包含五個部分：Pentaho平台、Pentaho示例資料庫、可獨立運行的Pentaho平台、Pentaho解決方案示例和一個預先配製好的 Pentaho網路伺服器。其中Pentaho平台是Pentaho平台最主要的部分，囊括了Pentaho平台源代碼的主體；Pentaho資料庫為 Pentaho平台的正常運行提供的數據服務，包括配置信息、Solution相關的信息等等，對於Pentaho平台來說它不是必須的，通過配置是可以用其它資料庫服務取代的；可獨立運行的Pentaho平台是Pentaho平台的獨立運行模式的示例，它演示了如何使Pentaho平台在沒有應用伺服器支持的情況下獨立運行；
Pentaho解決方案示例是一個Eclipse工程，用來演示如何為Pentaho平台開發相關的商業智能解決方案。
Pentaho BI 平台構建於伺服器，引擎和組件的基礎之上。這些提供了系統的J2EE 伺服器，安全，portal，工作流，規則引擎，圖表，協作，內容管理，數據集成，分析和建模功能。這些組件的大部分是基於標準的，可使用其他產品替換之。
7、 SAS Enterprise Miner
§ 支持整個數據挖掘過程的完備工具集
§ 易用的圖形界面,適合不同類型的用戶快速建模
§ 強大的模型管理和評估功能
§ 快速便捷的模型發布機制, 促進業務閉環形成
數據分析演算法
大數據分析主要依靠機器學習和大規模計算。機器學習包括監督學習、非監督學習、強化學習等，而監督學習又包括分類學習、回歸學習、排序學習、匹配學習等（見圖1）。分類是最常見的機器學習應用問題，比如垃圾郵件過濾、人臉檢測、用戶畫像、文本情感分析、網頁歸類等，本質上都是分類問題。分類學習也是機器學習領域，研究最徹底、使用最廣泛的一個分支。
最近、Fernández-Delgado等人在JMLR（Journal of Machine Learning Research，機器學習頂級期刊）雜志發表了一篇有趣的論文。他們讓179種不同的分類學習方法（分類學習演算法）在UCI 121個數據集上進行了「大比武」（UCI是機器學習公用數據集，每個數據集的規模都不大）。結果發現Random Forest（隨機森林）和SVM（支持向量機）名列第一、第二名，但兩者差異不大。在84.3%的數據上、Random Forest壓倒了其它90%的方法。也就是說，在大多數情況下，只用Random Forest 或 SVM事情就搞定了。
KNN
K最近鄰演算法。給定一些已經訓練好的數據，輸入一個新的測試數據點，計算包含於此測試數據點的最近的點的分類情況，哪個分類的類型佔多數，則此測試點的分類與此相同，所以在這里,有的時候可以復制不同的分類點不同的權重。近的點的權重大點，遠的點自然就小點。詳細介紹鏈接
Naive Bayes
樸素貝葉斯演算法。樸素貝葉斯演算法是貝葉斯演算法裡面一種比較簡單的分類演算法，用到了一個比較重要的貝葉斯定理，用一句簡單的話概括就是條件概率的相互轉換推導。詳細介紹鏈接
樸素貝葉斯分類是一種十分簡單的分類演算法，叫它樸素貝葉斯分類是因為這種方法的思想真的很樸素，樸素貝葉斯的思想基礎是這樣的：對於給出的待分類項，求解在此項出現的條件下各個類別出現的概率，哪個最大，就認為此待分類項屬於哪個類別。通俗來說，就好比這么個道理，你在街上看到一個黑人，我問你你猜這哥們哪裡來的，你十有八九猜非洲。為什麼呢？因為黑人中非洲人的比率最高，當然人家也可能是美洲人或亞洲人，但在沒有其它可用信息下，我們會選擇條件概率最大的類別，這就是樸素貝葉斯的思想基礎。
SVM
支持向量機演算法。支持向量機演算法是一種對線性和非線性數據進行分類的方法，非線性數據進行分類的時候可以通過核函數轉為線性的情況再處理。其中的一個關鍵的步驟是搜索最大邊緣超平面。詳細介紹鏈接
Apriori
Apriori演算法是關聯規則挖掘演算法，通過連接和剪枝運算挖掘出頻繁項集，然後根據頻繁項集得到關聯規則，關聯規則的導出需要滿足最小置信度的要求。詳細介紹鏈接
PageRank
網頁重要性/排名演算法。PageRank演算法最早產生於Google,核心思想是通過網頁的入鏈數作為一個網頁好快的判定標准，如果1個網頁內部包含了多個指向外部的鏈接，則PR值將會被均分，PageRank演算法也會遭到LinkSpan攻擊。詳細介紹鏈接
RandomForest
隨機森林演算法。演算法思想是決策樹+boosting.決策樹採用的是CART分類回歸數,通過組合各個決策樹的弱分類器,構成一個最終的強分類器,在構造決策樹的時候採取隨機數量的樣本數和隨機的部分屬性進行子決策樹的構建,避免了過分擬合的現象發生。詳細介紹鏈接
Artificial Neural Network
「神經網路」這個詞實際是來自於生物學，而我們所指的神經網路正確的名稱應該是「人工神經網路（ANNs）」。
人工神經網路也具有初步的自適應與自組織能力。在學習或訓練過程中改變突觸權重值，以適應周圍環境的要求。同一網路因學習方式及內容不同可具有不同的功能。人工神經網路是一個具有學習能力的系統，可以發展知識，以致超過設計者原有的知識水平。通常，它的學習訓練方式可分為兩種，一種是有監督或稱有導師的學習，這時利用給定的樣本標准進行分類或模仿；另一種是無監督學習或稱無為導師學習，這時，只規定學習方式或某些規則，則具體的學習內容隨系統所處環境 （即輸入信號情況）而異，系統可以自動發現環境特徵和規律性，具有更近似人腦的功能。
㈦ 海量數據存儲結構和演算法
下面的存儲過程不僅含有分頁方案，還會根據頁面傳來的參數來確定是否進行數據總數統計。
-- 獲取指定頁的數據
CREATE PROCEDURE pagination3
@tblName varchar(255), -- 表名
@strGetFields varchar(1000) = '*', -- 需要返回的列
@fldName varchar(255)='', -- 排序的欄位名
@PageSize int = 10, -- 頁尺寸
@PageIndex int = 1, -- 頁碼
@doCount bit = 0, -- 返回記錄總數, 非 0 值則返回
@OrderType bit = 0, -- 設置排序類型, 非 0 值則降序
@strWhere varchar(1500) = '' -- 查詢條件 (注意: 不要加 where)
AS
declare @strSQL varchar(5000) -- 主語句
declare @strTmp varchar(110) -- 臨時變數
declare @strOrder varchar(400) -- 排序類型
if @doCount != 0
begin
if @strWhere !=''
set @strSQL = "select count(*) as Total from [" + @tblName + "] where "+@strWhere
else
set @strSQL = "select count(*) as Total from [" + @tblName + "]"
end
--以上代碼的意思是如果@doCount傳遞過來的不是0，就執行總數統計。以下的所有代碼都是@doCount為0的情況
else
begin
if @OrderType != 0
begin
set @strTmp = "<(select min"
set @strOrder = " order by [" + @fldName +"] desc"
--如果@OrderType不是0，就執行降序，這句很重要！
end
else
begin
set @strTmp = ">(select max"
set @strOrder = " order by [" + @fldName +"] asc"
end
if @PageIndex = 1
begin
if @strWhere != ''
set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+ " from [" + @tblName + "] where " + @strWhere + " " + @strOrder
else
set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+ " from ["+ @tblName + "] "+ @strOrder
--如果是第一頁就執行以上代碼，這樣會加快執行速度
end
else
begin
--以下代碼賦予了@strSQL以真正執行的SQL代碼
set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+ " from ["
+ @tblName + "] where [" + @fldName + "]" + @strTmp + "(["+ @fldName + "]) from (select top " + str((@PageIndex-1)*@PageSize) + " ["+ @fldName + "] from [" + @tblName + "]" + @strOrder + ") as tblTmp)"+ @strOrder
if @strWhere != ''
set @strSQL = "select top " + str(@PageSize) +" "+@strGetFields+ " from ["
+ @tblName + "] where [" + @fldName + "]" + @strTmp + "(["
+ @fldName + "]) from (select top " + str((@PageIndex-1)*@PageSize) + " ["
+ @fldName + "] from [" + @tblName + "] where " + @strWhere + " "
+ @strOrder + ") as tblTmp) and " + @strWhere + " " + @strOrder
end
end
exec (@strSQL)
GO
上面的這個存儲過程是一個通用的存儲過程，其注釋已寫在其中了。
㈧ 資料庫的多表大數據查詢應如何優化
1.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
2.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。優化器簡悉將無法通過索引來確定將要命中的行數,因此需要搜索該表的所有行。
3.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
4.in 和 not in 也要慎用，因為IN會使系統無法使用索引,而只能直接搜索表中的數據。如：
select id from t where num in(1,2,3)
對於連續的數值，能用 beeen 就不要用 in 了：
select id from t where num beeen 1 and 3
5.盡量避免在索引過的字元數據中，使用非打頭字母搜索。這也使得引擎無法利用索引。
見如下例子：
SELECT * FROM T1 WHERE NAME LIKE 『%L%』
SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=』L』
SELECT * FROM T1 WHERE NAME LIKE 『L%』
即使NAME欄位建有索引，前兩個查詢依然無法利用索引完成加快操作，引擎不得不對全表所有數據逐條操作來完成任務。而第三個查詢能夠使用索引來加快操作。
6.必要時強制查詢優化器使用某個索引，如在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變數的值還是未散罩知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id from t where num=@num
可以改為強制查詢使用索引：
select id from t with(index(索引名)) where num=@num
7.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
SELECT * FROM T1 WHERE F1/2=100
應改為:
SELECT * FROM T1 WHERE F1=100*2
SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=』5378』
應改為:
SELECT * FROM RECORD WHERE CARD_NO LIKE 『5378%』
SELECT member_number, first_name, last_name FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21
應改為:
SELECT member_number, first_name, last_name FROM members
WHERE dateofbirth < DATEADD(yy,-21,GETDATE())
即：任何對列的操作都將導致表掃描，它包括資料庫函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊。
8.應盡量避免在where子句中對欄位進行沖咐鬧函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)='abc'--name以abc開頭的id
select id from t where datediff(day,createdate,-11-30')=0--『2005-11-30』生成的id
應改為:
select id from t where name like 'abc%'
select id from t where createdate>=-11-30' and createdate<-12-1'
9.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
10.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致。
11.很多時候用 exists是一個好的選擇：
elect num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
SELECT SUM(T1.C1)FROM T1 WHERE(
(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)
SELECT SUM(T1.C1) FROM T1WHERE EXISTS(
SELECT * FROM T2 WHERE T2.C2=T1.C2)
兩者產生相同的結果，但是後者的效率顯然要高於前者。因為後者不會產生大量鎖定的表掃描或是索引掃描。
Statement stmt = null;
ResultSet rs = null;
String query = "select 列名 from 表名 where id=11 and fname='xx' order by 列名 desc limit 1";
stmt = conn.createStatement();
rs = stmt.executeQuery(query);
if (rs.next()) {
result = rs.getInt("列名");
}
樓上的 拼寫錯誤，我來修正 ^^
select count(*) from 表名
傳統資料庫處理大數據很困難吧，不建議使用傳統資料庫來處理大數據。
建議研究下，Hadoop，Hive等，可處理大數據。
如果有預算，可以使用一些商業大數據產品，國內的譬如永洪科技的大數據BI產品，不僅能高性能處理大數據，還可做數據分析。
當然如果是簡單的查詢，傳統資料庫如果做好索引，可能可以提高性能。
有兩種方法
方法1：
select 100 * from tbllendlist where fldserialNo not in ( select 300100 fldserialNo from tbllendlist order by fldserialNo ) order by fldserialNo
方法2：
SELECT TOP 100 * FROM tbllendlist WHERE (fldserialNo > (SELECT MAX(fldserialNo) FROM (SELECT TOP 300100 fldserialNo FROM tbllendlist ORDER BY fldserialNo) AS T)) ORDER BY fldserialNo
影響命中率的因素有四種：字典表活動、臨時段活動、回滾段活動、表掃描， 應用DBA可以對這四種因素進行分析，找出資料庫命中率低的症結所在。 1)字典表活動 當一個SQL語句第一次到達Oracle內核時資料庫對SQL語句進行分析，包含在查詢中的數據字典對象被分解，產生SQL執行路徑。如果SQL語句指向一個不在SGA中的對象?表或視圖，Oracle執行SQL語句到數據典中查詢有關對象的信息。數據塊從數據字典表被讀取到SGA的數據緩存中。由於每個數據字典都很小，因此，我們可緩存這些表以提高對這些表的命中率。但是由於數據字典表的數據塊在SGA中占據空間，當增加全部的命中率時，它們會降低表數據塊的可用空間， 所以若查詢所需的時間字典信息已經在SGA緩存中，那麼就沒有必要遞歸調用。 2)臨時段的活動 當用戶執行一個需要排序的查詢時，Oracle設法對內存中排序區內的所有行進行排序，排序區的大小由資料庫的init.ora文件的數確定。如果排序區域不夠大，資料庫就會在排序操作期間開辟臨時段。臨時段會人為地降低OLTP(online transaction processing）應用命中率,也會降低查詢進行排序的性能。如果能在內存中完成全部排序操作，就可以消除向臨時段寫數據的開銷。所以應將SORT_AREA_SIZE設置得足夠大，以避免對臨時段的需要。這個參數的具體調整方法是:查詢相關數據，以確定這個參數的調整。 select * from v$sysstat where name='sorts(disk)'or name='sorts(memory); 大部分排序是在內存中進行的，但還有小部分發生在臨時段， 需要調整 值，查看init.ora文件的 SORT_AREA_SIZE值，參數為：SORT_AREA_SIZE＝65536;將其調整到SORT_AREA_SIZE＝131072、這個值調整後，重啟ORACLE資料庫即可生效。 3)回滾段的活動 回滾段活動分為回滾活動和回滾段頭活動。對回滾段頭塊的訪問會降低應用的命中率， 對OLTP系統命中率的影響最大。為確認是否因為回滾段影響了命中率，可以查看監控輸出報表中的「數據塊相容性讀一重寫記錄應用」 的統計值，這些統計值是用來確定用戶從回滾段中訪問數據的發生次數。 4)表掃描 通過大掃描讀得的塊在數據塊緩存中不會保持很長時間， 因此表掃描會降低命中率。為了避免不必要的全表掃描，首先是根據需要建立索引，合理的索引設計要建立人對各種查詢的分析和預測上，筆者會在SQL優化中詳細談及；其次是將經常用到的表放在內存中，以降低磁碟讀寫次數。
1. SQL優化的原則是：將一次操作需要讀取的BLOCK數減到最低,即在最短的時間達到最大的數據吞吐量。
調整不良SQL通常可以從以下幾點切入：
? 檢查不良的SQL，考慮其寫法是否還有可優化內容
? 檢查子查詢 考慮SQL子查詢是否可以用簡單連接的方式進行重新書寫
? 檢查優化索引的使用
? 考慮資料庫的優化器
2. 避免出現SELECT * FROM table 語句，要明確查出的欄位。
3. 在一個SQL語句中，如果一個where條件過濾的資料庫記錄越多，定位越准確，則該where條件越應該前移。
4. 查詢時盡可能使用索引覆蓋。即對SELECT的欄位建立復合索引，這樣查詢時只進行索引掃描，不讀取數據塊。
5. 在判斷有無符合條件的記錄時建議不要用SELECT COUNT （*）和select 1 語句。
6. 使用內層限定原則，在拼寫SQL語句時，將查詢條件分解、分類，並盡量在SQL語句的最里層進行限定，以減少數據的處理量。
7. 應絕對避免在order by子句中使用表達式。
8. 如果需要從關聯表讀數據，關聯的表一般不要超過7個。
9. 小心使用 IN 和 OR，需要注意In集合中的數據量。建議集合中的數據不超過200個。
10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，這樣可以有效的利用索引。
11. 在查詢時盡量減少對多餘數據的讀取包括多餘的列與多餘的行。
12. 對於復合索引要注意，例如在建立復合索引時列的順序是F1，F2，F3，則在where或order by子句中這些欄位出現的順序要與建立索引時的欄位順序一致，且必須包含第一列。只能是F1或F1，F2或F1，F2，F3。否則不會用到該索引。
13. 多表關聯查詢時，寫法必須遵循以下原則，這樣做有利於建立索引，提高查詢效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值條件（=）) and (table1的非等值條件) and (table2與table1的關聯條件) and (table2的等值條件) and (table2的非等值條件) and (table3與table2的關聯條件) and (table3的等值條件) and (table3的非等值條件)。
注:關於多表查詢時from 後面表的出現順序對效率的影響還有待研究。
14. 子查詢問題。對於能用連接方式或者視圖方式實現的功能，不要用子查詢。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。應該用如下語句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。
15. 在WHERE 子句中，避免對列的四則運算，特別是where 條件的左邊，嚴禁使用運算與函數對列進行處理。比如有些地方 substring 可以用like代替。
16. 如果在語句中有not in（in）操作，應考慮用not exists（exists）來重寫,最好的辦法是使用外連接實現。
17. 對一個業務過程的處理，應該使事物的開始與結束之間的時間間隔越短越好，原則上做到資料庫的讀操作在前面完成，資料庫寫操作在後面完成，避免交叉。
18. 請小心不要對過多的列使用列函數和order by,group by等，謹慎使用disti軟體開發t。
19. 用union all 代替 union，資料庫執行union操作，首先先分別執行union兩端的查詢，將其放在臨時表中，然後在對其進行排序，過濾重復的記錄。
當已知的業務邏輯決定query A和query B中不會有重復記錄時，應該用union all代替union，以提高查詢效率。
數據更新的效率
1. 在一個事物中，對同一個表的多個insert語句應該集中在一起執行。
2. 在一個業務過程中，盡量的使insert,update,delete語句在業務結束前執行，以減少死鎖的可能性。
資料庫物理規劃的效率
為了避免I/O的沖突，我們在設計資料庫物理規劃時應該遵循幾條基本的原則(以ORACLE舉例)：
?? table和index分離：table和index應該分別放在不同的tablespace中。
?? Rollback Segment的分離：Rollback Segment應該放在獨立的Tablespace中。
?? System Tablespace的分離：System Tablespace中不允許放置任何用戶的object。（mssql中primary filegroup中不允許放置任何用戶的object）
?? Temp Tablesace的分離：建立單獨的Temp Tablespace，並為每個user指定default Temp Tablespace
??避免碎片：但segment中出現大量的碎片時，會導致讀數據時需要訪問的block數量的增加。對經常發生DML操作的segemeng來說，碎片是不能完全避免的。所以，我們應該將經常做DML操作的表和很少發生變化的表分離在不同的Tablespace中。
當我們遵循了以上原則後，仍然發現有I/O沖突存在，我們可以用數據分離的方法來解決。
?? 連接Table的分離：在實際應用中經常做連接查詢的Table，可以將其分離在不同的Taclespace中，以減少I/O沖突。
?? 使用分區：對數據量很大的Table和Index使用分區，放在不同的Tablespace中。
在實際的物理存儲中，建議使用RAID。日誌文件應放在單獨的磁碟中。
給出你的查詢，然後才可以對其進行優化
如果你的查詢比較固定，並且查詢的條件區別度較高，可以建立相應的索引。
其他的一些規則，比如使用exists代替 in都可以試試
查詢速度慢的原因很多，常見如下幾種：
1、沒有索引或者沒有用到索引(這是查詢慢最常見的問題，是程序設計的缺陷)
2、I/O吞吐量小，形成了瓶頸效應。
3、沒有創建計算列導致查詢不優化。
4、內存不足
5、網路速度慢
6、查詢出的數據量過大（可以採用多次查詢，其他的方法降低數據量）
7、鎖或者死鎖(這也是查詢慢最常見的問題，是程序設計的缺陷)
8、sp_lock,sp_who,活動的用戶查看,原因是讀寫競爭資源。
9、返回了不必要的行和列
10、查詢語句不好，沒有優化
可以通過如下方法來優化查詢 :
1、把數據、日誌、索引放到不同的I/O設備上，增加讀取速度，以前可以將Tempdb應放在RAID0上，SQL2000不在支持。數據量（尺寸）越大，提高I/O越重要.
2、縱向、橫向分割表，減少表的尺寸(sp_spaceuse)
3、升級硬體
4、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。注意填充因子要適當（最好是使用默認值0）。索引應該盡量小，使用位元組數小的列建索引好（參照索引的創建）,不要對有限的幾個值的欄位建單一索引如性別欄位
5、提高網速;
6、擴大伺服器的內存,Windows 2000和SQL server 2000能支持4-8G的內存。配置虛擬內存：虛擬內存大小應基於計算機上並發運行的服務進行配置。運行 Microsoft SQL Server? 2000 時，可考慮將虛擬內存大小設置為計算機中安裝的物理內存的 1.5 倍。如果另外安裝了全文檢索功能，並打算運行 Microsoft 搜索服務以便執行全文索引和查詢，可考慮：將虛擬內存大小配置為至少是計算機中安裝的物理內存的 3 倍。將 SQL Server max server memory 伺服器配置選項配置為物理內存的 1.5 倍（虛擬內存大小設置的一半）。
7、增加伺服器 CPU個數; 但是必須明白並行處理串列處理更需要資源例如內存。使用並行還是串列程是MsSQL自動評估選擇的。單個任務分解成多個任務，就可以在處理器上運行。例如耽擱查詢的排序、連接、掃描和GROUP BY字句同時執行，SQL SERVER根據系統的負載情況決定最優的並行等級，復雜的需要消耗大量的CPU的查詢最適合並行處理。但是更新操作Update,Insert， Delete還不能並行處理。
8、如果是使用like進行查詢的話，簡單的使用index是不行的，但是全文索引，耗空間。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查詢時，查詢耗時和欄位值總長度成正比,所以不能用CHAR類型，而是VARCHAR。對於欄位的值很長的建全文索引。
9、DB Server 和APPLication Server 分離；OLTP和OLAP分離
10、分布式分區視圖可用於實現資料庫伺服器聯合體。聯合體是一組分開管理的伺服器，但它們相互協作分擔系統的處理負荷。這種通過分區數據形成資料庫伺服器聯合體的機制能夠擴大一組伺服器，以支持大型的多層 Web 站點的處理需要。有關更多信息，參見設計聯合資料庫伺服器。（參照SQL幫助文件'分區視圖'）
a、在實現分區視圖之前，必須先水平分區表
b、在創建成員表後，在每個成員伺服器上定義一個分布式分區視圖，並且每個視圖具有相同的名稱。這樣，引用分布式分區視圖名的查詢可以在任何一個成員伺服器上運行。系統操作如同每個成員伺服器上都有一個原始表的復本一樣，但其實每個伺服器上只有一個成員表和一個分布式分區視圖。數據的位置對應用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數據和日誌 DBCC SHRINKDB,DBCC SHRINKFILE. 設置自動收縮日誌.對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能。在T-sql的寫法上有很大的講究，下面列出常見的要點：首先，DBMS處理查詢計劃的過程是這樣的：
1、 查詢語句的詞法、語法檢查
2、 將語句提交給DBMS的查詢優化器
3、 優化器做代數優化和存取路徑的優化
4、 由預編譯模塊生成查詢規劃
5、 然後在合適的時間提交給系統處理執行
6、 最後將執行結果返回給用戶其次，看一下SQL SERVER的數據存放的結構：一個頁面的大小為8K(8060)位元組，8個頁面為一個盤區，按照B樹存放。
12、Commit和rollback的區別 Rollback:回滾所有的事物。 Commit:提交當前的事物. 沒有必要在動態SQL里寫事物，如果要寫請寫在外面如： begin tran exec(@s) mit trans 或者將動態SQL 寫成函數或者存儲過程。
13、在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的數據，浪費了伺服器的I/O資源，加重了網路的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。
14、SQL的注釋申明對執行沒有任何影響
15、盡可能不使用游標，它佔用大量的資源。如果需要row-by-row地執行，盡量採用非游標技術,如：在客戶端循環，用臨時表，Table變數，用子查詢，用Case語句等等。游標可以按照它所支持的提取選項進行分類： 只進 必須按照從第一行到最後一行的順序提取行。FETCH NEXT 是唯一允許的提取操作,也是默認方式。可滾動性可以在游標中任何地方隨機提取任意行。游標的技術在SQL2000下變得功能很強大，他的目的是支持循環。有四個並發選項 READ_ONLY：不允許通過游標定位更新(Update)，且在組成結果集的行中沒有鎖。 OPTIMISTIC WITH valueS:樂觀並發控制是事務控制理論的一個標准部分。樂觀並發控制用於這樣的情形，即在打開游標及更新行的間隔中，只有很小的機會讓第二個用戶更新某一行。當某個游標以此選項打開時，沒有鎖控制其中的行，這將有助於最大化其處理能力。如果用戶試圖修改某一行，則此行的當前值會與最後一次提取此行時獲取的值進行比較。如果任何值發生改變，則伺服器就會知道其他人已更新了此行，並會返回一個錯誤。如果值是一樣的，伺服器就執行修改。選擇這個並發選項OPTIMISTIC WITH ROW VERSIONING:此樂觀並發控制選項基於行版本控制。使用行版本控制，其中的表必須具有某種版本標識符，伺服器可用它來確定該行在讀入游標後是否有所更改。在 SQL Server 中，這個性能由 timestamp 數據類型提供，它是一個二進制數字，表示資料庫中更改的相對順序。每個資料庫都有一個全局當前時間戳值：@@DBTS。每次以任何方式更改帶有 timestamp 列的行時，SQL Server 先在時間戳列中存儲當前的 @@DBTS 值，然後增加 @@DBTS 的值。如果某 個表具有 timestamp 列，則時間戳會被記到行級。伺服器就可以比較某行的當前時間戳值和上次提取時所存儲的時間戳值，從而確定該行是否已更新。伺服器不必比較所有列的值，只需比較 timestamp 列即可。如果應用程序對沒有 timestamp 列的表要求基於行版本控制的樂觀並發，則游標默認為基於數值的樂觀並發控制。 SCROLL LOCKS 這個選項實現悲觀並發控制。在悲觀並發控制中，在把資料庫的行讀入游標結果集時，應用程序將試圖鎖定資料庫行。在使用伺服器游標時，將行讀入游標時會在其上放置一個更新鎖。如果在事務內打開游標，則該事務更新鎖將一直保持到事務被提交或回滾；當提取下一行時，將除去游標鎖。如果在事務外打開游標，則提取下一行時，鎖就被丟棄。因此，每當用戶需要完全的悲觀並發控制時，游標都應在事務內打開。更新鎖將阻止任何其它任務獲取更新鎖或排它鎖，從而阻止其它任務更新該行。然而，更新鎖並不阻止共享鎖，所以它不會阻止其它任務讀取行，除非第二個任務也在要求帶更新鎖的讀取。滾動鎖根據在游標定義的 Select 語句中指定的鎖提示，這些游標並發選項可以生成滾動鎖。滾動鎖在提取時在每行上獲取，並保持到下次提取或者游標關閉，以先發生者為准。下次提取時，伺服器為新提取中的行獲取滾動鎖，並釋放上次提取中行的滾動鎖。滾動鎖獨立於事務鎖，並可以保持到一個提交或回滾操作之後。如果提交時關閉游標的選項為關，則 COMMIT 語句並不關閉任何打開的游標，而且滾動鎖被保留到提交之後，以維護對所提取數據的隔離。所獲取滾動鎖的類型取決於游標並發選項和游標 Select 語句中的鎖提示。鎖提示 只讀 樂觀數值 樂觀行版本控制 鎖定無提示 未鎖定 未鎖定 未鎖定 更新 NOLOCK 未鎖定 未鎖定未鎖定 未鎖定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 錯誤 更新 更新 更新 TABLOCKX 錯誤 未鎖定 未鎖定更新其它 未鎖定 未鎖定 未鎖定 更新 *指定 NOLOCK 提示將使指定了該提示的表在游標內是只讀的。
16、用Profiler來跟蹤查詢，得到查詢所需的時間，找出SQL的問題所在; 用索引優化器優化索引
17、注意UNion和UNion all 的區別。UNION all好
18、注意使用DISTINCT，在沒有必要時不要用，它同UNION一樣會使查詢變慢。重復的記錄在查詢里是沒有問題的
19、查詢時不要返回不需要的行、列
20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT來限制查詢消耗的資源。當評估查詢消耗的資源超出限制時，伺服器自動取消查詢,在查詢之前就扼殺掉。 SET LOCKTIME設置鎖的時間
21、用select 100 / 10 Percent 來限制用戶返回的行數或者SET ROWCOUNT來限制操作的行
22、在SQL2000以前，一般不要用如下的字句: "IS NULL", "＜＞", "!=", "!＞", "!＜", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'"，因為他們不走索引全是表掃描。也不要在Where字句中的列名加函數，如Convert，substring等,如果必須用函數的時候，創建計算列再創建索引來替代.還可以變通寫法：Where SUBSTRING(firstname,1,1) = 'm'改為Where firstname like 'm%'（索引掃描），一定要將函數和列名分開。並且索引不能建得太多和太大。NOT IN會多次掃描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 來替代，特別是左連接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，現在2000的優化器能夠處理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能優化她，而"＜＞"等還是不能優化，用不到索引。
23、使用Query Analyzer，查看SQL語句的查詢計劃和評估分析是否是優化的SQL。一般的20%的代碼占據了80%的資源，我們優化的重點是這些慢的地方。
24、如果使用了IN或者OR等時發現查詢沒有走索引，使用顯示申明指定索引： Select * FROM PersonMember (INDEX = IX_Title) Where processid IN ('男'，'女')
25、將需要查詢的結果預先計算好放在表中，查詢的時候再Select。這在SQL7.0以前是最重要的手段。例如醫院的住院費計算。
26、MIN() 和 MAX()能使用到合適的索引。
27、資料庫有一個原則是代碼離數據越近越好，所以優先選擇Default,依次為Rules,Triggers, Constraint（約束如外健主健CheckUNIQUE……,數據類型的最大長度等等都是約束）,Procere.這樣不僅維護工作小，編寫程序質量高，並且執行的速度快。
28、如果要插入大的二進制值到Image列，使用存儲過程，千萬不要用內嵌Insert來插入(不知JAVA是否)。因為這樣應用程序首先將二進制值轉換成字元串（尺寸是它的兩倍），伺服器受到字元後又將他轉換成二進制值.存儲過程就沒有這些動作: 方法：Create procere p_insert as insert into table(Fimage) values (@image), 在前台調用這個存儲過程傳入二進制參數，這樣處理速度明顯改善
㈨ 數據分析項目包含哪些流程
1、數據採集
了解數據採集的意義在於真正了解數據的原始面貌，包括數據產生的時間、條件、格式、內容、長度、限制條件等。
2、數據存儲
無論數據存儲於雲端還是本地，數據的存儲不只是我們看到的資料庫那麼簡單。
3、數據提取
數據提取是將數據取出的過程，數據提取的核心環節是從哪取、何時取、如何取。
4、數據挖掘
數據挖掘是面對海量數據時進行數據價值提煉的關鍵。
5、數據分析
數據分析相爛慶枯對於數據挖掘更多的是偏向業務應用和解讀，當數據挖掘演算法得出結論後，如何解釋演算法在結果、可信度、顯著程度等方面對於業務的實際意義，如何將挖掘結果反饋到業務操作過程中便於業務理解和實施是關鍵。
6、數據展現
數差褲據展現即數據可視化的部分，數據分析師如何把數據觀點展示給業務的過程。數據展現除遵循各公司統一規范原則外，具體形式還要根據實際需求和場景而定。
7、數據應用
數據應用是飢洞數據具有落地價值的直接體現，這個過程需要數據分析師具備數據溝通能力、業務推動能力和項目工作能力。
㈩ 數據結構中關於數據查詢的演算法有哪些
數據查詢分靜態查找和動態查找：
靜態查找有：順序查找、有順序表的折半查找、分塊查
動態查找主要用二叉排序數查找。
哈希表 常用的哈希函數有；直接定址法，除留余數法，數字分析法，平方取中法，折疊法。
一般情況下這些就夠用了