InfoQ 数据库架构采访文字修正稿

InfoQ 对我的采访发布后,我看到已经有网站在转载文字稿。其实口头的东西转换到文字,自己的话难免有些辞不达意的地方,征求 InfoQ 泰稳的意见后,我在这里就部分问答作一下修正,以免误导。

以下是正文:

InfoQ中文站: 作为一名资深的 DBA,大辉却在自己的 BLOG 上边写了不少关于网站架构这方面的一些文章,能不能谈谈 DBA 跟网站架构这方面的关系呢?

Fenng: 好多朋友和我开玩笑,说我做一个DBA,却总去写一些架构相关的东西,”是不是这个厨子不看菜谱,看兵法了?” 其实这二者之间我觉得是有些关系的。像数据库的维护,甚至设计、架构相关的工作,做到一定程度上还是要向前再走几步:也就是说要把我们架构相关的一些事情融合进来。当然作为一个 DBA 没必要一定要像我们的相关架构师这样,去做一些编码之类的实际工作,不过一些和 DB 结合的比较紧密的东西是一定要关注一下的,这也是我在 BLOG 上写了不少与架构相关文章的一个主要原因。

InfoQ中文站: 一般来说要提升网站的性能,瓶颈主要都有哪些,如果要解决这些瓶颈,又都存在哪些最佳实践呢?

Fenng: 在以前,可能瓶颈多数会在数据库上,也即最后瓶颈会落在 IO 上面。但是现在随着一些 Web2.0 发展而涌现出相关的技术解决方案,当前一个网站真正能否应付大流量、高并发,主要的问题还在于 Cache 能够充分、灵活、正确使用上,这点十分重要。【补充,因为这个整个话题基本是面向 Web 2.0 方面的,所以这里说 Cache 会是主要问题,如你所知,电子商务站点的话,事务处理能力无疑是比较棘手的事情】

InfoQ中文站: 一个要经受住大规模、高并发、访问量考验的成功 Web2.0 网站在设计的架构中要注意哪些东西呢?

Fenng: 这个在前期的规划中肯定是需要做一些预防性的措施,比如说选择适合的技术架构。这是第一步应该必须要考虑的事情。另外还有在产品设计上也会有很多需要注意的地方,现在我们的很多 Web 2.0 网站,包括国内的这些新兴的一些 Web 2.0 网站,多多少少存在一些过度设计的现象。这些设计不经意之间可能会对后台带来灾难性的影响,这就会对开发人员、架构师,甚至维护人员都带来很大的压力。

另一方面呢,参考当前业界上一些已经相对比较成熟的技术 DIY 搭建架构还是很关键的。我们做一个网站就好比造汽车一样,不一定非要造得像奔驰这样顶级豪华的(那成本会非常高),我们只需造一辆能跑起来,跑得很好的汽车,这可能就已经达到成功的一半了。

InfoQ中文站: 那刚才在网站性能和调优这方面,你刚才也提到了,缓存的作用是非常重要的,那么它到底处于怎么样一个重要的地位呢?如何对缓存进行优化从而提升性能?

Fenng: 就我以前的相关经验,基于 Oracle 环境的一些实践,一方面是在应用程序高并发的设计上有一些必须注意的事项,另外一个就是能否充分利用 Oracle 自己的内存,最后实质上看其是能否充分利用自己的 Cache 机制。对于 Web 2.0 网站,可能很少有使用 Oracle 数据库(多是 MySQL),但在MySQL上,一方面 MySQL 有自己的 Cache 机制,应该说还做得不错,再一个,绝大多数网站都会考虑使用像 Memcached 这样的外部组件进来,然后在这个地方,其实我们最后考量的是命中率,衡量命中率的高低,这是大家必须要注意的扩展性、性能指标。

命中丢失的 I/O 实际上最后压到我们的数据库上,到数据库的 I/O 命中再丢失有可能会压到最下面的磁盘上,这样磁盘【或存储】一定要能支撑住我们当前的最低需求。举个最简单的例子,我们的应用 Memcached,可能前面的 I/O 命中率是 80%,那么有剩下的 20% 会压到后面的 DB 上,这个 DB 的命中率有可能达到95%,剩下的5%,乘以前面那个 20%,总体 I/O 量 x 20% x 5%,这个 I/O 量会打到最后端的硬盘【或存储】上。而硬盘【乃至存储】的整体响应能力又是有限的…我们或许是做 RAID,也甚至可能出现单块硬盘支撑应用这样的情况。从这个基础往前推,就能计算出我们当前的系统能承载 Cache 的瓶颈,进一步知道整体 I/O 的处理能力。在设计的时候,一定要考虑到这样的情况,否则当压力突然增加到我们不能承受的时候,临时做一些扩展的手段,可能就会比较麻烦。

InfoQ中文站: 你刚才说到Cache命中率,那对于一个比较成功的这种网站,它Cache命中率一般会在多少呢?

拿 Oracle 来说,它本身的命中率做到 90% 甚至是 99.99 这样的情况,在MySQL的环境下可能做不到这样, Memcached 据我所知,可能70%~80%已经不错了【不同的应用表现差异很大,比如豆瓣的朋友告诉我他们命中率是 97% ! 】。当然命中率只是一个表面的现象,我们还要看实际真正的应用程序到底是怎样,可能不同的 Web 应用类型所能承载的访问频率也不大一样,所以并没有固定的比例,这里只能是凭一些经验。总体来说肯定是命中率越高,会越好一些。

第一部分先到这里。明天有时间修正剩下的部分。

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

Leave a Reply

Your email address will not be published. Required fields are marked *