Cobar + MySQL 技术验证(Ali)

一、简介

  Cobar是一个对数据进行拆分后进行分布式存储的产品,可以支持使用后台的 MySQL或者Oracle数据库,通过配置,将数据按照一定规则存储入不同的数据库中。即用分布式数据库代替了集中式数据库。传统的集中式数据库系统有如下不足:集中式处理,势必造成性能瓶颈;应用程序集中在一台计算机上运行,一旦该计算机发生故障,则整个系统受到影响,可靠性不高;集中式处理引起系统的规模和配置都不够灵活,系统的可扩充性差。在这种形势下,集中式数据库将向分布式数据库发展。

  分布式数据库系统的优点:降低费用。分布式数据库在地理上可以是分布的。其系统的结构符合这种分布的要求。允许用户在自己的本地录用、查询、维护等操作,实行局部控制,降低通信代价,避免集中式需要更高要求的硬件设备。而且分布式数据库在单台机器上面数据量较少,其响应速度明显提升;提高系统整体可用性。避免了因为单台数据库的故障而造成全部瘫痪的后果;易于扩展处理能力和系统规模。分布式数据库系统的结构可以很容易地扩展系统,在分布式数据库中增加一个新的节点,不影响现有系统的正常运行。这种方式比扩大集中式系统要灵活经济。在集中式系统中扩大系统和系统升级,由于有硬件不兼容和软件改变困难等缺点,升级的代价常常是昂贵和不可行的。

//优点:
//        配置简单, 可以很方便的实现数据的分布式存储。
//        使用透明, 客户端几乎不需要为此做任何的特殊设定。
//        扩展方便, Cobar服务端可以通过负载均衡进行扩展, 数据库可以根据不同的压力进行扩张。
//
//缺点:
//        查询限制, 如果提交的请求不包含分表字段的限制, 则可能在多个分区执行, 效率和可行性都大打折扣 (碰到过一个普通查询抛出异常的情况, 具体场景还需要验证)
//        联合查询限制, 对于在不同分区的数据, 无法进行联合查询。
//        扩展, 在初始时的分区数目如果无法应对后续需求, 需要增加分区的话 (如, 初始设计分为 64 个分区表, 因为单表通常限制数据量在 20G,
//        后期发现无法满足容量需求, 需要扩展成 128/256 个分区), 没有现成的解决方案, 只能对数据进行人工拆分

  Cobar在分布式数据库领域将致力解决数据切分,应付客户端"集中式"处理分布式数据。这儿集中式是一个相对概念,客户端不需要知道某种数据的物理存储地。避免这种逻辑出现在业务端,大大简化了客户端操作分布式数据的复杂程度。 专注分布式数据库proxy开发。其架设在Client、DB Server(s)之间、对客户端透明、具有负载均衡、高可用性、sql过滤、读写分离、可路由相关的query到目标数据库、可并发请求多台数据库合并结果。

                            

二、Cobar的使用验证

  目前, 我在开发环境 10.20.130.119 上部署了 Cobar 和 MySQL 的测试环境:MySQL 分为 128 个 DataBase, 分别是 cobar_1 至 cobar_128, 端口是 3306, 用户名/密码: root/password。Cobar 的访问方式为使用 MySQL 连接, URL 为 jdbc:mysql://10.20.130.119:8066/cobar, 用户名/密码: root/12345。测试数据库表为 q_reportkeywordsum, 分区所用字段为 custid, int 型。如果使用JDBC方式连接Cobar, 则只需要使用 MySQL的JDBC驱动(注意,不能使用最新的 5.1.13 版本, 需要使用 Cobar 自带的 5.1.6 版 MySQL Connector),正常连接即可。示例代码如下:

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;

public class CobarHelloWorld {

    public void mian(String[] args) {
        String url = "jdbc:mysql://10.20.130.119:8066/cobar";
        String driver = "com.mysql.jdbc.Driver";
        String user = "root";
        String pwd = "12345";
        Connection con = null;
        try {
            Class.forName(driver).newInstance();
            con = DriverManager.getConnection(url, user, pwd);
            Statement stmt = con.createStatement();
            // TODO
            stmt.close();
        } catch (Exception e) {
            // ...
        } finally {
            if (con != null) {
                try {
                    con.close();
                } catch (SQLException e) {
                    e.printStackTrace();
                }
            }
        }
    }
}

