Database 类别下的文章

2006 年度 Oracle 杂志编辑选择奖已经出来了。

Steven Feuerstein 是 "年度PL/SQL 开发者"。这位 PL/SQL Guru 还在琢磨如何和布什见个面

Jonathan Lewis 是 "年度 Oracle 作者",他的 Cost-Based Oracle Fundamentals 一书的确很见功力。Thomas Kyte 也有实力竞争这个奖,但 Tom 毕竟是 Oracle 公司的,多少也要避嫌一下--我猜的。

Eddie Awad 获得"年度 Oracle 相关 Blogger" 奖,我觉得这个大胡子写的其实也一般,谁让咱们不会用英文写 Blog 呢? 05 年的获得者是 Mark Rittman ,Blog 质量的确不错。

Tim Hall 获得 "年度 Oracle ACE"奖。Tim Hall 是 Oracle-Base 站长。他发表在 Oracle-Base 上的文章有一定的参考价值。到现在 我也不知道 Oracle 的 ACE 这三个字母都代表什么,A 是 advocates ? 总之, ACE 就是那些在 Oracle 技术圈子比较活跃的人,有些 Guru 级的人入选,也有些技术功底并非那么深厚但是在社区非常活跃的人入选。中国大陆似乎还没有 ACE。

Regent Roberge 获得 "年度DBA 奖"。对他的事迹不了解。

另外 还有个 "年度开源开发者" 被 Internet Archive 公司的 Gordon Mohr 得到,Oracle 杂志编辑选择奖本来和开源八杆子打不着,看来是收购 Sleepycat 之后专门为拉拢 Berkeley DB 开发社群而建的。

其它的得奖名目还有什么"年度 CIO" 之类的,没准是 Oracle 的关系客户。

--EOF--

Craigslist 的数据库架构

(插播一则新闻:竞拍这本《Don’t Make Me Think》,我出价 RMB 85,留言的不算--不会有恶意竞拍的吧? 要 Ping 过去才可以,失败一次,再来)

Craigslist 绝对是互联网的一个传奇公司。根据以前的一则报道:

每月超过 1000 万人使用该站服务,月浏览量超过 30 亿次,(Craigslist每月新增的帖子近 10 亿条??)网站的网页数量在以每年近百倍的速度增长。Craigslist 至今却只有 18 名员工(现在可能会多一些了)。

Tim O'reilly 采访了 Craigslist 的 Eric Scheide ,于是通过这篇 Database War Stories #5: craigslist 我们能了解一下 Craigslist 的数据库架构以及数据量信息。

数据库软件使用 MySQL 。为充分发挥 MySQL 的能力,数据库都使用 64 位 Linux 服务器, 14 块 本地磁盘(72*14=1T ?), 16G 内存。

不同的服务使用不同方式的数据库集群。

论坛

1 主(master) 1 从(slave)。Slave 大多用于备份. myIsam 表. 索引达到 17G。最大的表接近 4200 万行。

分类信息

1 主 12 从。 Slave 各有个的用途. 当前数据包括索引有 114 G , 最大表有 5600 万行(该表数据会定期归档)。 使用 myIsam。分类信息量有多大? "Craigslist每月新增的帖子近 10 亿条",这句话似乎似乎有些夸张,Eric Scheide 说昨日就超过 330000 条数据,如果这样估计的话,每个月的新帖子信息大约在 1 亿多一些。

归档数据库

1 主 1 从. 放置所有超过 3 个月的帖子。与分类信息库结构相似但是更大, 数据有 238G, 最大表有 9600 万行。大量使用 Merge 表,便于管理。

搜索数据库

4 个 集群用了 16 台服务器。活动的帖子根据 地区/种类划分,并使用 myIsam 全文索引,每个只包含一个子集数据。该索引方案目前还能撑住,未来几年恐怕就不成了。

Authdb

1 主 1 从,很小。

目前 Craigslist 在 Alexa 上的排名是 30,上面的数据只是反映采访当时(April 28, 2006)的情况,毕竟,Craigslist 数据量还在每年 200% 的速度增长。

