本文主要是介绍数据库结构演变，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
传统单机数据库面临的挑战
以电商网站为例，在网站创建之初，日均访问量可能只有几百到几千人，这时整个业务后台可能就一个数据库，所有业务表都放在这个数据库中，一台普通的服务器就可以支撑，而且这种架构对业务开发人员也非常友好，因为所有的表都在一个库中，这样查询语句就可以灵活关联了，使用起来很便捷。
图1 所有业务表都在一个数据库中
但是随着业务的不断发展，每天访问网站的人越来越多，数据库的压力也越来越大。通过分析发现，所有的访问流量中，80%以上都是读流量，只有20%左右的写流量，这时可以通过读写分离来缓解数据库的访问压力。
图2 读写分离
由于网站的访问量越来越大，尽管采取了读写分离的方式，但随着数据库的压力继续增加，数据库的瓶颈越来越突出。这时我们发现，我们的网站演进到现在，交易、商品、用户的数据都还在同一个数据库中。然而在这个巨大而且臃肿的数据库中，表和表之间的数据很多是没有关系的，也不需要JOIN操作，理论上就应该把它们分别放到不同的服务器，即垂直分库。
图3 垂直分库
随着业务的不断增长，我们发现交易、商品、用户这些库都变得巨大无比，单机数据库已经无法满足业务的继续增长，这时可以考虑对这些表进行水平拆分，即同一个表中的数据拆分到两个甚至多个数据库中。以用户表为例，数据可以根据userid的奇偶来确定数据的划分。把id为奇数的放到DB1，为偶数的放DB2。
图4 水平分表
开源中间件解决方案及其存在的问题
读写分离、垂直拆库、水平分表作为大型网站后台的刚需，市面上有很多中间件可以满足，比较有代表性的有：阿里巴巴的Cobar、MyCAT。然而这些开源中间件都存在以下缺点：
配置复杂
- 基于开源中间件对一张大表进行水平拆分需要以下六步操作：
- 部署数据库节点
- 安装和部署中间件软件（多个）
- 登录到各数据库节点，创建子表
- 把子表的信息，配置到每个中间件的配置文件，然后启动
- 用HAProxy等负载均衡收敛中间件IP，对外提供一个IP
- 业务正式访问
运维极其不便
基于开源中间件对系统进行扩容需要进行以下几步：
图5 开源中间件系统扩容
开源中间件使用和运维的复杂性给业务发展造成了非常大的压力，无形中为企业发展带来了很大的负担。
这篇关于数据库结构演变的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
