作者文章: Fenng

Oracle 收购仁科之战

最近稍微修订了一下《书写历史的甲骨文–ORACLE公司传奇》,本文可以看作是其续篇。在接下来一段时间,我可能会把 Oracle 这几年的发展历程做个回顾。

收购仁科之战

2004年12月13日,Oracle 公司宣布签订了以每股26.50美元、总计约 103 亿美元的代价收购仁科(PeopleSoft) 的最终协议。历时十八个月的争斗终于尘埃落定。

从 2003年6月宣布的51亿收购金额,到最终的 103 亿美元,Oracle 可以说是付出了血本。这次收购对于 Oracle 公司来说有着深远的意义。且听笔者慢慢道来。

PeopleSoft 公司由大卫·杜菲尔德(Dave Duffield)和 Ken Morris 在 1987 年联合创建,面向企业应用软件,在上世纪 90 年代发展得顺风顺水,到这场收购大战之前,在 ERP 领域已经稳坐第二把交椅。市场第一当然是SAP,而 Oracle 则远远落在后面。现在回过头看,PeopleSoft 当年能够在强敌如林的 ERP 市场有其一席之地,把客户放到第一位,用更好的服务赢得客户的心是PeopleSoft 的竞争法宝,而能做到这一点,与创始人大卫·杜菲尔德的处世之道有直接关系 。

Oracle 觊觎企业应用市场已久,苦于无法抢占更大领地,而在 2003 年,PeopleSoft 完成对 J.D. Edwards 的收购,代价是 15 亿美元,J.D. Edwards 在中型企业及制造、流通和资产密集型行业颇有一手,本来PeopleSoft 在人力资源管理方面已经是绝对的领先者,合并后,在企业应用市场,PeopleSoft 绝对超过 Oracle 处于第二位,这样一来在 ERP 领域也无疑给 SAP 相当的压力,老二当久了,谁都要做老大。话说,这样一来,Oracle 觉得在 ERP 领域要追上第二名都已千难万难,要做第一,更是无望,至于做到世界第一的位置,更是遥不可及了。因而这一领域是 Oracle 必争之地,依赖数据库这一块,虽说赚得盆满钵满,担市场增长毕竟有限,不在企业应用领域有所突破,迟早会在这个强手如林的市场上走下坡路。

如果某个领域不能战胜对手,最好办法就是收购,然后让竞争对手消失。手持大把现金的 Oracle 宣布对 PeopleSoft 展开并购,受到时任 PeopleSoft CEO 克莱格·康威(Craig Conway) 的超强力反对。康威本是 Oracle 的旧臣,曾任高级副总裁,当年也是埃利森身边红人,按理说应该和 Oracle 暗通款曲,竖起白旗才对。其实不然,当初康威离开甲骨文并非功成身退,而是被迫出走。正是出于这样的原因,新仇旧恨,难免要发起强势阻击。仁科公司上下也几乎都反对收购,明摆着一旦收购成功,Oracle 必将大刀挥起进行裁员。当然,这些因素不会有决定性作用,股东以及董事会才是决定这家公司命运的人。

这场收购战的前 16 个月可以说胜负未分,仁科抛出了若干自救的方法,大施”毒丸计划”,除了与 Oracle 对薄公堂之外,对客户发起了退款保证计划,大幅度增加福利提高 Oracle 收购成本,甚至和 IBM 结盟力求自保。

眼看着 Oracle 打赢了反垄断的案子,一场大战即将决出胜负,谁料想仁科董事竟然临阵换将,解除了康威的职务,理由是对其继续领导公司的能力失去信心,当时也有传言说董事会对康威不满有其它原因,包括其行事作风独断专行,但这个时候临阵换奖,无疑是头脑发昏。几年后回顾这个情节,真的怀疑是不是 Oracle 用了什么反间计,感觉像在看商业版的赤壁之战。

创始人杜菲尔德重回公司,企图挽救仁科。但这个时候情况已经对 Oracle 有利了,逐利的投资者们临门一脚,竟然多数同意收购,仁科束手投诚。尽管杜菲尔德坚决不妥协,但游戏规则就是如此,自己一手创建的公司从此改换门庭。

收购完成后,Oracle 裁掉了仁科 5000 多名员工,大屠杀,热忱的杜菲尔德自掏腰包建立了一只基金,帮助被裁员工就业,足见老爷子的仁爱之心。