Craigslist 采用的数据解决方案从软硬件上来看还是低成本的。优秀的 MySQL 数据库管理员对于 Web 2.0 项目是一个关键因素。

--EOF--

这两天我在尝试选择一个 CMS 系统,看过了网上的不少文章,在 CMS Matrix 站点上做了 N 次的对比表之后,决定采用 Joomla!。安装的时候,着实费了一点时间。

Joomla! 的官方安装文档倒是图文并茂的,但是还有些简略。第二步的时候,需要输入数据库的信息,主机名字,用户名,密码,还有数据库名字,可是总无情的弹出一个窗口告诉我 "Password and username incorrect..."。在终端命令行下,通过这些信息是可以登陆的。

RHEL 3 自带的 MySQL 版本比较低(3.23.58),启动比较麻烦,干脆跑到 MySQL 官方站点下载了一个 5.0 的稳定版本来用。

难道是版本太高带来的问题么 ?

尝试搜索了一下,原来是老问题

A.2.3. Client does not support authentication protocol MySQL 4.1 and up uses an authentication protocol based on a password hashing algorithm that is incompatible with that used by older clients. If you upgrade the server to 4.1, attempts to connect to it with an older client may fail with the following message:

按照该帖子提示的用 OLD_PASSWORD() 重新设置了一下指定用户的密码,安装可以继续下去了。

登录到后台,测试了几篇帖子,发现 Joomla! 对中文的支持超出我的期待。

--EOF--

eBay 的数据量

作为电子商务领头羊的 eBay 公司,数据量究竟有多大? 很多朋友可能都会对这个很感兴趣。在这一篇
Web 2.0: How High-Volume eBay Manages Its Storage(从+1 GB/1 min得到的线索) 报道中,eBay 的存储主管 Paul Strong 对数据量做了一些介绍,管中窥豹,这些数据也给我们一个参考。

站点处理能力

  • 平均每天的 PV 超过 10 亿 ;
  • 每秒钟交易大约 1700 美元的商品 ;
  • 每分钟卖出一辆车A ;
  • 每秒钟卖出一件汽车饰品或者配件 ;
  • 每两分钟卖出一件钻石首饰 ;
  • 6 亿商品,2 亿多注册用户; 超过 130 万人把在 eBay 上做生意看作是生活的一部分。

在这样高的压力下,可靠性达到了 99.94%,也就是说每年 5 个小时多一点的服务不可用。从业界消息来看,核心业务的可用性要比这个高。

数据存储工程组控制着 eBay 的 2PB (1Petabyte=1000Terabytes) 可用空间。这是一个什么概念,对比一下 Google 的存储就知道了。每周就要分配 10T 数据出去,稍微算一下,一分钟大约使用 1G 的数据空间。

计算能力

eBay 使用一套传统的网格计算系统。该系统的一些特征数据:
  • 170 台 Win2000/Win2003 服务器;
  • 170 台 Linux (RHES3) 服务器;
  • 三个 Solaris 服务器: 为 QA 构建与部署 eBay.com; 编译优化 Java / C++ 以及其他 Web 元素 ;
  • Build 整个站点的时间:过去是 10 个小时,现在是 30 分钟;
  • 在过去的2年半, 有 200 万次 Build,很可怕的数字。

存储硬件

每个供货商都必须通过严格的测试才有被选中的可能,这些厂家或产品如下:
  • 交换机: Brocade
  • 网管软件:IBM Tivoli
  • NAS: Netapp (占总数据量的 5%,2P*0.05, 大约 100 T)
  • 阵列存储:HDS (95%,这一份投资可不小,HDS 不便宜, EMC 在 eBay 是出局者) 负载均衡与 Failover: Resonate ;


搜索功能: Thunderstone indexing system ;
数据库软件:Oracle 。大多数 DB 都有 4 份拷贝。数据库使用的服务器 Sun E10000。另外据我所知, eBay 购买了 Quest SharePlex 全球 Licence 用于数据复制.

应用服务器


应用服务器有哪些特点呢?
  • 使用单一的两层架构(这一点有点疑问,看来是自己写的应用服务器)

  • 330 万行的 C++ ISAPI DLL (二进制文件有 150M)

  • 数百名工程师进行开发

  • 每个类的方法已经接近编译器的限制

