在Discuz!NT的企业版设计过程中，处理大数据表一直是一个让人头疼的问题，特别是像主题表 （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还是 有一些差距（注:更多内容参见该链接，然后这只限于在我们产品中压力测试环境下的结果，不具备普遍 性，所以希望大家具体问题具体分析）
2.考虑到有些用户公司是有相应技术储备的，两种方案也便于用户公司进行的技术选型（当然因为采 用接口方式，用户完全可以引入其它第三方的NOSQL工具来实现）。
好了，说了这么多，开始今天的正文吧。
前面说过，该方案使用了接口方式，这里就先看一下相应的接口声明：
