如何规划、建设你的数据库架构

引言

　　昨天和刚入行就带个人老领导相约北京酒吧，4年师徒情，7年未见，从老公司境况到老熟人的现状，到如今的工做，将来的发展。从当下的技术到新技术的展望，聊到数据库架构，我说我如今仍是在作传统的数据库架构，而老领导满心的分布式，好像不是分布式都是比较LOW了，这里面依然存在着这样一个问题，什么是“分布式”，由于每一个人说的都不同，理解的也都不同。

 　　而分布式又是怎样一步一步演变的，不一样状况下又该如何设计规划本身的架构，文章篇幅有限内容太多，这里只能粗浅的说一说啦。

------------------本文纯属我的观点，若有错误、不足望指教----------------

 

架构的演变

　　架构演变必定是根据当时要求的场景、压力下性能的须要、安全性、连续性的要求、技术的发展.....

　　我把架构的发展分为大概4个阶段：

　　1.单机模式

　　

 　　IT建设初期，高速建设阶段，你们要作的只有一件事，我须要什么构建什么，我须要ERP我买软件，须要HIS买HIS，这个时期按需构建大量的系统基本在这个时期产生，固然那个时候也没什么高可用的要求。

　　2.双机热备 和 镜像

　　　　

　　基本是20年前的技术了，在高速构建后，一堆的系统运行中，用户发现咱们的核心业务若是坏掉业务受影响，停机几个小时作恢复 这是没法接受的，那么双机热备或镜像，Active-Standby的模式出现，这样一台机器工做，一台备用坏了在短期能够接管业务，形成的损失会低不少！

　　那么问题也很明显，备机资源浪费，依赖存储，数据仍是单点，成本较高。产品也不少：RoseHA/RoseMirrorHA、NEC ExpressCluster、微软MSCS、Symantec VCS、Legato、RHCS 太多太多了。

　　随后为了解决数据单点的问题有出现了 存储的主备，存储的双活这厂商也太多了，这里就不介绍了

　　　　

 

　　基本上传统企业依然停留在第一和第二阶段，也就是要么单机，要么双机热备

 

　　3.节点多活 

　　     

　　随着业务量愈来愈大，数据量不断飚升，系统高效性的矛盾显现出来，系统卡慢、报表、接口业务没法分离OLAP OLTP业务混合致使系统锁状况严重，资源消耗极其庞大，光靠升级硬件已经没法知足要求，横向扩展已经成为大势所趋。

　　同时切换时间、备机没法启动的问题也困扰着用户。

　　那么节点多活，多台机器同时对外提供访问的技术登上舞台，表明的ORACLE RAC、微软ALWAYSON 、MOEBIUS集群

　　多活的两种模式也是从第二带架构的演变

　　oracle rac 把双机热备的辅助节点变的能够访问，关键点数据在多节点内存中的调配

　　Microsoft awo、Moebius 则是把镜像的辅助节点变的能够访问，关键点数据多节点同步

　　这样横向扩展来分担压力，而且能够在业务上进行分离。

　　 4.分布式架构 

 　　

 　　分布式架构真的不知道从何提及，概念太大，每一个人理解的都不同，只能意会不能言传：

　　好比说一份数据分开存成多份

　　好比说拆分，水平拆分、垂直拆分、分库、分表、分业务

　　好比说....

　　其实说到底就是在第三代横向扩展也没法知足的状况下，继续“拆”，根据不一样需求各类“拆”，拆到什么样呢？ 你们都知道能够说最慢的环节在数据库，传统的作法复杂语句，大存储过程运行很是慢，那咱们就把这些拆到表数据量足够小、语句足够简单、业务粒度小、访问压力尽可能的小！

　　这样细化的设计一切为业务服务，也是精细化设计产物，但这也存在一个问题，传统企业在缺乏高端人才，人力的状况下根本没法作到。如今的互联网公司为业务的须要同时对IT团队的大力建设，这是传统企业根本没法达到的。

　　

　　固然若是有第五代那也许能够说是云，将来业务一切的技术都是云端，云端看不见摸不到，传统行业人回归业务，而IT 建设与管理也必然由专业的人作专业的事儿。

 

　　我的总结的架构演变，主架构演变不包含其余辅助技术，仅供参考

　　

其余技术漫谈

 　　在这四代架构之间也有不少技术出现，主要以数据复制、存储同步为表明，如DG、OGG、LOGSHIPPING、Replication等等，这些都是不一样场景下的数据复制，让一个副本变成多个，基本目的在于副本读或者本/异灾备，而这些技术也在不一样的场景中扮演这重要的角色，每种技术都有本身的优缺点，不能一律而论。

　　

 

　　固然这里面还包含如今所谓的虚拟化、超融合、存储双活，这些技术首先不是数据库自己技术，在不少企业所谓数据库的高可用中扮演着擦边球的角色，虚拟化、超融合、存储双活都有本身适用的场景，而说到数据库的架构，这些方案只是基础架构层面。

　　

如何选架构

• 　　选架构

　　首先你该选的是几代架构？

　　四代架构是按照业务不断细分，以冗余 和 拆分、细化为主线大致过程

　　二代冗余

　　

　　三代粗拆分

　　

　　四代细拆分

　　

 

 

 

　　固然这是只是大概的意思，实际中拆分的场景，条件，扩展性一系列复杂的过程。

 

　　 我曾经无数次遇到几十G的库 几百并发的应用就要规划分片，领导最求高大上，底下技术人员叫苦。

• 　　构建

　　构建中主要是对建构的细节了解和熟练，这和企业的人员配置有很大的关系，传统企业中不少在架构方案中选择第三方产品？这是为何，构建须要专业的人，而企业最少的就是这部分人，而维护管理，责任划分也是不得不考虑的事情。

　　固然架构越复杂投入的经历也就越大，这也不是一个架构师能够主导的事情。

• 　　维护

　　维护才是关键，业务变更后的灵活性、压力下的扩展性、出问题的排查、技术力量的支持，一系列漫长的过程开始了.....

 

题外篇

　　本身在传统行业玩的过久了，写这片文章的过程当中也和PingCAP 联合创始人& CTO 黄东旭，聊了一些将来技术的发展，tidb作的风声水起，对将来数据库你们都是未知，但随着技术的不断涌现更牛的架构，更牛的理念也必将一一实现。

　　好比依靠智能化的机制集群自我修复，性能自提高，架构自适应等等

总结

 　　架构方案是几代不重要，重要的是适合本身的业务，保证稳定、安全、高效、持续，单机适合简单业务，没有那么高的安全性、连续性依然能够，双机热备能够保障基本的高可用，节点多活的集群适合业务压力较大简单粗暴的分离和压力分担，至于分布式若是企业有能力有资源，业务压力庞大天然会考虑，但在我接触的客户中太多认为本身业务只能经过分布式方案构建，可是其实只是简单优化+三代多活，读写分离负载均衡便可知足。

　　因此根据本身业务评估最为重要，一个好的架构规划，不但解决现有问题节省成本，更会避免步子太大激进带来的没必要要损失。