性能优化--暂记

一、数据库分库分表

1 基本思想之什么是分库分表?

从字面上简单理解,就是把原本存储于一个库的数据分块存储到多个库上,把原本存储于一个表的数据分块存储到多个表上。

2 基本思想之为什么要分库分表?

数据库中的数据量不一定是可控的,在未进行分库分表的情况下,随着时间和业务的发展,库中的表会越来越多,表中的数据量也会越来越大,相应地,数据操作,增删改查的开销也会越来越大;另外,由于无法进行分布式式部署,而一台服务器的资源(CPU、磁盘、内存、IO等)是有限的,最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。

3 分库分表的实施策略。

分库分表有垂直切分和水平切分两种。

  • 3.1 何谓垂直切分,即将表按照功能模块、关系密切程度划分出来,部署到不同的库上。例如,我们会建立定义数据库workDB、商品数据库payDB、用户数据库userDB、日志数据库logDB等,分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。
  • 3.2 何谓水平切分,当一个表中的数据量过大时,我们可以把该表的数据按照某种规则,例如userID散列,进行划分,然后存储到多个结构相同的表,和不同的库上。例如,我们的userDB中的用户数据表中,每一个表的数据量都很大,就可以把userDB切分为结构相同的多个userDB:part0DB、part1DB等,再将userDB上的用户数据表userTable,切分为很多userTable:userTable0、userTable1等,然后将这些表按照一定的规则存储到多个userDB上。
  • 3.3 应该使用哪一种方式来实施数据库分库分表,这要看数据库中数据量的瓶颈所在,并综合项目的业务类型进行考虑。

如果数据库是因为表太多而造成海量数据,并且项目的各项业务逻辑划分清晰、低耦合,那么规则简单明了、容易实施的垂直切分必是首选。
而如果数据库中的表并不多,但单表的数据量很大、或数据热度很高,这种情况之下就应该选择水平切分,水平切分比垂直切分要复杂一些,它将原本逻辑上属于一体的数据进行了物理分割,除了在分割时要对分割的粒度做好评估,考虑数据平均和负载平均,后期也将对项目人员及应用程序产生额外的数据管理负担。
在现实项目中,往往是这两种情况兼而有之,这就需要做出权衡,甚至既需要垂直切分,又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分,我们首先对数据库进行垂直切分,然后,再针对一部分表,通常是用户数据表,进行水平切分。

4 分库分表存在的问题。
  • 4.1 事务问题。
  • 在执行分库分表之后,由于数据存储到了不同的库上,数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价;如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。
  • 4.2 跨库跨表的join问题。
  • 在执行了分库分表之后,难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上,这时,表的关联操作将受到限制,我们无法join位于不同分库的表,也无法join分表粒度不同的表,结果原本一次查询能够完成的业务,可能需要多次查询才能完成。
  • 4.3 额外的数据管理负担和数据运算压力。
  • 额外的数据管理负担,最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题,这些都可以通过应用程序解决,但必然引起额外的逻辑运算,例如,对于一个记录用户成绩的用户数据表userTable,业务要求查出成绩最好的100位,在进行分表之前,只需一个order by语句就可以搞定,但是在进行分表之后,将需要n个order by语句,分别查出每一个分表的前100名用户数据,然后再对这些数据进行合并计算,才能得出结果。

  针对当前项目GPS点实时收集,造成单表数量庞大,我觉得应该进行水平切分。目前能想到的就是按照日期进行分表,分库暂不考虑。从而节省增删改查的开销。若对于数据量的瓶颈进行解决,除开表字段,类型等基本因素,可就下面几点进行优化,集群是最简单的解决数据量大的问题(数据库集群还没试过,之前都是应用的集群),加个Ngix实现负载均衡,且解决了单个数据库服务器宕机的问题。
  还可对user_id作为切分依据,将user_id为1~10000的所有的文章信息放入DB1中的article表中,将user_id为10001~20000的所有文章信息放入DB2中的 article表中,以此类推,一直到DBn。这样一来,文章数据就很自然的被分到了各个数据库中,达到了数据切分的目的。参考文章(http://www.cnblogs.com/zhongxinWang/p/4262650.html)

暂记
  1.    水平切分数据库:可以降低单台机器的负载,同时最大限度的降低了宕机造成的损失;
  2.         负载均衡策略:可以降低单台机器的访问负载,降低宕机的可能性;
  3.         集群方案:解决了数据库宕机带来的单点数据库不能访问的问题;
  4.         读写分离策略:最大限度了提高了应用中读取数据的速度和并发量;
  5.         分布式:解决模块耦合,单个模块出错导致整个系统瘫痪的问题

表太多---垂直切分(按模块分离)

单表数据量大--水平切分,table0 table1 table2 按一定规则存储 (按日期如月份进行切分,又或按id进行范围切分)

二、简单总体优化--针对面试

如何提高页面的显示速度? 假如一个页面的加载时间是 10.89s,你会用什么
样的方式进行优化?
分而治之

  • 1、代码
    • 异步编程--async await,多线程,并行处理(把正在执行的大量的任务分割成小块,分配给多个同时运行的线程),响应式编程等等进行并发控制。
  • 2、服务器端运行速度慢
  • 数据库的原因还是算法的问题
    • 数据库的问题:则尝试添加索引、 优化 SQL 语句。再往上,就是如上分库分表,读写分离等等。
    • 如果是算法的问题,则优化算法。 如果对于一些不经常改动的页面可以使用静态页技术!对于一些数据不需要及时更新的而且取数据的过程非常耗时可以使用缓存。
  • 3、服务器端到客户端的下载慢
    • 页面体积过于臃肿:优化 HTML 代码,去掉无用的标签,压缩JS、 CSS,可以用 CSS Spirit技术将多个图片放到一个图片中,减少向服务器的请求
    • 网络问题:则尝试在不同的网络、地区部署服务器,然后使用 CDN技术加速访问 。分布式,集群,负载均衡(Ngix,LVS(linux virtul system),F5,DNS)等。

 

转载于:https://www.cnblogs.com/joeymary/p/6077057.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值