專案經理手記 2023年5月21日

昨天是5.20，今天是5.21.昨天是我愛你，今天是我愛一(生一世)。呵呵，又不知道有多少少女要獻身了。

答應乙個朋友要寫點東西，關於工作的。反正這孩子剛從西安到北京，估計這會正暈頭轉向呢，我先寫吧。

所謂海量資料，就是指一大堆資料，嗯，和海那樣吧，一大堆一大堆一大堆一大大大大堆堆堆堆堆。。。

我因為工作原因，處理的比較多的就是海量資料的問題。每天新增的資料量是600w*24*60*60*4，單位是條。一條的話，大概要佔到20-30個位元組的感覺吧。夠海量了麼？當然，這點資料都不夠蓋子和老馮塞牙縫的，呵呵。那麼今天呢，就先說說關於海量資料的處理方案。

首先，要明確海量資料是幹嘛的，什麼地方可能是效能瓶頸。比如我們的系統，每天新增這麼多資料，只是儲存而已，要查詢的可能不是很大，即使查詢，也允許你稍微慢那麼一些。最重要的一點需求，就是要顯示最新加進來的那部分資料。於是乎，這個問題就變成了一下兩個：

1 如何在一大堆資料裡找那麼恆河泥沙一樣的資料？

2 這麼多東西怎麼存？

第二個問題好辦，無非是硬碟塔而已。第乙個問題呢，其實是個解決思路的問題。一般來說，同學們會想，我要顯示新加進來的資料，那麼我就要先讓資料到資料庫裡，然後再去查詢。

是啊，的確不錯啊。但是你想過乙個問題沒有？業務要求是顯示新加進來的這部分資料，那麼需要做的實際上是把新加進來的資料顯示，而不一定要強制你先存後顯示，對不？

所以我當時設計了乙個方案，前端返回資料的時候，先給我儲存乙份臨時的。每次重新整理給使用者的資料必然很少(多了您老人家有心情看？)，所以我即使select *，也嚇不死人。返回給我以後，前端程式再慢慢存資料庫去。這個儲存過程，存上一萬年，海枯石爛我都不在乎，因為我的資料已經顯示了，我的job完成了。

可能有的同學會說，您老這個例子比較單一，比較的侷限。right，我這個例子只是說明一種解決思路而已。我真正想要提示的，是乙個問題。

最值錢的是什麼？是你能解決問題。不僅僅要會寫**，還要能從更高的層次去解決。這，就是專案經理的日常工作中很普通的一項。你懶，不想寫具體**，ok，沒問題。您老人家寫個方案出來，寫清楚了，寫明白了，人家問你，你回答。方案有問題，您改。這就行了。

為什麼專案經理值錢，乙個好的專案經理更值錢？就是這個原因，因為你能解決人家解決不了的問題。懂技術的不懂業務啊，光知道rac,tt,pi，bi,olap,oltp，有個啥用？要能結合實際才行啊！