错误信息

Deprecated function: The each() function is deprecated. This message will be suppressed on further calls 在 menu_set_active_trail() (行 2405/data/itxueku/includes/menu.inc).

用Drupal多站点架构来解决Drupal存储的性能问题

浏览:319

   众所周知,drupal的核心部分是node,也是数据库性能的关键之处,随着内容的不断增长,node数据集就会变得较为庞大,尤其是当Drupal包含多种内容类型,也就是多种nodetype,Node的存储问题就变得尤为严重(Drupal6和Drupal7基本差不多,随着网站的数据增长,都会遇到类似的问题)。同时,有些模块,也会以把一些其他内容扩展到node的存储中,如content_profile, 把profile存储到node中,taxonomy_node把一个term也存储到node中,等等。


这样的结果就是node数据会不断的增长,变得巨大而不易维护和管理,数据存储的性能问题会逐渐成为整个网站的瓶颈。



我们的架构是把每一种类型的node单独存储,这样,与把所有node都存储在一个中心的情况相比,存储的压力会大大减小,从而提高网站的水平扩展性,解决了单站点的Drupal性能问题。


之前,我们建议过不要用content_profile等模块,假如我们有1万用户,如果一个用户有5个profile,那么就会给node表增加5万条数据,如果我们是一个以用户为中心的网站,那么用户的profile就会很大(并且content_profile的查询效率比较低,至少需要关联3个表的查询)。如果我们把每种nodetype单独存储,那content_profile也算是一种node类型,也很好的解决了content_profile模块的使用问题。


我们首先把用户独立出来,做一个user站点。这个站点可以使用content_profile,可以把所有的用户信息都存储在node中。
接下来,我们可以把所有数据较大的node类型分开到不同站点中,比如story站,比如page站,这些站点通过drupal的multiple站点的架构共享user站的用户信息,如user表,role表等(这个参考资料比较多,请查阅相关信息)。
这样架构可以水平扩展,整个站群的模块可以共享,当然这样也会有其他问题,比如跨站的数据访问,views的使用等等。
不过单个站点使用views还是没有问题的,如果要多个内容类型相互引用,这样最好把这两个node类型放在同一个站点中。


对于用户的profile信息的访问,可以写一个跨站的content_profile_load函数即可。当然现实的开发中,肯定会有一些小问题,跟独立drupal站点的开发略有不同,但是总的来说,对于大型网站来说,毫无疑问是利大于弊。


最后说一下apachesolr的索引问题,每个Drupal站点可以建立一个独立的solr实例,这样比只有一个索引节点要好很多,每一种内容都会独立被索引起来(包括user),对索引和查询以及solr服务器的管理也比较方便。
最终的架构结构示意图如下所示。


Drupal多站点结构


 


Drupal架构其他文章请参考:



  • 漫谈企业级Drupal架构应用与部署




  • Apache Solr 快速启动包以及中文分词集成



top