故事背景：
本人有幸,經老友( 現為x知名快遞公司技術總監 ) 推薦進入中國前三大民營快遞公司之一工作，在此非常感謝他,在此也非常感謝我在第一家公司幫助我進步的兄弟(我在時的項目經理，現為 x 知名自動識別行業企業部門高級經理)。
下面介紹6年后和6年前的我的職業生涯中的兩個單表大數據故事。
(1) 6年后 單表大數據 之故事（一）
來之前老友告之現在核心運營系統 Oracle數據庫中單表數據半年過10億了，使用傳統T-Sql不論如何優化，查詢客戶信息速度也提升不上去。
需要使用企業級搜索引擎(Solr)來解決本部門其余兩大輔助業務系統去查詢客戶信息。如果我過去的話，先把這塊帶肉的骨頭啃了。
當時一聽很開心,不就10億數據嗎?不就單表嗎?6年前就遇到過類似的情況了。這還是使用成熟企業級的開源軟件(Solr),這有何難啊，老友說項目開發周期大概2個月，最長盡量不要超過3個半月，我自信滿滿的說沒問題。
(2) 6年前 單表大數據 之故事（二）
還記得大概5年半前的一個項目，確切的說現在應該是成熟產品了。上次聽那兄弟（當時為項目經理，現在已經為該公司的系統集成部的部門高級經理,近十年工作經驗。）說：該系統全國大概已經400多家企業級用戶了，不乏跨國大企業用戶(美國，日本),不乏上市公司。當時遇見的那個問題應該是今天這個問題的縮微版了,那是個單表數據每天100w的量，SqlServer2005下。
當時的情景是這樣的：筆者當時正在山西一家企業做軟件項目的實施，突然接到上海總部公司電話，讓趕緊處理完就奔赴河南一家企業處理系統癱瘓的問題。當時也沒多想，實施完了就趕緊買張去河南焦作的汽車票。還沒下車，就不斷接到客戶公司老總的電話，詢問車已經到何地了。已經備好了車，老總帶着專職司機奔着高速收費站那邊等着我了(那一刻，我才深深知道自己的價值,才覺着自己對於這個社會還是可以做些貢獻的。)。
客戶公司老總也沒多說，就簡單告知系統癱瘓了，整個生產車間已經不能正常運轉了，停了一個星期了。大量葯品都堆在生產車間中了,另外在葯品生產車間的通道上也都堆滿了整箱整箱准備生產的葯品。一路上，我們飛奔，路上我簡單的吃了口燴面，然后我們就直奔廠區的生產車間。
去了以后發現有個單表數據量已經堆積幾千萬（具體的記不清楚了），當時看完就懵了。堆積了這么多數據，系統查詢怎么會不慢呢,生產不停下來那才怪呢?當時客戶方老總以為抓住了我問題馬上就能解決，我在他們車間里待多久他就陪多久，每天還點了不少好菜。中間我有打電話求助過總部項目經理，在客戶現場Google，百度了N篇解決方案的稿子，索引刪了重建，CPU 2核升級到4核(也是他們當時就近能夠買到的最好的CPU了)，內存單條8g?，又升級到16g?( 這個需要跟我那個高級經理的兄弟核實一下，時間久了當時反正內存不低了，本來是分享的經歷的，免得又弄成了口水戰，尊重事實，行文要嚴謹，要嚴格要求自己。)，系統在重啟的那幾十分鍾，速度飛快，但是過不了多久，系統又現之前的死相。前前后后總共折騰了3天2夜，期間睡眠時間嚴重不足，終於在第三天的下午，我也崩潰了。
緊接着我就給總部老板打電話，向他報告了這邊的慘狀，以及我所遇見的困境，讓他趕緊派項目經理過去。那時我的項目經理采取了一套救急的方案：
(i) 將該上傳到國家機構的數據全部上傳。
(ii) 將現有的生產任務結束，並上傳相應的數據到國家機構。
(iii) 重新創建新的生產庫，將未生產的未使用的原生產庫數據全部導入新生產庫,並重建索引。
(iv) 將原來的生產庫全部分離備份。
(V) 將生產系統切換到新的生產庫上。
問題才得以解決。
前前后后我們又花去了2天一夜，掐指一算這前后已經讓客戶公司停產了2個周。
那時才知道一個好的企業級應用的產品的系統架構是有多么重要。
這忙完后我在賓館睡了10多個小時才緩過氣來。
這就是我這幾年職業生涯中遇見的兩組大數據案例。欲知后事如何且聽下回分解。
下回預告：
1. 6年前，我和我的項目經理回到上海總部后對系統升級改進解決方案。
2. 6年后，我遇見比當年更為龐大的數據，我的大數據解決方案。
3. 對於產品級別系統和企業內部系統我的大數據解決方案心得。
4. 大數據應用我們還有哪些殺手鐧。
下一篇： MongoDb企業應用實戰(一) 寫在MongoDb應用介紹之前(ii)