MongoDb企业应用实战(一) 写在MongoDB应用介绍之前(ii)

上一篇： MongoDb企业应用实战(一) 写在MongoDB应用介绍之前(i)

有段时间没跟大家去分享和探讨过一些问题，分享过一些经验了(失败过的，痛苦过的才最有看点啊，不知道各位同仁们怎么去看这个问题?)。接着跟大家唠叨唠叨。

且说6年前，那段千万数据级别刻骨铭心的经历，让我真正意识到一个好的产品或者是一个好的软件系统是需要不断的提炼，优化，改进，检验，再改进。这才能够一举奠定它在市场中的地位和价值(6年前，与其说那是项目，到不如说是一个完整的自动识别行业的解决方案。(i)高速传送带,(ii)高速成组扫描设备,(iii)条形码打印机,(iv)自动剔除气缸,(v)手持终端[PDA],(vi)高速成像设备，十八般兵器悉数登场，才构筑了后来了全国400多家企业级客户，据最近我当年的那位带头大哥介绍，现在都在那套系统已经安装到一些欧美在华的企业车间中了，他们又弄出了国际版了。)。

接上回：我和我的项目经理回到上海总部后对系统升级改进解决方案

如果单表数据量过多，有什么好的思路呢?我在6年前那段时间真心觉着一些解决问题的办法或者思路太重要了。按照今天大家的官方说法是软件系统中的设计思想太重要,一个好的架构太重要了。如果是几个人或者几十个人的用户，抑或是一天几百条，几千条数据，简单的写写，不谈什么软件设计，不谈什么数据库设计,问题也能解决。但终归大家都能解决的那就没什么含量了，也体现不出来一个项目经理或者是项目中的核心灵魂人物的价值了。

话说我的项目经理到现场一看,毕竟是久经IT战场，迅速的提出解决问题的办法。当时他在我的心目中正如下面这则小故事中说的那个物理学家：

"有一台价值数百万的精密设备故障，怎么搞都没办法，最后一位物理学家说他行，开价十万美元。没办法，答应了。物理学家在图纸上划了一根线，说查这。结果真好了。老板一看一根线就十万，想赖账。物理学家说了一句话：划一根线一美元，知道在哪划线值九万九千九百九十九美元。老板一听，让人付钱。"

他知道从哪里划线，并且是属于一阵见血式的，那就聊聊当时的一些做法，大家如果看到这篇文章，有什么好的想法，好的做法，也欢迎大家不吝赐教。

(i) 根据数据的状态，重新划分使用过的和没使用过的数据。

(ii)没有使用过的数据，按照数据产生的月份迁移到对应月份的数据库表中。

(iii) 建立生产库的历史备份库，将生产库的中已上传至国家监管平台的数据备份至历史库中。

(iv)改进软件，针对查询数据部分，分为当前生产库查询和历史数据查询。

(v)改进新库创建为每一新年手动创建，根据时间判断自动创建，并同步迁移上一年没有使用过的数据。

其实我在后来一些项目中发现6年前的做法，在6年后这个办法依旧不过时。最近跟一个资深的Oracle DBA聊到他在 Oracle中数据的备份和优化策略时，发现他也是采取类似的方式去处理。

(i)对Oracle建立水平分区表,将一个完整的表中的数据存储到不同的数据空间中。

(SqlServer也可以做水平分区表,当时考虑到那是一个全国性的项目，只是采取了更容易维护的方式，自动创建对应数据库，自动创建表结构,这样整个系统的维护成本更低，也能够真正做到替用户着想，不是每个企业都专门去养一帮很N叉的开发，运维人员。)

(ii)每隔6个月，迁移6个月前的数据至历史备份库中。(跟6年前我们的数据库维护策略如出一辙。)

各位同仁们：但是6年前，我怎么能够理解到这种开发或者运维的思想呢?一上来开始写复杂的存储过程我就觉着自己很N了，多年后回想起来这其实没什么哦。现在ORM，LINQ,甚至是NoSql的产品也都用上了，也没有觉着自己有多么N叉哦。只是真心觉着这么6年来的持续的学习，保持着的持续学习状态让我受益匪浅。另外看待一些问题，思考一些问题也更加接地气，更加靠谱些了。想起来了那句话："最困难的事情是了解自己 最不容易的事情是欣赏自己。"

2014 新的一年真的需要对自己有一个更加理性的认识。