赵振平:项目成败取决于数据库架构设计

http://tech.it168.com/a2011/0416/1178/000001178961_all.shtml

【IT168 资讯】万丈高楼拔地起,高楼的成败取决于是否有一个好的地基。而一个系统的成败则取决于架构设计的优劣。当外部事物让公司项目失败,好的架构可以避免或减少损失,反之,一个不好的系统架构设计可能会让公司的损失更大。如何去设计系统架构呢?有请某跨国公司数据库架构师赵振平给大家分享一下他的经验。


▲某跨国公司数据库架构师赵振平

  架构最重要的就是围绕性能、成本、数据高可用性这三点,这三点是紧密相连,密不可分的,所以我们称之为数据库架构设计“铁三角”。这三个因素相互制约,相互影响,密不可分。


铁三角示意图


性能决定成本和高可用性


可用性取决于成本和性能


成本决定性能和可用性

  数据库架构设计路线图


▲数据库架构设计路线图


▲驱动性能的三驾马车

  第一驾马车--分布数据

  分布数据就是根据某些条件把数据分割分布成多块,然后放到不同的物理位置。所谓物理位置是指地理位置,物理主机和物理磁盘。分布数据目前来说是性能优化最有效的方法。分布数据的方法有一下几种:

  1、按照国家进行划分

  2、按照城市进行划分

  3、按照数据中心(DC)进行划分

  4、按照数据集合进行划分

  垂直拆分(Vertical shard )


▲垂直拆分示意图

  垂直拆分也叫行拆分(Row Splitting),其实就是把组成一行的多个列分开,放到不同的表中,这些表具有不同的结构,拆分后的每个表中含有更少的列。垂直拆分就是列的重新分布。垂直拆分其实就是“业务拆分”。


▲垂直拆分示意图

  垂直拆分完成以后形成的架构:1、一个业务对应一台数据库;2、其实,这就是垂直拆分(Vertical shard )。


垂直拆分完成以后形成的架构

  当“业务二”成为了焦点和热点,就必须对数据库进行水平拆分,什么是水平拆分?水平拆分其实就是把一个表分成几个表,这些表具有相同的列,但是存放更少的数据。其原理是根据现有的表克隆出新的表,这些表存放不同的数据而已。其具有以下特点:

  1、每一块的结构完全相同

  2、每一块的表结构和原来的“业务二”数据库的表结构完全相同

  3、唯一不同的是,每一块中存放不同用户的数据

  4、每一块在结构上其实就是原来数据库的克隆(clone)

  5、每一块其实就是一个完整的数据库

  假设经过一段时间的发展后,业务二业绩突出,目前的数据库无法满足业务二的需求,又需要对业务二数据库进行拆分。


▲“业务二”数据库的拆分


▲用户分布的变化


“业务二”数据库的拆分


拆分之后用户的变化

   其实以上就是水平拆分(Horizontal shard )。所谓水平拆分其实就是把一个表分成几个表,这些表具有相同的列,但是存放更少的数据。其原理是根据现有的表克隆出新的表,这些表存放不同的数据而已。水平拆分完成后,表S被拆分成三个表,这些表具有相同的结构。只是这三个表存放不同的数据。

  第二驾马车:“读写分离”

  数据拆分后,DB set1一套数据库由5台数据库组成,对于每台这样的数据库,仍然没有达到性能最优,那就要对db22实现读写分离。MySQL代理是一个介于MySQL客户端和MySQL服务器之间的简单程序,可用来监视、分析或者传输他们之间的通讯。最大优点就是:读写分离。

  
▲对db22实现读写分离

  
▲读写分离前的数据库

  
▲读写分离后的数据库

  第三驾马车:“Cache(缓存技术)”

  当上述分离后的业务三又发生了变化,其性能已经达到了瓶颈,利用拆分技术已经不能突破目前的局限,那么就只能考虑Cache(缓存技术)。

  Memcached的应用

  在使用Memcached技术的时候要注意两大影响:

  查询影响:查询之前,要在Memcached中查找结果.如果找到,则返回它;如果未找到,则到数据库服务器上执行查询,并将结果返回给Memcached

  插入影响:先把数据插入到数据库,在内存中受此影响的数据库将变成无效


使用Memcached技术示意图


▲Memcached应用后的数据库

   除了Memcached之外,当然其他的缓存技术也可以实现同样的效果。比如SolidDB和Oracle timesten等都可以实现这一效果。

时间: 2024-10-12 17:02:14

赵振平:项目成败取决于数据库架构设计的相关文章

java架构师课程、性能调优、高并发、tomcat负载均衡、大型电商项目实战、高可用、高可扩展、数据库架构设计、Solr集群与应用、分布式实战、主从复制、高可用集群、大数据

