Meta*Infinity

oracle终于买下了sun oracle 以74亿美元买了sun，而IBM最终错过了他的购买机会。 oracle买下sun是业界的大事，也对数据库领域起到了举足轻重的影响。我想对于oracle本身而言，正如larry Ellison所讲，oracle得到了sun的solaris 和java，将更加助力oracle成为贯穿前后台的，从底层到应用的系统集成商。可以预见不久，oracle吸纳了sun在硬件和软件上的优势，特别是mysql的优势,更加巩固oracle在数据库领域的霸主地位。 不知道Microsoft在想什么？oracle一直以来都有和ms争霸的决心和勇气，这几年的势头也处处证明了这一点。记得当初Ellison就公开坦言他比较妒忌盖茨，如今在数据信息领域，oracle已经达到了无法撼动的地位。似乎ellisson的愿望更近了一步。 有些地方还是值得关注和猜测的 1. 不久前，oracle联合HP发布的oracle exadata 和HP oracle database machine 计划。在sun的技术被购入之后，oracle会不会还一如既往的推动。希望不要成为鸡肋。 2.oracle无疑站在数据库领域的无法撼动的霸主地位，这包括开源和商业。那末mysql将来的命运如何？一方面mysql影响力极大，另一方面，照ellison的一贯手法，收购＝毁灭，mysql是否也要步以前foxpro,dbase的后尘？只能用时间来验证. 3.oracle一旦完成了收购，IT格局将大有变化。将来我们一打开电脑，就是ms，看到数据没准就是oracle。 oracle成功之后，他的下一个目标会是谁？兴许oracle也有被反垄断法告的那一天。在此环境下，ms的应对策略如何？真希望有一天，ms也迫于竞争，忙于把sql server一直到solaris的上，呵呵。

绿色计算 所谓绿色计算，当然是和环保连系在一起的。云计算被赋予绿色计算的头衔，其原由很容易被推理:大量的主机被集中化管理，人们只要向服务提供商买服务就可以了。被集中管理的主机有利于从整体上思考环保策略，如将计算中心移到离电厂近的地方，使用管理策略减少能源消耗，等等。总之被可运作的概念和理由很多。但是我还是质疑现实情况。 我们可以类比北京的冬日取暖，究竟是集中供暖更环保还是单户的天然气独立取暖更绿色？众说纷纭，莫衷一是。 支持集中供暖的人会讲：统一管理煤炭，集中燃烧，降低了污染，有利充分利用能源达到环保。 支持单户取暖的人会说：单户方式能够根据用户意愿决定是否使用，更agile，更有利于节约能源，更绿色。 究竟谁对？当然应当看实际数据，但这年头谁又能拿到靠普的数据。本人家里采用单户取暖，冬天取暖炉根本没用过，因为房子的保温效果不错，所以没必要。论其环保，我自然支持单户方式。 现在再回到绿色计算上来，所谓的计算中心，选择降低能源消耗策略应当是顺理成章的事，也符合商家的经济利益。但综合整个社会成本，绿色不绿色就很难讲了，比如，无论运转效果如何，你都需要一个固定的能源消耗，你还需要更多的配套设施，等。总之，这年头绿色就是炒作的话题，最终目的是推广自己的概念和产品。 环保是每个人应该做的，因为大家都住在一个地球上。你怎末推广自己的产品，只要合法，也没人干涉。不过在拿环保说事的同时，要衡量清楚自己有没有真的做到。

云计算是一个新潮而且听起来很牛的名词，今天探其根源，俺还是有点体会。 云计算可以说是分布式计算，网格计算的近亲，或者干脆点，就是它们的衍生品。这里的概念模糊不清，关系也并不明确。总之，不同机构有不同解释。 讲讲我的经历。记得最早接触分布式计算是在第一份工作，一个关于电信计费的大型项目。谈到计费就往往少不了数据的问题，比如如何接入通信网络，如何收集数据，也就是ETL。由于数据量庞大，这里ETL暴露出几个问题： 1.如何保证扩展性？ 2.如何保证24×7？ 3.如何保证处理效率？ 4.灾难发生，如何补偿？ 回想起那个时候的技术架构，简直就是糟糕到底。一群学院派的老前辈用OLTP方式处理这些数据ETL的问题，数据处理全部集中到数据库，其后果也是恐怖到底。好了，几个月后，数据库就是永远的瓶颈。 现在看来，ETL是最适合分布式计算的应用场景。原因： 1.被处理数据无需考虑状态。可以很随意拆分处理。 2.ETL处理的数据量往往很大，需首要考虑性能问题。分布式可以更好的提高效率。 3.既然有分布式的结构存在，自然扩展性和可靠性就很高。 当时自己也在实践中看到了这一点，所以写了一个很小的通信模块用来实现扩展性。原理很简单，只要这个程序运行，一旦它接收到控制信号，就取出一部分原始数据，执行设定的业务逻辑代码。记得当时写了两个版本，一个用UNIX C,一个用delphi。以后逐渐地把原来放在数据库中的处理，如数据清洗， 移到这些分布模块去做。很大程度上减少了数据库压力，而且效率和扩展性上有了很好的提升，架构也清晰多了。后来又完成了一个程序，起了个名字叫控制面板，就是用来监控各个分布程序的状态。基本上，这样的系统就成了分布式的并发处理系统，尽管很多其它的问题还没有考虑。 以后，偶然机会看到了一个开源项目，叫巡天望远镜计划（ http://lsstcorp.org/ ），关注了一段时间。发现其IT系统的一个模块，用来收集来自射电望远镜的数据，处理方式也是采用分布式并行处理方式，架构与我曾思考的类似。但这样的科研项目面临的挑战就大多了，其一是数据量大，50G/天。其二是，你如何找到足够的机器去完成分布运算环境。靠网友的捐助是比较好的方法，比如贡献你的机器，让它在晚上加入运算网络。当募捐到足够的机器时，一个庞大的计算网格形成了。 当回来商业环境中，我们发现类似的分布式系统还有很多，但总不能都让...