故事背景:
本人有幸,经老友( 现为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)