数据库分片以及schema概念

目录

前言

一，为什么需要分库分表

二，分库分表的最好方式

三，schema的存在

四，多shard会产生的问题

---

前言

这部分是数据库相关，思路是从数据库分库分表需求思路求解到一个数据库概念中很难懂的部分--schema。这两部分本来是不大相关，这里努力从逻辑上贯通便于更好地去理解schema存在的意义，并且尽量从业务上涵盖这种逻辑的发展趋势及痛点。

同时，有些是老生常谈的话题，甚至在我之前的blog也有提及很多，这里重新做一次归纳。

一，为什么需要分库分表

数据库两大瓶颈：IO和CPU

其中IO瓶颈就是读写，处理请求的网路带宽不够或者热点数据太多，缓存放不下，导致所有的数据请求打到数据库，每一次查询产生大量IO降低查询速度；CPU指执行层我们数据处理的问题，比如SQL大量join，order by，非索引字段查询会带来大量CPU负荷，单表数据量过大也会导致CPU利用率过高。

这两大瓶颈会直接造成数据库可用连接数减少，用户的角度感觉就是后台崩了（服务不可用）。

针对不同瓶颈都要有切实可行的方案去解决或者缓解流量压力，就算你再人傻钱多，也肯定要做合理的解决方案，否则就会出现某个节点跪了，重要业务取不出来导致全局不可用的情况。以后别人说某app后台崩了，你就可以知道这其实是业务层压力过大IO和CPU瓶颈限制导致的部分业务不可用，请求数据发不出来而造成的系统延迟或者服务失灵。

分库分表的逻辑也很简单，你数据多搞跨服务器是吧，我把业务数据合理分散管理，最大限度利用硬件资源提供数据服务就好。

---

二，分库分表的最好方式

这里小标题取得有点大，用意是以探讨地方式考虑数据库上云这一概念，从分库分表说起。

曾几何时我们以为这样的形式是最好的框架：

                                    fig.1微服务架构

但数据层的割裂必定导致业务层需要更高的复杂度去弥补，再加上数据的流动，维护成本可能更多，所以架构的选择只能是因业务而已，微服务架构以现在的是叫看肯定不是未来的架构。

我们所需要的是这样的数据库：

                              fig.2 数据库改进

这个数据库可以合OLTP和OLAP引擎为一身，做数据的弹性调度，甚至可以感知业务特点智能地去调度数据产生数据消化数据，这一部分智能在数据层比业务层更有理有效，云能力的加持更突出数据库有能力是未来技术潮流的代表，数据层的智能化运维才