mysql數(shù)據(jù)量大于多少條創(chuàng)建索引？這個看你的應(yīng)用網(wǎng)站查詢數(shù)據(jù)量的大小，網(wǎng)站查詢值越多，數(shù)據(jù)庫壓力越大，又要看你負載均衡和組建索引，看你的并發(fā)量，即相同在一瞬間操作數(shù)據(jù)庫的次數(shù)收到大數(shù)據(jù)信息如何處理？

mysql數(shù)據(jù)量大于多少條創(chuàng)建索引？

這個看你的應(yīng)用網(wǎng)站查詢數(shù)據(jù)量的大小，網(wǎng)站查詢值越多，數(shù)據(jù)庫壓力越大，又要看你負載均衡和組建索引，看你的并發(fā)量，即相同在一瞬間操作數(shù)據(jù)庫的次數(shù)

收到大數(shù)據(jù)信息如何處理？

1.大數(shù)據(jù)處理之一：哪采

大數(shù)據(jù)的采集是指利用多個數(shù)據(jù)庫來收得到發(fā)自客戶端（Web、App的或傳感器形式等）的數(shù)據(jù)，另外用戶這個可以這些數(shù)據(jù)庫來參與簡單網(wǎng)站查詢和處理工作。比如說，電商會在用民間的關(guān)系型數(shù)據(jù)庫MySQL和Oracle等來存儲每一筆事務(wù)數(shù)據(jù)，之外，Redis和MongoDB這樣的NoSQL數(shù)據(jù)庫也常應(yīng)用于數(shù)據(jù)的采集。

在大數(shù)據(jù)的采集過程中，其主要特點和挑戰(zhàn)是并發(fā)數(shù)高，畢竟同樣的有可能會有成千上萬的用戶來通過訪問和操作，諸如火車票售票網(wǎng)站和淘寶，它們并發(fā)的訪問量在峰值時提升到上百萬，所以才必須在喂養(yǎng)靈獸端布署大量數(shù)據(jù)庫才能支撐。而且如何能在這些數(shù)據(jù)庫之間通過負載均衡和分片的確是需要深入思考和設(shè)計。

2.大數(shù)據(jù)處理之二：導(dǎo)入/預(yù)處理

雖說再采集端本身會有很多數(shù)據(jù)庫，但假如要對這些海量數(shù)據(jù)進行比較有效的分析，肯定應(yīng)該要將這

些依附前端的數(shù)據(jù)導(dǎo)入到一個集中的大型分布式數(shù)據(jù)庫，或則分布式存儲集群，而且這個可以在導(dǎo)入基礎(chǔ)上做一些簡單可以清洗和預(yù)處理工作。也有一些用戶會在導(dǎo)入時使用用來自Twitter的Storm來對數(shù)據(jù)通過流式計算，來行最簡形矩陣部分業(yè)務(wù)的實時計算需求。

導(dǎo)入與預(yù)處理過程的特點和挑戰(zhàn)比較多是導(dǎo)入的數(shù)據(jù)量大，每秒鐘的導(dǎo)入量經(jīng)常會會都沒有達到百兆，哪怕千兆網(wǎng)絡(luò)級別。

3.大數(shù)據(jù)處理之三：統(tǒng)計出來/分析什么

統(tǒng)計與分析比較多憑借分布式數(shù)據(jù)庫，或則分布式計算集群來對存儲于陣內(nèi)的海量數(shù)據(jù)接受特殊

的分析和分類匯總等，以不滿足大多數(shù)常見的分析需求，在這方面，一些實時性需求會會用到EMC的GreenPlum、Oracle的Exadata，這些實現(xiàn)MySQL的列式存儲Infobright等，而一些批處理，或則實現(xiàn)半結(jié)構(gòu)化數(shù)據(jù)的需求可以不在用Hadoop。

統(tǒng)計與講這部分的主要特點和挑戰(zhàn)是分析不屬于的數(shù)據(jù)量大，其對系統(tǒng)資源，特別是I/O會有如此大的占用。

4.大數(shù)據(jù)處理之四：挖掘

與前面統(tǒng)計和分析過程不同的是，數(shù)據(jù)挖掘像是沒有什么先行設(shè)定好的主題，主要是在保證數(shù)據(jù)上面通過設(shè)計和實現(xiàn)各種算法的計算，使能起分析預(yù)測（Predict）的效果，最終達到利用一些高級別數(shù)據(jù)分析的需求。比較比較啊是算法有作用于聚類的Kmeans、主要用于統(tǒng)計出來去學習的SVM和作用于分類的NaiveBayes，主要注意使用的工具有Hadoop的Mahout等。該過程的特點和挑戰(zhàn)要注意是用于挖掘的算法很緊張，而且換算不屬于的數(shù)據(jù)量和計算量都不大，廣泛數(shù)據(jù)挖掘算法都以單線程為主。