zoukankan      html  css  js  c++  java
  • 数据库的零散的总结

    mysql 及其mycat 分库分表
    1.主从架构
    2.读写分离
    3.分表分库
    3.1水平拆分
    3.2垂直拆分

    一。读写分离
    当数据不断增多的时候,数据库压力增大,可以把读和写分离开,读是一些机器,写是另一些机器,对应主从服务器,主服务器是写操作,从服务器读操作,可以有多个从服务器,而且大多数业务是读操作,京东,淘宝大量浏览商品,是读操作。

    在主服务器写的同时,数据同步到从服务器,保持数据的完整性(主从复制)
    binlog 机制

         1. 垂直拆分是指,这个表的列,即字段,要拆分成两个或多个表。

      这个应用场景比如:这个表字段,几个都是int、datetime等,有那么一个是text类型的,而这个text的字段还不是被经常检索,而其他几个字段要被经常检索。当出现效率问题时,我们可以考虑垂直拆分表。把这个text字段拆出来,可以提高检索效率。两个表建立关系可以利用原来表的主键。

      2. 水平拆分是指,把一个可能或者已经是大数据量的表拆分成多个表。

      一个表数据量很大时,比如超过百万或者更多,那么数据量仍然可能在扩充的时候,即便是加索引,检索效率也不高。很自然想到要表拆分。

      比如一张用户表,这个量会比较大。比如我根据业务的拓展形式,预算的量,我分成100张表。比如,user0,user1。。。user99。

      拆分以后,当然是尽可能让用户数据平均分散在各个表里。怎么对用户数据的存取呢?可以有多种方法,比如散列或者取模。

    分布式分库分表中间件
    mycat
    Sharding-JDBC
    分表能够解决单表数据量过大带来的查询效率下降的问题,但是,却无法给数据库的并发处理能力带来质的提
    分表策略相似,分库可以采用通过一个关键字取模的方式,来对数据访问进行路由,如下图所示

    分库分表
    场景:有时数据库可能既面临着高并发访问的压力,又需要面对海量数据的存储问题,这时需要对数据库既采用分表策略,又采用分库策略,以便同时扩展系统的
    并发处理能力,以及提升单表的查询性能,这就是所谓的分库分表。
    分库分表的策略比前面的仅分库或者仅分表的策略要更为复杂,一种分库分表的路由策略如下:
    1. 中间变量 = user_id % (分库数量 * 每个库的表数量)
    2. 库 = 取整数 (中间变量 / 每个库的表数量)
    3. 表 = 中间变量 % 每个库的表数量
    表锁定和行锁定
    表锁定(myisam存储引擎),一个是行锁定(innodb存储引擎)
    利用mysql cluster ,mysql proxy,mysql replication,drdb 做集群


    4 分库分表存在的问题。

    4.1 事务问题。
    在执行分库分表之后,由于数据存储到了不同的库上,数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价;如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。


    4.2 跨库跨表的join问题。
    在执行了分库分表之后,难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上,这时,表的关联操作将受到限制,我们无法join位于不同分库的表,也无法join分表粒度不同的表,结果原本一次查询能够完成的业务,可能需要多次查询才能完成。


    4.3 额外的数据管理负担和数据运算压力。
    额外的数据管理负担,最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题,这些都可以通过应用程序解决,但必然引起额外的逻辑运算,例如,对于一个记录用户成绩的用户数据表userTable,业务要求查出成绩最好的100位,在进行分表之前,只需一个order by语句就可以搞定,但是在进行分表之后,将需要n个order by语句,分别查出每一个分表的前100名用户数据,然后再对这些数据进行合并计算,才能得出结果。
    一主多备多从 读写分离分库分表 主从服务器,主服务器是写操作,从服务器读操作 在主服务器写的同时,数据同步到从服务器,保持数据的完整性(主从复制)

    (负载均衡一般使用在:网络优化/单点登录/集群分布式/高并发
    分布式数据库架构--排序、分页、分组、实现


    1、MyISAM:默认表类型,它是基于传统的ISAM类型,ISAM是Indexed Sequential Access Method (有索引的顺序访问方法) 的缩写,它是存储记录和文件的标准方法。不是事务安全的,而且不支持外键,如果执行大量的select,insert MyISAM比较适合。

    2、InnoDB:支持事务安全的引擎,支持外键、行锁、事务是他的最大特点。如果有大量的update和insert,建议使用InnoDB,特别是针对多个并发和QPS较高的情况。


    先说区别:

    一句话:分布式是并联工作的,集群是串联工作的。

    1:分布式是指将不同的业务分布在不同的地方。 而集群指的是将几台服务器集中在一起,实现同一业务。

    分布式中的每一个节点,都可以做集群。 而集群并不一定就是分布式的。

    举例:就比如新浪网,访问的人多了,他可以做一个群集,前面放一个响应服务器,后面几台服务器完成同一业务,如果有业务访问的时候,响应服务器看哪台服务器的负载不是很重,就将给哪一台去完成。

    而分布式,从窄意上理解,也跟集群差不多, 但是它的组织比较松散,不像集群,有一个组织性,一台服务器垮了,其它的服务器可以顶上来。

    分布式的每一个节点,都完成不同的业务,一个节点垮了,哪这个业务就不可访问了。

    2:简单说,分布式是以缩短单个任务的执行时间来提升效率的,而集群则是通过提高单位时间内执行的任务数来提升效率。

    例如:

    如果一个任务由10个子任务组成,每个子任务单独执行需1小时,则在一台服务器上执行该任务需10小时。

    采用分布式方案,提供10台服务器,每台服务器只负责处理一个子任务,不考虑子任务间的依赖关系,执行完这个任务只需一个小时。(这种工作模式的一个典型代表就是Hadoop的Map/Reduce分布式计算模型)

    而采用集群方案,同样提供10台服务器,每台服务器都能独立处理这个任务。假设有10个任务同时到达,10个服务器将同时工作,1小时后,10个任务同时完成,这样,整身来看,还是1小时内完成一个任务!

    以下是摘抄自网络文章:

    集群概念
    1. 两大关键特性

    集群是一组协同工作的服务实体,用以提供比单一服务实体更具扩展性与可用性的服务平台。在客户端看来,一个集群就象是一个服务实体,但事实上集群由一组服务实体组成。与单一服务实体相比较,集群提供了以下两个关键特性:

    · 可扩展性--集群的性能不限于单一的服务实体,新的服务实体可以动态地加入到集群,从而增强集群的性能。

    · 高可用性--集群通过服务实体冗余使客户端免于轻易遇到out of service的警告。在集群中,同样的服务可以由多个服务实体提供。如果一个服务实体失败了,另一个服务实体会接管失败的服务实体。集群提供的从一个出 错的服务实体恢复到另一个服务实体的功能增强了应用的可用性。

    2. 两大能力

    为了具有可扩展性和高可用性特点,集群的必须具备以下两大能力:

    · 负载均衡--负载均衡能把任务比较均衡地分布到集群环境下的计算和网络资源。

    · 错误恢复--由于某种原因,执行某个任务的资源出现故障,另一服务实体中执行同一任务的资源接着完成任务。这种由于一个实体中的资源不能工作,另一个实体中的资源透明的继续完成任务的过程叫错误恢复。

    负载均衡和错误恢复都要求各服务实体中有执行同一任务的资源存在,而且对于同一任务的各个资源来说,执行任务所需的信息视图(信息上下文)必须是一样的。

    3. 两大技术

    实现集群务必要有以下两大技术:

    · 集群地址--集群由多个服务实体组成,集群客户端通过访问集群的集群地址获取集群内部各服务实体的功能。具有单一集群地址(也叫单一影像)是集群的一个基 本特征。维护集群地址的设置被称为负载均衡器。负载均衡器内部负责管理各个服务实体的加入和退出,外部负责集群地址向内部服务实体地址的转换。有的负载均 衡器实现真正的负载均衡算法,有的只支持任务的转换。只实现任务转换的负载均衡器适用于支持ACTIVE-STANDBY的集群环境,在那里,集群中只有 一个服务实体工作,当正在工作的服务实体发生故障时,负载均衡器把后来的任务转向另外一个服务实体。

    · 内部通信--为了能协同工作、实现负载均衡和错误恢复,集群各实体间必须时常通信,比如负载均衡器对服务实体心跳测试信息、服务实体间任务执行上下文信息的通信。

    具有同一个集群地址使得客户端能访问集群提供的计算服务,一个集群地址下隐藏了各个服务实体的内部地址,使得客户要求的计算服务能在各个服务实体之间分布。内部通信是集群能正常运转的基础,它使得集群具有均衡负载和错误恢复的能力。

    集群分类
    Linux集群主要分成三大类( 高可用集群, 负载均衡集群,科学计算集群)

    高可用集群( High Availability Cluster)
    负载均衡集群(Load Balance Cluster)
    科学计算集群(High Performance Computing Cluster)
    ================================================

    具体包括:

    Linux High Availability 高可用集群 (普通两节点双机热备,多节点HA集群,RAC, shared, share-nothing集群等)

    Linux Load Balance 负载均衡集群 (LVS等....)

    Linux High Performance Computing 高性能科学计算集群 (Beowulf 类集群....)

    分布式存储

    其他类linux集群 (如Openmosix, rendering farm 等..)

    详细介绍
    1. 高可用集群(High Availability Cluster)

    常见的就是2个节点做成的HA集群,有很多通俗的不科学的名称,比如"双机热备", "双机互备", "双机".

    高可用集群解决的是保障用户的应用程序持续对外提供服务的能力。 (请注意高可用集群既不是用来保护业务数据的,保护的是用户的业务程序对外不间断提供服务,把因软件/硬件/人为造成的故障对业务的影响降低到最小程度)。

    2. 负载均衡集群(Load Balance Cluster)

    负载均衡系统:集群中所有的节点都处于活动状态,它们分摊系统的工作负载。一般Web服务器集群、数据库集群和应用服务器集群都属于这种类型。

    负载均衡集群一般用于相应网络请求的网页服务器,数据库服务器。这种集群可以在接到请求时,检查接受请求较少,不繁忙的服务器,并把请求转到这些服务器上。从检查其他服务器状态这一点上看,负载均衡和容错集群很接近,不同之处是数量上更多。

    3. 科学计算集群(High Performance Computing Cluster)

    高性能计算(High Perfermance Computing)集群,简称HPC集群。这类集群致力于提供单个计算机所不能提供的强大的计算能力。

    高性能计算分类  

    高吞吐计算(High-throughput Computing)

    有一类高性能计算,可以把它分成若干可以并行的子任务,而且各个子任务彼此间没有什么关联。象在家搜寻外星人( SETI@HOME -- Search for Extraterrestrial Intelligence at Home )就是这一类型应用。这一项目是利用Internet上的闲置的计算资源来搜寻外星人。SETI项目的服务器将一组数据和数据模式发给Internet上 参加SETI的计算节点,计算节点在给定的数据上用给定的模式进行搜索,然后将搜索的结果发给服务器。服务器负责将从各个计算节点返回的数据汇集成完整的 数据。因为这种类型应用的一个共同特征是在海量数据上搜索某些模式,所以把这类计算称为高吞吐计算。所谓的Internet计算都属于这一类。按照 Flynn的分类,高吞吐计算属于SIMD(Single Instruction/Multiple Data)的范畴。

    分布计算(Distributed Computing)

    另一类计算刚好和高吞吐计算相反,它们虽然可以给分成若干并行的子任务,但是子任务间联系很紧密,需要大量的数据交换。按照Flynn的分类,分布式的高性能计算属于MIMD(Multiple Instruction/Multiple Data)的范畴。

    4. 分布式(集群)与集群的联系与区别

    分布式是指将不同的业务分布在不同的地方。

    而集群指的是将几台服务器集中在一起,实现同一业务。

    分布式中的每一个节点,都可以做集群。

    而集群并不一定就是分布式的。

    举例:就比如新浪网,访问的人多了,他可以做一个群集,前面放一个响应服务器,后面几台服务器完成同一业务,如果有业务访问的时候,响应服务器看哪台服务器的负载不是很重,就将给哪一台去完成。

    而分布式,从窄意上理解,也跟集群差不多, 但是它的组织比较松散,不像集群,有一个组织性,一台服务器垮了,其它的服务器可以顶上来。

    分布式的每一个节点,都完成不同的业务,一个节点垮了,哪这个业务就不可访问了。

  • 相关阅读:
    又玩起了“数独”
    WebService应用:音乐站图片上传
    大家都来DIY自己的Blog啦
    CSS导圆角,不过这个代码没有怎么看懂,与一般的HTML是不同
    网站PR值
    CommunityServer2.0何去何从?
    网络最经典命令行
    炎热八月,小心"落雪"
    Topology activation failed. Each partition must have at least one index component from the previous topology in the new topology, in the same host.
    SharePoint 2013服务器场设计的一些链接
  • 原文地址:https://www.cnblogs.com/aibabel/p/10925953.html
Copyright © 2011-2022 走看看