近几年web2.0的火爆，带动了Mysql的使用热潮，不管是小企业还是大网站，都有意无意的开始使用Mysql来搭建数据平台。传统网站随着业访问量，数据量的急剧膨胀，集中式的数据库也越来越成为瓶颈，很难做进一步的扩展，做读写分离，而这些都是Mysql的优势所在，容易扩展使Mysql渐渐成为了企业新的选择。

     说到可扩展性，和app一样，当数据库压力上来时，只要通过不断增加数据库服务器来解决，尽量不去调整应用程序，服务器硬件坏掉了，直接拿台新的服务器顶上就可以了，这是我们设计的初衷，也是我们使用Mysql的动力所在。下面我会通过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可扩展性的优势，多了解业界成熟的设计思路，结合自身的业务模式，设计出更合理的系统。

    参考：

    http://www.biuuu.com/?p=315

    http://highscalability.com/flickr-architecture

    http://www.example.net.cn/archives/2006/06/feedburneruoumy.html

    http://www.dbanotes.net/arch/facebook_photos_arch.html

    http://www.baselinemag.com/c/a/Projects-Networks-and-Storage/Inside-MySpacecom/

建议继续学习：

1. 我对技术方向的一些反思    (阅读：9851)
2. sns视觉设计分享    (阅读：7897)
3. 可扩展的分布式数据库架构    (阅读：4814)
4. 基于MySQL的高可用可扩展架构探讨    (阅读：3706)
5. 构建可扩展的微博架构(qcon beijing 2010演讲)    (阅读：3184)
6. SNS死在中国    (阅读：2660)
7. SNS背后的科学 (2) ―― 割裂的Web和割裂的Twitter    (阅读：2442)
8. SNS背后的科学（4）―― 信息的传播    (阅读：2358)
9. 门户、论坛、博客、SNS，网站模式的辨析    (阅读：2305)
10. 移动互联网时代谁主沉浮    (阅读：2274)