曾經在以前的公司做過IT，凡事跟電腦相關的都要做，也就是俗話說的IT民工吧。

當時公司裡有一個數據庫會接收到的測試資料大約為一個月100萬條左右，然後要透過程式每五分鐘左右抓取一下這個資料庫。

說實話，當時壓力蠻大的，因為程式涉及到生產不能停，頻繁的讀取這麼多數量的資料庫會導致程式很卡，一卡使用這個程式的人就會停下生產的，所以我在方面也研究了一些方法 注：當時使用的伺服器為windows2008r2，資料庫為sql 2008版本，程式為php語言編寫。

我總結一下當時的方法:

1、每個月都會找個時間重啟伺服器，釋放CPU和記憶體資源

2、一定要分開檔案伺服器和資料庫伺服器為同一臺，因為檔案伺服器佔用頻寬資源比較嚴重

3、防止資料庫鎖死，編寫程式時已經避免同時使用更新語句

4、使用任務管理把相應的資料進行後臺處理，如先把資料寫到a表裡，再透過任務後臺讓它跟b表進行匹配

5、編寫sql語句時，儘量精確匹配，不要模糊匹配，可以透過資料庫管理器來查詢所用的時間是多少

6、關於資料物理安全的小建議，一定要給系統盤和資料盤，做好raid，經常觀察硬碟是否亮紅燈報警，要及時更換，二，使用備份軟體對資料進行定時備份，在空閒的時間點備份，不會影響資料庫使用的效率，比如吃飯的點

系統無法啟動時，請勿隨意重灌系統，可以試一下最後一次正確配置啟動

總結：實際情況要有靈活的方法，也就是資料執行的瓶頸在哪裡，就對哪裡進行最佳化。

我是做JAVA後臺開發的，目前為止最多處理過每天600萬左右的資料！資料不算特別多，但是也算是經歷過焦頭爛額，下面淺談下自己和團隊怎麼做的？

後臺架構:

前置部門:負責接收別的公司推過來的資料，因為每天的資料量較大，且分佈不均，使用十分鐘推送一次報文的方式，使用batch框架進行資料落地，把落地成功的資料某個欄位返回給呼叫端，讓呼叫端驗證是否已經全部落地成功的，保證資料的一致性！

核心處理:使用了springcloud作為微服務架構，使用feign進行客戶端的負載均衡，使用分庫分表的資料架構，分庫分表資料庫中介軟體為公司自己開發，透過欄位no採用hash的方式分佈到8個數據庫，每個庫128張表，為了資料不重複，滿足冪等性，會使用redis進行加鎖操作，因為redis是單執行緒處理，保證資料不會重複儲存！

遇到的問題:

①，資料沒落地:雖然使用呼叫端和服務端確認的方法保證一致性，但是因為網路延遲，服務宕機等影響，會發生資料重複，或者資料沒落地等，首先在做好介面，資料冪等性的同時，保證服務的穩定性，透過統計等方式對沒有落地的資料重新儲存！

③，快取失效:在使用redis的過程中，經常遇到redis服務掛了，延遲等情況，可能會導致資料丟失，這種情況尤為嚴重，多數時間只能通過後期人為干預，重新拉取前置資料進行資料儲存，同時快取資料一定要使用持久化，保證資料丟失時，損失最低化！

快取爆炸:期間遇到一個問題，運維打電話來說資料超過了一千萬，問咋回事，查程式碼才知道，很多資料沒設定過期時間，導致資料積壓，簡直就是失敗的經歷！

④，資料庫:透過分庫分表的方式，我們的資料庫還算穩定，高峰的時候也沒超過資料庫效能監控的閾值，最重要的是怕資料庫中介軟體宕機引起資料丟失，所以中介軟體通常使用叢集的方式進行部署，同時，分庫分表對全域性唯一ID的產生也有需求，使用的是taobao的一套sequnce生成元件，避免使用分庫分表字段(no)作為查詢條件，避免使用連線查詢(可以使用no進行同庫的連線)，統計採用別的方式！

