現在的大資料產品，都是採用分布式儲存和分布式計算的集群方案。衡量大資料處理能力的強弱，主要有以下幾個制約因素。
1.網路頻寬
網路是聯接計算機的紐帶，這個紐帶當然越寬越好，這樣可以在計算機資源許可的情況下，在單位時間內傳輸更多的資料，讓計算機處理更多的資料。現在企業網路中，普遍採用的多是百兆網路，也有千兆，萬兆雖然有，但是用得不多。
2.磁碟
所有資料，不管它從**來，最終都要存進不同的硬碟裡面，或者快閃儲存器盤。快閃儲存器盤的讀寫效率比硬碟高得多，但是缺點也明顯：**貴、容量小。現在的儲存介質主要還是硬碟，硬碟有順序讀寫和隨機讀寫兩種模型。順序讀寫是磁頭沿著磁軌，好象流水線一樣，有規律的向前滾動進行。隨機讀寫是磁頭跳躍著，找到磁軌上留空的地方，把資料寫進去。很明顯，順序讀寫比隨機讀寫效率高，所以系統架構師在設計大資料儲存方案時，都是以順序讀寫為主要選擇。
3.計算機的數量
分布式的集群環境下，計算機的規模當然越大越好。這樣在資料等量的情況下，計算機數量越多，分配給每台計算機的資料越少，處理效率自然就高了。但是計算機的數量也不是可以無限增加，集群對計算機規模的容納有乙個峰值，超過這個峰值，再提公升就很困難，處理不好還會下降。原因主要來自木桶短板效應、邊界效應、規模放大效應。根據多年前的乙個測試，當時以pentium 3和pentium 4晶元為基礎平台，配合100m網路，在上面執行laxcus大資料系統。當達到千台計算機的規模時，瓶頸開始顯露出來。如果現在用新的x86晶元，加上更高速的網路，應該是能夠容納更多的計算機。
laxcus集群架構圖
4. 成本
這是困擾所有企業的乙個大問題。雖然大資料解決了很多企業在資料儲存和計算上的問題，但是因為硬體基礎裝置的投入規模大，成本是成倍的增加。這個問題，可以從兩個方面解決，一是採購成本，單體硬體**是關鍵。二是運營成本，耗電量是關鍵。這種情況下，低**低功耗的計算機架構應運而生了。這方面，arm晶元走在了前面，目前幾乎所有手機裡的晶元，不管是水果系還是谷歌系，採用的都是arm架構。試想一下，如果把這樣的架構移植到大資料平台上，原來一堆嗡嗡叫的計算機，需要空調風扇配合的機房，換成了一堆安靜如平板電腦/手機的計算機，是不是能夠節約成本呢？這不是幻想，現在已經有人有企業在做這方面的工作了。
5.**質量
這不是關鍵問題，但是是企業必須關注的乙個問題。這和程式設計師編寫的計算機**質量有關。實際上，每個大資料產品都是半成品，它們只是提供了乙個計算框架，要實際應用到企業生產中，裡面還有大量業務編碼需要程式設計師來實現。要使大資料應用達到高質量，技術負責人要做好前期設計，清楚和規範業務流程，程式設計師拿在方案後，用統一格式編寫**。這是雙方互相配合的過程。或者說，要做好協同和協調的事情。
預處理的幾個問題
一 解決塊注釋 不能巢狀的問題 我們知道行注釋 可以多層巢狀和逐層取消，而塊注釋 不能巢狀或不能與 混用，否則有可能出現編譯錯誤。通常我們在程式除錯時如果要取消一大段 可以用條件編譯 if 0 endif實現 二 避免標頭檔案的重複包含 假如a.h中自定義了乙個結構體，在b.h和c.h中都又自定義了...
Redis 快取處理的幾個問題
目錄 問題一 快取穿透 問題二 快取擊穿 問題三 快取雪崩 測試 說明 利用redis與mysql資料庫的機制 redis中一旦不存在查詢的ksy,就訪問mysql 直接繞過快取,訪問myslq,而製造db的請求壓力 解決 將從mysql請求出的空存入redis一定時間 說明 某一熱點key在高併發...
TCP連線的幾個問題的處理
問題一 accept4 too many open files retrying in 640ms或者 dial tcp 127.0.0.1 8080 socket too many open files都是socket的數量，即檔案描述符的數量不夠用了，解決方法，增加檔案描述符的數量 ulimit...