使用Mysql来搭建可扩展的SNS网站（浅谈）

近几年WEB2.0的火爆，带动了Mysql的使用热潮，不管是小企业还是大网站，都有意无意的开始使用Mysql来搭建新数据平台，传统网站随着业访问量，数据量的急剧膨胀，集中式的数据库也越来越成为瓶颈，很难做进一步的扩展，做读写分离，而这些都是Mysql的优势所在，容易扩展使Mysql渐渐成为了企业新的选择。
说到可扩展性，和APP一样，当数据库压力上来时，只要通过不断增加数据库服务器来解决，尽量不去调整应用程序，服务器硬件坏掉了，直接拿台新的服务器顶上就可以了，这是我设计的初衷。下面我会通过Mysql来浅谈SNS数据库的设计思路（注：只是我的理解），SNS关注的是个体（userid），比如我的好友，我的日志，我的相册，我的帮派等等，强调人的个体行为，现在很火的SNS网站如51.com，Facebook，Myspace都是通过Mysql来搭建的，接下来我将尝试探讨这种业务类型的设计轨迹，如何做到可扩展性。
先从如何分库开始，考虑按用户（userid）属性来分库，用户有好友，有博客，有相册等，只要是用户的行为，都跟着用户走，单库中包含了用户的所有行为，这种分法定位起来很容易，找到某个库后就找到了用户的所有行为，很方便。也可以按业务类型来分库，每个业务独立成库，分成好友库，博客库，相册库等，不同业务模块各自独立，这种分法思路很清晰，分库的规则可以不同业务灵活多变，开发起来也相对比较简单。
接下来讨论分表的设计，Mysql上设计数据库我力求做到小快灵的原则，单库数据量要比较小，数据库要做到快速响应，表设计要非常灵活，不同的业务可以选择相应的分表规则，小快灵的思想要求表设计很容易做水平扩展，数据量过大时很容易进行表拆分。从设计思路上来说，可以使用配置表（元数据）来存储分表的配置信息，假设今年的注册用户规划在2000万左右，考虑分成4张表，table1存储1-500万的数据，500万-1000万存储在table2，。。。每个表保留500万的数据，分表规则和查询路由通过配置表来维护，某天我们发现table1的数据量过于活跃，数据库压力很大，同样的开始考虑拆表，修改分表配置信息，同时把table1拆成两张表存到两台服务器来分担压力，当然也不一定说是访问压力才导致分表，当表的记录数大到一定的数量，同样也需要拆表。采用配置信息来维护分表的规则非常灵活，一切以配置信息为准，不过太灵活也意味这风险点很高，配置信息的重要性不言而喻。接下来我提到的是采用mod取模来分表，初期考虑采用mod(4)分成4张表，根据取模的结果0,1,2,3分成4张表，随着业务发展的带来数据量的膨胀，访问压力加大，需要对表作进一步拆分，因为取模带来的特殊性以及拆表尽量不做数据迁移的原则，我建议通过倍数来扩展，采用mod（8）来扩展表，接下来考虑使用mod(16)来拆分，不断的通过倍数来做扩展。相对于配置信息分表，取模设计相对来说并不是那么的灵活，不过灵活也不一定全是好事，万一配置信息被人误调整过，那就麻烦了。
经常看到很多表中没有主键，这对于严谨的系统设计来说，通常是不可接受的，大部分表会使用自增id来做主键，刚开始可能是单表，接下来可能拆成多张表，用auto incremental很难保证在多个表中保持唯一性，那如何保证分表（user_table1,user_table2,…）之间id的唯一性呢？考虑oracle使用序列来保证id的唯一性，序列是凌驾于表之上的，同样考虑在Mysql数据库中增加一张序列表，模拟oracle的序列实现方式，需要自增的表都可以在这里面添加一条记录，对于分表来说，每个子表调用的是同一条记录，应用程序直接调用这条记录来做自增，来保证id的唯一性。这仅仅是一种实现方式，如果只要求id的唯一性，可以使用函数来生成，也可以按照某种规则如时间精确到毫秒来保证id的唯一，方法太多了。
围绕可扩展性，简单提了一些分库，分表，id生成的设计思路，这仅仅是整个网站中的冰山一角，还有太多的细节上需要我们去思考，如基础数据表，仅仅几十条数据不做分表分库，当其他表拆成多个库时这些数据保存在哪儿，专门建个基础库还是每个库都保留一份呢，分表，到底分多少个合适，是用Myisam存储引擎还是用Innodb呢？这些都需要我们细细的思索，细节决定成败，关注每个细节，每个表的实现方式，尽量多参与到业务中去，多了解产品经理，开发的想法，多去了解Mysql的实现方式，Mysql自身的优势，Mysql可扩展性的优势，多了解业界成熟的设计思路，结合自身的业务模式，设计出更合理的系统。