非常有意思,根据eWeek 的该篇文档,昨天还有上面这段划掉的内容,今天上去发现已经修改了:

架构

  • 高分布式
  • 拍卖站点是基于 Java 的,搜索的架构是用 C++ 写的
  • 数百名工程师进行开发,所有的工作都在同样的代码环境下进行

可能是被采访者看到 eWeek 这篇报道,联系了采访者进行了更正。我还有点奇怪原来"两层"架构的说法。

其他信息

  • 集中化存储应用程序日志;
  • 全局计费:实时的与第三方应用集成(就是eBay 自己的 PayPal 吧?)
  • 业务事件流:使用统一的高效可靠消息队列. 并且使用 Cookie-cutter 模式用于优化用户体验(这似乎是大型电子商务站点普遍使用的用于提高用户体验的手法)。

后记

零散作了一点流水帐。作为一个 DBA, 或许有一天也有机会面对这样的数据量。到那一天,再回头看这一篇电子垃圾。

更新:更详细信息请参考:Web 2.0: How High-Volume eBay Manages Its Storage。可能处于 Cache 的问题,好几个人看到的原文内容有差异

--EOF--

Oracle 的 Unbreakable Linux

Uploaded by Fenng(Refer).


Larry Ellison 在 Oracle Open World 大会上宣布提供企业级别的 Linux 支持服务,"Unbreakable Linux" ,在 Oracle 公司公布的新闻稿上这么写着:

Oracle starts with Red Hat Linux, removes Red Hat trademarks, and then adds Linux bug fixes.

Currently, Red Hat only provides bug fixes for the latest version of its software. This often requires customers to upgrade to a new version of Linux software to get a bug fixed. Oracle's new Unbreakable Linux program will provide bug fixes to future, current, and back releases of Linux. In other words, Oracle will provide the same level of enterprise support for Linux as is available for other operating systems.

也就是说,Oracle 在 Red Hat 的 RHN 之外提供一个同样性质的服务,价格更低($99 per system per year)。红帽子公司会怎么想? 这不摆明了坑人么... 自从 Red Hat 收购 Jboss 之后, Oracle 对红帽子的觊觎之心路人皆知。Oracle 的这个计划 FUD 的意味很浓,似乎就是要给红帽子公司压力,打击客户对 Red Hat 的信心,进而找机会收购它。

另外,Oracle "Unbreakable Linux" 的迁移战略也将展开,据说要协助客户从 "AIX、Solaris、HP/UX、Windows、遗留主机 或者 TRU64" 迁移到 Linux 上来,这是一个非常得罪人的活,不知道 Oracle 的目的何在。颇有讽刺意味的是,HP、IBM 居然加入了这个项目。

我个人的看法:

1) 这件事情对开源软件业界没什么积极的影响;
2) Oracle 提供的这个服务质量好不到什么地方去, 看看他们数据库服务器的一堆一堆的 Patch 就知道了;
3) Oracle 可能不会对 Novell 的 SuSE 下手

题外话,我觉得 Oracle 在进行连番收购之后,居然财务报表仍然那么好看,似乎耐人寻味。

--EOF--

现在是广告时间。

电子工业出版社博文视点资讯有限公司诚征《Database In Depth》一书的技术审校(兼职)。

《Database In Depth》一书基本信息:
此书是出版名社 O'Reilly 的力作,Amazon 四星级图书,Software Development Magazine 和 UnixReview 鼎力推荐!
1) 官方网站链接:
《Database In Depth》在O'Reilly
《Database In Depth》在 Amazon
2) 作者:C.J. Date [Fenng 注:C.J. Data 的著作都不错]
3) 出版社:O'Reilly
4) 页数:228 页

基本要求如下:
1) 有高度的责任心,重承诺,守合约;
2) 熟悉关系数据库理论,技术把握力强;
3) 有较强的英语和中文功底,翻译用词精准,语句通顺易懂;
4) 时间相对较为充裕。