从这次收购开始,Oracle 在企业应用软件市场上一跃成为第二名。这么大手笔、马拉松式的收购的最终成功极大的刺激了大手笔并购的信心与野心,整合仁科(包括J.D. Edwards)这样的大公司也给其带来了大量且可复制的并购管理经验。从这次收购开始,Oracle 收购战正式拉开序幕,其影响直到今天仍未散去。

未完待续…

此文作者:, 位于 Database 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

《软件随想录》(More Joel on Software)

前一段时间提前读了几章 Joel Spolsky《软件随想录》(More Joel on Software)。这是一本能带来新思维、能改变技术官僚思维惯性的图书。

这本书的内容覆盖了一个 IT 人将要面临的方方面面,不管是否认可书中的观点,不可否认的是 Joel 的见解的确是颇为独到的,有些话语堪称一针见血,这家伙的写作风格也是从不隔靴搔痒。我觉得在这本书中传递给我们的是一种理念–如何把技术效能发挥出来,如何把技术的价值最大化。而 Joel 本人也用自己的亲身经历来证明他所说的并非是做不到的事情,实际上,他创建的 Fog Creek Software 就是一家很酷而且颇为成功的公司。

《软件随想录》不是一本讲技术的图书,但是我相信如果认真读过之后会发现对自己的技术提升会最大。另外,有必要强调的是Joel 对人才的论述,如果要招聘真正牛的技术人员,那么自认为理解技术人员的管理者都应该读一下这本书,某些章节场景或许会让你觉得脸红,哦,原来以前自己所谓的一些招聘手段是多么的低级而低效,我们有太多的理念需要转变

今天晚上还给 Yupoo 的刘平阳推荐了这本书。个人觉得,无论是一线技术人员还是 IT 公司的的管理者,或是创业团队的成员,都应该读一下这本书,相信能给你很多启迪。

八卦一下:Joel Spolsky 给自己起了一个中文名字:周思博,不知道他知道在中国有这么多粉丝不?

好久没有读到这么有趣的书了,也要感谢译者 阮一峰 的辛苦工作,他也是个有趣的家伙。

EOF

数据分片(Sharding)设计问题一例

Question:假设一家 C2C 网站,数据库中某表存储买卖双方交易的数据信息,对于一条交易来说,买卖双方数据具有一定程度的耦合性,比如卖家的状态更新对应买家的状态也会更新,对于一个中大规模的电子商务网站,架构师在设计中如何考虑数据分片的问题(假定该表随着数据的膨胀必须拆分)?

Answer:对于一个中大规模的电子商务网站,随着网站的不断发展,其相应的数据规模会不断膨胀。数据分片技术是使网站得于实现可扩展性的一种常用解决方案。对于 C2C 类型的网站,由于交易记录不容易进行水平的数据分割,因此对于这样的应用处理要再进行细分:

  • 买卖双方交易的信息,具备较高的时效性,即交易全部完成后就不会再有更新,因此这部分数据可以与正在交易中的数据区分开来,并可以单独分表,定时归纳。具体的做法可以采用水平分割的数据分片技术,比如可以根据用户号码段范围进行切片,把不同的群体划分到不同的 DB 上,这样可以很好的进行横向水平扩展(Scale Out)。它可以很好的突破单节点数据库服务器的 I/O 能力限制,解决数据库扩展性问题。
  • 对于正在交易中的数据,主要根据时间进行分表。如果分的更细,则可以分三个表,但是这样在事务保证方面则要复杂很多,不建议这样做。

这个问答是《程序员》杂志架构师接龙栏目的第一期的内容。提问者是我,回答者是腾讯研发总监王速瑜先生。其实我抛出问题后当时还真不知道接龙的是哪位,只是知道会是百度或是腾讯的朋友来回答,当然我也对这两家的数据处理方式都是比较感兴趣的。最后刊登的内容或许让很多人觉得不过瘾 — 如果能更详细一点就好了(毕竟还有其他问题呢)。不过能够引发思考就好,这也是这个栏目的初衷吧。

对这个问题或许可以补充的是,切分或许还算是容易的事情,但是切分后用户对数据的查询多少是有点麻烦。一旦要查询历史交易信息,则必须考虑跨多个数据分片获取数据并排序的问题。交易中的数据与交易完成的数据是否做切分,是有必要根据自己的实际情况仔细衡量。要注意如对交易中的活动数据单独存放的一个表中,则还是不可避免的要产生 I/O 热点问题,而且,这个表实际上变成了一个数据队列(新的瓶颈)–新生成的交易进来,完成的交易删除或归档。这样产生的双重 I/O 压力不容忽视。

