Sharding-JDBC

Sharding-JDBC是当当开源的用于分库分表的基础类库。定位轻量级java框架，可以通过客户端直接连接数据库，只需要在增加额外的数据源配置就可以轻松实现完整的分库分表功能。 Sharding-JDBC是一个开源的适用于微服务的分布式数据访问基础类库，它始终以云原生的基础开发套件为目标。 目前Sharding-JDBC已经实现的功能包括（最新稳定版本为 2.0.0.M1 ）： 分库分表 读写分离 分布式主键 柔性事务 分布式治理能力（2.0新功能），具体包括： 配置集中化与动态化，可支持数据源、表与分片策略的动态切换 客户端的数据库治理，数据源失效自动切换 基于Open Tracing协议的APM信息输出 下面的例子都是基于Spring Boot开发： Spring Boot + Mybatis + Druid + Sharding-Jdbc 工程结构 Application 是项目的启动入口 DataSourceConfig 是数据源配置，包括如何结合Sharding-Jdbc设置分库分表 algorithm 下面是设置的分库分表策略，比如当 city_id % 2 为偶数放在库A，否则放在库B UserMapper 是Mybatis的接口，由于采用了全注解配置，所以没有Mapper文件 druid 下面是druid的监控页面配置 pom配置 <?xml version="1

0.数据库sharding基本思想 水平切分：把表的数据按某种规则（比如按ID散列）切分到多张表或者多个数据库(server)上。 垂直切分：把关系紧密（比如同一模块）的表切分出来放在一个server上。 1.sharding-jdbc 当当开源中间件：https://github.com/dangdangdotcom/sharding-jdbc 注意：Sharding-jdbc目前实现的是水平切分，垂直切分配置暂未实现！ 2.架构图 3.maven pom.xml <dependency> <groupId>com.dangdang</groupId> <artifactId>sharding-jdbc-core</artifactId> <version>1.0.0</version> </dependency> 4.spring+mybatis+sharding-jdbc完整配置 配置文件基于github demo <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www

为什么要分库分表？（设计高并发系统的时候，数据库层面该如何设计？） 说白了，分库分表是两回事儿，大家可别搞混了，可能是光分库不分表，也可能是光分表不分库，都有可能。 我先给大家抛出来一个场景。 假如我们现在是一个小创业公司（或者是一个 BAT 公司刚兴起的一个新部门），现在注册用户就 20 万，每天活跃用户就 1 万，每天单表数据量就 1000，然后高峰期每秒钟并发请求最多就 10。天，就这种系统，随便找一个有几年工作经验的，然后带几个刚培训出来的，随便干干都可以。 结果没想到我们运气居然这么好，碰上个 CEO 带着我们走上了康庄大道，业务发展迅猛，过了几个月，注册用户数达到了 2000 万！每天活跃用户数 100 万！每天单表数据量 10 万条！高峰期每秒最大请求达到 1000！同时公司还顺带着融资了两轮，进账了几个亿人民币啊！公司估值达到了惊人的几亿美金！这是小独角兽的节奏！ 好吧，没事，现在大家感觉压力已经有点大了，为啥呢？因为每天多 10 万条数据，一个月就多 300 万条数据，现在咱们单表已经几百万数据了，马上就破千万了。但是勉强还能撑着。高峰期请求现在是 1000，咱们线上部署了几台机器，负载均衡搞了一下，数据库撑 1000QPS 也还凑合。但是大家现在开始感觉有点担心了，接下来咋整呢...... 再接下来几个月，我的天，CEO 太牛逼了，公司用户数已经达到 1 亿

