博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
web DB优化思路
阅读量:4046 次
发布时间:2019-05-24

本文共 2111 字,大约阅读时间需要 7 分钟。

随着数据量的不断增长以及前端应用的不断水平扩充,数据库的压力会成为明显的问题,这个时候常用的方案是数据拆分,在数据拆分时有些什么较好的拆分方式?

 

 

1.按功能划分(垂直切分)

将不同功能相关的表放到不同的数据库中,这样做的好处是非常直观。但当某一部分的功能其数据量或性能要求超出了可控的范围,就需要继续对其进行深入的再切分。

2.按表中某一字段值的范围划分(水平切分)

当伴随着某一个表的数据量越来越大,以至于不能承受的时候,就需要对它进行进一步的切分。一种选择是根据key 的范围来做切分,譬如ID 为 1-10000的放到A上,ID 为10000~20000的放到B。这样的扩展就是可预见的。另一种是根据某一字段值来划分,譬如根据用户名的首字母,如果是A-D,就属于A,E-H就属于B。这样做也存在不均衡性,当某个范围超出了单点所能承受的范围就需要继续切分。还有按日期切分等等。

3.基于hash的切分

类似于memcached的key hash 算法,一开始确定切分数据库的个数,通过hash取模来决定使用哪台。这种方法能够平均地来分配数据,但是伴随着数据量的增大,需要进 行扩展的时候,这种方式无法做到在线扩容。每增加节点的时候,就需要对hash 算法重新运算,数据需要重新割接。

4.基于路由表的切分

前面的几种方式都是根据应用的数据来决定操作的,基于路由表的切分是一种更加松散的方法。它单独维护一张路由表,根据用户的某一属性来查找路由表决定使用哪个数据库,这种方式是一种更加通用的方案。因为每次数据操作的时候都需要进行路由的查找,所以将这些内容存储到一台独立的Cache上是一个非常好的方式,譬如memcached。这种切分的方式同时也带来了另一个好处,当需要增加数据库节点的时候,可以在不影响在线应用的情况下来执行,当然这也跟应用 程序的架构设计相关,你的设计必须适用这种增加。

最后我还需要说明的是数据不止可以存在数据库中,大的概念来讲,像邮件系统中的邮件、视频文件等都有着相同的分布式存储的算法。我自己经历过的邮件、播客等都应用了大量的数据切分的模式将数据切分到数百台存储节点中去。

 

对于大型网站而言,经常要面对不可预知的热点事件带来的高流量,如何能够做到避免这样突发的高流量造成网站的不可用呢?

1.业务运营原则上来讲应该可以有所预知,像奥运这样的热点事件应很早就可以预知。

2.系统自身就因为面对过热点事件,而拥有冗余能力。

3.系统快速部署能力和扩展方式非常重要,之所以Cache在大型网站应用广泛,就是因为其扩展方式支持极快的部署。

4.分布式服务更可以利用GSLB在全网调动流量,使得单个服务点的故障得以解决,同时也可以充分地利用多个节点的冗余能力。

 

成本问题逐渐成为互联网行业关注的重点问题,请提供一些可降低成本的技术方法,并介绍一下这些技术方法会带来些什么挑战?

从成本上来说,实质上是越来越低的,我们会发现磁盘容量、计算能力已经越来越便宜。降低成本的方法即是勇敢地尝试和探索新的技术。从互联网的发展来看,有几个技术非常值得我们去关注:

1. 存储技术。一些新的存储技术, 如Sun 的ZFS和基于ZFS的存储解决方案已经在很多地方使用起来。而且基于应用层的分布式存储技术也大量出现。它将原有EMC和Netapp的存储模型完全打倒。

2.负载均衡技术。基于Linux 的LVS和BSD的PF的负载均衡技术其实早已经被大量使用。但现在数G带宽的应用越来越多,相信未来与交换机结合在一起的二层、三层负载均衡技术又会兴起。另一方面,基于应用系统架构设计的七层负载均衡技术与互联网的壮大在各个公司里变得越来越重要。

从挑战上来讲,这些技术会让之前人们认为很“值钱”的某某认证付诸东流,而对于自己所掌握的技术能力会有更高的要求。现在来看,互联网的大容量正是会培养出一批优秀系统工程师、系统架构师的基础,谁能培养出这些人才并留住,必然会取得领先。

 

 

大量的用户使用行为记录需要留存,而留存下的数据量非常大,对于相关的数据也要进行频繁和复杂的业务计算,对于这样的存储有什么解决方案吗?对于这样的分析型计算有什么有效的架构 ?

 

首先存储方面,根据计算对于数据的读写需求,可以有两种方案:

一种方式是采用适合流式处理的分布式文件系统,如 HDFS、GFS,通过自动数据块的备份等技术,可以保证数据的可靠存储,同时利用大数据块的存储保证流式顺序数据读写的高性能。当一些数据需要经常性的全量访问,且这样的访问较容易流式的处理的时候,可以把这些数据存在这类文件系统中。

另一种方式是采用分布式的Key-Value 结构,如HBase、BigTable 等,他们的特点是可以支持随机读写,而简化的操作限制又使得它比数据库更容易实现大规模的分布式结构,因而适合计算中只需要读写海量数据中随机一部分条目的情况。

运算框架只要是支持大规模分布运算的都可以,例如前面提到的基于Map/Reduce 的分布式计算框架Hadoop。

 

 

9月刊精彩文章:架构师接龙 王速瑜VS.林昊 

冯大辉 vs. 王速瑜:支付宝架构师对话腾讯研发总监 

 

 

 

转载地址:http://fggdi.baihongyu.com/

你可能感兴趣的文章
为什么觉得协程是趋势?
查看>>
PV、UV、VV、CV
查看>>
用Node.js实现Restful风格webservice
查看>>
REST简介
查看>>
理解RESTful架构
查看>>
nginx日志切割
查看>>
js函数的作用域与this指向
查看>>
腾讯QQ团队开源分布式后台服务引擎msec
查看>>
看看腾讯和百度等这样的大型网站系统架构是如何演化的
查看>>
AMQP与QPID简介
查看>>
nginx虚拟主机
查看>>
Nginx 性能调优
查看>>
nginx rewrite规则之last和break
查看>>
Redis和Memcached的区别
查看>>
Memcached 集群的高可用(HA)架构
查看>>
浏览器端的缓存规则
查看>>
redis持久化RDB和AOF
查看>>
Redis持久化存储(AOF与RDB两种模式)
查看>>
memcached工作原理与优化建议
查看>>
Redis与Memcached的区别
查看>>