参考：
微信公众号:架构师之路
数据库究竟该怎么垂直拆？
什么是数据库水平切分，垂直拆分？当数据库的数据量非常大时，水平切分和垂直拆分都是常见的降低库空间，提升库性能的方法。
太抽象，能不能举个例子？假设有用户表：
user(
uid bigint,
name varchar(16),
pass varchar(16),
age int,
sex tinyint,
flag tinyint,
sign varchar(64),
intro varchar(256)
…);
什么是水平切分？以某个字段为依据（例如uid），按照一定规则（例如取模），将一个库（表）上的数据拆分到多个库（表）中，以降低单库（表）大小，达到提升性能的目的的方法。
水平切分后，各个库（表）有什么特点？（1）每个库（表）的结构都一样；（2）每个库（表）的数据都不一样，没有交集；（3）所有库（表）的并集是全量数据； 什么是垂直拆分？垂直拆分是指，将一个属性较多，一行数据较大的表，将不同的属性拆分到不同的库（表）中，以降低单库（表）大小，达到提升性能的目的的方法。
垂直拆分后，各个库（表）有什么特点？（1）每个库（表）的结构都不一样；（2）每个库（表）的属性至少有一列交集，一般是主键；（3）所有库（表）的并集是全量数据；
以上文提到的用户表为例，垂直拆分结果可能是这样的：
user_base(
uid bigint,
name varchar(16),
pass varchar(16),
age int,
sex tinyint,
flag tinyint,
…);
user_ext(
uid bigint,
sign varchar(64),
intro varchar(256)
…);
当一个表属性很多时，如何来进行垂直拆分呢？主要依据以下几点：（1）将长度较短，访问频率较高的属性尽量放在一个表里，这个表暂且称为主表；（2）将字段较长，访问频率较低的属性尽量放在一个表里，这个表暂且称为扩展表；（3）经常一起访问的属性，也可以放在一个表里；
画外音：优先考虑1和2。
另，如果属性过多，可以有多个扩展表。画外音：一般来说，只有1个主表。 为何要将字段短，访问频率高的属性放到一个表内？为何这么垂直拆分可以提升性能？（1）数据库有自己的内存缓冲池，会将磁盘上的数据load到缓冲池里；画外音：详见《数据库缓冲池，这次彻底懂了！》。（2）数据库缓冲池，以row为单位缓存数据；（3）在内存有限的情况下，在数据库缓冲池里缓存短row，就能缓存更多的数据；（4）在数据库缓冲池里缓存高频访问row，就能提升缓存命中率，减少磁盘的访问； 能不能举个例子？假设数据库内存缓冲池为1G，未拆分的user表1行数据大小为1k，那么只能缓存100w行数据。
如果垂直拆分成user_base和user_ext，其中：（1）user_base访问频率高，一行大小为0.1k；画外音：例如uid, name, passwd, 以及一些flag等。（2）user_ext访问频率低，一行大小为0.9k；画外音：例如签名, 个人介绍等。那边缓冲池就就能缓存近乎1000w行user_base的记录，访问磁盘的概率会大大降低，数据库访问的时延会大大降低，吞吐量会大大增加。 总结（1）水平拆分和垂直拆分都是降低数据量大小，提升数据库性能的常见手段；（2）垂直拆分的依据，尽量把长度较短，访问频率较高的属性放在主表里；
动静分离架构，究竟是啥？
什么是动静分离架构设计准则？动静分离是指，静态页面与动态页面解耦分离，用不同系统承载对应流量的架构设计方法。
什么是静态页面？静态页面，是指互联网架构中，几乎不变的页面（或者变化频率很低），例如：
- 首页等html页面
- js/css等样式文件
- jpg/apk等资源文件
静态页面，有与之匹配的技术架构来加速，例如：
- CDN
- nginx
- squid/varnish
什么是动态页面？动态页面，是指互联网架构中，不同用户不同场景访问，都不一样的页面，例如：
- 百度搜索结果页
- 淘宝商品列表页
- 速运个人订单中心页
这些页面，不同用户，不同场景访问，大都会动态生成不同的页面。动态页面，有与之匹配的技术架构，例如：
- 分层架构
- 服务化架构
- 数据库，缓存架构
架构上，如何实施动静分离架构？静态页面与动态页面解耦分离，用不同系统承载对应流量的架构，如下图所示。
- 静态页面访问路径短，访问速度快，几毫秒
- 动态页面访问路径长，访问速度相对较慢(数据库的访问，网络传输，业务逻辑计算)，几十毫秒甚至几百毫秒，对架构扩展性的要求更高
- 静态页面与动态页面以不同域名区分
既然静态页面访问快，动态页面生成慢，有没有可能，将原本需要动态生成的站点提前生成好，使用静态页面加速技术来访问呢？可以，这就是互联网架构中的“页面静态化”优化技术。
什么是页面静态化技术？举个栗子，如下图，58同城的帖子详情页，原本是需要动态生成的：
（1）端访问/detail/12348888x.shtml 详情页；（2）web-server层从RESTful接口中，解析出帖子id是12348888；（3）service通过DAO层拼装SQL，访问数据库；（4）最终获取数据，拼装html返回浏览器；
而“页面静态化”是指，将帖子ID为12348888的帖子12348888x.shtml提前生成好，由静态页面相关加速技术来加速：这样的话，将极大提升访问速度，减少访问时间，提高用户体验。 页面静态化，适合什么业务场景？一切脱离业务的架构设计都是耍流氓，并不是所有的业务场景都适合页面静态化，滥用该技术，反而会降低系统性能。
页面静态化，适用于：总数据量不大，生成静态页面数量不多的业务。
举一些栗子：（1）快狗打车的城市页只有几百个，就可以用这个优化，只需提前生成几百个城市的“静态化页面”即可；（2）一些二手车业务，只有几万量二手车库存，也可以提前生成这几万量二手车的静态页面；（3）像58同城这样的信息模式业务，有几十亿的帖子量，就不太适合于静态化（碎片文件多，反而访问慢）； 简单总结（1）动静分离是指，静态页面与动态页面解耦分离，用不同系统承载流量的架构设计方法；（2）“页面静态化”是一种将原本需要动态生成的站点提前生成静态站点的优化技术；（3）总数据量不大，生成静态页面数量不多的业务，非常适合于“页面静态化”优化；
啥是数据库读写分离架构？
RD：数据量太大，数据库扛不住了，帮忙申请一个从库，读写分离。DBA：数据量多少？RD：5000w左右。DBA：读写吞吐量呢？RD：读QPS约200，写QPS约30左右。
额，数据库读写分离虽然不难，但并不是所有的“数据库扛不住”的场景，都应该用读写分离。今天花1分钟简单介绍下这个场景。
什么是数据库读写分离？一主多从，读写分离，主动同步，是一种常见的数据库架构，一般来说：
- 主库，提供数据库写服务
- 从库，提供数据库读服务
- 主从之间，通过某种机制同步数据，例如mysql的binlog
一个组从同步集群通常称为一个“分组”。
分组架构究竟解决什么问题？大部分互联网业务读多写少，数据库的读往往最先成为性能瓶颈，如果希望：
- 线性提升数据库读性能
- 通过消除读写锁冲突提升数据库写性能
此时可以使用分组架构。
一句话，分组主要解决“数据库读性能瓶颈”问题，在数据库扛不住读的时候，通常读写分离，通过增加从库线性提升系统读性能。
什么是数据库水平切分？水平切分，也是一种常见的数据库架构，一般来说：
- 每个数据库之间没有数据重合，没有类似binlog同步的关联
- 所有数据并集，组成全部数据
- 会用算法，来完成数据分割，例如“取模”
一个水平切分集群中的每一个数据库，通常称为一个“分片”。
水平切分架构究竟解决什么问题？大部分互联网业务数据量很大，单库容量容易成为瓶颈，如果希望：
- 线性降低单库数据容量
- 线性提升数据库写性能
此时可以使用水平切分架构。
一句话总结，水平切分主要解决“数据库数据量大”问题，在数据库容量扛不住的时候，通常水平切分。
我为什么不喜欢读写分离？对于互联网大数据量，高并发量，高可用要求高，一致性要求高，前端面向用户的业务场景，如果数据库读写分离：
- 数据库连接池需要区分：读连接池，写连接池
- 如果要保证读高可用，读连接池要实现故障自动转移
- 有潜在的主库从库一致性问题
- 如果面临的是“读性能瓶颈”问题，增加缓存可能来得更直接，更容易一点
- 关于成本，从库的成本比缓存高不少
- 对于云上的架构，以阿里云为例，主库提供高可用服务，从库不提供高可用服务
所以，上述业务场景下，建议使用缓存架构来加强系统读性能，替代数据库主从分离架构。
当然，使用缓存架构的潜在问题：如果缓存挂了，流量全部压到数据库上，数据库会雪崩。因此，对缓存，一般也会做水平切分，确保不会同一时间全挂。
总结
- 读写分离，解决“数据库读性能瓶颈”问题
- 水平切分，解决“数据库数据量大”问题
- 对于互联网大数据量，高并发量，高可用要求高，一致性要求高，前端面向用户的业务场景，微服务缓存架构，可能比数据库读写分离架构更合适
前台与后台，为什么要分离？
如果你经历过快速迭代业务，经历过用户量不断上涨，经历过访问并发越来越大，你一定会遇到以下系统问题：
-
用户访问页面越来越慢
-
系统性能下降，数据库扛不住，连接数经常打满，最终数据库挂掉，重启后又快速挂掉
-
改了一个小地方，另外一个看似不相干的地方却挂了，严重耦合
遇到上述痛点，经常使用“前台与后台分离”的架构优化方案。
业务早期，最常见的场景是什么？
虚拟一个类似于“AJK”租房买房的业务场景，这个业务的数据有两大来源：
-
用户发布的数据
-
爬虫抓取来的数据
这个业务对应的系统有两类使用者：
-
普通用户，浏览与发布数据，俗称“前台用户”
-
后台用户，运营与管理数据，俗称“后台用户”
在创业公司，为了快速迭代，系统架构如上：
-
web层：前台web，后台web
-
任务层：抓取数据
-
数据层：存储数据
上述架构方案，存在什么问题？
系统两类数据源，一类是用户发布的数据，一类是爬虫抓取的数据，两类数据的特点不一样：
-
自有数据相对结构化，变化少
-
抓取数据源很多，数据结构变化快
如果将自有数据和抓取数据耦合在一个库里，经常出现的情况是：
-
抓取数据结构变化
-
需要修改数据结构
-
影响前台用户展现
-
经常被动修改前台用户展现逻辑，配合抓取升级
如果经历过这个过程，其中的痛不欲生，是谁都不愿意再次回忆起的。
耦合的根本原因，是数据层的耦合。
应该怎么优化？
优化思路：前台展现数据，后台抓取数据分离，解耦。
如上图所示：
-
前台展现的稳定数据，库独立
-
后台抓取的多变数据，库独立
-
任务层新增一个异步转换的任务
如此这般：
-
频繁变化的抓取程序，以及抓取的异构数据存储，解耦
-
前台数据与web都不需要被动配合升级
-
即使出现问题，前台用户的发布与展现都不影响
有些朋友说，自己使用的是“微服务架构”，数据库为服务私有，不存在数据耦合。你以为微服务架构，就没有问题了吗？
微服务架构，服务耦合的新问题是什么？
上面解决了不同数据源写入的耦合问题，再来看看前台与后台用户访问的耦合问题。
用户侧，前台访问的特点是：
-
访问模式有限
-
访问量较大，DAU不达到百万都不好意思说是互联网C端产品
-
对访问时延敏感，用户如果访问慢，立马就流失了
-
对服务可用性要求高，系统经常用不了，用户还会再来么
-
对数据一致性的要求高，关乎用户体验的事情就是大事
运营侧，后台访问的特点是：
-
访问模式多种多样，运营销售各种奇形怪状的需求，大批量分页的，模糊搜索的
-
用户量小，访问量小
-
访问延时不这么敏感，大批量分页，几十秒能出结果，也能接受
-
对可用性能容忍，系统挂了，10分钟之内重启能回复，也能接受
-
对一致性的要求始终，晚个30秒的数据，也能接受
前台和后台的模式与访问需求都不一样，但是，如果前台与后台混用同一套服务和结构化数据，会导致：
-
后台的低性能访问，对前台用户产生巨大的影响，本质还是耦合
-
随着数据量变大，为了保证前台用户的时延，质量，做一些类似与分库分表的升级，数据库一旦变化，可能很多后台的需求难以满足
耦合的根本原因，是服务层的耦合。
应该怎么优化？
优化思路：冗余数据，前台与后台服务与数据分离，解耦。
如上图所示：
-
前台和后台独立服务与数据，解耦
-
如果出现问题，相互不影响
-
通过不同的技术方案，在不同容忍度，业务对系统要求不同的情况下，可以使用不同的技术栈来满足各自的需求，如上图，后台使用ES或者hive在进行数据存储，用以满足“售各种奇形怪状的，大批量分页的，查询需求”
小结
-
创业早期，可能存在数据耦合，需要进行前台与后台分离，数据解耦
-
微服务架构，可能存在服务耦合，需要进行前台与后台分离，服务解耦
“前台与后台分离”的架构设计方案，是最常见的解耦与优化方案之一。
12条SQL技巧