阿飞Javaer ，转载请注明原创出处，谢谢！ - 配置集中化与动态化。可支持数据源、表与分片及读写分离策略的 动态切换 ； - 数据治理。提供熔断数据库访问程序对数据库的访问和禁用从库的访问的能力； - 支持Zookeeper和etcd的注册中心； 摘自 sharding-jdbc编排治理 ，官方文档也有比较详细的使用文档； 由sharding-jdbc2.x新的架构图可知，sharding-jdbc2.x与sharding-jdbc1.x版本最大的变化就是最左边的sharding-jdbc-orchestration。即为了动态修改配置引入的注册中心和编排模块。而sharding-jdbc内部实现架构几乎没有任何改变。 注册中心在定义的命名空间下，创建数据库访问对象运行节点，用于区分不同数据库访问实例。命名空间中包含2个数据子节点，分别是config和state。 config节点信息如下： config ├―― datasource 数据源（可能多个，数据结构为 json 数组）配置 ├―― sharding 分库分表（包括分库分表+读写分离）配置根节点 ├ ├―― rule 分库分表（包括分库分表+读写分离）规则 ├ ├―― configmap 分库分表 ConfigMap 配置，以 K / V 形式存储，如：{ "k1" : "v1" } ├ ├―― props

阿飞Javaer ，转载请注明原创出处，谢谢！！ 分析insert解析之前，首先看一下mysql官方对insert语法的定义，因为SQL解析跟语法息息相关： INSERT [ LOW_PRIORITY | DELAYED | HIGH_PRIORITY ] [ IGNORE ] [ INTO ] tbl_name [ PARTITION ( partition_name [, partition_name ] ... )] [( col_name [, col_name ] ... )] { VALUES | VALUE } ( value_list ) [, ( value_list )] ... [ ON DUPLICATE KEY UPDATE assignment_list ] INSERT [ LOW_PRIORITY | DELAYED | HIGH_PRIORITY ] [ IGNORE ] [ INTO ] tbl_name [ PARTITION ( partition_name [, partition_name ] ... )] SET assignment_list [ ON DUPLICATE KEY UPDATE assignment_list ] INSERT [ LOW_PRIORITY | HIGH_PRIORITY ] [ IGNORE ] [

原文出自： https://blog.csdn.net/jornada_/article/details/82947677 一般对于业务记录类随时间会不断增加的数据，当数据量增加到一定量（一般认为整型值为主的表达到千万级，字符串为主的表达到五百万）的时候，性能将遇到瓶颈，同时调整表结构也会变得非常困难。为了避免生产遇到这样的问题，在做系统设计时需要预估可能产生的数据量：预估记录主体个数*预估记录主体产生的记录数（e.g.用户订单表预估数据量=预估用户数*单用户产生订单数），预估达到一定量时，就不得不考虑分库分表了，目前国内比较成熟的开源数据库中间件有sharding-jdbc、mycat；而drds是阿里云最近推出的商业产品，考虑到大部分公司都在使用阿里云，做一个全家桶，也是一个不错的选择。接下来将对这三款产品的优缺点及适用场景做以介绍。 可以看出sharding-jdbc作为一个组件集成在应用内，而mycat则作为一个独立的应用需要单独部署，drds则是阿里云的一个独立产品，不过需要结合rds一起使用。从架构上看sharding-jdbc更符合分布式架构的设计，直连数据库，没有中间应用，理论性能是最高的（实际性能需要结合具体的代码实现，理论性能可以理解为上限，通过不断优化代码实现，逐渐接近理论性能）。同时缺点也很明显，由于作为组件存在，需要集成在应用内，意味着作为使用方

闲来无事，喜欢研究一些自己未接触过的技术~ 看到了当当开源的Sharding-JDBC组件，它可以在几乎不修改代码的情况下完成分库分表的实现。摘抄其中一段介绍： 直接封装JDBC API ，可以理解为增强版的JDBC 驱动，旧代码迁移成本几乎为零： 可适用于任何基于java 的ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用JDBC 。 可基于任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid 等。 理论上可支持任意实现JDBC 规范的数据库。虽然目前仅支持MySQL ，但已有支持Oracle ，SQLServer ，DB2 等数据库的计划。 先做一个最简单的试用，不做分库，仅做分表。选择数据表bead_information，首先复制成三个表：bead_information_0、bead_information_1、bead_information_2 测试实现过程 1、修改pom.xml增加dependency <dependency> <groupId>com.dangdang</groupId> <artifactId>sharding-jdbc-core</artifactId> <version>1.4.2</version> </dependency>

数据库相关 sharding-jdbc 当当开源sharding-jdbc，轻量级数据库分库分表中间件 Sharding-JDBC是当当应用框架ddframe中，从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架，实现透明化数据库分库分表访问。Sharding-JDBC是继dubbox和elastic-job之后，ddframe系列开源的第3个项目。 Sharding-JDBC直接封装JDBC协议，可以理解为增强版的JDBC驱动，旧代码迁移成本几乎为零。 Sharding-JDBC定位为轻量级java框架，使用客户端直连数据库，以jar包形式提供服务，无proxy代理层，无需额外部署，无其他依赖，DBA也无需改变原有的运维方式。 主要包括以下特点： 可适用于任何基于java的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。 可基于任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid等。 理论上可支持任意实现JDBC规范的数据库。虽然目前仅支持MySQL，但已有支持Oracle，SQLServer等数据库的计划。 分片策略灵活，可支持等号，between，in等多维度分片，也可支持多分片键。 SQL解析功能完善，支持聚合，分组，排序，limit，or等查询

移动互联网时代，海量的用户每天产生海量的数量，比如： 用户表 订单表 交易流水表 以支付宝用户为例，8亿；微信用户更是10亿。订单表更夸张，比如美团外卖，每天都是几千万的订单。淘宝的历史订单总量应该百亿，甚至千亿级别，这些海量数据远不是一张表能Hold住的。事实上MySQL单表可以存储10亿级数据，只是这时候性能比较差，业界公认MySQL单表容量在1KW以下是最佳状态，因为这时它的BTREE索引树高在3~5之间。 既然一张表无法搞定，那么就想办法将数据放到多个地方，目前比较普遍的方案有3个： 分区； 分库分表； NoSQL/NewSQL； 既然一张表无法搞定，那么就想办法将数据放到多个地方，目前比较普遍的方案有3个： 分区； 分库分表； NoSQL/NewSQL； 说明：只分库，或者只分表，或者分库分表融合方案都统一认为是分库分表方案，因为分库，或者分表只是一种特殊的分库分表而已。NoSQL比较具有代表性的是MongoDB，es。NewSQL比较具有代表性的是TiDB。 Why Not NoSQL/NewSQL? 首先，为什么不选择第三种方案NoSQL/NewSQL，我认为主要是RDBMS有以下几个优点： - RDBMS生态完善； - RDBMS绝对稳定； - RDBMS的事务特性； NoSQL/NewSQL作为新生儿，在我们把可靠性当做首要考察对象时

一、为什么需要分布式数据据库 随着计算机和信息技术的迅猛发展，行业应用系统的规模迅速扩大，行业应用所产生的数据量呈爆炸式增长，动辄达到数百TB甚至数百PB的规模，已远远超出传统计算技术和信息系统的处理能力，集中式数据库面对大规模数据处理逐渐表现出其局限性。因此，人们希望寻找一种能快速处理数据和及时响应用户访问的方法，也希望对数据进行集中分析、管理和维护。这已经成为迫切需求。 分布式数据库是在集中式数据库的基础上发展起来的，是计算机技术和网络技术结合的产物。分布式数据库是指数据在物理上分布而在逻辑上集中管理的数据库系统。物理上分布是指数据分布在物理位置不同并由网络连接的节点或站点上;逻辑上集中是指各数据库节点之间的逻辑上是一个整体，并由统一的数据库管理系统管理。不同的节点分布可以跨不同的机房、城市甚至国家。 二、分布式数据库的特点 分布式数据库具有透明性、数据冗余性、易于扩展性、自治性等特点，还具有经济、性能优越、响应速度更快、灵活的体系结构、易于集成现有系统等特点。 分布式数据库尽管有着天生的高贵血统，但它依赖调整网络，对事务的处理远没有传统数据库成熟，在很长一段时间内分布式数据存储将与传统数据存储共存。 三、MyCat数据库中间件简介 MyCat是一个彻底开源的面向企业应用开发的大数据库集群，支持事务、ACID，是可以替代MySQL的加强版数据库