如果使用 Spring + iBatis 访问, 则需要对配置文件作少许改动, 将原org.springframework.orm.ibatis.SqlMapClientTemplate 替换为 Cobar Client 提供的com.alibaba.cobar.client.CobarSqlMapClientTemplate。同时, 将TransactionManager从原 org.springframework.jdbc.datasource.DataSourceTransactionManager替换为 com.alibaba.cobar.client.transaction.MultipleDataSourcesTransactionManager,其他部分不需要改动, 修改后的配置代码类似以下示例:

<bean id="sqlMapClientTemplate" class="com.alibaba.cobar.client.CobarSqlMapClientTemplate">
<property name="sqlMapClient" ref="sqlMapClient"/>
...
</bean>

<bean id="transactionManager" class="com.alibaba.cobar.client.transaction.MultipleDataSourcesTransactionManager">
...
</bean>

<bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="configLocation" value="classpath:META-INF/ibatis/sqlmap-config.xml" />
</bean>

<bean id="dataSource" ...>
...
</bean>

开发注意点:如果查询条件不包含分区字段条件, 则会将请求在所有的分区执行后返回全部结果集, 如执行:

select count(*) from q_reportkeywordsum

则返回所有分区中的查询结果 (如分区为 128 个, 则结果集中包含 128 个记录). 而且, 在这样的情况下, 效率会很差, 需要等待 128 个分区全部执行完后才会返回结果集.解决: 所有查询都 必须 限定在某一指定的分区字段, 如

select count(*) from q_reportkeywordsum where custid=1

但是,要注意:select count(*) from q_reportkeyworsum where custid < 10; 代码是不能正确返回结果的。同样的,如果插入记录时不指定分区字段, 则会在所有分区表内均插入记录, 如执行:

insert into q_reportkeywordsum (id, keywordid) values (2, ...)

将会在全部 128 个分区内均插入本条记录。解决: 对于用作分区规则的字段 (如示例中所用 custid) 必须设置为非空 (NOT NULL) 字段,以避免此类问题。对于不同的分区表, 数据库主键可以重复, 这一点从上一段即可看出, id 作为主键字段, 插入过程会在所有分区中均插入一条 id 为 2 的记录, 因此, 需要额外使用主键生成机制保障在不同表内的主键不会发生重复。

三、Cobar使用约束

Cobar表的水平拆分,上图中,数据库表被水平拆分成2份,分别放到两个库中。F( x )是拆分函数,它根据每一条记录的拆分字段的取值,决定将这条记录拆分到哪个库里。拆分函数可以是多元函数,即 F(x1,x2,..xn)。但是对任意一个拆分函数,不存在该函数的两个自变量xi,xj,使得 xi 和 xj 是来自不同拆分表的拆分字段。

左图所示,cobar位于应用和数据库之间,cobar与应用通过mysql protocol交互。若应用发来的sql语句中包含拆分字段(拆分函数的自变量),以左图方式工作:否则,根据配置,以右图方式工作,或直接报错。

// 如果应用和cobar之间通过F5连接,那么F5与cobar的连接保持时间设置为1小时。
// 应用必须通过mysql-connector-5.0.4连接cobar,拆分函数值域元素数最大1024
// 不支持DDL,不支持事务,不允许跨库的join、跨库的子查询、跨库的分页排序
// 对于操作拆分表的sql语句,需包含拆分字段,方式如下:
// 1.对select, delete, update语句,拆分字段存在于where中,以c[i]=xx的形式存在(运算符必须是=、xx必须是某个具体值,不能是字段名或子查询结果)
// 2.insert语句(insert into table (c1, c2 ...) values (value1,value2); insert into table set
// c1=value1,c2=....)中拆分字段出现在红色部分中,同时拆分字段对应的valueXX也必须是某个具体值。

// 建议:
// 1. 记录数小于1千万或表空间小于10G的,不做拆分。
// 2. F(拆分字段取值)服从均匀分布,其中F是拆分函数。

备注:

利用Redis解决MySQL分表自增ID的问题。采用redis的ID自增生成器 就行,每次插入之前,都去调用一个自增长的函数,返回的数值永远是唯一,全局唯一的。

 

时间: 2024-10-10 07:56:52

Cobar + MySQL 技术验证(Ali)的相关文章

MySQL技术内幕-InnoDB存储引擎-读书笔记(二)

MySQL技术内幕-InnoDB存储引擎-读书笔记(二) 作为php开发,使用mysql总是少不了的 系列文章博客链接 http://itsong.net/articles/466.html 第三章 文件 mysql与innodb几个类型的文件 参数文件,配置路径.初始化参数.内存大小等 日志文件,包括错误日志,二进制日志,慢查询日志,查询日志 socket文件,用unix域套接字,unix domain socket来进行连接时需要的文件,这一般是本机连接,比通常tcp快 pid文件,进程id

