海量資料問題和解決方案蒐集彙總：傳統關係型資料的問題：1. 擴充套件困難：由於存在類似join這樣多表查詢機制，使得資料庫在擴充套件方面很艱難。
2. 讀寫慢：這種情況主要發生在資料量達到一定規模時由於關係型資料庫的系統邏輯非常複雜，使得其非常容易發生死鎖等的併發問題，所以導致其讀寫速度下滑非常嚴重;
3. 成本高：企業級資料庫的license**很驚人，並且隨著系統的規模，而不斷上公升;
4. 有限的支撐容量：現有關係型解決方案還無法支撐google這樣海量的資料儲存;
mysql海量資料解決方案
1.資料切分，庫外路由，或者庫內切分表。可考慮切分方式：
(1) user_id為區分，1～1000的對應db1，1001～2000的對應db2，以此類推;
優點：可部分遷移
缺點：資料分布不均
(2)hash取模分：
對user_id進行hash(或者如果user_id是數值型的話直接使用user_id 的值也可)，然後用乙個特定的數字，比如應用中需要將乙個資料庫切分成4個資料庫的話。
我們就用4這個數字對user_id的hash值進行取模運算，也就是user_id%4,這樣的話每次運算就有四種可能：結果為1的時候對應db1;結果為2的時候對應db2;結果為3的時候對應db3;結果為0的時候對應db4，這樣一來就非常均勻的將資料分配到4個db中。
優點：資料分布均勻
缺點：資料遷移的時候麻煩，不能按照機器效能分攤資料
(3)在認證庫中儲存資料庫配置
就是建立乙個db，這個db單獨儲存user_id到db的對映關係，每次訪問資料庫的時候都要先查詢一次這個資料庫，以得到具體的db資訊，然後才能進行我們需要的查詢操作。
優點：靈活性強，一對一關係
缺點：每次查詢之前都要多一次查詢，效能大打折扣
2. 資料庫集群，讀寫分離，資料切分。
海量資料問題和解決方案蒐集彙總
傳統關係型資料的問題 1.擴充套件困難 由於存在類似join這樣多表查詢機制，使得資料庫在擴充套件方面很艱難 2.讀寫慢 這種情況主要發生在資料量達到一定規模時由於關係型資料庫的系統邏輯非常複雜，使得其非常容易發生死鎖等的併發問題，所以導致其讀寫速度下滑非常嚴重 3.成本高 企業級資料庫的licen...
海量資料解決方案
首先做使用者量估算需求，假如我們做的是學術社群，那麼這個使用者量不會很大，可能我們不需要考慮這個，對於使用者量的級別，我們暫時把使用者量級別定 為三種，百萬級別 m 和千萬界別 s 以及億萬級別 q 並考慮使用者登入驗證以及查詢常用的操作，對m和s進行擴充以及了解。眾所周知，在這個情況下，對於使用者...
關於海量資料問題的解決方案
1.給定a b兩個檔案，各存放50億個url，每個url各佔64位元組，記憶體限制是4g，讓你找出a b檔案共同的url？方案1 可以估計每個檔案安的大小為50g 64 320g，遠遠大於記憶體限制的4g。所以不可能將其完全載入到記憶體中處理。考慮採取分而治之的方法。s 求每對小檔案中相同的url時...