15套Java架构师详情 * { font-family: "Microsoft YaHei" !important } h1 { background-color: #006; color: #FF0 } 15套java架构师.集群.高可用.高可扩展.高性能.高并发.性能优化.Spring boot.Redis.ActiveMQ.Nginx.Mycat.Netty.Jvm大型分布式项目实战视频教程 视频课程包含: 高级Java架构师包含:Spring boot.Spring  clo

数据库架构设计思路

一 .58同城数据库架构设计思路 (1)可用性设计 解决思路:复制+冗余 副作用:复制+冗余一定会引发一致性问题 保证"读"高可用的方法:复制从库,冗余数据,如下图  带来的问题:主从不一致 解决方案:见下文 保证"写"高可用的一般方法:双主模式,即复制主库(很多公司用单master,此时无法保证写的可用性),冗余数据,如下图  带来的问题:双主同步key冲突,引不一致 解决方案: a)方案一:由数据库或者业务层保证key在两个主上不冲突 b)方案二:见下文 58同

互联网数据库架构设计思路

一 .58同城数据库架构设计思路 (1)可用性设计 解决思路:复制+冗余 副作用:复制+冗余一定会引发一致性问题 保证"读"高可用的方法:复制从库,冗余数据,如下图   带来的问题:主从不一致 解决方案:见下文 保证"写"高可用的一般方法:双主模式,即复制主库(很多公司用单master,此时无法保证写的可用性),冗余数据,如下图   带来的问题:双主同步key冲突,引不一致 解决方案: a)方案一:由数据库或者业务层保证key在两个主上不冲突 b)方案二:见下文 5

数据库架构设计

参考 数据库之互联网常用架构方案 数据库架构原则 架构核心的核心-数据库设计原则(金融行业) 海量数据存储--分库分表策略详解 原文地址:https://www.cnblogs.com/zhangchao0515/p/11493236.html

商业级项目——基金客户端的架构设计与开发(下)(附源码)

#项目简介 上一次的博文中详细分析了基金项目的整体架构和主界面的UI设计.今天分享地方是剩下的3个页面及相应功能的实现. #个人中心 个人中心界面,最开始会跳转到一个登陆界面,用户可以通过选择"身份证.基金账户.护照.户口本",然后输入相应的账号和密码进行登陆.在这个界面中,还具有相应的记住密码,忘记密码功能.不输入是不允许进入账户的,当正确输入相应的账号密码后,通过和后台服务器进行验证登陆,登陆进去之后是一个账户详情页,有持仓查询.盈亏查询.交易查询等功能,在持仓查询中hi有总资产,

商业级项目——基金客户端的架构设计与开发(上)

本项目是通力基金的商业级项目,声明:在此仅用于交流学习.该项目主要有三个主要功能模块:1.基金模块:包括基金的查询.展示等功能:2.账户模块:包括登录.充值.提现.收藏等功能:3.辅助模块:消息中心.帮助.意见反馈等. 项目运行首先会有一个闪屏页,然后进入的是一个新手引导页(只显示一次),可以向右滑动,共4页图片,当滑到最后一张时,图片中会有一个进入的按钮,点击这个按钮进可以进入到App的主页. 主页中:下面是4个导航,根据用户点击的不同,会切换至不同的界面. ok,我们现在开始来分享一下这个软

企业级电商项目P2P金融项目实战,企业架构师培训视频课程

15套java架构师.集群.高可用.高可扩 展.高性能.高并发.性能优化.Spring boot.Redis.ActiveMQ.Nginx.Mycat.Netty.Jvm大型分布 式项目实战视频教程 视频课程包含: 高级Java架构师包含:Spring boot.Spring  cloud.Dubbo.Redis.ActiveMQ.Nginx.Mycat. Spring.MongoDB.ZeroMQ.Git.Nosql.Jvm.Mecached.Netty.Nio.Mina.性能调优.高并发.

java架构师大型分布式综合项目实战,高并发,集群,高可用,程序设计,性能优化,架构设计,负载均衡,大数据量

* { font-family: "Microsoft YaHei" !important } h1 { color: #FF0 } 15套java架构师.集群.高可用.高可扩 展.高性能.高并发.性能优化.Spring boot.Redis.ActiveMQ.Nginx.Mycat.Netty.Jvm大型分布 式项目实战视频教程 视频课程包含: 高级Java架构师包含:Spring boot.Spring  cloud.Dubbo.Redis.ActiveMQ.Nginx.Mycat

支撑日活百万用户的高并发系统,应该如何设计其数据库架构?

目录: 用一个创业公司的发展作为背景引入 用多台服务器来分库支撑高并发读写 大量分表来保证海量数据下查询性能 读写分离来支撑按需扩容及性能提升 高并发下的数据库架构设计总结 " 这篇文章,我们来聊一下对于一个支撑日活百万用户的高并系统,他的数据库架构应该如何设计? 看到这个题目,很多人第一反应就是: 分库分表啊! 但是实际上,数据库层面的分库分表到底是用来干什么的,他的不同的作用如何应对不同的场景,我觉得很多同学可能都没搞清楚. (1)用一个创业公司的发展作为背景引入 假如我们现在是一个小创业公