精华内容
下载资源
问答
  • 最近项目使用分布式数据库中间件 ,后端数据库使用到Oracle ,使用客户端工具连接 ,发现中间件使用JDBC连接方式连接后端数据库为Oracle、SQL Server /DB2等 不显示表名 ,查询数据必须使用SQL命令窗口执行,但是SQL...

    最近项目使用分布式数据库中间件 ,后端数据库使用到Oracle ,使用客户端工具连接 ,发现中间件使用JDBC连接方式连接后端数据库为Oracle、SQL Server /DB2等 不显示表名 ,查询数据必须使用SQL命令窗口执行,但是SQL命令窗口执行SQL时,也不提示表名 字段名 、给开发人员和数据库运维人员带来极大的不便,偷窥一下源码 ,也许这个不是最好的解决,欢迎吐槽和转载 。。。

    问题:

    用 Navicat Client 、MySQL 客户端 连接数据库中间件(MyCat),中间件连接不显示表名称, 后端数据库是Oracle、DB2等  效果图如下:


        解决方式

    涉及类 : JDBCConnection 主要解决Oracle 表显示    【已解决】 需要完善表显示数据和分片节点 后续迁移到 io.mycat.backend.jdbc.oracle.ShowTables中

    修个内容:

    private void executeSQL(RouteResultsetNode rrn, ServerConnection sc,
                                boolean autocommit) throws IOException {
            String orgin = rrn.getStatement();
            // String sql = rrn.getStatement().toLowerCase();
             LOGGER.debug("JDBC SQL:"+orgin+"|"+sc.toString());
            if (!modifiedSQLExecuted && rrn.isModifySQL()) {
                modifiedSQLExecuted = true;
            }

            try {
                syncIsolation(sc.getTxIsolation()) ;
                if (!this.schema.equals(this.oldSchema)) {
                    con.setCatalog(schema);
                    this.oldSchema = schema;
                }
                if (!this.isSpark) {
                    con.setAutoCommit(autocommit);
                }
                int sqlType = rrn.getSqlType();
                 if( rrn.isCallStatement() && "oracle".equalsIgnoreCase(getDbType()))
                 {
                     //存储过程暂时只支持oracle
                     ouputCallStatement(rrn,sc,orgin);
                 } else if (sqlType == ServerParse.SELECT || sqlType == ServerParse.SHOW) {
                    if( (sqlType == ServerParse.SHOW) && (!dbType.equals("MYSQL")) ) {
                        // showCMD(sc, orgin);
                        //ShowVariables.execute(sc, orgin);
                        boolean showExecute = true;
                        if ("SHOW TABLES".equalsIgnoreCase(orgin)){
                             orgin = "SELECT TABLE_NAME FROM  USER_TABLES" ;
                        } else if ("SHOW FULL TABLES WHERE Table_type != 'VIEW'".equalsIgnoreCase(orgin)){
                             orgin = " SELECT OBJECT_NAME,'BASE TABLE' AS Table_type FROM USER_OBJECTS WHERE OBJECT_TYPE='TABLE' ";
                        } else if ("SHOW TABLE STATUS".equalsIgnoreCase(orgin)){
                             StringBuffer sb = new StringBuffer();
                             sb.append(" SELECT  A.TABLE_NAME,A.NUM_ROWS AS \"Rows\",A.LAST_ANALYZED AS Create_time,A.LAST_ANALYZED AS Update_time,");
                             sb.append(" 'InnoDB' AS ENGINE, '' AS Auto_increment ,  B.COMMENTS AS  \"COMMENT\" ");
                             sb.append(" FROM USER_TABLES A, USER_TAB_COMMENTS B WHERE A.TABLE_NAME = B.TABLE_NAME ORDER BY TABLE_NAME ");
                             orgin = sb.toString();
                        } else {
                             showExecute = false;
                        }
                        
                        if( showExecute ){
                            ouputResultSet(sc, orgin);
                        } else {
                            ShowVariables.execute(sc, orgin,this);
                        }    
                    } else if ("SELECT CONNECTION_ID()".equalsIgnoreCase(orgin)) {
                        //ShowVariables.justReturnValue(sc,String.valueOf(sc.getId()));
                        ShowVariables.justReturnValue(sc,String.valueOf(sc.getId()),this);
                    } else{
                        if("SELECT @@character_set_database, @@collation_database".equalsIgnoreCase(orgin)){
                            orgin = "SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER= 'NLS_CHARACTERSET' ";
                        }
                        ouputResultSet(sc, orgin);
                    }
                } else {
                    executeddl(sc, orgin);
                }

            } catch (SQLException e) {

                String msg = e.getMessage();
                ErrorPacket error = new ErrorPacket();
                error.packetId = ++packetId;
                error.errno = e.getErrorCode();
                error.message = msg.getBytes();
                this.respHandler.errorResponse(error.writeToBytes(sc), this);
            } catch (Exception e) {
                String msg = e.getMessage();
                ErrorPacket error = new ErrorPacket();
                error.packetId = ++packetId;
                error.errno = ErrorCode.ER_UNKNOWN_ERROR;
                error.message = ((msg == null) ? e.toString().getBytes() : msg.getBytes());
                String err = null;
                if(error.message!=null){
                    err = new String(error.message);
                }
                LOGGER.error("sql execute error, "+ err , e);
                this.respHandler.errorResponse(error.writeToBytes(sc), this);
            }
            finally {
                this.running = false;
            }

        }

     

    转载于:https://my.oschina.net/fxdemon/blog/1529697

    展开全文
  • 轻轻的点击下图,试试一键式免费开通DDM实例拆分键拆分算法是在华为云分布式数据库中间件DDM控制台创建逻辑表时进行配置,本文主要介绍如何选择拆分键拆分算法。拆分算法拆分算法即将逻辑表中数据拆分到多个...

    开始前先撒一波福利,感兴趣的小伙伴抓住机会哦。

    官网正在进行一系列的体验活动,了解更多详情请移步官网看看大大大福利~~

    各种配置太麻烦? 轻轻的点击下图,试试一键式免费开通DDM实例

    98ad5d7747dce3b1ea8d6910ebfcb824.png

    拆分键和拆分算法是在华为云分布式数据库中间件DDM控制台创建逻辑表时进行配置,本文主要介绍如何选择拆分键和拆分算法。

    拆分算法

    拆分算法即将逻辑表中数据拆分到多个数据库分片上的算法,华为云分布式数据库中间件DDM当前支持hash和range两种拆分算法。

    hash

    将数据均匀分布在各个分片。

    适用于SQL查询条件使用“=”、“IN”之类运算符相对较多的场景。

    range

    将数据表内的记录按照算法原数据的取值范围进行分片存储。

    适用于SQL查询条件使用“>”、“

    拆分算法的使用,需要结合业务查询场景进行评估,以选择最佳拆分算法,提升DDM效率。

    拆分键

    拆分键是在水平拆分逻辑表的过程中,用于生成路由结果的表字段,指定表字段后,可以进一步选择日期函数,也可以手动输入“日期函数(字段名)”。

    数据表字段必须是日期类型(date、datetime、timestamp),日期函数适用于需要按时间(年、月、日、周及其组合)对数据进行拆分的场景。

    DDM根据拆分键与拆分算法计算路由结果,对分片表的数据进行自动水平拆分,分发到数据分片中。

    选取拆分算法与拆分键一般遵循以下规则:尽可能使数据均匀分布到各个分片上。

    该拆分键是最频繁或者最重要的查询条件。

    优选主键作为拆分键,因为主键作为查询条件时,查询速度最快。

    有明确主体的业务场景

    分片表的数据量一般都达到千万级,因此选择合适的拆分算法和拆分键非常重要。如果能找到业务主体,并且确定绝大部分的数据库操作都是围绕这个主体的数据进行的,那么可以选择这个主体所对应的表字段作为拆分键,进行水平拆分。

    业务逻辑主体与实际应用场景相关,下列场景都有明确的业务逻辑主体。

    银行类客户业务应用,业务逻辑主体是客户,可使用客户对应的表字段(例如客户号)作为拆分键。部分业务系统的业务场景为围绕银行卡/账号的,可以选取卡/账号作为拆分键。

    电商类应用,如果业务场景是围绕商品进行操作,业务逻辑主体是商品,可使用商品对应的表字段(例如商品编码)作为拆分键。

    游戏类的应用,主要围绕玩家数据进行操作,业务逻辑主体是玩家,可使用玩家对应的表字段(例如玩家id)作为拆分键。

    以银行类客户业务为例,建表SQL语句如下:

    CREATE TABLE PERSONALACCOUNT (    ACCOUNT VARCHAR(20) NOT NULL PRIMARY KEY,    NAME VARCHAR(60) NOT NULL,    TYPE VARCHAR(10) NOT NULL,    AVAILABLEBALANCE DECIMAL(18,2) NOT NULL,    STATUS CHAR(1) NOT NULL,    CARDNO VARCHAR(24) NOT NULL,    CUSTOMID VARCHAR(15) NOT NULL) ENGINE=INNODB DEFAULT CHARSET=UTF8;

    建表示例如下图所示。

    thread-10229-1-1.html

    无明确主体的业务场景

    如果业务场景中找不到合适的主体,也可以选择那些数据分布较为均匀的属性所对应的表字段作为拆分键。

    例如日志分析场景,日志系统中可能包含各类复杂的信息,这时您可以选择时间字段作为拆分键。

    选择时间字段作为拆分键时,支持对拆分键使用日期函数拆分。

    为了方便清理和转储,采用range拆分算法,对时间字段用日期函数转换成年,表示按年存储到各个分片上,如下图所示。

    建表SQL语句:

    CREATE TABLE LOG (    LOGTIME DATETIME NOT NULL,    LOGSOURCESYSTEM VARCHAR(100),    LOGDETAIL VARCHAR(10000));

    thread-10229-1-1.html

    展开全文
  • 目前数据库中间件有很多,基本这些中间件在下都有了解使用,各种中间件优缺点及使用场景也都有些心的。所以总结一个关于中间件比较的系列,希望可以对大家有帮助。 1. 什么是中间件 传统的架构模式就是 应用连接...

    分布式数据库中间件对比总结

     

     

    分布式数据库中间件对比总结(1)

    目前数据库中间件有很多,基本这些中间件在下都有了解和使用,各种中间件优缺点及使用场景也都有些心的。所以总结一个关于中间件比较的系列,希望可以对大家有帮助。

    1. 什么是中间件

    传统的架构模式就是 应用连接数据库直接对数据进行访问,这种架构特点就是简单方便。

    但是随着目前数据量不断的增大我们就遇到了问题:

    • 单个表数据量太大
    • 单个库数据量太大
    • 单台数据量服务器压力很大
    • 读写速度遇到瓶颈

    当面临以上问题时,我们会想到的第一种解决方式就是 向上扩展(scale up) 简单来说就是不断增加硬件性能。这种方式只能暂时解决问题,当业务量不断增长时还是解决不了问题。特别是淘宝,facebook,youtube这种业务成线性,甚至指数级上升的情况

    此时我们不得不依赖于第二种方式: 水平扩展 。 直接增加机器,把数据库放到不同服务器上,在应用到数据库之间加一个proxy进行路由,这样就可以解决上面的问题了。

    2. 中间件与读写分离

    很多人都会把中间件认为是读写分离,其实读写分离只是中间件可以提供的一种功能,最主要的功能还是在于他可以 分库分表 ,下面是一个读写分离的示意图:

    分布式数据库中间件对比总结

    上面的图可以看出,红线代表写请求,绿线代表读请求。这就是一个简单的读写分离,下面我们在看看分库分表中间件。

    分布式数据库中间件对比总结

    上面这幅图就可以看出中间件作用,比如下面的这个SQL:

    select * from table_name where id = 1;

    按照中间件分库分表算法,此SQL将发送到DB1节点,由DB1这个MySQL负责解析和获取id=1的数据,并通过中间件返回给客户端。而在读写分离结构中并没有这些分库分表规则, 他只能在众多读节点中load balance随机进行分发,它要求各个节点都要存放一份完整的数据。

    3.各类中间件比较

    目前市面上中间件种类很多种 先看下各种中间件背景:

    分布式数据库中间件对比总结

    Cobar:

    阿里巴巴B2B开发的关系型分布式系统,管理将近3000个MySQL实例。 在阿里经受住了考验,后面由于作者的走开的原因cobar没有人维护 了,阿里也开发了tddl替代cobar。

    MyCAT:

    社区爱好者在阿里cobar基础上进行二次开发,解决了cobar当时存 在的一些问题,并且加入了许多新的功能在其中。目前MyCAT社区活 跃度很高,目前已经有一些公司在使用MyCAT。总体来说支持度比 较高,也会一直维护下去,

    OneProxy:

    数据库界大牛,前支付宝数据库团队领导楼总开发,基于mysql官方 的proxy思想利用c进行开发的,OneProxy是一款商业收费的中间件, 楼总舍去了一些功能点,专注在性能和稳定性上。有朋友测试过说在 高并发下很稳定。

    Vitess:

    这个中间件是Youtube生产在使用的,但是架构很复杂。 与以往中间件不同,使用Vitess应用改动比较大要 使用他提供语言的API接口,我们可以借鉴他其中的一些设计思想。

    Kingshard:

    Kingshard是前360Atlas中间件开发团队的陈菲利用业务时间 用go语言开发的,目前参与开发的人员有3个左右, 目前来看还不是成熟可以使用的产品,需要在不断完善。

    Atlas:

    360团队基于mysql proxy 把lua用C改写。原有版本是支持分表, 目前已经放出了分库分表版本。在网上看到一些朋友经常说在高并 发下会经常挂掉,如果大家要使用需要提前做好测试。

    MaxScale与MySQL Route:

    这两个中间件都算是官方的吧,MaxScale是mariadb (MySQL原作者维护的一个版本)研发的,目前版本不支持分库分表。

    MySQL Route是现在MySQL 官方Oracle公司发布出来的一个中间件。

    这两个中间件后面也会跟进测试下,看下效果如何。

    4. 结语

    这里主要是简单介绍了下各种中间件由来和特点,后面文章会陆续介绍各个中间件更详细的特性,优缺点,性能测试结果

    展开全文
  • 官网说明:Apache ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-ProxySharding-Sidecar(规划中)这3款相互独立,却又能够混合部署配合使用的产品组成。...

    ShardingSphere官网:https://shardingsphere.apache.org/

    什么是ShardingSphere?

    官网说明:

    Apache ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(规划中)这3款相互独立,却又能够混合部署配合使用的产品组成。它们均提供标准化的数据分片、分布式事务和数据库治理功能,可适用于如Java同构、异构语言、云原生等各种多样化的应用场景。

    ShardingSphere定位为关系型数据库中间件,旨在充分合理地在分布式的场景下里用关系型数据库的计算和存储能力,而并非实现一个全新的关系型数据库,它通过关注不变,进而抓住事物本质。关系型数据库当今依然占有巨大市场,是各个公司核心业务的基石,未来也难于撼动,我们目前阶段更加关注在原有基础上的增量,而非颠覆。

    ShardingSphere已经在2020年4月16日成为Apache顶级项目(Apache官网发布从4.0.0版本开始)。

    小结:

    1. 是一套开源的分布式数据库中间件解决方案

    2. 有三个产品Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(TODO)组成

    3. 定位为一个关系型数据库中间件,合理在分布式环境下使用关系型数据库

    什么是Sharding-JDBC

    定位为轻量级Java框架,在Java的JDBC层提供的额外服务。它使用客户端直连数据库,以jar包形式提供服务,无需额外部署和依赖,可理解为增强版的JDBC驱动,完全兼容JDBC和各种ORM框架。

    适用于任何基于JDBC的ORM框架,如:JPA,Hibernate,Mybatis,Spring JDBC Template或直接使用JDBC。支持任何第三方的数据库连接池,如:DBCP,C3P0,Druid,HikariCP等。支持任意实现JDBC规范的数据库。目前支持MySQL,Oracle,SQLServer,PostgreSQL以及任何遵循SQL92便准的数据库。

    什么是Sharding-Proxy

    定位为透明化的数据库代理端,提供封装数据库二进制协议的服务端版本,用于完成对异构语言的支持。目前先提供MySQL/PostgreSQL版本,它可以使用任何兼容MySQL/PostgreSQL协议的访问客户端(如:MySQL Command Client、MySQL Workbench、Navlcat等)操作数据,对DBA更加友好。

    向应用程序完全透明,可直接当做MySQL/PostgreSQL使用。适用于任何兼容MySQL/PostgreSQL协议的客户端。

    什么是分库分表?

    背景:

    随着时间和业务的发展,数据库中表数据将越来越多,此时对我们数据库进行CURD操作,就会有性能问题。

    怎么解决?

    方案1:从硬件上解决,例如:加存储,加内存等 (治标不治本)

    方案2:分库分表

    原始数据库结构简图:

    3a852e6d299e2b80ba73c6a9b39a5fe4.png

    说明:

    原始库设计一般为 一个数据库中多个不同的表。

    分库分表后数据库简图:

    9949c80490fd22de6401251c984e11b0.png

    说明:

    分库分表,将原始设计的数据库拆分为多个数据库,例如:商品数据库、商家数据库等,将原始数据库中的大表拆分为多个表,例如,商品数据库下存放商品表1、商品表2、商品表...,每个表中限制最大存储量,例如20w条。

    当然,以上只是示例,真实分库分表要根据需求来做。

    如何分库分表?

    一、垂直切分

    1. 垂直分表

    例如当前有一个商品表:

    商品名称varchar商品封面varchar商品价格int商品描述varchar商品其他描述varchar

    垂直分表后表为商品基本信息表和商品描述信息表:

    商品基础信息表:

    商品名称varchar商品封面varchar商品价格int

    商品描述信息表:

    商品描述varchar商品其他描述varchar

    说明:

    操作数据库中有某张表,将该表的一部分字段拿出分为一张表,其他字段分为一张表。(按需分配)将其按照字段分为多 个表,数据条数是一致的。

    此时,垂直分表后表仍在一个数据库中,由于表的数量增加了,所以增加了当前数据库的IO,这时我们就需要垂直分库操 作了!

    2. 垂直分库

    在垂直分表中咱们把商品表进行了划分,那现在数据库中假设还有一个订单表,将商品表和订单表划分到商品数据库和订 单数据库,在部署时将两个库划分在两个服务器,这样就减轻了我们每个数据库的IO操作,进而提升CURD操作的效率。

    简而言之就是 把单一数据库按照业务需求进行划分,分为专库专表的形式!

    二、水平切分

    思考:在以上咱们采用了垂直分表分库操作,但依旧有个问题,随时间和业务增加每个表中的数据依旧会很大,怎么办? 难道继续增加服务器,垂直分库分表到不同服务器?垂直分一次行,二次也还行,难道最终一个字段一个表,一个库?当然很 不现实。

    此时,就可以采用水平分库分表操作。

    1. 水平分库

    将商品数据库划分为商品数据库A商品数据库B,判断商品ID为奇数的存入A库,为偶数的存入B库。这样就使假设原本 单库10w条数据的数据库分为了两个数据量5w条的数据库,减少了单库的数据量,提高CURD操作效率。

    2. 水平分表

    以上经过垂直分库分表,水平分库后,仍会造成单表数据量过大的问题,难道再进行水平分库为A.B.C.D.E.F...?如果再 进行水平分库,又将增加服务器,不仅提高了硬件成本,运维起来也很不方便。

    这时,可采用水平分表操作,在垂直分库分表以及水平分库的基础上,将每个服务器上的商品数据库A,B中商品基础信息表和商品描述表水平切分,例如可根据商品ID奇偶来分为商品基础信息表1,2...商品描述信息表1,2...

    这样,就可在不增加服务器的条件下将巨大数据量的单表分为多个数据量一般的表,提高CURD效率。

    三、分库分表的应用场景和问题

    应用场景:

    1. 在数据库设计之初就应该考虑到垂直分库和垂直分表。

    2. 随着数据库数据量的增加,不要马上考虑做水平切分,首先考虑缓存处理,索引,读写分离等方式,如果这些方式不能根本上解决问题,再考虑做水平分库和水平分表。

    问题:

    1. 跨节点连接查询(关联查询)问题(分页、排序怎么做)。

    2. 多数据源管理问题。

    Sharding-JDBC的使用

    注意:Sharding-JDBC不是做分库分表的工具,它有两个主要功能:

    1. 数据分片

    2. 读写分离

    它是通过对sql语义的分析,将读操作和写操作分别路由到主数据库和从数据库。它提供透明化读写分离,让使用者尽量像使用一个数据库一样使用主从数据库集群。(注意:主数据库与从数据库的数据同步,是数据库方面来实现的)

    目的:是为了简化对分库分表以及读写分离的数据库相关操作。

    展开全文
  • MyCat 是一个功能强大的分布式数据库中间件,是一个实现了 MySQL 协议的 Server,前端人员可以把它看做是一个数据库代理中间件,用 MySQL 客户端工具命令行访问;而后端人员可以用 MySQL 原生协议与多个 MySQL ...
  • 什么是分布式数据库中间件 更新时间:2020/06/10 GMT+08:00 查看PDF 分享 分布式数据库中间件(Distributed Database Middleware,简称DDM),是一款分布式关系型数据库,采用先进的存储计算分离架构,实现并发...
  • Mycat:分布式数据库中间件。对数据库用户而言,是数据库代理。Mycat将用户给到逻辑库的SQL语句路由到实际库,访问结果被Mycat处理后返回给用户(如:结果聚合)。Mycat可以屏蔽分库分表的影响,像操作整表整库一样...
  • 分布式存储系统数据库中间件-Mycat 官方文档网站:http://mycat.org.cn/ Mycat基本定义 一个彻底开源的,面向企业应用开发的大数据库集群 支持事务、ACID、可以替代MySQL的加强版数据库 一个可以视为MySQL...
  • 概述ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-ProxySharding-Sidecar(计划中)这3款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务...
  • 比较两个非常流行的开源分布式数据库中间件:Mycat ShardingSphere(包括 Sharding-JDBC、Sharding-Proxy Sharding-Sidecar 3 款产品)。另外还有一个增强版的Mycat:DBLE(专注于 MySQL) 。
  • MyCat:开源分布式数据库中间件 为什么需要MyCat? 虽然云计算时代,传统数据库存在着先天性的弊端,但是NoSQL数据库又无法将其替代。如果传统数据易于扩展,可切分,就可以避免单机(单库)的性能缺陷。 ...
  • 分布式数据库中间件对比总结2016年08月28日 11:19:22阅读数:11082摘要:目前数据库中间件有很多,基本这些中间件在下都有了解使用,各种中间件优缺点及使用场景也都有些心的。所以总结一个关于中间件比较的系列,...
  • 它是 Apache ShardingSphere 从分库分表中间件分布式数据库生态转化的里程碑。从 4.x 版本后期伊始打磨的可插拔架构在 5.x 版本终见雏型,项目的设计理念 API 都随之大幅革新。 本文将向读者阐述其新一代分布式...
  • 华为云分布式数据库中间件(Distributed Database Middleware)是解决数据库容量、性能瓶颈和分布式扩展问题的中间件服务,提供分库分表、读写分离、弹性扩容等能力,应对海量数据的高并发访问场景,有效提升数据库...
  • 希望能mycat之类的分布式数据库中间件打通,这样在配置数据源的时候可以直接连接mycat,数据库分库后,上线SQL,就可以直接一次性将其路由到所有分库去执行相同的SQL。 <p><strong>描述您...
  • 分布式数据库中间件 ShardingSphere 将 Sea t a 分布式事务能力进行整合,旨在打造一致性更强的分布式 数据库中间件 。背景数据库领域,分布式事务的实现主要包含:两阶段的 XA BASE 柔性事务。XA 事务底层,依赖...
  • 日前,分布式数据库中间件ShardingSphere将 Seata 分布式事务能力进行整合,旨在打造一致性更强的分布式数据库中间件。 背景 数据库领域,分布式事务的实现主要包含:两阶段的 XA BASE 柔性事务。XA 事务底层,...
  • 分布式数据库中间件—TDDL 一. 概念 1.分层 Matrix层 作用:实现分库分表逻辑 过程: Sql的解析 规则的匹配与计算 表名替换 Sql转发:将上一步生成的各个sql语句转发到对应的Group进行执行 Group层 作用:...
  • 通俗点这边数据库中间件,介于应用与物理数据库之间。我们操作中间件就像操作一个普通的 MySQL 一样,这就是 MyCat 的优势之一。 数据切分:通过某种特定的条件,将我们存放在同一个数据库中的数据分散存放到多个...
  • 这是华为云Paas推出的分布式数据库中间件,DDM(Distributed Database Middleware)是一个实现了Mysql协议栈的服务器,前端用户可以把它看做一个数据库代理,用Mysql客户端工具命令行访问,而DDM后端连接一到多个...

空空如也

空空如也

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

数据库中间件和分布式数据库