精华内容
下载资源
问答
  • 数据库中间件技术

    2015-09-17 11:16:44
    数据库访问中间件实现了应用程序与本地或异地的同构或异构数据源的数据交换。 简单的说,利用数据访问中间件,客户端发出数据查询指令,经过中间件处理,发送到服务器,服务器完成数据查询,再经中间件,将结果送回...
  • mycat数据库中间件、支持分库分表。本文档对数据库的水平拆分配置、环境搭建、分片规则等做了详细描述。
  • 解决的问题数据库相关平台主要解决以下三个方面的问题为海量前台数据提供高性能、大容量、高可用性的访问为数据变更的消费提供准实时的保障高效的异地数据同步上图的讲解最上层的是分布式数据库分表分库中间件,读写...

    解决的问题

    数据库相关平台主要解决以下三个方面的问题

    为海量前台数据提供高性能、大容量、高可用性的访问

    为数据变更的消费提供准实时的保障

    高效的异地数据同步

    AAffA0nNPuCLAAAAAElFTkSuQmCC

    上图的讲解

    最上层的是分布式数据库分表分库中间件,读写分离,水平扩容 --》代表中间件有(Cobar,Mycat,tddl,drds,ddb)

    增量数据订阅和消费,用户对数据库操作,比如DML DDL DCL操作,中间件可以监控这些操作所产生的增量数据。典型代表Canal,根据MySQL的binlog实现。也有针对Oracle(redolog)的增量数据订阅与消费的中间件有 Canal,erosa

    数据库同步中间件涉及数据库之间的同步操作,可以实现跨(同)机房同步以及异地容灾备份、分流等功能。可以涉及多种数据库,处理之后的数据也可以以多种形式存储。(Otter, JingoBus, DRC)

    数据库与数据库之间会有数据迁移(同步)的动作,同款数据同步原理比较简单,比如MySQL主备同步,只要在数据库层进行相应的配置既可,但是跨数据库同步就比较复杂了,比如Oracle->MySQL. 数据迁移一般包括三个步骤:全量复制,将原数据库的数据全量迁移到新数据库,在这迁移的过程中也会有新的数据产生;增量同步,对新产生的数据进行同步,并持续一段时间以保证数据同步;原库停写,切换新库。将“跨数据库”这个含义扩大一下——“跨数据源”,比如HDFS, HBase, FTP等都可以相互同步。(yugong, DataX)

    数据库中间件举例

    分布式数据库分表分库

    数据增量订阅与消费

    数据库同步(全量,增量,跨机房,复制)

    跨数据库(数据源)迁移

    分布式数据库

    分表分库类的中间件主要有两种形式向应用提供服务

    一种是以JDBC的jar包形式为Java应用提供直接依赖,Java应用通过提供的JDBC包实现透明访问分布式数据库集群中的各个分库分表,典型代表网易的DDB和阿里的TDDL.

    另一种是为应用部署独立的服务来满足应用分库分表的需求,在这种方式下通过标准JDBC访问Proxy,而Proxy则根据MySQL标准通信协议对客户端请求解析,还原应用SQL请求,然后通过本地访问数据库集群,最后再将得到的结果根据MySQL标准通信协议编码返回给客户端。典型代表阿里的Cobar, Cobar变种MyCAT, 阿里的DRDS,网易的DDB proxy模式以及DDB的私有云模式。

    Mycat

    这里就不对Cobar做介绍了,目前来看Cobar的发起人的离职导致维护也停止了,整个开发不算完备所以直接跳过,介绍MyCat

    从定义和分类看,它是一个开源的分布式数据库系统,是一个实现了MySQL协议的Server,前端用户可以把它看做是一个数据库代理,用MySQL客户端工具和命令行访问,而其后端可以用MySQL Native Protocol与多个MySQL服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信,其核心功能是分表分库,即将一个大表水平分割为N个小表,存储在后端MySQL服务器里或者其他数据库里。

    MyCAT发展到目前的版本,已经不是一个单纯的MySQL代理了,它的后端可以支持MySQL, SQL Server, Oracle, DB2, PostgreSQL等主流数据库,也支持MongoDB这种新型NoSQL方式的存储,未来还会支持更多类型的存储。

    MyCAT是一个强大的数据库中间件,不仅仅可以用作读写分离,以及分表分库、容灾管理,而且可以用于多租户应用开发、云平台基础设施,让你的架构具备很强的适应性和灵活性,借助于即将发布的MyCAT只能优化模块,系统的数据访问瓶颈和热点一目了然,根据这些统计分析数据,你可以自动或手工调整后端存储,将不同的表隐射到不同存储引擎上,而整个应用的代码一行也不用改变。

    MyCAT和Cobar比较有两个显著提高:

    后端由BIO改为NIO,并发量有大幅提高

    增加了对Order By, Group By, Limit等聚合功能(虽然Cobar也可以支持Order By, Group By, Limit语法,但是结果没有进行聚合,只是简单返回给前端,聚合功能还是需要业务系统自己完成)

    AAffA0nNPuCLAAAAAElFTkSuQmCC

    事务是弱XA含义:分布式事务处理( Distributed Transaction Processing , DTP )指一个程序或程序段,在一个或多个资源如数据库或文件上为完成某些功能的执行过程的集合,分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作,提交或回滚事务的决定必须产生统一的结果(全部提交或全部回滚)

    MyCAT的原理中最重要的一个动词是“拦截”,它拦截了用户发来的SQL语句,首先对SQL语句做了一些特定的分析:如分片分析,路由分析、读写分离分析、缓存分析等,然后将此SQL发往后端的真实数据库,并将返回的结果做适当的处理,最终再返回给用户

    MyCAT对自身不支持的SQL语句提供了一种解决方案——在要执行的SQL语句前添加额外的一段由注解SQL组织的代码,这样SQL就能正确执行,这段代码称之为“注解”。注解的使用相当于对MyCAT不支持的SQL语句做了一层透明代理转发,直接交给目标的数据节点进行SQL语句执行。

    MyCAT自身有类似其他数据库的管理监控方式,可以通过MySQL命令行,登录管理端口(9066)执行相应的SQL进行管理,也可以通过jdbc的方式进行远程连接管理

    高可用(HA)

    MySQL的HA

    MySQL节点开启主从复制的配置方案,并将主节点配置为MyCAT的dataHost里的writeNode,从节点配置为readNode,同时MyCAT内部定期对一个dataHost里的所有writeHost与readHost节点发起心跳检测

    正常情况下,MyCAT将第一个writeHost作为写节点,所有的DML SQL会发送此节点

    若MyCAT开启了读写分离,则查询节点会根据读写分离的策略发往readHost(+writeHost)执行

    如果第一个writeHost宕机,MyCAT会在默认的三次心跳检测失败后,自动切换到下一个可用的writeHost执行DML SQL语句

    当原来配置的MySQL写节点宕机恢复后,作为从节点,跟随新的主节点,重新配置主从同步

    MyCAT自身的HA

    官方建议是采用基于硬件的负载聚亨或者软件方式的HAproxy等

    如果还担心HAproxy的稳定性和但节点问题,则可以用keepalived的VIP的浮动功能,加以强化。

    MyCAT功能和特性

    支持SQL 92标准

    支持Mysql集群,可以作为Proxy使用

    支持JDBC连接多数据库

    支持NoSQL数据库

    支持galera sfor mysql集群,percona-cluster或者mariadb cluster,提供高可用性分片集群

    自动故障切换,高可用性

    支持读写分离,支持MySQL双主多从,以及一主多从的模式

    支持全局表,数据自动分片到多个节点,用于高效表关联查询

    支持一致性Hash分片,有效解决分片扩容难题

    多平台支持,部署和试试简单

    支持Catelet开发,类似数据库存储过程,用于跨分片复杂SQL的人工智能编码实现

    支持NIO与AIO两种网络通信机制,windows下建议AIO,Linux下目前建议NIO

    支持MySQL存储过程调用

    以插件的方式支持SQL拦截和改写

    支持自增长逐渐、支持Oracle的Sequence机制

    支持Mysql, MongoDB,Oracle, SQL Server, Hive, DB2, PostgreSQL等。

    mycat的缺点

    我能想到的就是他是具有浓厚java基因的产品

    数据增量订阅与消费

    增量订阅和消费模块应当包括binlog日志抓取,binlog日志解析,事件分发过滤(EventSink),存储(EventStore)等主要模块。

    如果需要确保HA可以采用Zookeeper保存各个子模块的状态,让整个增量订阅和消费模块实现无状态化,当然作为consumer(客户端)的状态也可以保存在zk之中。

    整体上通过一个Manager System进行集中管理,分配资源。

    Canal

    AAffA0nNPuCLAAAAAElFTkSuQmCC

    server代表一个canal运行实例,对应于一个jvm

    instance对应于一个数据队列 (1个server对应1..n个instance)

    instance模块:

    eventParser (数据源接入,模拟slave协议和master进行交互,协议解析)

    eventSink (Parser和Store链接器,进行数据过滤,加工,分发的工作)

    eventStore (数据存储)

    metaManager (增量订阅&消费信息管理器)

    注意:一台机器下部署一个canal,一个canal可以运行多个instance(通过配置destinations等), 一般情况下一个client连接一个instance(每个instance可以配置standby功能), 可以多个client连接同一个instance,但是同一时刻只能有一个client消费instance的数据,这个通过zookeeper控制。

    数据库同步

    关于数据库同步这里就贴出相应的技术栈,后期会单独开文章讲解,目前接触的就是mycat和canal

    名称

    otter

    异地双活数据架构基础设施DRC

    JD多中心交易系统

    原理

    基于Canal开源产品,获取数据库增量日志数据典型管理系统架构manager(Web管理)+node(工作节点)manager行时推送同步配置到node节点node节点将同步状态反馈到manager上基于zookeeper,解决分布式状态调度的,允许多node节点之间协同工作。

    所谓异地双活主要关注两件事,一个数据同步,一个数据分发。异地双活重点做了几件事。一个是热插拔,可以做到在业务高峰时增加节点,高峰过了把增加的节点关闭。做到这个的一个关键是流量实时切换 ,DRC可以在20秒以内把一个单元(region)的流量迁移到另一个单元。另一个是数据实时恢复,就是通过一定的冗余设计,一旦一个单元挂掉了,可以在另一个单元做全量恢复

    多中心交易系统通过数据总线JingoBus进行快速数据交换,同步性能是mysql的3倍以上,而且可用性高,架构灵活。其中,全新的总线设计解决了多中心交易跨机房的数据库复制和多数据源间的数据异构同步等难题,实现了高性能、低延时、健壮的数据同步机制

    作用

    异构库
    mysql->mysql、oracle. (目前开原版只支持mysql增量,目标库可以是mysql或者oracle,取决于canal的功能)
    单机房同步(数据库之间RTT(Round-Trip Time)<1ms)
    数据库版本升级
    数据表迁移
    异步二级索引
    双向同步
    文件同步

    异地多活中DRC的核心能力就是在低延迟,一致性和高可用一致性:基于日志流式抓取、回放库表结构变更、基于事务的冲突检测。低延迟:最大延迟不超过1s, 消息协议优化,三级数据存储,预读优化IO, 多连接复用和传输压缩,高效的并发复制算法。高可用:主备切换,拓扑变化,心跳跟踪,多维度容灾。

    Replicator直接连接Relay,消费Relay内存队列中的事务日志。但有些情况下,因为网络抖动、目标库的负载过高等因素,可能导致Replicator相对Relay落后很多。另外,当新的消费端加入同一数据源的订阅者时,新消费端有冷启动的问题。为了避免重新从数据源做全量快照,Snapshot作为Relay的一个特殊消费端,通过一种高吞吐的消费方式,从Relay源源不断的消费在线事务日志,通过对事务日志的有效处理,最终保存了数据源的一份一致快照(Consistent Snapshot),即包括了数据源库表中每一行的最新状态的快照,同时保留了一段比Relay buffer更旧的事务日志(Log Store)。由此看来,数据总线作为一个数据层的通用CDC组件,对于多中心交易项目以及异步复制场景提供了整体解决方案,奠定了项目的核心内容。

    拓展

    Otter调度模型:batch处理+双节点部署。
    Otter数据入库算法
    Otter双向回环控制
    Otter数据一致性
    Otter高可用性
    Otter扩展性

    Otter与DRC的区别:- Otter是阿里B2B的产品,DRC是阿里技术保障团队的产品- Otter是针对MySQL的,DRC可以支持多种类型的数据源- DRC从业务上进行了划分,可以实现单元内封闭,Otter的实现不涉及业务,而是在纯数据库层打通的技术- Otter是双写,DRC是中心写、分中心读,或者都部分写,相互同步。- Otter所处的网络环境较DRC差,解决一致性问题也较复杂(基于trusted source的单向环回的补救,基于时间交集的补救),DRC有两种实现方式,具体参考上面。

    系统包括一个主中心和多个分中心,主中心与分中心之间通过数据总线交换数据。数据流向中,主数据(商品数据、商家数据、用户数据等)的流向从主中心通过数据总线实时同步到分中心,分中心只读;而交易数据(订单数据)的流向从分中心实时同步到主中心;在故障时,会从分中心转移到主中心。在这个系统中,有多处体现分流的概念。通过分流,将用户分配到相应的分中心,一方面响应速度快,用户体验更好,不用跨地域访问数据中心了;另一方面,每个中心服务一定数量的用户,水平扩展性好,也能支撑更大的交易规模了。当然,多数据中心不能盲目干活,还考虑到容灾备份的问题。(支付宝光纤事件)交易系统包括应用和数据部分,应用部分是无状态的,就是说,这些工作是无差别的,一台服务器出问题,我换一台服务器来处理就是了,较容易实现多机房多活。但是数据不一样,多中心交易本质上是一个更大的分布式系统,必然涉及到数据分区、路由、复制、读写一致性、延迟等分布式领域的常见问题。另外,交易流程中依赖和产生的数据和服务有不同的特点。比如商品、促销和价格、库存的读服务,我们可以将之称为基础主数据,它们在用户下单流程中是无法分区的,否则无法实现单机房内流量闭环,也就是说,不能因为分区数据的不一致,导致同一用户在单一流程中看到不同的数据,数据的问题表现在以下几个方面:一、 如何保证数据的即时性和准确性,多中心之间需要同步卖家数据和商品数据,由于是异地部署,最好延时能控制在1秒内。数据正确性也是很大的挑战,因为数据故障跟应用层故障不一样,应用出故障了,可能只影响用户访问;数据写错了无法恢复。2、如何保证路由规则的一致性,要保障这个用户从进来到访问服务,到访问数据库,全链路的路由规则都是完全一致的;如果路由错误,看到的数据不正确。从同城双机房的分布转变为异地多机房的分布,给数据同步带来了新的挑战,因此如何设计数据总线也是项目能否实现的关键因素。通过数据总线JingoBus进行快速数据交换,同步性能是mysql的3倍以上,而且可用性高,架构灵活。其中,全新的总线设计解决了多中心交易跨机房的数据库复制和多数据源间的数据异构同步等难题,实现了高性能、低延时、健壮的数据同步机制。

    数据库迁移

    yugong

    整个数据迁移过程,分为两个部分:

    全量迁移

    增量迁移

    过程描述:

    增量数据收集(创建Oracle表的增量物化视图)

    进行全量复制

    进行增量复制(可并行进行数据校验)

    原库停写,切换到新库

    DataX

    DataX是一个在异构的数据库/文件系统之间高速交换数据的工具,实现了在任意的数据处理系统(RDBMS/Hdfs/Local filesystem)之间的数据交换。

    目前成熟的数据导入导出工具比较多,但是一般都只能用于数据导入或者导出,并且只能支持一个或者几个特定类型的数据库。

    这样带来的一个问题是,如果我们拥有很多不同类型的数据库/文件系统(Mysql/Oracle/Rac/Hive/Other…),并且经常需要在它们之间导入导出数据,那么我们可能需要开发/维护/学习使用一批这样的工具(jdbcdump/dbloader/multithread/getmerge+sqlloader/mysqldumper…)。而且以后每增加一种库类型,我们需要的工具数目将线性增长。(当我们需要将mysql的数据导入oracle的时候,有没有过想从jdbcdump和dbloader上各掰下来一半拼在一起到冲动?)这些工具有些使用文件中转数据,有些使用管道,不同程度的为数据中转带来额外开销,效率差别很非常大。很多工具也无法满足ETL任务中常见的需求,比如日期格式转化,特性字符的转化,编码转换。另外,有些时候,我们希望在一个很短的时间窗口内,将一份数据从一个数据库同时导出到多个不同类型的数据库。DataX正是为了解决这些问题而生

    核心模块介绍:

    DataX完成单个数据同步的作业,我们称之为Job,DataX接受到一个Job之后,将启动一个进程来完成整个作业同步过程。DataX Job模块是单个作业的中枢管理节点,承担了数据清理、子任务切分(将单一作业计算转化为多个子Task)、TaskGroup管理等功能。

    DataXJob启动后,会根据不同的源端切分策略,将Job切分成多个小的Task(子任务),以便于并发执行。Task便是DataX作业的最小单元,每一个Task都会负责一部分数据的同步工作。

    切分多个Task之后,DataX Job会调用Scheduler模块,根据配置的并发数据量,将拆分成的Task重新组合,组装成TaskGroup(任务组)。每一个TaskGroup负责以一定的并发运行完毕分配好的所有Task,默认单个任务组的并发数量为5。

    每一个Task都由TaskGroup负责启动,Task启动后,会固定启动Reader—>Channel—>Writer的线程来完成任务同步工作。

    DataX作业运行起来之后, Job监控并等待多个TaskGroup模块任务完成,等待所有TaskGroup任务完成后Job成功退出。否则,异常退出,进程退出值非0。

    DataX调度流程:

    举例来说,用户提交了一个DataX作业,并且配置了20个并发,目的是将一个100张分表的mysql数据同步到odps里面。 DataX的调度决策思路是:

    DataXJob根据分库分表切分成了100个Task。

    根据20个并发,DataX计算共需要分配4个TaskGroup。

    4个TaskGroup平分切分好的100个Task,每一个TaskGroup负责以5个并发共计运行25个Task。

    展开全文
  • 数据库中间件技术的研究与应用

    千次阅读 2014-07-22 08:56:34
    数据库和计算机网络之间的联系和应用越来越紧密,对数据库访问时的功能、性能、安全等要求越来越高,传统的简单的C/S模式或者B/S模式已经越来越难以满足日益增长的要求,数据库中间件技术的出现和应用,对传统结构...
       随着网络和信息管理系统的发展,数据库和计算机网络之间的联系和应用越来越紧密,对数据库访问时的功能、性能、安全等要求越来越高,传统的简单的C/S模式或者B/S模式已经越来越难以满足日益增长的要求,数据库中间件技术的出现和应用,对传统结构进行了有效的改进和扩充。
    

            1、数据库中间件的作用

            多媒体教学支撑平台系统.对于数据库的容量和访问能力要求不苛刻.但是它存储的数据类型杂、访问量不固定、后台数据库种类不一、服务器操作系统各异。因此.这一类数据库中间件的作用主要是以下一些:

             1)支持常用大型数据库的各种操作。可以支持ORACLE,INFORMIX,SYBASE,MSSQL,DB2,MYSQL等常用数据库,以及JDBC、ODBC接口。更换数据库只要更换相应的驱动就可以,而不需要修改所开发软件系统的代码,方便安全。

             2)提供统一接口。屏蔽数据库之间的操作差异。

             3)封装复杂烦琐的数据库应用接口和数据库操作过程,简化应用程序的数据库操作.提高应用程序开发效率。

             4)支持常用的操作系统。如Windows、UNIX、Linux等常见主流操作系统。跨平台支持。便于应用代码在各平台之间的移植。

             2、数据库中间件的设计

             客户端到数据连接管理器之间的是逻辑连接,而数据库到数据连接器之间的是物理连接。

             数据库中间件位于客户端与数据库之间把二者隔离开来。中间件与各个客户之间的数据通讯采用流套接字实现,多个连接由多个线程完成,这种并发的通讯机制使得访问效率大大提高。中间件与数据库之间采用JDBC连接,多用户共享一个数据连接。同样起到了提高数据库访问效率的效果。数据库中间件对数据库的访问和操作采用SQL语言。

            数据库中间件的核心是数据连接管理器,它是一个服务程序,连接了客户端和后台数据库。客户端向其发出对数据库的访问请求,由数据连接管理器寻找与该数据库的可用连接,通过数据连接将访问请求传递给目标数据库。目标数据库执行相应的SQL语句,将结果通过数据连接传回数据连接管理器,再传回给客户端。

             3、常用的数据库中间件种类

            3.1通用网关接口CGI

            CGI是Web服务器与CGI应用程序之间进行信息传递的一种标准,是目前访问数据库最常用的方法之一,它移植性好。几乎所有的Web服务器都支持CGI标准,CGI程序驻留在Web服务器上,当Web服务器受到客户浏览器的请求后,执行相应的CGI程序,并通过Webserve将结果返回给浏览器。CGI有一个致命的弱点,那就是CGI程序不能被多个客户请求共享。每当接到一个请求后,即使有一个该CGI程序的实例在运行,也必须重新启动一个相同的实例。即创建一个并发进程,并发请求越多,创建的并发进程越多,占用的内存空间越大,这样就限制了应用程序自身所用的内存资源,而且每个请求创建一个进程一也会消耗很多时间,在需要多个数据库连接的多用户应用中,采用CGI来连接数据库势必会随着用户的增加而延长用户连接数据库的等待时间,使系统的性能降低,并可导致系统最终的崩溃。

             3.2 WebAPI

             WebAPI同CGI一样也是一种中间件,它是针对CGI程序的诸多不足而提出的,为了提高webserver与数据库服务器的通信效率和性能。Netscape和Microsoft推出了运行于各自服务器软件的NSAPI和ISAPI。与比工作为独立运行机制不同,这些API都是以DLL形式提供的,它们和Webserve软件处少相同地址空间,webserve进程可以直接调用这些webAPI。所以,使用界webAPI的速度明显快于CGI程序,功能也比较强大,但它也有缺点,如NSAPI和ISAPI互不兼容,只能运行在特定的Web服务器和操作系统之上,互相不能移植。

            3.3 DJBC技术

            针对CGI和webAPI的上述缺点,人们借鉴了ODBC成功的经验,开发出了Java语言的数据库访问接口DJBC。它由一组用Java语言写成的类和接口组成。与DJBC类似,也是通过数据库驱动程序管理器调用具体数据库驱动程序来向数据库SQL语句,支持对多种数据库的访问。由于Java语言与平台无关,以利用DJBCAPI写成的访问数据库的程序具有很好的通用性,移植方便,但由于Java的性能问题,DJBC访问数据库的速度很慢,对系统硬件的要求也很高。

             4、数据库中间件方法的优缺点

             移植性好中间件封装了各种与平台有关的细节,使更换操作系统和通信协议等底层的配置无需改变应用程序代码。

             集成方便中间件可以非常容易的集成到应用开发环境中,无需大的代码改动。

            易于扩充中间件的局部改进和整体升级只要保持对外接口不变就不会影响到系统的其他部分,在功能上对应用程序实现了透明性。

            使用简单中间件对各种数据源使用统一的访问方法,使用户不必关心数据库选择等琐碎的操作,降低了用户参与的程度。

            中间件方法比使用传统的数据库访问方法具有独有的好处,任何一个DBMS都有连接数据库用户数的限制,不可能无限制的接收用户连接。按传统方式连接数据库,需要先建立数据连接,然后通过这个用户连接进行数据库操作。这时就会受到数据库用户数的限制。当与DBMS连接的用户数量达到这个上限时,新的用户连接请求就会失败,使用数据库中间件技术访问数据库的思想是把数据库连接的操作从客户端向后移到中间层,这样多个用户就可以共享一个数据库连接,从而增加了用户的访问数量。但这样做的缺点是数据库操作比较集中,统一由数据库中间件负责数据间的同步及点到点的通信,对数据库中间件的可靠性要求比较高,一旦中间件出现问题,所有的数据连接都将断掉。从而导致系统的瘫痪。这种方法尤其不适合高性能的应用处理。因为它需要大量的数据通信,对数据库中间件的要求将更加严格。

    参考文献:

    [1] 数据库中间件的研究及其应用 张宗军 商场现代化 2010(9)

    [2] 智能化数据库中间件的设计与实现 俞国红 廊坊师范学院学报(自然科学版) 2010(1)

    [3] 中间件技术在数据库开发中的应用 万长辉 硅谷 2008(24)

    转载来源:http://blog.csdn.net/jfkidear/article/details/7272787

    展开全文
  • Mycat是一个开源的高性能的数据库中间件,主要用于数据库的分库分表的操作,解决单库单表数据量过大的性能问题。 主要介绍了Mycat的基本概念、原理特性、开发环境搭建、详细的相关配置、Mycat常用分片规则以及支持的...
  • 解决的问题 ...最上层的是分布式数据库分表分库中间件,读写分离,水平扩容 –》代表中间件有(Cobar,Mycat,tddl,drds,ddb) 增量数据订阅和消费,用户对数据库操作,比如DML DDL DCL操作,中间件可...

    解决的问题

    数据库相关平台主要解决以下三个方面的问题

    • 为海量前台数据提供高性能、大容量、高可用性的访问
    • 为数据变更的消费提供准实时的保障
    • 高效的异地数据同步

    数据库架构图

    上图的讲解
    • 最上层的是分布式数据库分表分库中间件,读写分离,水平扩容 –》代表中间件有(Cobar,Mycat,tddl,drds,ddb)
    • 增量数据订阅和消费,用户对数据库操作,比如DML DDL DCL操作,中间件可以监控这些操作所产生的增量数据。典型代表Canal,根据MySQL的binlog实现。也有针对Oracle(redolog)的增量数据订阅与消费的中间件有 Canal,erosa
    • 数据库同步中间件涉及数据库之间的同步操作,可以实现跨(同)机房同步以及异地容灾备份、分流等功能。可以涉及多种数据库,处理之后的数据也可以以多种形式存储。(Otter, JingoBus, DRC)
    • 数据库与数据库之间会有数据迁移(同步)的动作,同款数据同步原理比较简单,比如MySQL主备同步,只要在数据库层进行相应的配置既可,但是跨数据库同步就比较复杂了,比如Oracle->MySQL. 数据迁移一般包括三个步骤:全量复制,将原数据库的数据全量迁移到新数据库,在这迁移的过程中也会有新的数据产生;增量同步,对新产生的数据进行同步,并持续一段时间以保证数据同步;原库停写,切换新库。将“跨数据库”这个含义扩大一下——“跨数据源”,比如HDFS, HBase, FTP等都可以相互同步。(yugong, DataX)

    数据库中间件举例

    • 分布式数据库分表分库
    • 数据增量订阅与消费
    • 数据库同步(全量,增量,跨机房,复制)
    • 跨数据库(数据源)迁移

    分布式数据库

    分表分库类的中间件主要有两种形式向应用提供服务

    • 一种是以JDBC的jar包形式为Java应用提供直接依赖,Java应用通过提供的JDBC包实现透明访问分布式数据库集群中的各个分库分表,典型代表网易的DDB和阿里的TDDL.
    • 另一种是为应用部署独立的服务来满足应用分库分表的需求,在这种方式下通过标准JDBC访问Proxy,而Proxy则根据MySQL标准通信协议对客户端请求解析,还原应用SQL请求,然后通过本地访问数据库集群,最后再将得到的结果根据MySQL标准通信协议编码返回给客户端。典型代表阿里的Cobar, Cobar变种MyCAT, 阿里的DRDS,网易的DDB proxy模式以及DDB的私有云模式。

    Mycat

    这里就不对Cobar做介绍了,目前来看Cobar的发起人的离职导致维护也停止了,整个开发不算完备所以直接跳过,介绍MyCat
    从定义和分类看,它是一个开源的分布式数据库系统,是一个实现了MySQL协议的Server,前端用户可以把它看做是一个数据库代理,用MySQL客户端工具和命令行访问,而其后端可以用MySQL Native Protocol与多个MySQL服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信,其核心功能是分表分库,即将一个大表水平分割为N个小表,存储在后端MySQL服务器里或者其他数据库里。

    MyCAT发展到目前的版本,已经不是一个单纯的MySQL代理了,它的后端可以支持MySQL, SQL Server, Oracle, DB2, PostgreSQL等主流数据库,也支持MongoDB这种新型NoSQL方式的存储,未来还会支持更多类型的存储。

    MyCAT是一个强大的数据库中间件,不仅仅可以用作读写分离,以及分表分库、容灾管理,而且可以用于多租户应用开发、云平台基础设施,让你的架构具备很强的适应性和灵活性,借助于即将发布的MyCAT只能优化模块,系统的数据访问瓶颈和热点一目了然,根据这些统计分析数据,你可以自动或手工调整后端存储,将不同的表隐射到不同存储引擎上,而整个应用的代码一行也不用改变。
    MyCAT和Cobar比较有两个显著提高:

    • 后端由BIO改为NIO,并发量有大幅提高
    • 增加了对Order By, Group By, Limit等聚合功能(虽然Cobar也可以支持Order By, Group By, Limit语法,但是结果没有进行聚合,只是简单返回给前端,聚合功能还是需要业务系统自己完成)
      Mycat架构

      • 事务是弱XA含义:分布式事务处理( Distributed Transaction Processing , DTP )指一个程序或程序段,在一个或多个资源如数据库或文件上为完成某些功能的执行过程的集合,分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作,提交或回滚事务的决定必须产生统一的结果(全部提交或全部回滚)
      • MyCAT的原理中最重要的一个动词是“拦截”,它拦截了用户发来的SQL语句,首先对SQL语句做了一些特定的分析:如分片分析,路由分析、读写分离分析、缓存分析等,然后将此SQL发往后端的真实数据库,并将返回的结果做适当的处理,最终再返回给用户
      • MyCAT对自身不支持的SQL语句提供了一种解决方案——在要执行的SQL语句前添加额外的一段由注解SQL组织的代码,这样SQL就能正确执行,这段代码称之为“注解”。注解的使用相当于对MyCAT不支持的SQL语句做了一层透明代理转发,直接交给目标的数据节点进行SQL语句执行。
      • MyCAT自身有类似其他数据库的管理监控方式,可以通过MySQL命令行,登录管理端口(9066)执行相应的SQL进行管理,也可以通过jdbc的方式进行远程连接管理
      高可用(HA)

      MySQL的HA

      • MySQL节点开启主从复制的配置方案,并将主节点配置为MyCAT的dataHost里的writeNode,从节点配置为readNode,同时MyCAT内部定期对一个dataHost里的所有writeHost与readHost节点发起心跳检测
      • 正常情况下,MyCAT将第一个writeHost作为写节点,所有的DML SQL会发送此节点
      • 若MyCAT开启了读写分离,则查询节点会根据读写分离的策略发往readHost(+writeHost)执行
      • 如果第一个writeHost宕机,MyCAT会在默认的三次心跳检测失败后,自动切换到下一个可用的writeHost执行DML SQL语句
      • 当原来配置的MySQL写节点宕机恢复后,作为从节点,跟随新的主节点,重新配置主从同步
        MyCAT自身的HA

      • 官方建议是采用基于硬件的负载聚亨或者软件方式的HAproxy等

      • 如果还担心HAproxy的稳定性和但节点问题,则可以用keepalived的VIP的浮动功能,加以强化。

    MyCAT功能和特性

    • 支持SQL 92标准
    • 支持Mysql集群,可以作为Proxy使用
    • 支持JDBC连接多数据库
    • 支持NoSQL数据库
    • 支持galera sfor mysql集群,percona-cluster或者mariadb cluster,提供高可用性分片集群
    • 自动故障切换,高可用性
    • 支持读写分离,支持MySQL双主多从,以及一主多从的模式
    • 支持全局表,数据自动分片到多个节点,用于高效表关联查询
    • 支持一致性Hash分片,有效解决分片扩容难题
    • 多平台支持,部署和试试简单
    • 支持Catelet开发,类似数据库存储过程,用于跨分片复杂SQL的人工智能编码实现
    • 支持NIO与AIO两种网络通信机制,windows下建议AIO,Linux下目前建议NIO
    • 支持MySQL存储过程调用
    • 以插件的方式支持SQL拦截和改写
    • 支持自增长逐渐、支持Oracle的Sequence机制
    • 支持Mysql, MongoDB,Oracle, SQL Server, Hive, DB2, PostgreSQL等。
    mycat的缺点

    我能想到的就是他是具有浓厚java基因的产品

    数据增量订阅与消费

    增量订阅和消费模块应当包括binlog日志抓取,binlog日志解析,事件分发过滤(EventSink),存储(EventStore)等主要模块。

    如果需要确保HA可以采用Zookeeper保存各个子模块的状态,让整个增量订阅和消费模块实现无状态化,当然作为consumer(客户端)的状态也可以保存在zk之中。

    整体上通过一个Manager System进行集中管理,分配资源。

    Canal

    这里写图片描述
    server代表一个canal运行实例,对应于一个jvm

    instance对应于一个数据队列 (1个server对应1..n个instance)

    instance模块:

    • eventParser (数据源接入,模拟slave协议和master进行交互,协议解析)

    • eventSink (Parser和Store链接器,进行数据过滤,加工,分发的工作)

    • eventStore (数据存储)

    • metaManager (增量订阅&消费信息管理器)

      注意:一台机器下部署一个canal,一个canal可以运行多个instance(通过配置destinations等), 一般情况下一个client连接一个instance(每个instance可以配置standby功能), 可以多个client连接同一个instance,但是同一时刻只能有一个client消费instance的数据,这个通过zookeeper控制。

      数据库同步

      关于数据库同步这里就贴出相应的技术栈,后期会单独开文章讲解,目前接触的就是mycat和canal

    名称 otter 异地双活数据架构基础设施DRC JD多中心交易系统
    原理 基于Canal开源产品,获取数据库增量日志数据典型管理系统架构manager(Web管理)+node(工作节点)manager行时推送同步配置到node节点node节点将同步状态反馈到manager上基于zookeeper,解决分布式状态调度的,允许多node节点之间协同工作。 所谓异地双活主要关注两件事,一个数据同步,一个数据分发。异地双活重点做了几件事。一个是热插拔,可以做到在业务高峰时增加节点,高峰过了把增加的节点关闭。做到这个的一个关键是流量实时切换 ,DRC可以在20秒以内把一个单元(region)的流量迁移到另一个单元。另一个是数据实时恢复,就是通过一定的冗余设计,一旦一个单元挂掉了,可以在另一个单元做全量恢复 多中心交易系统通过数据总线JingoBus进行快速数据交换,同步性能是mysql的3倍以上,而且可用性高,架构灵活。其中,全新的总线设计解决了多中心交易跨机房的数据库复制和多数据源间的数据异构同步等难题,实现了高性能、低延时、健壮的数据同步机制
    作用 异构库
    mysql->mysql、oracle. (目前开原版只支持mysql增量,目标库可以是mysql或者oracle,取决于canal的功能)
    单机房同步(数据库之间RTT(Round-Trip Time)<1ms)
    数据库版本升级
    数据表迁移
    异步二级索引
    双向同步
    文件同步
    异地多活中DRC的核心能力就是在低延迟,一致性和高可用一致性:基于日志流式抓取、回放库表结构变更、基于事务的冲突检测。低延迟:最大延迟不超过1s, 消息协议优化,三级数据存储,预读优化IO, 多连接复用和传输压缩,高效的并发复制算法。高可用:主备切换,拓扑变化,心跳跟踪,多维度容灾。 Replicator直接连接Relay,消费Relay内存队列中的事务日志。但有些情况下,因为网络抖动、目标库的负载过高等因素,可能导致Replicator相对Relay落后很多。另外,当新的消费端加入同一数据源的订阅者时,新消费端有冷启动的问题。为了避免重新从数据源做全量快照,Snapshot作为Relay的一个特殊消费端,通过一种高吞吐的消费方式,从Relay源源不断的消费在线事务日志,通过对事务日志的有效处理,最终保存了数据源的一份一致快照(Consistent Snapshot),即包括了数据源库表中每一行的最新状态的快照,同时保留了一段比Relay buffer更旧的事务日志(Log Store)。由此看来,数据总线作为一个数据层的通用CDC组件,对于多中心交易项目以及异步复制场景提供了整体解决方案,奠定了项目的核心内容。
    拓展 Otter调度模型:batch处理+双节点部署。
    Otter数据入库算法
    Otter双向回环控制
    Otter数据一致性
    Otter高可用性
    Otter扩展性
    Otter与DRC的区别:- Otter是阿里B2B的产品,DRC是阿里技术保障团队的产品- Otter是针对MySQL的,DRC可以支持多种类型的数据源- DRC从业务上进行了划分,可以实现单元内封闭,Otter的实现不涉及业务,而是在纯数据库层打通的技术- Otter是双写,DRC是中心写、分中心读,或者都部分写,相互同步。- Otter所处的网络环境较DRC差,解决一致性问题也较复杂(基于trusted source的单向环回的补救,基于时间交集的补救),DRC有两种实现方式,具体参考上面。 系统包括一个主中心和多个分中心,主中心与分中心之间通过数据总线交换数据。数据流向中,主数据(商品数据、商家数据、用户数据等)的流向从主中心通过数据总线实时同步到分中心,分中心只读;而交易数据(订单数据)的流向从分中心实时同步到主中心;在故障时,会从分中心转移到主中心。在这个系统中,有多处体现分流的概念。通过分流,将用户分配到相应的分中心,一方面响应速度快,用户体验更好,不用跨地域访问数据中心了;另一方面,每个中心服务一定数量的用户,水平扩展性好,也能支撑更大的交易规模了。当然,多数据中心不能盲目干活,还考虑到容灾备份的问题。(支付宝光纤事件)交易系统包括应用和数据部分,应用部分是无状态的,就是说,这些工作是无差别的,一台服务器出问题,我换一台服务器来处理就是了,较容易实现多机房多活。但是数据不一样,多中心交易本质上是一个更大的分布式系统,必然涉及到数据分区、路由、复制、读写一致性、延迟等分布式领域的常见问题。另外,交易流程中依赖和产生的数据和服务有不同的特点。比如商品、促销和价格、库存的读服务,我们可以将之称为基础主数据,它们在用户下单流程中是无法分区的,否则无法实现单机房内流量闭环,也就是说,不能因为分区数据的不一致,导致同一用户在单一流程中看到不同的数据,数据的问题表现在以下几个方面:一、 如何保证数据的即时性和准确性,多中心之间需要同步卖家数据和商品数据,由于是异地部署,最好延时能控制在1秒内。数据正确性也是很大的挑战,因为数据故障跟应用层故障不一样,应用出故障了,可能只影响用户访问;数据写错了无法恢复。2、如何保证路由规则的一致性,要保障这个用户从进来到访问服务,到访问数据库,全链路的路由规则都是完全一致的;如果路由错误,看到的数据不正确。从同城双机房的分布转变为异地多机房的分布,给数据同步带来了新的挑战,因此如何设计数据总线也是项目能否实现的关键因素。通过数据总线JingoBus进行快速数据交换,同步性能是mysql的3倍以上,而且可用性高,架构灵活。其中,全新的总线设计解决了多中心交易跨机房的数据库复制和多数据源间的数据异构同步等难题,实现了高性能、低延时、健壮的数据同步机制。

    参考链接

    数据库迁移

    yugong

    整个数据迁移过程,分为两个部分:
    • 全量迁移

    • 增量迁移

    过程描述:
    • 增量数据收集(创建Oracle表的增量物化视图)

    • 进行全量复制

    • 进行增量复制(可并行进行数据校验)

    • 原库停写,切换到新库

      DataX

    DataX是一个在异构的数据库/文件系统之间高速交换数据的工具,实现了在任意的数据处理系统(RDBMS/Hdfs/Local filesystem)之间的数据交换。

    目前成熟的数据导入导出工具比较多,但是一般都只能用于数据导入或者导出,并且只能支持一个或者几个特定类型的数据库。

    这样带来的一个问题是,如果我们拥有很多不同类型的数据库/文件系统(Mysql/Oracle/Rac/Hive/Other…),并且经常需要在它们之间导入导出数据,那么我们可能需要开发/维护/学习使用一批这样的工具(jdbcdump/dbloader/multithread/getmerge+sqlloader/mysqldumper…)。而且以后每增加一种库类型,我们需要的工具数目将线性增长。(当我们需要将mysql的数据导入oracle的时候,有没有过想从jdbcdump和dbloader上各掰下来一半拼在一起到冲动?)这些工具有些使用文件中转数据,有些使用管道,不同程度的为数据中转带来额外开销,效率差别很非常大。很多工具也无法满足ETL任务中常见的需求,比如日期格式转化,特性字符的转化,编码转换。另外,有些时候,我们希望在一个很短的时间窗口内,将一份数据从一个数据库同时导出到多个不同类型的数据库。DataX正是为了解决这些问题而生

    核心模块介绍:

    DataX完成单个数据同步的作业,我们称之为Job,DataX接受到一个Job之后,将启动一个进程来完成整个作业同步过程。DataX Job模块是单个作业的中枢管理节点,承担了数据清理、子任务切分(将单一作业计算转化为多个子Task)、TaskGroup管理等功能。

    DataXJob启动后,会根据不同的源端切分策略,将Job切分成多个小的Task(子任务),以便于并发执行。Task便是DataX作业的最小单元,每一个Task都会负责一部分数据的同步工作。

    切分多个Task之后,DataX Job会调用Scheduler模块,根据配置的并发数据量,将拆分成的Task重新组合,组装成TaskGroup(任务组)。每一个TaskGroup负责以一定的并发运行完毕分配好的所有Task,默认单个任务组的并发数量为5。

    每一个Task都由TaskGroup负责启动,Task启动后,会固定启动Reader—>Channel—>Writer的线程来完成任务同步工作。

    DataX作业运行起来之后, Job监控并等待多个TaskGroup模块任务完成,等待所有TaskGroup任务完成后Job成功退出。否则,异常退出,进程退出值非0。

    DataX调度流程:

    举例来说,用户提交了一个DataX作业,并且配置了20个并发,目的是将一个100张分表的mysql数据同步到odps里面。 DataX的调度决策思路是:
    1. DataXJob根据分库分表切分成了100个Task。
    2. 根据20个并发,DataX计算共需要分配4个TaskGroup。
    3. 4个TaskGroup平分切分好的100个Task,每一个TaskGroup负责以5个并发共计运行25个Task。

    展开全文
  • 但是在做数据库中间件的研发的时候不得不考虑这些问题,这个也是我司在数据库中间件开发过程中踩的坑之一,我尽可能用简洁易懂的语言说明踩坑的原理和解决方案,以后有机会会慢慢多写一点。单表数据过大的时候,往往...

    简介

    这篇文章可能有点枯燥,主要涉及的从SQL的原理设计分库分表操作的要点。耐心看完,一定会有收获。

    但是在做数据库中间件的研发的时候不得不考虑这些问题,这个也是我司在数据库中间件开发过程中踩的坑之一,我尽可能用简洁易懂的语言说明踩坑的原理和解决方案,以后有机会会慢慢多写一点。

    单表数据过大的时候,往往需要分表,有几种分表方式,例如针对用户数据可以按照用户ID的Hash进行分表,对于时间序列的流水账(比如IoT,我司是车联网,就是按天分表)采用按小时,按天,按月等分表方式。

    这里说一下多表查询中的聚合逻辑,在这些聚合逻辑的说明中,我们都以ANSI 92 SQL为标准。

    一般聚合逻辑

    SUM/COUNT/MIN/MAX/AVG/……

    除了AVG计算的情形比较特殊,需要拆分为SUM和COUNT单独计算:

    select avg(x) as ax from t_xxx where y=1;

    拆分为:

    select sum(x) as ax_num, count(x) as ax_den from t_xxx_{SUB-TABLE-ID} where y=1;

    最后使用ax_num/ax_den计算得到结果。

    其余的基本上就是在各个分表做操作以后再次聚合即可(即求最大值的最大值,求和的和……),这个没什么可说的。

    下面我们只针对SUM、MIN,MAX,COUNT作讨论。

    带有其他坑爹约束时候的聚合函数详解

    如果一个语句带有Group By、Order By,Limit的时候事情就不是那么简单了。(TOP我们可以解析为这三个操作的组合上,暂不考虑)

    正常来说,我们应该把所有的子句在各个分表上都执行一遍然后再聚合,但是ANSI SQL眉头一皱,发现事情没有那么简单:

    正常聚合即可的操作组合

    group by a

    group by a order by b

    group by a limit x, y

    limit x, y

    需要改变SQL语句的坑爹操作

    1、order by b limit x, y

    这个时候需要将在子库上运行的语句变为order by b limit 0, y。

    原理很简单,举个小栗子就可以说明:如果要求全年级考试成绩的5~10名,那么应该是拿出每个班的1~10名进行比较而不是拿出每个班的5~10名进行比较。

    2、group by a order by b limit x, y

    这个时候需要去掉limit条件,变为group by a order by b,这个原理也不复杂,也是一个小栗子就可以说明:

    如果要求考试总成绩的5~10名,那么应该将所有学生的成绩都算出来再求,而不是求每个考试科目的前十名,这样有可能会漏掉一些学生得到成绩。

    注意点

    两个需要改变limit条件的语句要慎用,否则可能会造成一些性能问题。

    总结

    分库分表是个好东西,但是不要滥用,单个MySQL的表撑个几百万到千万的数据是轻轻松松的,如果使用MongoDB到亿级别都是OK的,没有迫切的性能需求不要乱分表,否则考虑的事情就多了……

    展开全文
  • Web数据库中间件技术

    2008-04-30 21:56:00
    数据库中间件技术 曾晓金   (云南工业大学计算机应用重点实验室 昆明 650051) 摘要:介绍了 Web 数据库的几种中间件解决方案,并比较了它们的特色与不足,以及 Web 数据库出现的相应最新技术。 关键词:...
  • MyCat数据库分库分表数据读写分离中间件 Author:xusy 不怕从零开始 只怕从未启程 Mycat诞生:2013年阿里的Cobar在社区使用过程中发现存在一些比较严重的问题,及其使用限制,经过mycat发人第一次改良,第一代...
  • 本文阐述了数据库中间件的概念、功能、原理,介绍了现今数据库中间件的几种主要技术,并进行了比较。 关键词:数据库中间件技术比较
  • 系统架构随着业务的变化演进,从而推动各种技术的发展,而数据库中间件技术就是在架构演进中出现的。 (1)初始架构方案 初始架构如上图所示。我们初始在单机上同时部署tomcat和DB。客户端访问的时候,首先通过...
  • 假如让你来设计数据库中间件

    千次阅读 2018-11-04 10:03:51
    最近在网上逛的时候看到一篇关于数据库... 可以了解下数据库中间件技术 可以了解下架构师系统设计的思路   一、总体目标 数据库中间层项目背景不再展开,根据前期的调研以及和公司同事的讨论,中间层的核...
  • 数据库中间件mycat

    2016-01-27 09:50:31
    什么是MyCAT?简单的说,MyCAT就是: • 一个彻底开源的,面向企业应用开发的“大数据库集群” • 支持事务、ACID、可以替代Mysql的加强版数据库 • 一个可以视为“Mysql”集群的企业...• 一个新颖的数据库中间件产品
  • 文章目录数据库中间件设计要点数据库拆分数据库拆分 - 垂直拆分数据库拆分 - 水平拆分水平拆分 - 分片规则分库分表的技术难点数据库中间件的两种实现模式常用数据库中间件简介 数据库中间件设计要点 数据库拆分 ...
  • Mycat数据库中间件

    2020-09-17 22:27:31
    1、什么是MyCat 1、一个彻底开源的,面向企业应用开发的大数据库集群 2、支持事务、ACID、可以替代MySQL的加强版数据库 3、一个可以视为MySQL集群的企业级数据库,用来替代昂贵的...6、一个新颖的数据库中间件产品
  • 数据库中间件 数据库中间件-dble 参考:http://www.sohu.com/a/291248428_100251585 安装目录:/opt/soft/dble 启用:./dble restart 客户端工具 Navicat premium Navicat是一套快速、可靠并...
  • 分布式数据库中间件 ShardingSphere 将 Sea t a 分布式事务能力进行整合,旨在打造一致性更强的分布式 数据库中间件 。背景数据库领域,分布式事务的实现主要包含:两阶段的 XA 和 BASE 柔性事务。XA 事务底层,依赖...
  • 数据库中间件详解

    千次阅读 2019-07-01 09:34:14
    数据库中间件详解 原创:田守枝田守枝的技术博客3月24日 1数据库拆分过程及挑战 互联网当下的数据库拆分过程基本遵循的顺序是:垂直拆分、读写分离、分库分表(水平拆分)。每个拆分过程都能解决业务上的一些问题...
  • myCAT 是一个彻底开源的,面向企业应用开发的“大数据库集群” 支持... 一个新颖的数据库中间件产品。 一.什么是MyCat? MyCat是目前最流行的基于Java语言编写的数据库中间件,是一个实现了MySql协议的服务器,其核
  • 前言碎语好久没更博了,今天引用美团技术团队的一篇文章来给大家分享一款数据库中间件-美团DBProxy!我们都知道,随着数据量的不断增大,传统的直连数据库对数据进行访问的方式已经无法满足一般公司的需求。相对于...
  • 为您提供Mycat数据库中间件下载,MyCAT是一种开源软件,是面向企业的“大型数据库集群”。MyCAT是一个强制数据库,可以替代MySQL,并支持事务和ACID。作为企业数据库的MySQL群集,MyCAT可以代替昂贵的Oracle群集。...
  • 数据库中间件MyCat

    2019-09-16 05:58:26
    什么是MyCat? 查看官网的介绍是这样说的 一个彻底开源的,面向企业应用开发的大数据库集群 支持事务、ACID、可以替代MySQL的加强版数据库 一个可以视为MySQL集群的... 一个融合内存缓存技术、NoSQL技术...
  • 因为 MyCat 是一个分布式数据库中间件,要理解 MyCat ,那你就得先知道到底什么是中间件! 中间件简介 说起中间件,很多人首先想到的就是消息中间件,那么除了消息中间件呢?其实我们日常开发中,接触到的中间件太多...
  • 分布式数据库中间件 ShardingSphere 将 Sea t a 分布式事务能力进行整合,旨在打造一致性更强的分布式 数据库中间件 。背景数据库领域,分布式事务的实现主要包含:两阶段的 XA 和 BASE 柔性事务。XA 事务底层,依赖...
  • 分布式存储系统数据库中间件-Mycat 官方文档网站:http://mycat.org.cn/ Mycat基本定义 一个彻底开源的,面向企业应用开发的大数据库集群 支持事务、ACID、可以替代MySQL的加强版数据库 一个可以视为MySQL...
  • 在互联网飞速发展,数据量成指数级爆发的背景下,数据库中间件MyCAT满足了...下面从技术难点与实现效果将数据库中间件MyCAT VS 分布式事务数据库 HotDB做如下比较: 最后,不得不提现在企业信息化对分布式事务数
  • 转载自 Mycat - 数据库分库分表中间件,国内最活跃的、性能最好的开源数据库中间件Mycat是什么Mycat - 数据库分库分表中间件,国内最活跃的、性能最好的开源数据库中间件!一个彻底开源的,面向企业应用开发的大...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,010
精华内容 1,204
关键字:

数据库中间件技术