项目经理手记 -- 2010年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，有个啥用？要能结合实际才行啊！