当然,这个问题的前提限制了回答的发挥,其实在设计初期也可以考虑买家信息与卖家信息分别放入不同的表中,然后对这两种属性的表再进行切分,这也是可选的途径,这样的开销是每笔交易会重复存储一条记录,而记录的变化也要在两个表中更新。对数据的一致性维护有一定的挑战。这似乎是个只带来额外开销的办法?其实也有益处–索引的设计起码会更简单一些,而用户对交易记录的定制查询也会更加方便。

数据分片(或 Sharding) 现在几乎是每个网站架构师都必须要考虑的基础问题。多数情况下,分片的粒度和方式取决于业务,慢慢地快变成可意会不可言说的话题了,你有什么建议或意见不妨留言说说。

EOF

为了避免误导,对于数据量不大的站点,首选如何利用好 Cache 吧,分片只是手段,不是目的。

OpenDNS 的统计(Stats)服务的实现

对国内互联网用户来说,OpenDNS.com 这个服务在技术圈子里还是有些知名度的,当然这要归功于国内电信服务商对域名的无耻劫持行为。

OpenDNS 的员工 Richard Crowley 在 Velocity 2009 上和与会者分享了关于 OpenDNS Stats 服务的实现。当时的数据是每天有 140 亿次的 DNS 查询,而现在从公开的数据看,每天已经超过 180 亿次查询。这个 PPT 的内容就是讲 OpenDNS 是如何处理并统计这些查询记录的。

主要的策略分两步,第一步,根据网段切数据;第二步,聚合与存储。体现到 DB 层面是给每个网段单独分配一个表,尽可能的让表更小,让主键更小。

选择合适的方式存储域名。如果表使用 auto_increment 字段做主键是不太合适的做法–不同的引擎都有或多或少的锁问题,OpenDNS 采用域名的 SHA1 摘要值用来做域名的主键(SHA1 是20个字节,倒也不算浪费空间)。用了两台机器,每台 48GB 左右的存储空间,另外通过跨在 8 台机器上总共 28GB 的 Memcached 来避免对数据库的读操作。

对于聚合数据的进程会产生内存溢出的问题,采取的办法是清空内存,重启进程(而不是释放内存)的思路。利用了 supervise 这个小工具来做到。这地方其实值得商榷。

开始曾发现 80% 的 I/O 等待表的打开与关闭上。通过 Strace 发现存在大量的 open() 与 close() 调用。通过設置 ulimit -n 600000 解决(关于 ulimit 参数的意义参考。这意味着 OpenDNS 用了大约 60 万个表(网段)!(?) 这的确是比较极端的做法。

而在 DB 存储引擎的选择开始用了 MyISAM ,也是不合适的,通过迁移到 InnoDB 速度得到了很大提升。这似乎是缺乏评估与规划的表现,或许 OpenDNS 在这方面并非十分擅长。

OpenDNS.jpg
(Copyright by Richard Crowley )

上图从右向左看,查询日志通过 rsync 同步到 Stage 1 的服务器上(位于旧金山),根据查询到的域名把查询日志映射为中间文件,然后把数据文件同步到 Stage 2 的服务器,启动聚合进程把中间文件读入,修剪(Pruning)进程把拼装好的 SQL 语句写入 DB。整个步骤其实暗合 MapReduce 的思路。虽然不是严格的 MapReduce 实现。

听说国内提供类似服务的 DNSPod 因为上次的暴风长老事件受到了广泛瞩目,前不久成立了公司旨在专门提供智能 DNS 服务。不知道每天查询量有多大。[Updated: 见楼下 DNSPod 站长的回复 “DNSPod请求数每天20来个亿” ]

EOF

几句题外话:因为逐渐远离一线技术环境,为保持对技术的兴趣,每天多读一些 PPT 也是有乐趣的事情,或许一年没有敲多少条命令,但是看的 PPT 恐怕没有几个人比我多。看到一些还算有趣的 PPT 就做点笔记和大家分享。或许对人有用呢。

Updated:Google 开始提供 DNS 了。Google Public DNS

还可以参考一下这篇:OpenDNS MySQL abuses,另外,Richard Crowley 已经在2010 年2月份从 OpenDNS 离职…