【 导读】
关于如何构建千万级别用户的后台数据库架构话题，在ITPUB及CSDN论坛都有不少网友提问，新型问答网站知乎上也有人提问，并且顺带梳理了下思路，方便更多的技术朋友有章可循，整理一篇抛砖引玉性的文章。
一、 技术朋友给出的背景资料：
(1). 网站型应用，主要指：SNS社交网站、新闻门户型网站、邮件系统、SNS Game社交游戏、电子商务网站、即时通信IM等类型系统；
(2). 注册用户为千万级别，也即1KW注册用户以内；
二、要求
构建千万级别用户的后台数据库架构分析思路，对数据层架构设计的有章可循，必须考虑数据量的大小，以及数据库提供服务的性能和系统的可靠性，适当地考虑用户量超过，以及需要使用的服务器资源等信息。
三、构建千万级别用户的后台数据库架构的分析思路
曾经发过一篇文章，关于千万级别用户应用架构设计的歌谣，供大家参考 千万级架构设计诀窍，接下来我们针对如何构建千万级别用户的后台数据库架构，给出通用性分析思路的建议，未必完全靠谱，但求基本靠谱（注：毕竟很多事情需要看具体业务而定的）：
(1). 一定要区分业务类型，可能达到千万用户级别的应用业务场景，可归类描述为： SNS社交平台、SNS社交游戏、即时通信IM系统、电子商务、邮件系统、新闻门户网站等，这些不同类型的业务场景做法会不一样，主要是由他们业务性质决定，后续分析项中逐一描述；
(2). 应用业务的核心KPI数值，产品每天的日活跃用户量大概多少？若是网站类型应用，还需要加入其他参数PV,UV等数据辅助决策，即时通信IM的消息量，邮件系统的新增邮件数，SNS社交平台的Feeds量等核心数据；
(3). 系统中每个用户可能产生的数据量大概多大，分固定部分，以及动态部分的方式统计分析，对非固定部分以参考值和结合实践跨度（注释：1年为硬性指标，2年为预期，3年可选，再长的时间段不考虑）的方式进行分析，然后预测出整个系统的用户锁产生的数据条数和数据容量大概的估值；
(4). 注册用户并不等于活跃用户，为此需要预估日活跃用户量大概多少？周活跃用户量大概？月活跃用户量大概多少？系统设计的最高并发量为多少？这数字还是非常有必要，不管是对数据量预估，还是对技术实现方案的选择都有帮助；
(5). 根据应用业务的特点，以及系统不同模块的功能特点，初期必须判断出可能负载最大的系统模块，对于可以静态化模块或功能，尽量要Cache起来，以降低系统的负载和提高前端响应速度；若是非Cache技术能解决的，是否可以考虑独立或通过整体水平扩展方式解决系统的负载和性能问题；
(6). 针对系统中各个模块的功能或业务特点，大致那些用户数据会累计比较大，以及那些数据操作频率比较高；
(7). 不同的业务其对数据操纵不一样，要大致明白自己的应用：读写比如关系，也即：SELECT:UPDATE:DELETE:UPDATE=？；
(8). 系统的整体架构中，必须考虑系统的稳定性、负载均衡和响应速度，为此必须考虑一些模块借助Cache、异步、消息队列等技术，进行一些特殊处理或折中做法，以达到目标；
(9). 若使用MySQL数据库产品作为后台数据库提供数据服务，建议尽量使简洁的SQL语句，并不是说不用JOIN，而是要考虑MySQL对JOIN的实现算法，符合Nested loop join优缺点中的优点；
(10). 数据库结构设计
既然说是 构建千万级别用户的后台数据库架构，前面讲清楚如何熟悉和理解业务模型，清楚系统可能存在的瓶颈、技术难度，以及一些技术实现方案，现在必须回归到数据库设计阶段。
开始讨论如何收集、分析和设计数据库结构之前，我们先简单地对数据库，什么情况下要考虑进行水平拆分？尤其针对互联网行业流行的数据库产品MySQL来讨论，各大数据库技术论坛或个人博客型技术网站，有不少名言式的基调：数据量超过100W，就需要分表，MySQL无法支持大数据量的服务等等？
以前的MySQL（主要指：MySQL5.0以前版本）版本确实存在诸多问题，以及当时跑MySQL的服务器一般都是超低配置，还依然记得当时我们的数据库服务器最高也就8G内存，一般都是2G内存，硬盘都是单盘且转速是10K，甚至7500转的，而当时大多主流数据库产品Oracle跑的服务器配置却很少这么差。我们大家要一时俱进，技术人员尤其DBA或架构师，要学会以数据说话，以其中一测试用例，DELL 2950 415K146G RAID1+0 ，16G内存，E5410 CPU*2 ，一张分31个分区的区表业务模型只有INSERT+SELECT，且以50个INSERT+10个SELECT线程并发执行， 总记录写入数据量 6KW 行左右，单表数据容量超过100G ，并发从最高的9100 TPS/S 下降到8700 TPS/S 之后就稳定在此值。
上面论述MySQL支持大表并没有太大的性能方面的下降，但是并不表示笔者建议大家这么做，至少有二点MySQL的备份和数据库结构变更非常麻烦，尤其数据库结构变更其特殊的做法，使其成为一大瓶颈，也不知道要牺牲我们多少DBA的睡眠，具体的信息大家可以参考文章 MySQL数据库生产环境维护，但是对于新闻内容的存储需求，可以把新闻主题内容单独放到一张表中，以子表的方式存在，提供数据服务器，且该数据很少做变更，一般情况下是INSERT之后就只有读为主，那么就不会是任何问题，阿里巴巴旺旺弹出的新闻页面的内容就是采用此方式存储，当时单表容量接近1T，早高峰的时候也不会出现服务器性能问题，以及系统负载都非常稳定。
我们继续回到 构建千万级别用户的后台数据库架构 的话题上，具体建议或做法如下所示：
10.1> 数据库的设计开始之前，必须优先进行业务的数据流梳理（注释：必须尽量考虑应用所有可能的功能模块），以及对业务优先进行优化和规划，然后根据数据流和功能 考虑数据库的结构设计和优化；
10.2> 千万级别用户量，若是非游戏行业的产品（SNS游戏除外），建议考虑用户数据拆分架构设计，以及考虑后续未来1-2年的承受量，若是SNS平台必须考虑拆分，除非考虑上SSD、Fusion-io、存储等更高端的设备，用金钱换时间的方式支持技术改造；
10.3> 数据拆分的核心与难处：同一个用户的数据尽量放一起（拆分规则要尽量简单可执行），拆分之后用户关系的数据如何保存的抉择有多种（存2份或存1份放一个地方），难处数据的分页，统计合并等；
10.4> 要考虑一些冗余的方式解决SQL性能问题，但是又不能过多引入冗余而造成IO开销增加太多，冗余字段要尽量整型字段；
10.5> 数据库表对象的字段属性，要尽量考虑数字化，尤其游戏行业；
