精华内容
下载资源
问答
  • 数据库拆分

    2019-12-22 12:33:21
    数据库拆分分类: 1、垂直拆分 概念:按照业务拆分,比如可以拆分为:产品库,客户库,订单库等。 目的:可降低单节点数据库的负载;原来的情况是:所有的数据表都集中在一个数据库节点上,如此所有的读写请求就...

    数据库拆分分类:

    1、垂直拆分

    概念:按照业务拆分,比如可以拆分为:产品库,客户库,订单库等。

    目的:可降低单节点数据库的负载;原来的情况是:所有的数据表都集中在一个数据库节点上,如此所有的读写请求就都发到此节点上(暂时忽略一主多从,读写分离的解决方案),所以数据库的负载会比较高。于是把一个节点的数据库表拆分到多个MySQL数据库,这样就可以有效的降低每个MySQL数据库的负载。如此,也就引出了服务拆分-分布式,每个数据库对应各自的服务。

    2、水平拆分

    概念:就是同一张表,在同一数据库或多个数据库中,存在多张(名称不同,结构完全相同,支持统一业务)

    目的:将大数量的单张表的查询压力,分散到多个节点的多张表的查询,化整为零。

    中间件举例:目前比较常用到MyCat

     

     

    展开全文
  • 数据库拆分经验

    2013-05-08 11:08:07
    数据库拆分经验,总结的很好,虽然描述的比较简单,但是很值得一看,
  • 数据库拆分:横向拆分和纵向拆分

    千次阅读 2018-08-03 16:12:20
    数据库拆分:横向拆分和纵向拆分 一、基本思想  Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上,从而缓解单一数据库的性能问题。不太严格的讲,对于海量数据的数据库,如果是因为...

    数据库拆分:横向拆分和纵向拆分

    一、基本思想 
    Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上,从而缓解单一数据库的性能问题。不太严格的讲,对于海量数据的数据库,如果是因为表多而数据多,这时候适合使用垂直切分,即把关系紧密(比如同一模块)的表切分出来放在一个server上。如果表并不多,但每张表的数据非常多,这时候适合水平切分,即把表的数据按某种规则(比如按ID散列)切分到多个数据库(server)上。当然,现实中更多是这两种情况混杂在一起,这时候需要根据实际情况做出选择,也可能会综合使用垂直与水平切分,从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列。下面分别详细地介绍一下垂直切分和水平切分.

      垂直切分的最大特点就是规则简单,实施也更为方便,尤其适合各业务之间的耦合度非
    
    •  

    常低,相互影响很小,业务逻辑非常清晰的系统。在这种系统中,可以很容易做到将不同业 
    务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分,对应用程序的影响也 
    更小,拆分规则也会比较简单清晰。(这也就是所谓的”share nothing”)。

    这里写图片描述
    水平切分于垂直切分相比,相对来说稍微复杂一些。因为要将同一个表中的不同数据拆 
    分到不同的数据库中,对于应用程序来说,拆分规则本身就较根据表名来拆分更为复杂,后 
    期的数据维护也会更为复杂一些。

    这里写图片描述 
    让我们从普遍的情况来考虑数据的切分:一方面,一个库的所有表通常不可能由某一张表全部串联起来,这句话暗含的意思是,水平切分几乎都是针对一小搓一小搓(实际上就是垂直切分出来的块)关系紧密的表进行的,而不可能是针对所有表进行的。另一方面,一些负载非常高的系统,即使仅仅只是单个表都无法通过单台数据库主机来承担其负载,这意味着单单是垂直切分也不能完全解决问明。因此多数系统会将垂直切分和水平切分联合使用,先对系统做垂直切分,再针对每一小搓表的情况选择性地做水平切分。从而将整个数据库切分成一个分布式矩阵。

    这里写图片描述 
    二、切分策略 
    如前面所提到的,切分是按先垂直切分再水平切分的步骤进行的。垂直切分的结果正好为水平切分做好了铺垫。垂直切分的思路就是分析表间的聚合关系,把关系紧密的表放在一起。多数情况下可能是同一个模块,或者是同一“聚集”。这里的“聚集”正是领域驱动设计里所说的聚集。在垂直切分出的表聚集内,找出“根元素”(这里的“根元素”就是领域驱动设计里的“聚合根”),按“根元素”进行水平切分,也就是从“根元素”开始,把所有和它直接与间接关联的数据放入一个shard里。这样出现跨shard关联的可能性就非常的小。应用程序就不必打断既有的表间关联。比如:对于社交网站,几乎所有数据最终都会关联到某个用户上,基于用户进行切分就是最好的选择。再比如论坛系统,用户和论坛两个模块应该在垂直切分时被分在了两个shard里,对于论坛模块来说,Forum显然是聚合根,因此按Forum进行水平切分,把Forum里所有的帖子和回帖都随Forum放在一个shard里是很自然的。

      对于共享数据数据,如果是只读的字典表,每个shard里维护一份应该是一个不错的选择,这样不必打断关联关系。如果是一般数据间的跨节点的关联,就必须打断。
    
      需要特别说明的是:当同时进行垂直和水平切分时,切分策略会发生一些微妙的变化。比如:在只考虑垂直切分的时候,被划分到一起的表之间可以保持任意的关联关系,因此你可以按“功能模块”划分表格,但是一旦引入水平切分之后,表间关联关系就会受到很大的制约,通常只能允许一个主表(以该表ID进行散列的表)和其多个次表之间保留关联关系,也就是说:当同时进行垂直和水平切分时,在垂直方向上的切分将不再以“功能模块”进行划分,而是需要更加细粒度的垂直切分,而这个粒度与领域驱动设计中的“聚合”概念不谋而合,甚至可以说是完全一致,每个shard的主表正是一个聚合中的聚合根!这样切分下来你会发现数据库分被切分地过于分散了(shard的数量会比较多,但是shard里的表却不多),为了避免管理过多的数据源,充分利用每一个数据库服务器的资源,可以考虑将业务上相近,并且具有相近数据增长速率(主表数据量在同一数量级上)的两个或多个shard放到同一个数据源里,每个shard依然是独立的,它们有各自的主表,并使用各自主表ID进行散列,不同的只是它们的散列取模(即节点数量)必需是一致的。(
    
    •  

    本文着重介绍sharding的基本思想和理论上的切分策略,关于更加细致的实施策略和参考事例请参考我的另一篇博文:数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示 

    1.事务问题: 
    解决事务问题目前有两种可行的方案:分布式事务和通过应用程序与数据库共同控制实现事务下面对两套方案进行一个简单的对比。 
    方案一:使用分布式事务 
    优点:交由数据库管理,简单有效 
    缺点:性能代价高,特别是shard越来越多时 
    方案二:由应用程序和数据库共同控制 
    原理:将一个跨多个数据库的分布式事务分拆成多个仅处 
    于单个数据库上面的小事务,并通过应用程序来总控 
    各个小事务。 
    优点:性能上有优势 
    缺点:需要应用程序在事务控制上做灵活设计。如果使用 
    了spring的事务管理,改动起来会面临一定的困难。 
    2.跨节点Join的问题 
    只要是进行切分,跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。

    3.跨节点的count,order by,group by以及聚合函数问题 
    这些是一类问题,因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案:与解决跨节点join问题的类似,分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行,因此很多时候它的速度要比单一大表快很多。但如果结果集很大,对应用程序内存的消耗是一个问题。

    参考资料: 
    《MySQL性能调优与架构设计》

    注:本文图片摘自《MySQL性能调优与架构设计》一 书

    展开全文
  • 数据库拆分

    2014-10-25 20:52:00
    1 数据库拆分的兴起在过去几年中,随着商业应用数据库事务量的大幅增长和数据库体积的增大,数据库拆分的概念已日益普及。许多在线服务供应商,软件即服务供应商(SaaS)和社交网站的成功更说明了这一点。数据库拆分...

    1 数据库拆分的兴起 
    在过去几年中,随着商业应用数据库事务量的大幅增长和数据库体积的增大,数据库拆分的概念已日益普及。许多在线服务供应商,软件即服务供应商(SaaS)和社交网站的成功更说明了这一点。 
    数据库拆分可以简单定义为针对跨多个服务器的大型数据库设计的一种“零共享”分区方案,这种方案使数据库性能和扩展性提高到一个新的水平变得可行。想象一下碎玻璃,您就能理解什么是sharding(碎片)——将数据库分成较小块所谓的“碎片”,散布在众多分布式服务器上。 
    术语“sharding”是谷歌工程师们首创,并通过他们的大表架构的公布得到推广的。然而,“shared-nothing(零分享)”这一数据库分区的思想已经存在了十年以上。在此期间已经产生了许多实例,特别是一些知名的在线服务提供商的著名的内部解决方案,如eBay、Amazon、Digg、Flickr、Skype、YouTube、Friendster和Wikipedia。 
    本文的重点是关于数据库拆分的需求、数据库分区的可选方案和成功进行数据库拆分的一些关键考虑因素。 


    1 大表:一个结构化数据分布式存储系统,由Fay Chang,Jeffrey Dean及其他Google员工提出。 


    2 是什么推动了对数据库拆分的需求? 

    数据库拆分是一个高可扩展性的方法,用于提高高度事务化、大型以数据库为中心的商业应用程序的数据吞吐和整体性能。自从关系数据库产生以来,显而易见,商业数据库一般随着时间增长而增长,对此应用工程师和设计师们要求不断地提高数据库的性能和容量。除此之外,网络经济的发展、信息时代的大背景、大量电子商务的普及使得商业数据急剧膨胀,导致了这一趋势更加明显。 
    正如任何一位有经验的数据库管理员或应用程序开发人员所深知,当数据层的大小和事务规模呈线性增长的话,响应时间往往呈对数增长,这是不言而喻的。如下图所示: 

    图1. 数据库大小和事务数的增长对响应时间有着巨大影响。 
    数据库性能和扩展性面临挑战的内在原因就是数据库管理系统本身的基础设计。任何计算机的数据库主要依赖于其三个部件: 
    - CPU 

    - 内存 
    - 磁盘 
    通过进行基准测试,我们知道,单个服务器上的某个部件只能扩展到一定的限度,然后必须采取其他措施。很明显,磁盘I / O是主要瓶颈,因为即使数据库管理系统得到改善,它依然保持对CPU和内存的高占用率。事实上,我们已经注意到,正是这三个因素的匹配程度决定了数据库的最大性能。换句话说,你不能通过单纯无限制增加CPU(或处理核心)的数量,而不提高内容容量,也不改善磁盘驱动子系统的性能,来使整个数据库系统整体性能得到相应的提高。显而易见,将资源投入到单个数据库服务器上的回报会逐渐减小。尤其是在混合使用的商业事务系统上,在执行大量读写事务的系统上,以及支持广义的商业报表任务方面,这些因素会更加明显。 
    因此,随着商业应用程序日益成熟,对它的需求也持续增长。架构师、开发人员和数据库管理员一直面临着维护关键任务系统的数据库性能的挑战。这一前景推动着对数据库拆分的需求。 


    3 数据库分区的可选项 
    人们早就知道数据库分区能够改善关系数据库的性能和扩展性。演变至今的技术包括: 
    - 主/从服务器:这是被许多组织使用的最简单的一个选择。使用一个主服务器处理所有的写(创建、更新或删除,或增删改查)操作,同时使用一个或多个从服务器处理只读操作。主服务器使用标准地、近似实时的复制功能将数据复制到各个从服务器。主/从模式可以将数据库整体性能提升到一定程度,允许读密集型的操作被分离到从服务器进行处理,但此种方法也有如下局限性: 
    l 单个主服务器处理写操作,在扩展性上有明显的局限性,并且会很快产生瓶颈。 
    l 主/从服务器的复制机制是“近于实时”的,这意味着从服务器不能保证获得主服务器上的即时快照。这种机制对于某些应用来说是可行的,但如果您的应用需要的是最新数据,这种方法是不可取的。 
    l 许多组织同样采用主/从服务器的方法来实现高可用性,但同样受限于主从服务器并不完全同步。如果主服务器发生灾难性故障时,任何事务都将在复制之前丢失,这种情况是大多商业事务应用所不能接受的。 
    - 集群运算:利用多台服务器同组集群计算,服务器之间通过群集的节点共享信息。大多数情况下这要依赖于一个集中的共享磁盘设备,通常是一个存储区域网络(SAN)。集群中的每个节点运行数据库服务器的单一实例,且以不同的模式工作: 
    l 对于高可用性,集群中的多个节点可用于读取,但只有一个处理写(增删改查)操作。这虽然可以使读取速度更快,而写操作却得不到任何改善。如果一个节点失败时,则群集中的另一个节点接替它,继续在共享磁盘设备上进行工作。由于一个增删改查操作瓶颈,这种做法限制了其扩展性。即使是读取操作也最终会达到一个性能极限,因为集中共享的磁盘设备在性能增幅递减之前只能分担这么大的负载。当一个应用程序需要复杂的联接或包含未优化的SQL语句时,其读操作所受的限制就是一个有力的证明。 
    l 更先进的集群技术依靠节点之间实时内存复制,该技术通过一种实时信息系统来保持在集群节点的内存镜像是实时的。这样使得每个节点具备既可工作在读取模式也可工作在写入模式,但最终还是会被通信节点之间可以传输的流量大小所限制(采用一个典型的网络或其他高速通信机制)。因此,随着节点的增加,通讯和内存复制的开销呈几何级数倍增,从而严重限制了扩展性,通常只好采用相对较少的节点数。此方案遇到了和传统集群一样的共享磁盘的限制,即不断增大的单一的大型数据库会产生越来越密集的磁盘读写。 
    - 表分区: 许多数据库管理系统支持表分区,如在一个大表中的数据可以跨多个磁盘以提高磁盘I / O利用率。这种分区通常是做横向(跨磁盘分区分行),但某些系统也可以垂直分区(在不同的分区上放置不同的列)。这种方法可以帮助减少对于某个特定表的磁盘I / O瓶颈,但往往使联接和其他操作变慢。此外,由于这种方法依赖于数据库管理系统下的单个数据库实例,所有其他对于CPU和内存的争夺所造成的限制进一步限制了其扩展性。 
    - Federated表:表分区技术的一个分支就是Federated表方法。使用这种方法,表可以在跨多个服务器被访问。这种做法管理起来非常复杂,且由于Federated表必须通过网络访问,效率也不高。这种做法可能适合某些报道性或分析性工作,但对于一般的读/写事务来说并非一个很好的选择。 
    这些方法的共同缺点是依赖于共享设备和资源。无论是依赖于共享内存,集中磁盘,还是处理器,扩展性都会受到限制,更不用提其他缺点了,包括复杂的管理,缺乏对关键业务需求的支持以及高可用性方面的限制。 


    4 数据库拆分,一种“零共享”的方法 
    数据库拆分提供了一个跨多个独立的服务器实现可扩展性的方法。每个服务器有自己的CPU,内存和磁盘。与传统的增强数据库性能的方法相比,它没有其他方法所遇到的典型限制。对于“零共享”数据库如何实现的研究和探讨已超过15年之久,但直到最近几年因为应用数据量的大增,才在商业领域找到较为广泛的市场需求。 
    数据库拆分的基本概念非常直白:将一个大的数据库,跨服务器分解成许多更小的数据库。如下图所示: 



    图2:数据库拆分就是将大数据库拆分成若干个小数据库。 
    很明显,“零共享”数据库拆分的优势就是大大提高扩展性。当更多的服务器被添加到网络中时,扩展性以近线性的方式增长。不过,在考虑一个拆分方案时,拆分成若干小数据库的方式还有其他几个优点不容忽视: 
    l 较小的数据库更易于管理。生产数据库必须进行全面的管理:定期备份、数据库优化和其他常规任务。使用一个大数据库的话,如果仅就完成操作所需的时间而言,实现这些日常任务非常困难。常规表与索引优化可以持续到几小时或几天,某些情况下会导致定期维护变得不那么灵活。通过拆分的方法,每个单独的“子库”可以单独维护。这样,管理更为简单,可以并行执行多个维护任务。 
    l 较小的数据库速度更快。拆分的扩展性是显而易见的,它通过在网络中跨子库和服务器的分布式处理得以实现。还有一个较不明显的事实是,每个子库库因其较小的尺寸从而在性能上胜过单个大的数据库。每个子库都有自己的服务器,这样内存和磁盘之间比率大为提高,从而减少磁盘的I/O。这样带来的后果是更少的资源争夺,更优秀的联接操作的性能,更快的索引搜索,以及更少的数据库锁定。因此,不仅拆分后的系统可以扩展到更高级别的容量,而且单个事务的性能也得到了提高。 
    l 数据库拆分能够降低成本。大多数数据库拆分方案可以从成本较低的开源数据库中受益,甚至可以从“工作组”版的商业数据库中受益。此外,拆分数据库在商用多核心服务器硬件上工作的很好,而这种硬件的花费远低于昂贵的高端多处理器服务器和昂贵的存储区域网络(SAN)。在许可证、软件维护和硬件投资上节约的综合成本是非常可观的,相比其他解决方案,有时可以节约70%或者更多。毫无疑问,数据库拆分对许多组织而言是一个可行的方案,这已由不少大型在线销售商和软件即服务(SaaS)供应商的实践证明过了(巨头如亚马逊,易趣,当然还有谷歌)。 


    5 数据库拆分的实用性 
    如果数据库拆分具有高扩展性,花费更低的成本,并且提高了性能,为什么该技术还没被广泛采用?它是否适合你的组织? 
    事实上,数据库拆分是一项非常有用的技术,但像其他方案一样,要成功实施需要考虑很多因素。此外,还存在一些限制,并且数据库拆分并不能在所有类型的商业应用上良好运行。本章讨论了这些关键因素以及它们如何能得到解决。 
    5.1 数据库拆分面临的挑战 
    鉴于单个数据库分布的性质,一些关键因素必须加以考虑: 
    - 可靠性。首先,任何生产经营性的商业应用都必须是可靠、容错的,且不能遭受频繁的断电。数据层通常是任一可靠性设计方案中最为关键的因素,数据库拆分的实施也不例外。事实上,鉴于多个拆分数据库分布的性质,一个设计优秀的方案显得尤为重要。为确保可靠性和容错性,需要具备以下几点: 
    n 单个子库的自动备份 
    n 子库冗余,确保每个子库至少有2个实时的备份可在断电或服务器发生故障时接替其工作。这就需要一个高性能、高效率、可靠的复制机制。 
    n 经济的硬件冗余,不管是服务器内部的硬件,还是跨服务器的硬件。 
    n 断电或服务器发生故障时自动故障切换。 
    n 灾难恢复的站点管理 
    - 分布式查询。 如果使用分布式查询并行处理模式,每个子库单独进行查询,再将每个子库的处理结果进行合并,那么许多类型的查询的处理速度会快上很多。这种技术使数据库性能获得数量级的提升,在很多情况下性能提高都在10倍或者更多。为了在应用程序上无缝地进行分布式查询,很重要的一点是需要一个设备对每个子库的查询进行处理,然后将结果合并成一个结果集返回到应用层。能从这种分布式处理模式中受益的常见查询有: 
    n 统计汇总,需要对整个系统的数据进行全面扫描。例如产品销售量计算通常要对整个数据库进行评估。 
    n 支持复杂报表的查询,如给出某一指定商品的前一天、前一周或前一月的所有顾客的列表。 
    - 避免跨子库的联接。在拆分系统中,跨子库使用内联的查询或其他语句效率很低,执行起来也很困难。在大多数情况下,如果采用的方法正确,实际上并不需要使用内联。主要技巧就是复制全局表,即那些相对不变化,通常用来与大型主表进行联接的对照表。那些包含状态代码、国家、类型甚至产品的表都属此类。我们需要的是一个自动化的复制机制,以确保在全局表中的值在所有子库中是同步的,尽量减少或消除跨子库联接。 
    - 自增长键管理。数据库管理系统所提供的典型的自增长功能对每一条插入数据库的新行生成一个序号键。这对一个单数据库的应用程序来说没有问题,但当使用数据库拆分技术时,必须对这些键值进行跨子库的协调管理。对此,我们需要为应用程序提供一个跨子库运行的、无缝的、自动的方法来生成键值,以确保整个系统的键值都是唯一的。 
    - 支持多个拆分方案。有一点很重要,就是据库拆分技术之所以有效,是因为它提供了一个面向应用的大规模扩展和性能改进技术。事实上,可以说拆分效果与拆分算法本身和应用程序面临的问题有多贴切是直接挂钩的。我们需要的是一套多样、灵活的、的拆分方案,其中每一个方案针对一个应用程序面临的特定问题。每一个方案都具备固有的性能以及针对应用程序的特质和优势,或者其中之一。事实上,使用错误的拆分方案会限制性能,达不到预期效果。单个应用采用多个拆分方案,每个方案用于应用程序的特定部分,从而获得优化的情况并不常见。以下列出了一些常见的拆分方案: 
    n 基于会话的拆分。如果单个用户或进程在整个用户或进程的会话期间内,与一个具体的子库进行交互,则采用这种方案。这是最容易实现的拆分技术,对整体性能来说几乎没有额外的开销,这是因为每一会话期只做一次拆分。从中受益的应用通常是以客户为中心的商业应用,每个客户相关的所有数据都放在一个子库上。 
    n 基于事务的拆分。判定子库的依据是检查给定事务的第一个SQL语句。这通常是通过评估语句中 “拆分键”的键值来完成(如订单号)。然后,将事务中其他所有的语句直接导向同一子库。 
    n 基于语句的拆分。以语句为基础的拆分是所有拆分类型中最为进程密集型的一种,它评估每一个SQL语句来确定这条语句应该导入哪个正确的子库。同样的,它同样需要对“拆分键”键值进行评估。这种拆分方案适合于数量大粒度小的事务,如记录通话记录。 
    - 决定如何拆分数据的最佳方法。这是另一领域,变化繁多,不同的应用有不同的选择。这与上述几种拆分方案的选择有很大的关系。有很多方法可以确定如何拆分您的数据,但重要的是要知道您的事务频率,表的大小量,键值如何分布,以及您的应用的其他特性。知道了这些数据就可以确定最优化的拆分策略: 
    n 根据表的主键进行拆分。这是最直截了当的选择,也是映射到一个应用的最容易的方法。不过,只有当您的数据分布合理才会有效。例如,如果您按客户ID(这是一个顺序的数字型值)拆分数据库,而大多数事务是针对新客户的,那么拆分效果只是微乎其微。另一方面,如果您选择一个能将用来合理自然的分发事务的键,则可以获得巨大的收益。 
    n 按一个键的键值的模数拆分。这种方法应用非常广泛,它对键值取模,并根据模数分发事务。实际上,您可以预先设定任意数量的子库,然后取模函数会基于“循环”规则处理键值,使得新键值能够非常均衡地分布于整个数据库。 
    n 维护子库索引主表。此项技术使用一个单独的主表,给不同的子库分配不同的值。这种方法非常灵活,适用面很广。但是,这种方法经常导致数据库性能不高,因为它需要对每一个拆分后的SQL语句进行额外查询。 
    由上可知,有很多因素需要考虑,也需要满足许多条件,才能确保数据库拆分能够成功而且有效,以达到提供经济的、更高级别的扩展能力和性能的目标。 
    5.2 什么时候进行数据库拆分合适 
    数据库拆分对许多类型的、有常规的数据库需求的商业应用来说非常合适。它同样可以有效地应用于数据仓库应用,不过因为有很多产品和技术可以实现这方面应用,我们就不在此详细讨论了。 
    适合对数据库进行拆分的常规数据库需求如下: 
    - 高度事务化的数据库应用 
    - 混合任务的数据库应用 
    n 频繁的读操作,包括复杂的查询和联接 
    n 写操作密集型的事务(增删改查语句,包括插入、更新、删除) 
    n 对于公共表和公共行,或者两者之一的资源争夺 
    - 常规商业报表 
    n 典型的“重复分段”报表的生成 
    n 一些数据分析(混合了其他任务) 
    要确定数据库拆分是否适合您特定应用或环境,最重要的事情是评估您的数据库结构能拆分的多好。从本质上讲,数据库拆分是一种“横向”分区的方法,即单个表的行集(与列相反)分布在多个子库上。为了搞清楚针对于特定情况下判定拆分的好坏的依据,以下一些事情非常重要: 
    - 找出您的数据库结构中所有事务密集型的表 
    - 确认您的数据库目前处理的事务数量(或者是预期需要处理的事务数量) 
    - 找出所有公用的SQL语句(选择、插入、更新、删除),确认每个语句的使用量 
    - 理解您的数据库结构的“表层次”,换句话说就是表之间的从属关系。 
    - 确定基于大容量表的事务的“键分布”情况,以确定他们是否均匀地分布还是集中于狭窄的区域内。 
    有了以上信息,您可以对拆分您的应用的价值和适用性做一个快速的评估。举一个例子,这有一个简单的书店系统的数据库结构,显示了数据是如何进行拆分的: 



    图3. 图例 书店系统数据库结构,显示了数据是如何进行拆分的 
    在书店系统这个例子当中,主拆分表是“顾客”表。这是用来拆分数据的表。“顾客”表是子库的父表,“顾客订单”表和“订单书目详情”表是其子表。这些数据根据“顾客ID”属性进行拆分,所有子表中与指定“顾客ID”的行集都拆分的很好。那些全局表是公用的对照表,它们相对来说操作较少,并被复制给所有的子库,以避免跨子库的联接操作。 
    虽然这个例子非常简单,但它提供了在决定如何对一个指定的数据库应用进行拆分时,应该考虑的基本因素。通过这样的评估方式,您就可以确定拆分是否适用于您的特定环境,以及数据库拆分后所能带来的好处。 


    6 结束语 
    本文对数据库拆分做了一个概述,包括对数据拆分所面临挑战的讨论,以及完成一个数据拆分方案的基本方法。数据库拆分已经在许多大型组织中得到了证明,也会很好的适用于您的应用中所碰到的具体问题。只要正确使用,数据库拆分一定会帮助大量的商业事务应用实现获得低成本的、近于线性的扩展性能的目标。

    转载于:https://www.cnblogs.com/timchen5858/p/4050859.html

    展开全文
  • 数据库拆分案例

    2017-12-14 10:47:41
    数据库拆分案例 杭州湖畔网络技术有限公司是一家专业提供SaaS化电商ERP服务的创业公司,主要用户群体为经营淘宝、天猫、京东等主流电商平台、自建商城、线下渠道的商家及中小企业。作为SaaS服务提供商,服务数万...

    数据库拆分案例

    杭州湖畔网络技术有限公司是一家专业提供SaaS化电商ERP服务的创业公司,主要用户群体为经营淘宝、天猫、京东等主流电商平台、自建商城、线下渠道的商家及中小企业。作为SaaS服务提供商,服务数万乃至数十万级用户是业务架构初期就必须考虑的问题。庞大的用户群以及海量的用户数据意味着基础设施的构建必须兼顾高效与稳定,而按照通用的基础设施建设方案的话,需要面对成本过高、实现复杂、需要投入太多精力等问题,这对当时的湖畔网络这样的初创公司来说,完全不能承受。因此,更经济、更方便扩展的云服务平台成为首选。在对比现有各家云服务后,我们选择了稳定性与成熟度都经过大量用户检验的阿里云。

    但要构建高性能的SaaS应用,仅凭云服务基础设施是不够的。如何基于云服务平台设计并实施符合自身业务特点的系统架构,也是决定产品性能的关键。本文将讲述我们如何利用云服务,使用相对经济的方案,解决海量用户的数据库使用问题。

    架构

    我们的SaaS化电商ERP服务的整体架构是基于阿里云服务平台实施的,如图1所示。

    图1  系统架构精简示意图

    通过该方案,不仅发挥了阿里云的优势(不涉及物理机器的维护和折损,灵活地配置升级,成熟的备份与快照方案),而且通过集群,避免了系统可能会遇到的单点故障,提高了系统弹性扩容的灵活性和可用性。

    作为一个SaaS化、数据更集中、数据体量庞大的企业应用,数据库是我们整体架构中的关键节点,如何保证其稳定与性能,是本文讲述的重点。

    当用户进入快速增长期后,随着业务量迅速增加,核心业务表的存量数据和增长速度绝对不是单个DB所能承受的(几乎所有单DB配置都存在性能物理上限瓶颈,即使选择升级配置也会受到成本和资源上限的约束)。因此,我们一开始就将数据库分库分片(Sharding)作为一个可行方案优先考虑,主要分析如下。

    考虑到业务特性,我们最终采用了行业比较通用的水平拆分+垂直拆分策略,并自主完成DAO与JDBC之间的数据访问封装层开发工作。

    水平拆分:按用户将数据拆分到多个库的相同表中

    水平拆分的思路,就是将原本存放在单个RDS数据库中的数据,根据业务ID不同,拆分到多个数据库中(参见图2)。拆分后,各库的表数量及表结构都保持一致。水平拆分首先需要确立唯一的业务主表,即其他所有表的数据都与主表ID(前文所说的业务ID)存在直接或间接的主从关系,可以通过主表ID对全部数据做很好的切分。我们选择的业务主表为用户表,其他业务表或表的父表都包含一个用户ID。因此,我们切分的目标就是将不同用户数据存放到不同的数据库中。

    图2  水平拆分示意图

    确定了拆分规则后,下一步是着手封装Sping数据访问封装层(DBWrapper)。DBWrapper介于DAO与JDBC之间,每个业务DAO进行数据库基本操作,都会经过DBWrapper。它的主要作用是将数据库架构的变化对业务层透明,业务层可以如同操作单个DB一样,调用DBWrapper提供的数据库操作接口,而判断操作哪个数据库的逻辑,则全部交由DBWrapper封装完成(参见图3)。 

    图3  水平拆分架构示意图

    DBWrapper主要提供新用户初始化和数据库操作接口。在新增用户初始化到系统时,需先动态判断系统各库的负载分布情况。粗略一点的算法就是判断各库的用户数,如共有4个库,可以根据user_id%4的情况决定目标库;再精细一点可以挖掘下核心业务数据的分布情况,具体分配算法需要基于业务设定(如考虑不同用户的平均订单量)。通过各库压力综合计算后,分析出压力最小的目标数据库,并将该新增用户数据存放到指定的目标库,同时更新路由信息(Router)。

    当用户完成初始化进行业务操作时,则需由业务层调用DBWrapper的操作接口。DBWrapper接收到请求后,会根据业务层传入的User_id匹配Router,判断最终需要操作的RDS实例和数据库。判断完成后,只需要按部就班地开连接执行就可以了。具体的代码实现,需要结合自身的持久层框架,找一名研究过持久层框架实现的开发人员即可完成。

    这样就将系统用户整体数据压力,相对均匀地分布到多个RDS实例与数据库上。事实证明,这确实是一个非常有效的方案,尤其是对于数据量大、增长迅猛的表。只是在后续实施过程中,我们发现有时会有单个用户的业务压力比较突出,针对这种情况,我们可以通过一些人工干预(如迁移数据到单独的库)进行微调,当然最终的解决方案还是要不断调优路由算法。

    切分后,不可避免地需要考虑数据字典(DD)和数据路由(Router)的处理。暂时我们采用的方法是将所有数据字典与路由放入独立的库,这也是后文中垂直拆分的一种应用。需要说明的是,数据库仅是这两个业务的一种实现方式,一般还可以通过或结合分布式缓存来处理这些业务(我们选用了OCS)。而对于可能出现的单点障碍,预留的扩展方案为水平拆分或创建只读节点(只读节点可以使用RDS最新提供的只读实例,目前还在内测阶段)。

    垂直拆分:按业务将表分组拆分到多个库中

    与水平拆分相比,垂直拆分要更简单一些。其基本思路就是将存放在单个数据库的表分组,把其中业务耦合度较高、联系紧密的表分为一组,拆分到其他DB中(参见图4)。拆分后,各库的表结构及其业务意义将完全不同。虽然规则简单、实施方便,但垂直拆分总是需打断些关联,因为实际操作中,基础资源常常出现在各个业务场景,在切分时又不得不切分到两个库中,此时就需要业务层多次查询后,在内存处理数据,实现数据库Join的效果。

    图4  垂直拆分示意图

    垂直拆分同样需要DBWrapper,但封装规则与水平拆分略有不同,需要针对不同的业务,建立不同的DBWrapper。此时不再是完全业务层无感知,需要业务层根据业务场景有针对性使用。单个DBWrapper的实现与水平拆分一致。

    垂直拆分的好处在于,将整体业务数据切分成相对独立的几块,隔离了不同业务之间的性能影响。而由于拆分后的数据库业务比较集中,也更容易找到业务主表,更有利于水平拆分。

    对于垂直拆分,目前我们主要用于解决数据路由(包含了用户的基本信息)、数据字典模块,以及常见的冷数据问题。冷数据的处理一直是行业的常见问题(其实对于冷数据的划分,也是水平拆分),目前我们采用的方案是集中存储,即按自己的冷数据切分方式,通过自行开发的迁移程序将判定的冷数据增量迁移到一个库中。这个方案既能够分离冷数据对热点数据的操作影响,也可以为大数据的挖掘提供比较便利的条件。使用相对独立的冷数据存储结构,能方便以后采用更高效、成本更低廉的存储介质。当然该方案存在一些潜在问题,如果冷数据库满了该怎么办?目前我们预留的设计方案是,历史库的水平拆分,也可以考虑其他存储形式。

    水平拆分与垂直拆分组合使用

    拆分一直是数据库优化的关键词(无论是库表结构还是SQL写法),它是每个高并发产品最终都要经历的一步。拆分方案的核心主要在于可以通过添加更多RDS实例和数据库(常常为了节约成本,多个数据库可以部署在一个RDS实例上),灵活扩容系统的负载能力。在数据库架构中,水平拆分和垂直拆分一般都是搭配使用的,两者的先后顺序视具体情况而定。一般而言,垂直拆分更容易,也可以为水平拆分做铺垫,一是业务集中,便于提取主表,二是垂直拆分后,可以只水平拆分压力高的表,而业务增长缓慢的表则可以保留单DB,从而提高拆分效率以及降低实施成本(参见图5)。

    图5  数据库Sharding方案示意图 

    我们之所以优先水平拆分,主要原因还是成本和效率及当时的一些局限性。只按业务ID(用户)做好路由配置,这样各个库中的结构完全一致,保留了原本的业务逻辑与实现,避免了跨库关联,能大大节省实现成本。

    尽管拆分有种种好处,但由于分布式事务及跨库Join的实现复杂度较高及可用性较差,所以分布式事务一般都通过业务层使用乐观锁控制。而跨库的表间关联一定要打断,否则性能和实现复杂度都会超出可接受范围。对于跨库的Join、Group by等问题,都需要在业务层处理。目前我们采用的是分批查询,在业务层组装结果的方式。

    有些遗憾的是,由于我们早期使用RDS时,阿里云尚未推出DRDS(分布式数据库)产品,所以上述拆分的数据库底层架构均是由我们自行研发的,投入了大量的精力。而现在有了DRDS,正准备做拆分的团队,则无需再自己造轮子,直接拿来用即可,这样团队可以将更多的精力放在业务上。

    小处大有可为

    虽然我们在架构上做了优化,但在产品发展过程中还是会出现性能不太理想的情况。在阿里云支持中心和论坛上,也可以看到其他业务型团队反馈使用RDS时遇到类似的情况。最初大家都怀疑是不是RDS的底层资源隔离有问题,多个用户共享资源时发生争抢,导致RDS的性能问题。但在阿里云DBA的指导和协助下,发现是由于产品设计时对数据库的使用太“不拘小节”,而随着并发压力与数据量增加,大量细小的性能问题被放大,集中暴露出来。

    解决灯下黑:修正业务层的数据库操作陋习

    在数据库的优化过程中,研发团队最容易忽视的往往是业务层中的数据库使用。一些优化方案可以作为开发的常态化准则。下面仅列举几个常用的优化方案。

    挤掉海绵里的水:优化数据库执行计划

    由于执行计划的优化往往涉及到数据库的运行机制与底层设计,此处实难三言两语说清。所以下面仅列举几个我们受益颇深的优化方案。建议大家优化执行计划时,多关注、分析iDB Cloud控制台中的性能报告和建议,也尽量多向阿里云DBA们请教,一般可以通过提工单的方式。有条件或兴趣的话,DBA可以通过预约到阿里云现场学习。另外,执行计划的优化需要大量的调试工作,通过在阿里云控制台创建生产数据库的临时实例,可以准确模拟当前系统的数据结构、分布与压力。

    字段类型选择

    选择合理的字段,往往可以大大减少数据库行数据的大小,并提高索引匹配的效率,进而大大提升数据库性能。使用更小的数据类型,如日期采用date代替datetime、类型或标记使用tinyint代替smallint和int、使用定长字段代替非定长字段(如char代替varchar),都能或多或少减少数据行大小,提高数据库缓冲池的命中率。而作为表字段中特殊的一员—主键,其选型更会对表索引的稳定和效率带来很大的影响,一般建议考虑数据库自增或自主维护的唯一数值。

    高分离度字段建立索引

    对于查询来讲,高分离度字段往往意味着精准或部分精准的条件。相对来讲是最好优化的一种场景,只需要对分离度较高的字段单独建立索引即可。当然实际使用中会有更多细节需要摸索。精确条件在各业务中基本都会用到,在越复杂的业务场景中,精确条件优先的原则,将是最有效的优化方案。需要注意的是,尽管高分离度字段单独建立索引效率很高,但过多的索引会影响表写入的效率,所以需要谨慎添加。这一点iDB Cloud中有大表索引的建议可以参考。

    覆盖索引(Covering Index)

    通俗一点理解,就是执行计划可以通过索引完成数据查找和结果集获取,而无需回表(去缓冲池或磁盘查找数据)。而由于MySQL的索引机制限制,一次查询时,将只用到一个索引或将两个索引聚合(index_merge)起来使用,所以意味着复杂的业务场景中,单独对每个字段建立索引可能没有什么用处。所以对于一些特定的查询场景,建立合适的组合索引,应用覆盖索引方法可以避免大量随机I/O,是更为推荐的优化方案(如果执行计划Explain的Extra中有Using Index,就说明使用了覆盖索引)。但实际业务总是会比索引本身更复杂,业务中需要查找或者获取的字段信息往往是很多的,而组合索引并不能涵盖所有的字段(否则我们将拥有一个比数据还要庞大的索引)。此时,为了应用覆盖索引,就需要使用主键延迟关联(Deferred Join),即先通过组合索引中包含的字段条件,初步查询出相对较小的结果集(面向结果集原则),该结果集只包含主键字段;然后通过获取到的这个主键队列,再对数据表做关联。

    适当妥协

    见招拆招:升配置

    一般业务型的研发团队,很难有额外的精力投入到数据库方面,也没有专业的DBA来不断调优数据库配置、优化数据库服务器性能。所以早期团队可以选择的方案不多,也很难在技术上深挖下去,只能用成本换时间:性能配置不够,那就升级服务器配置。

    那么问题来了:自己部署的数据库要升级配置,除了调整数据库配置参数,还会受到物理机的限制,因此就要考虑更加复杂的数据库备份和同步策略。但这是业务团队所不能接受,甚至短期内无法实现的,升配置也就变成了一个复杂的问题。不过我们使用了RDS,其弹性升级策略,正是这个问题的最佳解决方案。

    二八原则

    在长期的数据库乃至整个产品的优化过程中,我感受最深刻的就是:完美的方案可遇不可求。选择方案时,如果能解决80%的问题,并规避或保留剩下的20%,则将大大提升团队的整体效率。产品与架构都是在不断优化演变的,我们要循序渐进、不断努力,将今天的终点留作明天的起点。

    总结与展望

    作为一位创业公司的技术开发人员,通过实际使用阿里云产品,我总结了几点关于使用云计算产品的优势。

    1. 便利的服务器弹性升级功能,可随时应付像“双十一”这样的大促。而通过使用传统IDC托管模式,物理机的维护、升级以及升级后的数据迁移都是比较头疼的。

    2. 成熟可靠的数据备份与快照、数据库主从分离与同步的底层方案。创业团队无须承受自己造轮子的代价,可专注于业务开发。

    3. 云计算产品经过检验、值得信赖的安全防护。

    4. 精简了创业团队人员规模。云计算平台具备专业的技术支持与服务,使得创业团队不再需要数据库和服务器管理员。

    除了使用云产品的心得,数据库调优实践是本文的重点。在数据库的架构设计与性能优化方面,我秉承的原则是解决主要问题,按先分而击之、再挖掘细节的步骤,周返往复不断进行,同时系统架构也在这个过程中不断演变。相信随着时间推移,会有更多优秀的方案出现。尤其随着云服务不断发展,业务研发团队投入到基础设施的精力与成本,将会无限减少。会有越来越多专注于业务研发的团队,推出更多优秀的互联网产品,用互联网服务推动企业创新,重塑中小企业信息化形态。 

     

    • 采用SLB(Server Load Balance,负载均衡)作为Web集群访问入口,负责为Web端的多台服务器进行流量分发。SLB是基于集群建设的,并且可以随时变配,按量付费。它不仅为我们实现了成熟的负载均衡方案,其稳定性与灵活性也为Web集群提供了更多可能。
    • 后端配置多台ECS(Elastic Compute Service,云服务器)实例,将主要应用服务都部署在ECS上。除了可弹性扩容这一特性,ECS提供的安全防护和快照备份为服务器安全和容灾提供了非常成熟的解决方案,这恰恰是我们这种业务型创业团队积累相对最薄弱的方面。另外,ECS多线接入骨干网络能保证网络的稳定和性能,使得任何网络的用户访问应用服务都非常顺畅。
    • DB集群由多台RDS(Relational Database Service,关系型数据库服务)实例组成。RDS是云数据库,简单易用,使用方法与自行部署的数据库完全一样。其成熟的双机热备与底层资源隔离,保证了我们这两年来数据库的平稳运行。另外,强大的iDB Cloud控制台、专业的DBA团队支持,为我们监控数据库运行状况、定位和解决数据库问题,提供了非常多的建议和帮助。
    • 集群之间的共享资源统一存放在OCS(Open Cache Service,开放缓存服务)中。我们用OCS来存放数据路由和实时性不高的业务数据。缓存作为我们架构性能中非常重要的一个环节,在承受了来自整个集群各方面压力的同时,还要保证响应稳定高速。
    • 场景:业务热点数据持续增加,团队有一定的数据库架构积累能支撑独立研发或熟悉成熟的中间件(如Cobar)。
    • 优点:成本低(可以利用开源免费的数据库集群替代大型商业DB);可灵活扩容(不断增加新的数据库切片即可);相对均匀分布的数据读写,避免单点障碍。
    • 缺点:需要研发团队在数据库架构上投入大量精力;数据库集群维护需要成本投入。
    • 场景:数据库性能有问题,应优先从业务层分析。
    • 优点:减轻数据库的直接压力,比执行数据库优化方案更加迅速有效。
    • 缺点:业务研发需要关注一些数据库操作内容;有时会牺牲一些业务;产品规模越大实施越困难。
    • 延迟加载。很多页面展现时,单个实体实际只展现部分内容,因此可按需加载,减轻数据库压力,又节省网络流量。延迟加载也可体现在数据库表的拆分设计上。
    • 适当缓存,以空间换时间。对于很多实时性较低或干脆就是数据字典的内容,无需实时到数据库中加载,只需在使用前加载到内存中,实际使用时到内存中获取即可。
    • 减少不必要的开连接(连接池、批量查询及提交)。对于大部分的Web应用,连接池大大减少了系统因开数据库连接产生的开销。而在查询和提交中,将多个任务合并到一次数据库操作中,也可以大大提高数据库使用效率。
    • 乐观锁是高并发下不错的解决方式。相比于数据库的悲观锁,业务层实现的乐观锁,不仅能减少锁争抢,还可以减少数据库的锁开销,进而提高数据库使用效率。
    • 分解大事务。数据库对于大事务的原子性保证,也是不容忽视的开销。业务使用时,尽量将大事务切分为小事务,或者适当利用异步提交,精简事务体积。
    • 合理使用Join。数据库执行计划中,有一条准则是越简单越快速。所以通过适当冗余数据设计或业务层分批查询后内存组装数据,减少数据库Join语句及SQL复杂度,对于数据库执行效率和执行计划的优化都有不可忽视的好处。
    • 场景:并发不多、数据量并不很大,或系统整体压力较低,只有某几个业务点性能较差。
    • 优点:在不改变基本条件的情况下,挖掘数据库更大潜力。
    • 缺点:需要DBA协助或研发团队对数据库执行计划做研究。
    • 场景:性能问题紧迫,团队时间资源有限。
    • 优点:简单粗暴见效快,基本适用于任何优化阶段。
    • 缺点:增加成本;治标不治本,只是延迟问题再次爆发时间;资源总有上限,迟早升无可升。

     

    转载:http://blog.sina.com.cn/l1pe1  感谢博主分享


    展开全文
  • 数据库拆分的问题

    2017-07-02 21:37:24
    数据库拆分有水平和垂直两种。垂直拆分就是把不同业务的数据放到不同的库中,水平拆分就是根据一定规则将同一业务的数据分到不同库中。这两种方式会带来如下问题:   对于解决方案,敬请期待。
  • 大型网站架构演进(7)数据库拆分 原文:大型网站架构演进(7)数据库拆分 能过数据库的读写分离和使用NoSQL,以及搜索引擎后,能够降低主库的压力,解决数据存储方面的问题,不过随着业务的继续发展,...
  • 互联网当下的数据库拆分过程基本遵循的顺序是:垂直拆分、读写分离、分库分表(水平拆分)。每个拆分过程都能解决业务上的一些问题,但同时也面临了一些挑战。 1 垂直拆分 对于一个刚上线的互联网项目来说,由于前期...
  • 数据库拆分技术

    2010-08-27 11:39:00
    <br />  <br />     1 数据库拆分的兴起 在过去几年中,随着商业应用数据库事务量的大幅增长和数据库体积的增大,数据库拆分的概念已日益普及。许多在线服务供应商,软件即服务...
  • ghostferry是一款开源的以go为开发语言的数据库拆分工具,支持MySQL,MariaDB。对于开发人员友好,不需要十分了解数据库,即可进行数据库拆分。类比MySQL原生的数据库复制filter进行的数据拆分优势在于,不需要数据...
  • 数据库拆分的几种方式1 垂直拆分2 读写分离3 分库分表挑战1:基本的数据库增删改功能挑战2:分布式id挑战3:分布式事务挑战4:动态扩容4、总结 转载地址:http://www.tianshouzhi.com/api/tutorials/dragon/362 1.1 ...
  • 架构设计之数据库拆分原则 数据拆分前其实是要首先做准备工作的,然后才是开始数据拆分,我先讲拆分前需要做的事情: 第一步:采用分布式缓存redis、memcached等降低对数据库的读操作。 第二步:如果缓存使用...
  • mid=2456618601&idx=1&sn=c10839f1797e7be1ea41f005b57432df&chksm=87897237b0fefb215dd74c28cf5b524984b8f50d2ef13293e37919774f1c51e36642e489ee38&token=936375027&...1数据库拆分过.
  • 互联网当下的数据库拆分过程基本遵循的顺序是:垂直拆分、读写分离、分库分表(水平拆分)。每个拆分过程都能解决业务上的一些问题,但同时也面临了一些挑战。 1 垂直拆分 对于一个刚上线的互联网项目来说,由于前期...
  • 数据库拆分的理解和案例1 数据库拆分过程及挑战1.1 垂直拆分1.2 读写分离1.3 分库分表挑战1:基本的数据库增删改功能挑战2:分布式id挑战3:分布式事务挑战4:动态扩容2 主流数据库中间件设计方案2.1 设计方案2.1.1 ...
  • 当单机数据库遇到瓶颈后,我们最...垂直拆分就是把一个数据库的不同业务单元的数据分到不同数据库中。二、优缺点优点:拆分后业务清晰,拆分规则明确。系统之间整合或扩展容易。数据维护简单。缺点:部分业务表无法j...
  • 1,为什么要进行数据库的拆分在LNMP架构中,动态数据的...数据库作为后端,它的数据处理速度就代表了整个web架构的效率,所以数据库单独部署且不止一台数据库服务器2,数据库拆分后解决了什么问题1)提高了数据库处...
  • 数据库拆分 分库,即垂直数据拆分,比如拆分为商家库、客户库、订单库。分库解决多个表之间的IO竞争、单机容量问题。 分表,即水平数据拆分。分表提高了单表查询速度。 先按照业务维度进行垂直拆分,不同的应用...
  • 提高你的架构能力:数据库拆分实现数据库能力线性扩展 Java全栈技术 2018-12-21 08:45:32 点击关注,快速进阶高级架构师 作者:兔龙象 我们公司前几年的核心系统,平均80人左右开发至今已经8年多了,至今还在...
  • 任何脱离业务的架构设计都是耍流氓。 数据库分布式,其核心内容无非就是数据切分(Sharding),以及切分后对数据的定位、整合工作,解决单一数据库或数据表因数据量...纵向拆分数据库(逻辑关系),横向拆分数据表...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,819
精华内容 3,527
关键字:

数据库拆分