昨天是5.20，今天是5.21.昨天是我愛你，今天是我愛一(生一世)。呵呵，又不知道有多少少女要獻身了。
答應一個朋友要寫點東西，關於工作的。反正這孩子剛從西安到北京，估計這會正暈頭轉向呢，我先寫吧。
所謂海量數據，就是指一大堆數據，嗯，和海那樣吧，一大堆一大堆一大堆一大大大大堆堆堆堆堆。。。
我因爲工作原因，處理的比較多的就是海量數據的問題。每天新增的數據量是600W*24*60*60*4，單位是條。一條的話，大概要佔到20-30個字節的感覺吧。夠海量了麼？當然，這點數據都不夠蓋子和老馮塞牙縫的，呵呵。那麼今天呢，就先說說關於海量數據的處理方案。
首先，要明確海量數據是幹嘛的，什麼地方可能是性能瓶頸。比如我們的系統，每天新增這麼多數據，只是存儲而已，要查詢的可能不是很大，即使查詢，也允許你稍微慢那麼一些。最重要的一點需求，就是要顯示最新加進來的那部分數據。於是乎，這個問題就變成了一下兩個：
1 如何在一大堆數據裏找那麼恆河泥沙一樣的數據？
2 這麼多東西怎麼存？
第二個問題好辦，無非是硬盤塔而已。第一個問題呢，其實是個解決思路的問題。一般來說，同學們會想，我要顯示新加進來的數據，那麼我就要先讓數據到數據庫裏，然後再去查詢。
是啊，的確不錯啊。但是你想過一個問題沒有？業務要求是顯示新加進來的這部分數據，那麼需要做的實際上是把新加進來的數據顯示，而不一定要強制你先存後顯示，對不？
所以我當時設計了一個方案，前端返回數據的時候，先給我保存一份臨時的。每次刷新給用戶的數據必然很少(多了您老人家有心情看？)，所以我即使SELECT *，也嚇不死人。返回給我以後，前端程序再慢慢存數據庫去。這個存儲過程，存上一萬年，海枯石爛我都不在乎，因爲我的數據已經顯示了，我的Job完成了。
可能有的同學會說，您老這個例子比較單一，比較的侷限。right，我這個例子只是說明一種解決思路而已。我真正想要提示的，是一個問題。
最值錢的是什麼？是你能解決問題。不僅僅要會寫代碼，還要能從更高的層次去解決。這，就是項目經理的日常工作中很普通的一項。你懶，不想寫具體代碼，OK，沒問題。您老人家寫個方案出來，寫清楚了，寫明白了，人家問你，你回答。方案有問題，您改。這就行了。
爲什麼項目經理值錢，一個好的項目經理更值錢？就是這個原因，因爲你能解決人家解決不了的問題。懂技術的不懂業務啊，光知道RAC,TT,PI，BI,OLAP,OLTP，有個啥用？要能結合實際才行啊！