⑤，訊息中介軟體堵塞:有時候訊息中介軟體延遲，導致資料積壓幾十萬，上百萬，怕怕的有木有？保證中介軟體穩定的情況下，最重要的新增報警郵件，及時處理積壓問題(50%的機率是重啟，哈哈)！

從事程式設計師工作以來，歷時三年，呆過兩個公司，前一個公司處於傳統國企製造型企業網際網路化的程序中，後者處於網際網路公司成熟發展期，作為新業務型的研發人員，或多或少都經歷了一些資料量，在製造型企業處理過的最多量級的資料應該是使用者的註冊登入資訊，在之後的網際網路企業處理過最多量級的資料應該是瀏覽日誌的實時統計監控。下面就簡單說說這兩個業務場景以及對應的處理方式和資料量級。

在傳統的製造型企業，我們團隊負責公司對外業務的統一註冊和認證，所有對外應用、網站提供的註冊、登入資訊都需要呼叫我們團隊的相關介面完全相關流程，註冊的使用者資訊也以我們團隊的使用者資料為準，統一註冊和認證服務上線執行近兩年的時間裡，至我離職時，註冊使用者200萬，登入均耗時40ms，獲取賬戶資訊均耗時10ms。處理方式也簡單，就是應用普遍採用的mysql+redis，賬戶相關的認證資訊都普遍走分散式快取，mysql是主從結構，redis採用叢集模式+哨兵叢集的處理方式。整個應用是最初的架構是spring mvc+dubbo的分散式架構，對外提供restful風格的介面服務，之後版本升級為spring boot+eureka+consul的微服務架構，對外相容提供restful風格的介面之外，還提供基於Oauth2.0的第三方登入服務，包括QQ、微信、百度等第三方應用。資料處理的量級按照資料庫來說應該是百萬級，或許不太準備，對這個量級的概念理解不深，對這方面有深入研究的同學可以留言科普哈。

在現在的網際網路企業，處理資料量級最多的應該是我目前所做的流量實時監控，今天才壓測完，記憶還比較清晰，採用的處理方式是kafka+storm+redis，處理的量級是1.2億/10分鐘，啟用了10臺伺服器+4核CPU+2G記憶體+64G磁碟部署的storm叢集，64個執行緒跑storm拓撲，統計分析的結果儲存在redis，透過其他方式進行實時展示。

資料是有價值的，資料的價值在於我們的應用，當看到我們自己開發的專案，可以實時處理億級的資料，真心感覺收穫滿滿。雖然過程經歷很多坑，但是隻要出結果，再多的辛苦、努力都感覺值得，做自己喜歡的事情，再累都有勁兒。

我是在IT上班的，目前每天大概要處理2TB以上的資料，大概10多億條，基本上使用Hadoop+Hive+Spark進行處理。

這些資料是從FTP下載的，採集協議和處理過程自己寫，基本上每一條資料都會過一到兩遍才入庫。

看了大家的回答，好像處理資料都是程式設計師乾的活，說說我吧，從事製造業，代工蘋果手機，技術部門主管。每天上百K的產品檢測資料，分佈在不同的裝置中，有一次需要重工一批物料(主要是看檢測資料是否OK)，如果全部再過一遍檢測裝置浪費的人力物力可不是一點點，想讓IT部門開發資料庫，結果光簽單都得半個月(大公司流程繁瑣你懂的)，最後沒辦法自己動手寫程式，自動採集機臺資料，設定判斷邏輯，讓生產部門只需掃描產品即可判定挑選，總共用了不到半天。全程使用excel處理，資料大概有1000K吧

處理過的最大的資料量是：每天14億條，是幫一個企業做大資料採集分析處理的，我們公司是專門做大資料的，是用的我們自主研發的伺服器版本ForeSpider爬蟲軟體進行採集，開了多個程序進行採集，同時對採集到的資料進行挖掘分類處理。當然，除了爬蟲還用到了我們自主研發的分類器，文字挖掘系統以及ForeLib資料庫等。

ForeLib資料庫是專門針對於大資料研發的，效能比MySQL高100倍，使用起來很順手，資料量再大，也不會宕機，當時基本每天都得采集處理這麼多資料，大概用了1個月的時間。