《mysql技术内幕 InnoDB存储引擎(第二版)》阅读笔记

一.mysql架构 mysql是一个单进程多线程架构的数据库. 二.存储引擎 InnoDB: 支持事务 行锁 读操作无锁 4种隔离级别,默认为repeatable 自适应hash索引 每张表的存储都是按主键的顺序记性存放 支持全文索引(InnoDB1.2.x - mysql5.6) 支持MVCC(多版本并发控制)实现高并发 MyISAM: 不支持事务 表锁 支持全文索引 三.InnoDB体系架构 1.后台线程 Master Thread 负责将缓冲池中的数据异步刷新到磁盘,保证数据的一致性 IO

MySQL技术内幕-InnoDB存储引擎-读书笔记(一)

MySQL技术内幕-InnoDB存储引擎-读书笔记(一) 作为php开发,使用mysql总是少不了的 博客链接 http://itsong.net/articles/466.html 第一章 MySQL体系结构和存储引擎 MySQL被设计为一个单进程多线程架构的数据库 ./mysql --help | grep my.cnf 可以查看mysql数据库实例启动时,它会在哪些位置查找配置文件. 配置文件中有一个datadir参数,指定了数据库所在的路径.默认为/usr/local/mysql/dat

mysql技术内幕InnoDB存储引擎-阅读笔记

mysql技术内幕InnoDB存储引擎这本书断断续续看了近10天左右,应该说作者有比较丰富的开发水平,在源码级别上分析的比较透彻.如果结合高可用mysql和高性能mysql来看或许效果会更好,可惜书太厚,还在啃当中,希望能早点读完……. 应该说与oracle相比,mysql数据库还是相对比简单,以后还是深入学习下oracle去. 搞数据库也比搞应用运维相对单纯,不用知道各种应用架构,不用写各种脚本工具,只要掌握这个软件就足够了.当然希望自己的知识还是全面一些好.

基于SSH2+Maven+EasyUI+MySQL技术实战开发易买网电子商务交易平台【课程分享】

链接:http://pan.baidu.com/share/link?shareid=1334596560&uk=3611155194 密码:ffna 对这个课程有兴趣的朋友可以加我的QQ2059055336和我联系 课程讲师:IT小生 课程分类:Java 适合人群:中级 课时数量:52课时 用到技术:Hibernate.Struts.Spring.Maven.EasyUI 涉及项目:易买网电子商务 更新程度:完毕 一.易买网前台部分讲解: 第一讲: Maven初体验 第二讲:Maven打包测试

Mysql技术内幕——表&amp;索引算法和锁

表 4.1.innodb存储引擎表类型 innodb表类似oracle的IOT表(索引聚集表-indexorganized table),在innodb表中每张表都会有一个主键,如果在创建表时没有显示的定义主键则innodb如按照如下方式选择或者创建主键.首先表中是否有唯一非空索引(unique not null),如果有则该列即为主键.不符合上述条件,innodb存储引擎会自动创建一个6字节大小的指针,rowid(). 4.2.innodb逻辑存储结构 innodb的逻辑存储单元由大到小分别是

c# 调用mysql数据库验证用户名和密码

使用mysql数据库验证用户名和密码时,如果用户名是中文,一直查不到数据 需要把app.config 中修改为 数据库统一设置utf8编码格式,连接数据库的时候设置编码Charset=utf8可以避免,例如:string connectiontext = "Server=139.222.313.153;Database=testsys;User=root;Password=1123456;Charset=utf8;"; 这样就调试OK 原文地址:https://www.cnblogs.

SpringBot添加多数据源mysql的验证方法

package com.holytax.accenture_fp_in.datasource; import javax.sql.DataSource; import org.springframework.beans.factory.annotation.Qualifier;import org.springframework.boot.autoconfigure.jdbc.DataSourceBuilder;import org.springframework.boot.context.pr

瞄上星座市场,三菱电机将为JAXA造技术验证小卫星

日本宇宙航空研究开发机构(JAXA)已选定由三菱电机公司来建造一颗 100 公斤重的卫星,希望以此为研制一款可批量生产的星座级别卫星奠定基础.三菱电机 12 月 22 日称,它将作为主承包商为 JAXA 建造"创新卫星技术验证"2 卫星(日文称"小型实证卫星 2 号机").卫星定于 2022 年 3 月底之前由本国"艾普西龙"火箭发射. 三菱电机主要为日本政府建造卫星,比如相当于日本版 GPS 的"准天顶卫星系统".但该公司也