技术审校的工作职责如下:
1) 对译稿进行技术审校,以保证书稿翻译质量;
2) 对照原书,修正译稿中翻译错误和翻译不妥的地方;
3) 对不符合阅读和思考习惯以及不通顺的译文进行修润;
4) 对译文所作的修订内容作记录(博文视点会提供“修订记录”模板)
5) 书出版后,技术审校可在封面署名

应征者敬请联系:
邮件:xiaofei#broadview.com.cn (王晓菲) 把#换成@
电话:027-87690813转83(王晓菲)

博文找到了我,如果是三年前,我可能就接手了(虽然肯定有难度), 可惜现在我自己比较忙,也比较懒。

有兴趣的朋友可以直接通过上面的信息联系。别忘了最后送我一本样书 :)

--EOF--

DBA 的冷幽默

有人在邮件列表里提问,系统表空间文件丢了,没有归档,如何恢复?

来自技术专家 Tim Gorman 的回答:

It's kind of like voting for president in North Korea. Only one choice -- under any circumstances -- when in NOARCHIVELOG mode: full database restore from cold backup. There are no options for partial recovery or any recovery at all. NOARCHIVELOG mode = full database restore, no recovery, period. This scenario is no exception.

--EOF--

高效能 DBA 的七个习惯

邮件列表中有人推荐了 DMReview 的一篇文章 Seven Habits of Highly Effective DBAs, "高效 DBA 的七个习惯", 这个题目应该是受了 《高效能人士的七个习惯》一书的启发。虽然颇有拾人牙慧之嫌,还是记录一下吧,就算是自己的学习笔记。"如人饮水,冷暖自知"

在开篇有一个关于什么是个"高效能 DBA" 的定义, 作者指的高效并不是说 DBA 每天都在忙于救火的那种"高效",而是能够防患于未然.

1. 专业的多面手(Be an expert generalist)
熟知存储、操作系统等领域的知识, 跨平台数据库的技术也是必须要掌握的,不能离开了 Windows 环境到了 Unix 下什么都作不了. 看上去这一点似乎有些苛求,不过个人认为通过持续的学习能力加上良好的知识积累方法会让你无限接近这种能力.

2. 理解来自商业、用户的需求(Understand the business and user expectations).
如何把掌握的数据库知识应用到商业需求上,还不给用户一种“木匠拎着锤子,看什么都是钉子" 的感觉是需要一点艺术的。

3. 通过可量化的度量构建更加正规的服务级别协议(
Build more granular service level agreements (SLAs) via quantitative and easy-to-understand metrics)
用户(或你的老板)对你的数据库管理工作是否满意,总要有一个可以达成一致的地方,这个一致应该来自"服务级别协议". 服务级别协议是很多 DBA 最容易忽略的一个地方。


4. 把环境分割为更小更易于管理的组成部分(Break down the environment into smaller, more manageable pieces)
一揽子计划不是个好主意,分而治之。这样也容易与委托方达成一致。

5. 关注于任务,而不是实现的细节(Be task-focused, not necessarily on how to accomplish it)
这一点应该是说于开发人员的关系的。DBA 不应该去关注太多程序设计的细节,而应该把注意力集中任务实现上--有效的与数据库交互. (这一点说起来似乎有些勉强,或许站在高效 DBA 的角度上就容易理解了,呵)

6. 隔离并委派普通任务(Segregate and delegate the mundane).
如果从一个技术领导者的角度上说,这是必须的。既然是高效DBA ,那么在没必要事必躬亲拘泥于一些琐碎的事情. 否则再高效也不成.

7. 淘汰特定环境下才可以用的那些玩意儿(Weed out the one-trick ponies)
特定的第三方工具、GUI 工具等只会使得整个环境更为复杂。一个高效的 DBA 应该致力于整个环境的简化与标准化。

说的是 DBA ,其实放到其他工种上也是蛮适合的。

从卓越到优秀,还是从普通到平庸,这是个问题.

--EOF--

关于归档

本页包含 Database 类别下的所有文章.

上一类别为 Arch.

Geek 为下一类别.

回到 首页 查看最近发表的文章或者查看所有 归档文章.