最近在做一些调研工作，查看了BigTable以及Hadoop的一些资料，并且结合自身需要开发的项目，得出了一些领悟，可能并不是对的，但是自认为还是有一定道理，先在此记录下来，稍后逐条论证。在此我仅假设我们构造的是普通的Web应用，类似论坛系统这样的东西，其实很多系统都可以往这个方向靠，可以认为他们是类似的。那么这样的系统我们未来主要考虑如何能承载更多的用户访问，如何能做到可扩展和稳定以及分布式、异步数据同步等细节。ok，在这个前置条件下，我觉得：
改变原有的数据操作思路，数据根据特性来划分，放弃关系型数据库。数据可以分成下面的类型
1、 一次创建，后续只读，更新会写入新的版本，旧版本删除（key,data,timestamp）
帖子、附件或贴图、用户信息、用户访问日志数据
2、 创建后数据会频繁被更改，写操作针对单条记录做事务性操作（锁机制）
主题信息（回帖数，最后回帖时间等）、论坛版块信息（主题数等）
3、 需要保证唯一的数据单元（锁机制，分布式后的唯一性）
主题编号，帖子编号等
第一类数据使用基本的数据同步机制，根据时间戳进行增量同步就可以保证数据一致。被同步节点只是会存在数据延迟，中间丢失数据可以使用脚本检查完整性。
第二类数据原则性统一存储不做分布处理，为了提高每个节点的响应，可以使用树形结构部署，中心节点负责核心数据写操作，镜像数据同步至节点并设定只读。
也可以将数据写操作分布在不同接点，但只记录对数据的操作范围（加xx，减xx），数据基础通过中心接点定期汇总下放各个节点，节点收到更新数据基础后更新，用户便可以查询到相对实时的数据了。
其实可以将此类数据更加细分，一般数据没有这么高的准确要求，例如总帖子数据、帖子访问数等，此类数据通过第二种方法分别在每个节点读写，中心只是负责汇总数据将系统总数据下放至各个节点。目前只有类似积分这样可以添加或消费，并且有并发可能的、需要处理事务的数据，才需要严格的处理，此类数据很少，足可以将其集中管理，在中心节点出现问题时，停止消费操作（扣减操作），对于增加的操作可以在每个节点记录日志，待中心节点恢复后再做异步处理。
第三类数据分显性和隐形数据，显性是指要给用户查看的，并且用户参与指定的（例如用户账号名），此类数据只确定一次后期只有读操作，因此绝对集中存放，集中申请。隐形的数据类似帖子编号等，此类只是要保证系统内唯一，但是是什么值对于用户来讲无所谓，因此此类数据可以根据每个节点的名字空间来区分，名字空间内使用程序自我保持不重复性。
也许上述内容是我特定工作环境下的问题，如果正巧你也在思考这些问题，欢迎与我联系讨论！
十一月 20th, 2008 at 02:24
不是很理解，不过可以提供新的思考方向，有时间我也看看