站长网_站长创业_站长主页_站长之家_易采站长站

会员投稿 投稿指南 站长资讯通告: 安装Discuz X1.5网址后面带端口的解决方法
搜索:
您的位置: 主页 > 教程 > CMS > discuz > » 正文

Discuz!NT千万级数据量上的两驾马车 TokyoCabinet,MongoDB

来源: 易采站长站
特别是像主题表(topic),用户表(user)等,因为对于一个流量和发帖量都很大的论坛而言,在运行几年之后,这两个表的数据量可能会破千万(注:因为帖子表采用分表机制,所以这里暂未涉及,但出于性能考虑,也提供了本文中类似的解决方案)。当时考虑的架构设计中有两种思路来解决这种问题:
      一种是采用类似MYSPACE的方式,即按一定记录KEY值(比如用户表的UID)来对大数据表中的记录进行分割,比如前200万用户(即:UID<200w)放入一个表,200-400万的用户放入另一个表,以此类推。当然可以把几个表都放到一个数据库中,也可以放到别的MSSQL数据库上或实例上。但这种方案有一些问题,例如当用户表需要被联表(如LEFT JION)查询时使用,比如我们的帖子表进行分页查询时就需要左联user表,这时如采用分表或分布式布署就可能面临这样的问题,不仅业务逻辑要变化,就连存储过程中也要产生不小的变化,这里还不考虑效率上的问题。当然有人建议可以使用数据冗余的方式,比如在帖子表中冗余用户信息相应字段,但这种方案同样要大幅度的修改即有代码,同时如果用户信息发生变化时,不仅要更新用户表,还要更新帖子表中的相应冗余字段,如果这两者不同步,就会造成数据显示异常,当然在数据库层面增加存储成本也是不得不付出的。
      第二种就是使用能处理大数据量表格的第三方工具,比如本文所说的TokyoTyrant,Mongodb等,这类NOSQL软件从一问世就是面向海量数据存储访问的,而且这类软件往往都是开源的,另外通过与打算布署企业版的用户接触,发现虽然他们的服务器配置很高,但数量即不多,所以就要考虑如何最大限度的复用已有的机器资源,而这类NOSQL软件往往都是‘性价比’很高的,即用不多的资源(内存,CPU等)就能达到意想不到的效果。当然我目前对其还是很谨慎的使用,即不会马上把它当做主力数据存储工具,而是辅助MSSQL数据库工具,所以大家在看完本文后会发现,这两个工具在企业版中的角色顶多就是一个高级的MEMCACEHD。不过我的想法很简单,就是任何工具和技术,如果不是很了解它或者它很新,那么必定要有一个“考核期”,如果在‘任间’内它通过考核,才委以重任,如未通过考核,也不会让系统平台承担过多的技术层面上的‘风险’。

     综上所述,最终我把方向放到了TokyoTyrant,Mongodb上,之所以选择了这两个工具,主要基于下面因素:
   
    1.海量数据的解决方案应该可以跑在LINUX和WINDOW平台上。当然有人会说Mongodb完全可以跑这两个平台,那还为什么要引入TokyoTyrant呢?其实这里有一些产品的特殊情况要考虑,比如我们的用户中绝大多数对于数据的读写比在 4:1,即5条SQL访问中有4条是SELECT操作,1条是CUD操作,这就造成了读写比例的失衡。虽然Mongodb在读写性能上非常优异和稳定,但在并发读上相对于TokyoTyrant+cabinet还是有一些差距(注:更多内容参见该链接,然后这只限于在我们产品中压力测试环境下的结果,不具备普遍性,所以希望大家具体问题具体分析)

Tags:
最新图文资讯
1 2 3 4 5 6
相关文章列表:
易采站长站 - 联系我们 - 广告服务 - 友情链接 - 网站地图 - 版权声明 - 人才招聘 - 帮助 -