文章归档友情连接照片地图

WordpressMU分布式数据库插件Multi-DB教程

分类:wordpress  作者:rming  时间:2010-12-14
本文原发传奇博客 CN.am ,未经允许不得转载。

http://wordpress.cn.am/2009/01/wordpress-mu-multi-db/

Wordpress MU的安装行为和Lyceum不同,默认安装条件下它为每个用户建立8个数据表,这样的好处是结构相对清晰,各个用户的数据可以方便地分别进行管理。但是它无法便捷地实现全站的索引与检索,同时最大的弊病在于这样的结构在可扩展性上存在缺陷。一旦用户数量达到数千人,wp数据库内将存在数万张表,这给管理与备份带来很大的不便,而单库的数据表总存在物理极限,因此必须切分数据库。

Wordpress.com 的用户数在写本文的时候达到了5,164,192,他们使用了多个数据中心同时建立了自己的负载均衡手段。这方面的细节将专文论述,本文主要讨论数据库结构的规划。他们开发了HyperDB 来划分数据库,具体有大致三种功能实现:

Partitioning,数据在不同层级上的迁移。
Replication,主/从数据库的读写规则,Master写,Slave只读不写,这是典型的负载均衡手段。
Failover,故障转移机制。

HyperDB的下载地址是:
http://svn.wp-plugins.org/hyperdb/trunk/

以上是背景知识介绍,我们主要论述在现实中广泛使用的Multi-DB。WPMUDEV的人在这个思路与成果的基础上开发了简化版的Multi-DB:
http://premium.wpmudev.org/project/multi-db

这个插件允许我们建立16/256/4096个数据库,用户建立时数据会被散列纳入相应的数据库中,这样就实现了用户数量级的跃升。譬如原先我们的心理接受极限是在单库数万张表,几千用户,那么使用multi-db之后承载能力,形式上地,就获得了×16、×256、×4096的倍率。当然我们知道其实这不是简单的乘数效应,因为系统的短板会在不同时期出现在不同的环节,比如blogs.dir的文件数理论极限,比如单一WEB服务器不做负载均衡时单机的负载能力上限,比如静态文件请求产生的资源消耗等等。但是,通过这个插件,我们就可以轻松跨越单数据库海量表单对站长心理上的考验。这取决于你对自身站点规划的需要。一个小型的团队博客无需计较这个问题,但是比如我早前运行的 blog.cn.com,注册数字每一天都是在往骆驼背上加草,这也是为什么在2008年中期关闭注册的原因。
现在你看到的 CN.am及其绑定的站群,是建立在4096+2的定制上的。为什么要+2?因为我们倾向于把重要博客的数据单列以方便管理,同时对于博客的插件系统,有时需要一个global的数据库进行设置。此外,对于有特殊需求的用户,从数据稳定性考虑也可以为他们单独建库。因为不同的数据库可以存在于不同的数据中心,这一切都是可设置的。

以下介绍安装过程,我们的平台是CentOS,管理工具使用PHPMyAdmin。

1,首先使用工具构造建立数据库的代码:
http://db-tools.wpmudev.org/db_sql.php

推荐使用256库设置,因为16库不会带来本质上承载能力的提升,而4096仅限于中型以上的规划。
你获得的代码是:
CREATE DATABASE `wp_00` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

CREATE DATABASE `wp_ff` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
wp_00~wp_ff就是数据库的标号,你可以使用root身份在PhpMyAdmin里运行并创建。

2,建立用户赋予wildcard的数据库使用权限:
你需要对应地建立用户,然后为该用户赋权,确保它可以使用上述数据库。这是PhpMyAdmin的基本操作。

3,使用工具完善db-config.php:
http://db-tools.wpmudev.org/db_servers.php
你获得的代码类似于:
add_db_server(’00′, ‘dc1′, 1, 1,’38.×.×.×’,'localhost’, ‘wp_00′, ‘admin’,  ‘password’);

add_db_server(’ff’, ‘dc1′, 1, 1,’38.×.×.×’,'localhost’, ‘wp_00′, ‘admin’,  ‘password’);
然后完善这个到db-config.php文件。另外它需要数据中心的IP(DC IPs)那里只需要填写前三位IP位址,还要声明计划的数据库数目。
之后的安装每个人方法不同,我讲我的处理。现在需要单独建立一个global的数据库,一个home库。因为我需要一个单独的global库给插件,同时一个独立的库给主博客。然后也要记得给那个user赋权,注意数据库命名的规则与前面的数据库阵列统一。然后令add_global_table(’global’);这句可用,这里的global是你的那个总库名称。
我们先不上传插件,仅使用global库默认安装MU,这是基本操作。
然后上传插件,填写好db-config.php的每一个环节,这里可能容易出错,但是调试几次就好。需要声明建库总数,是否设定global,主要的是那个数据库阵列的配置。还有下面的add_vip_blog(1, ‘home’); 也就是声明主博客单独使用的数据库。

4,手动将主博客的8个表迁移到home数据库。完工!
数据库的scale一定要从长计议,在一开始就认真规划。一旦完成了配置,今后注册的新用户都会被散列到各自的合适位置。对应关系服从hash的计算:
http://cn.am/wp-content/scripts/list-hashes.php
所以第2个用户的数据库标号是c8,第100个ID的数据库标号是f8,以此类推,在需要修改他们的时候可以分别进行整理。

完工后的数据库非常整洁,很有逻辑性,符合数据库洁癖人士的喜好。因为总库和主博客的home库都是很清爽的。当然这最主要的目的就是实现用户负载数目的跃升。假定10000个注册用户,散列到256个数据库,每个数据库不到40人,管理起来很容易。如果按照单库接近1000注册用户的情况,使用4096个数据库,那就是超过400万用户,当然,我们都不会面对那样的托管情况:-)


  1. 没必要吧~~~ :-|

    1. pser pser

      @Micheal, :evil: 不是一般的有必要。。。你做大了试试啊,数据库能慢的要死 :arrow:

      1. @pser, 我做大了,就会自己做优化,Squid+ Nginx+Memcached,再来个分库分表。分布式的,是超大数据用的。

        1. @Micheal, …… :arrow:

提交评论