60数据库(数据库结构被划分为用户级,存储级)

　　60数据库

数据库是数据的仓库。
与普通的“数据仓库”不同的是，数据库依据“数据结构”来组织数据，因为“数据结构”，所以咱们看到的数据是比较“条理化”的（比方不会跟以前的普通文件存储式存储成一个文件那么不条理化，咱们的数据库分红一个个库，分红一个个表，分红一条条记录，这些记录是多么清楚）
也因为其“数据结构”式，所以有极高的查找速率（比方B-Tree查找法），（因为专精，能够根据自己的结构特性来快速查找，所以关于数据库的查找会比较快捷；不像普通文件体系的“查找”那么通用）
如果与EXCEL来比的话，能显着的看出数据库的优点，咱们能给一个个“字段”添加“约束”（比方约束一列的值不能为空）
数据库与普通的文件体系的首要区别（原因）：数据库能快速查找对应的数据
常说的XX数据库，其实实质上是XX数据库办理体系。数据库办理体系是一个软件，是数据库办理的程序完成。
什么是联系型数据库？
联系型数据库是依据联系模型来创建的数据库。
所谓联系模型就是“1对1、一对多、多对多”等联系模型，联系模型就是指二维表格模型,因此一个联系型数据库就是由二维表及其之间的联系组成的一个数据组织。
联系型数据能够很好地存储一些联系模型的数据，比方一个老师对应多个学生的数据（“多对多”），一本书对应多个作者（“一对多”），一本书对应一个出版日期（“1对1”）
联系模型是咱们生活中能常常遇见的模型，存储这类数据一般用联系型数据库
联系模型包含数据结构（数据存储的问题，二维表）、操作指令调集（SQL语句）、完整性约束(表内数据约束、表与表之间的约束)。

数据库结构被划分为用户级,存储级

随着互联网的高速发展，带来了海量数据存储的问题，比方像物联网行业，每个智能终端每天进行数据采集和上报，每天能够产几千万乃至上亿的数据。在互联网电商行业，或许一些O2O平台，每天也能发生上千万的订单数据，这些量级的数据在传统的联系型数据库中现已无法支撑了，那么怎么处理海量数据存储和核算等问题，在业界引进了散布式存储和散布式核算等处理计划，特别是NoSql的生态，我在前面讲过的k-v数据库、文档数据库、图形数据库等，都是比较主流的散布式数据库处理计划。
即便如此，联系型数据库依然有它不行替代的特性，所以联系型数据库依然是中心事务的根底数据平台，因而联系型数据库必然会面对数据量日益增长带来的海量数据处理问题。
Mysql数据库海量数据带来的功用问题
现在简直一切的互联网公司都是选用mysql这个开源数据库，依据阿里巴巴的《Java开发手册》上提到的，当单表行数超越500W行或许单表数据容量超越2G时，就会对查询功用发生较大影响，这个时分主张对表进行优化。
其实500W数据只是一个折中的值，详细的数据量和数据库服务器装备以及mysql装备有关，因为Mysql为了提高功用，会把表的索引装载到内存，innodb_buffer_pool_size足够的状况下，mysql能把悉数数据加载进内存，查询不会有问题。
可是，当单表数据库抵达某个量级的上限时，导致内存无法存储其索引，使得之后的SQL查询会发生磁盘IO，从而导致功用下降。当然，这个还有详细的表结构的规划有关，终究导致的问题都是内存限制，这儿，添加硬件装备，或许会带来立竿见影的功用提高。
innodb_buffer_pool_size包括数据缓存、索引缓存等。
Mysql常见的优化手法
当然，咱们首先要进行的优化是依据Mysql自身的优化，常见的优化手法有：
添加索引，索引是直观也是最快速优化检索功率的方法。
依据Sql句子的优化，比方最左匹配原则，用索引字段查询、下降sql句子的杂乱度等
表的合理规划，比方契合三范式、或许为了必定的功率破坏三范式规划等
数据库参数优化，比方并发连接数、数据刷盘战略、调整缓存大小
数据库服务器硬件晋级
mysql咱们主从仿制计划，完结读写别离
这些常见的优化手法，在数据量较小的状况下作用十分好，可是数据量抵达必定瓶颈时，常规的优化手法现已处理不了实践问题，那怎么办呢？
大数据表优化计划
关于大数据表的优化最直观的方法便是削减单表数据量，所以常见的处理计划是：
分库分表，大表拆小表。
冷热数据别离，所谓的冷热数据，其实便是依据拜访频次来区分的，拜访频次较多的数据是热数据，拜访频次少的数据是冷数据。冷热数据别离便是把这两类数据别离到不同的表中，从而削减热数据表的大小。
其实在许多地方咱们都能看到类似的完结，比方去一些网站查询订单或许买卖记载，默许只允许查询1到3个月，3个月之前的数据，基本上咱们都很少关心，拜访频次较少，所以能够把3个月之前的数据保存到冷库中。
历史数据归档，简略来说便是把时刻比较长远的数据别离出来存档，确保实时库的数据的有效生命周期。
其实这些处理计划都是归于偏事务类的计划，并不彻底是技能上的计划，所以在施行的时分，需求依据事务的特性来挑选适宜的方法。
详解分库分表
分库分表对错常常见针对单个数据表数据量过大的优化方法，它的中心思想是把一个大的数据表拆分红多个小的数据表，这个进程也叫（数据分片），它的本质其实有点类似于传统数据库中的分区表，比方mysql和oracle都支撑分区表机制。
分库分表是一种水平扩展手法，每个分片上包括本来总的数据集的一个子集。这种分而治之的思想在技能中很常见，比方多CPU、散布式架构、散布式缓存等等，像前面咱们讲rediscluster集群时，slot槽的分配便是一种数据分片的思想。

如图6-1所示，数据库分库分表一般有两种完结方法：
水平拆分，依据表或字段区分，表结构不同，有单库的分表，也有多库的分库。
笔直拆分，依据数据区分，表结构相同，数据不同，也有同库的水平切分和多库的切分。
笔直拆分
笔直拆分有两种，一种是单库的笔直拆分，另一种是多个数据库的笔直拆分。
单库笔直分表
单个表的字段数量主张控制在20~50个之间，之所以主张做这个限制，是因为假如字段加上数据累计的长度超越一个阈值后，数据就不是存储在一个页上，就会发生分页的问题，而这个问题会导致查询功用下降。
所以假如当某些事务表的字段过多时，咱们一般会拆去笔直拆分的方法，把一个表的字段拆分红多个表，如图6-2所示，把一个订单表笔直拆分红一个订单主表和一个订单明细表。
在Innodb引擎中，单表字段最大限制为1017
参阅：https://dev.mysql.com/doc/mysql-reslimits-excerpt/5.6/en/column-count-limit.html
多库笔直分表
多库笔直拆分实践上便是把存在于一个库中的多个表，依照必定的纬度拆分到多个库中，如图6-3所示。这种拆分方法在微服务架构中也是很常见，基本上会依照事务纬度拆分数据库，相同该纬度也会影响到微服务的拆分，基本上服务和数据库是独立的。
多库笔直拆分最大的长处便是完结了事务数据的隔离。其次便是缓解了恳求的压力，本来一切的表在一个库的时分，一切恳求都会打到一个数据库服务器上，经过数据库的拆分，能够分摊掉恳求，在这个层面上提高了数据库的吞吐能力。
水平拆分
笔直拆分的方法并没有处理单表数据量过大的问题，所以咱们还需求经过水平拆分的方法把大表数据做数据分片。
水平切分也能够分红两种，一种是单库的，一种是多库的。
单库水平分表
如图6-4所示，表明把一张有10000条数据的用户表，依照某种规则拆分红了4张表，每张表的数据量是2500条。

两个事例：
银行的买卖流水表，一切进出的买卖都需求挂号这张表，因为绝大部分时分客户都是查询当天的买卖和一个月以内的买卖数据，所以咱们依据运用频率把这张表拆分红三张表：
当天表：只存储当天的数据。
当月表：咱们在夜间运行一个守时任务，前一天的数据，悉数搬迁到当月表。用的是insertintoselect，然后delete。
历史表：相同是经过守时任务，把挂号时刻超越30天的数据，搬迁到history历史表（历史表的数据十分大，咱们依照月度，每个月树立分区）。
费用表：消费金融公司跟线下商户协作，给客户办理了借款以后，消费金融公司要给商户返费用，或许叫提成，每天都会发生许多的费用的数据。为了方便管理，咱们每个月树立一张费用表，例如fee_detail_201901……fee_detail_201912。
可是留意，跟分区一样，这种方法尽管能够必定程度处理单表查询功用的问题，可是并不能处理单机存储瓶颈的问题。
多库水平分表
多库水平分表，其实有点类似于分库分表的归纳完结计划，从分表来说是削减了单表的数据量，从分库层面来说，下降了单个数据库拜访的功用瓶颈，如图6-5所示。
常见的水平分表战略
分库更多的是关注事务的耦合度，也便是每个库应该放那些表，是由事务耦合度来决定的，这个在前期做领域建模的时分都会先考虑好，所以问题不大，只是分库之后带来的其他问题，咱们在后续内容中来剖析。
而分表这块，需求考虑的问题会更多一些，也便是咱们应该依据什么样的战略来水平分表？这儿就需求涉及到分表战略了，下面简略介绍几种最常见的分片战略。
哈希取模分片
哈希分片，其实便是经过表中的某一个字段进行hash算法得到一个哈希值，然后经过取模运算确认数据应该放在哪个分片中，如图6-6所示。这种方法十分适宜随机读写的场景中，它能够很好的将一个大表的数据随机涣散到多个小表。
hash取模的问题
hash取模运算有个比较严重的问题，假定依据当时数据表的量以及增长状况，咱们把一个大表拆分红了4个小表，看起来满意现在的需求，可是经过一段时刻的运行后，发现四个表不行，需求再添加4个表来存储，这种状况下，就需求对本来的数据进行全体搬迁，这个进程十分费事。
一般为了削减这种方法带来的数据搬迁的影响，咱们会选用共同性hash算法。
共同性hash算法
在前面咱们讲的hash取模算法，实践上对方针表或许方针数据库进行hash取模，一旦方针表或许数据库发生数量上的变化，就会导致一切数据都需求进行搬迁，为了削减这种大规模的数据影响，才引进了共同性hash算法。
如图6-7所示，简略来说，共同性哈希将整个哈希值空间组织成一个虚拟的圆环，如假定某哈希函数H的值空间为0-2^32^-1（即哈希值是一个32位无符号整形），什么意思呢？
便是咱们经过0-2^32^-1的数字组成一个虚拟的圆环，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、5、6……直到2^32^-1,也便是说0点左侧的第一个点代表2^32^-1。咱们把这个由2的32次方个点组成的圆环称为hash环。
那共同性hash算法和上面的虚拟环有什么联系呢？继续回到前面咱们讲解hash取模的比方，假定现在有四个表，table_1、table_2、table_3、table_4，在共同性hash算法中，取模运算不是直接对这四个表来完结，而是对2^32^来完结。
hash(table编号)%2^32^
经过上述公式算出的成果必定是一个0到2^32^-1之间的一个整数，然后在这个数对应的方位标示方针表，如图6-8所示，四个表经过hash取模之后别离落在hash环的某个方位上。
好了，到现在为止，咱们现已把方针表与hash环联络在了一起，那么接下来咱们需求把一条数据保存到某个方针表中，怎么做呢？如图6-9所示，当添加一条数据时，相同经过hash和hash环取模运算得到一个方针值，然后依据方针值所在的hash环的方位顺时针查找最近的一个方针表，把数据存储到这个方针表中即可。
不知道咱们是否发现了共同性hash的长处，便是hash运算不是直接面向方针表，而是面向hash环，这样的长处便是当需求删去某张表或许添加表的时分，关于整个数据变化的影响是部分的，而不是大局。举个比方，假定咱们发现需求添加一张表table_04，如图6-10所示，添加一个表，并不会对其他四个现已发生了数据的表造成影响，本来现已分片的数据彻底不需求做任何改动。
假如需求删去一个节点，相同只会影响删去节点自身的数据，前后表的数据彻底不受影响。
hash环偏斜
上述规划有一个问题，理论状况下咱们方针表是能够均衡的散布在整个hash环中，但实践状况有或许是图6-11所示的姿态。也便是发生了hash环偏斜的现象，这种现象导致的问题便是许多的数据都会保存到同一个表中，却是数据分配极度不均匀。
为了处理这个问题，有必要要确保方针节点要均匀的散布在整个hash环中，可是真实的节点就只要4个，怎么均匀散布呢？最简略的方法便是，把这四个节点别离仿制一份出来涣散到这个hash环中，这个仿制出来的节点叫虚拟节点，依据实践需求能够虚拟出多个节点出来，如图6-12所示。
依照规模分片
按规模分片，其实便是依据数据表的事务特性，依照某种规模拆分，这个规模的有许多含义，比方：
时刻规模，比方咱们依照数据创立时刻，依照每一个月保存一个表。依据时刻区分还能够用来做冷热数据别离，越早的数据拜访频次越少。
区域规模，区域一般指的是地理方位，比方一个表里面存储了来自全国各地的数据，假如数据量较大的状况下，能够依照地域来区分多个表。
数据规模，比方依据某个字段的数据区间来进行区分。
如图6-7所示，表明依照数据规模进行拆分。
规模分片终究要的是挑选一个适宜的分片键，这个是否适宜来自于事务需求，比方之前有个学员是在做智能家居的，他们卖的是硬件设备，这些设备会采集数据上签到服务器上，当来自全国规模的数据共同保存在一个表中后，数据量到达了亿级别，所以这种场景比较适宜依照城市和地域来拆分。
分库分表实战
为了让咱们了解分库分表以及实操，咱们经过一个简略的事例来演示一下。代码详见：springboot-split-table-example项目
假定存在一个用户表，用户表的字段如下。
该表首要供给注册、登录、查询、修正等功用。
该表的详细的事务状况如下（需求留意，在进行分表之前，需求了解事务层面对这个表的运用状况，然后再决定运用什么样的计划，不然脱离事务去规划技能计划是耍流氓）
用户端：前台拜访量较大，首要涉及两类恳求：
用户登录，面向C端，对可用性和共同性要求较高，首要经过login_name、email、phone来查询用户信息，1%的恳求归于这种类型
用户信息查询，登录成功后，经过uid来查询用户信息，99%归于这种类型。
运营端：首要是运营后台的信息拜访，需求支撑依据性别、手机号、注册时刻、用户昵称等进行分页查询，因为是内部体系，拜访量较低，对可用性共同性要求不高。
依据uid进行水平分表
因为99%的恳求是依据uid进行用户信息查询，所以毫无疑问咱们挑选运用uid进行水平分表。那么这儿咱们选用uid的hash取模方法来进行分表，详细的施行如图6-9所示，依据uid进行共同性hash取模运算得到方针表进行存储。
依照图6-9的结构，别离仿制user_info表，重新命名为01~04，如图6-10所示。
怎么生成大局仅有id
当完结上述动作后，就需求开端开端落地施行，这儿需求考虑在数据添加、修正、删去时，要正确路由到方针数据表，其次是老数据的搬迁。
老数据搬迁，一般咱们是写一个脚本或许一个程序，把旧表中的数据查询出来，然后依据分表规则重新路由分发到新的表中，这儿不是很杂乱，就不做打开阐明，咱们要点说一下数据添加/修正/删去的路由。
在施行之前，咱们需求先考虑一个十分重要的问题，便是在单个表中，咱们运用递加主键来确保数据的仅有性，可是假如把数据拆分到了四个表，每个表都选用自己的递加主键规则，就会存在重复id的问题，也便是说递加主键不是大局仅有的。
咱们需求知道一个点是，user_info尽管拆分红了多张表，可是本质上它应该仍是一个完好的数据全体，当id存在重复的时分，就失去了数据的仅有性，因而咱们需求考虑怎么生成一个大局仅有ID。
怎么完结大局仅有ID
大局仅有ID的特性便是能够确保ID的仅有性，那么依据这个特性，咱们能够轻松找到许多的处理计划。
数据库自增ID（定义大局表）
UUID
Redis的原子递加
Twitter-Snowflake算法
美团的leaf
MongoDB的ObjectId
百度的UidGenerator
散布式ID的特性
仅有性：确保生成的ID是大局仅有的。
有序递加性：确保生成的ID是关于某个用户或许事务是按必定的数字有序递加的。
高可用性：确保任何时分都能正确的生成ID。
带时刻：ID里面包括时刻，一眼扫过去就知道哪天的数据
数据库自增计划
在数据库中专门创立一张序列表，运用数据库表中的自增ID来为其他事务的数据生成一个大局ID，那么每次要用ID的时分，直接从这个表中获取即可。
CREATETABLE`uid_table`(`id`bigint(20)NOTNULLAUTO_INCREMENT,`business_id`int(11)NOTNULL,PRIMARYKEY(`id`)USINGBTREE,UNIQUE(business_type))
在运用程序中，每次调用下面这段代码，就能够继续取得一个递加的ID。
begin;REPLACEINTOuid_table(business_id)VALUES(2);SELECTLAST_INSERT_ID();commit;
其中，replaceinto是每次删去本来相同的数据，一起加1条，就能确保咱们每次得到的便是一个自增的ID
这个计划的长处对错常简略，它也有缺陷，便是关于数据库的压力比较大，而且最好是独立布置一个DB，而独立布置又会添加全体的本钱，这个在美团的leaf里面规划了一个很巧妙的规划计划，后边再讲
长处：
十分简略，运用现有数据库体系的功用完结，本钱小，有DBA专业保护。
ID号单调自增，能够完结一些对ID有特别要求的事务。
缺陷：
强依靠DB，当DB反常时整个体系不行用，归于致命问题。装备主从仿制能够尽或许的添加可用性，可是数据共同性在特别状况下难以确保。主从切换时的不共同或许会导致重复发号。
ID发号功用瓶颈限制在单台MySQL的读写功用。
UUID
UUID的格局是：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx8-4-4-4-12共36个字符，它是一个128bit的二进制转化为16进制的32个字符，然后用4个-连接起来的字符串。
UUID的五种生成方法
依据时刻的UUID（date-time&MACaddress）：首要依靠当时的时刻戳及机器mac地址，因而能够确保全球仅有性。（运用了Mac地址，因而会露出Mac地址和生成时刻。）
散布式安全的UUID（date-time&group/userid）将版别1的时刻戳前四位换为POSIX的UID或GID。
依据姓名空间的UUID-MD5版（MD5hash&namespace），依据指定的姓名空间/姓名生成MD5散列值得到，标准不推荐。
依据随机数的UUID（pseudo-randomnumber）：依据随机数或伪随机数生成。
依据姓名空间的UUID-SHA1版（SHA-1hash&namespace）：将版别3的散列算法改为SHA1
在Java中，供给了依据MD5算法的UUID、以及依据随机数的UUID。
长处：
本地生成，没有网络消耗，生成简略，没有高可用危险。
缺陷：
不易于存储：UUID太长，16字节128位，通常以36长度的字符串表明，许多场景不适用。
信息不安全：依据MAC地址生成UUID的算法或许会造成MAC地址走漏，这个漏洞曾被用于寻找梅丽莎病毒的制作者方位。
无序查询功率低：因为生成的UUID是无序不行读的字符串，所以其查询功率低。
UUID不适宜用来做数据库的仅有ID，假如用UUID做主键，无序的不递加，咱们都知道，主键是有索引的，然后mysql的索引是经过b+树来完结的，每一次新的UUID数据的插入，为了查询的优化，都会对索引底层的b+树进行修正，因为UUID数据是无序的，所以每一次UUID数据的插入都会对主键的b+树进行很大的修正，严重影响功用
雪花算法
SnowFlake算法，是Twitter开源的散布式id生成算法。其中心思想便是：运用一个64bit的long型的数字作为大局仅有id。雪花算法比较常见，在百度的UidGenerator、美团的Leaf中，都有用到雪花算法的完结。
如图6-11所示，表明雪花算法的组成，总共64bit，这64个bit位由四个部分组成。
第一部分，1bit位，用来表明符号位，而ID一般是正数，所以这个符号位一般状况下是0。
第二部分，占41个bit：表明的是时刻戳，是体系时刻的毫秒数，可是这个时刻戳不是当时体系的时刻，而是当时体系时刻-开端时刻，更大的确保这个ID生成计划的运用的时刻！
那么咱们为什么需求这个时刻戳，意图是为了确保有序性，可读性,我一看我就能猜到ID是什么时分生成的。
41位能够2^41^-1表明个数字，
假如只用来表明正整数（核算机中正数包括0），能够表明的数值规模是：0至2^41^-1，减1是因为可表明的数值规模是从0开端算的，而不是1。
也便是说41位能够表明2^41^-1个毫秒的值，转化成单位年则是(2^41^-1)/1000*60*60*24*365=69年，也便是能容纳69年的时刻
第三部分，用来记载工作机器id，id包括10bit，意味着这个服务最多能够布置在2^10台机器上，也便是1024台机器。
其中这10bit又能够分红2个5bit，前5bit表明机房id、5bit表明机器id，意味着最多支撑2^5个机房（32），每个机房能够支撑32台机器。
第四部分，第四部分由12bit组成，它表明一个递加序列，用来记载同毫秒内发生的不同id。
那么咱们为什么需求这个序列号，设想下，假如是同一毫秒同一台机器来恳求，那么咱们怎么确保他的仅有性，这个时分，咱们就能用到咱们的序列号，
意图是为了确保同一毫秒内同一机器生成的ID是仅有的，这个其实便是为了满意咱们ID的这个高并发，便是确保我同一毫秒进来的并发场景的仅有性
12位（bit）能够表明的最大正整数是2^12-1=4095，即能够用0、1、2、3、….4094这4095个数字，来表明同一机器同一时刻截（毫秒)内发生的4095个ID序号。
12位2进制，假如悉数都是1的状况下，那么终究的值便是4095，也便是12bit能够存储的最大的数字是4095.
分库分表之后的数据DML操作
有序需求用到大局id，所以在user_info表需求添加一个仅有id的字段。
装备完结之后，在如下代码中引进signal方法。
@Slf4j@RestController@RequestMapping(“/users”)publicclassUserInfoController{@AutowiredIUserInfoServiceuserInfoService;SnowFlakeGeneratorsnowFlakeGenerator=newSnowFlakeGenerator(1,1,1);@PostMapping(“/batch”)publicvoiduser(@RequestBodyListuserInfos){log.info(“beginUserInfoController.user”);userInfoService.saveBatch(userInfos);}@PostMappingpublicvoidsignal(@RequestBodyUserInfouserInfo){LongbizId=snowFlakeGenerator.nextId();userInfo.setBizId(bizId);Stringtable=ConsistentHashing.getServer(bizId.toString());log.info(“UserInfoController.signal:{}”,table);MybatisPlusConfig.TABLE_NAME.set(table);userInfoService.save(userInfo);}}
而且，需求添加一个mybatis阻拦器，针对user_info表进行阻拦和替换，从而完结动态表的路由。
@ConfigurationpublicclassMybatisPlusConfig{publicstaticThreadLocalTABLE_NAME=newThreadLocal<>();@BeanpublicMybatisPlusInterceptormybatisPlusInterceptor(){MybatisPlusInterceptorinterceptor=newMybatisPlusInterceptor();PaginationInnerInterceptorpaginationInnerInterceptor=newPaginationInnerInterceptor(DbType.MYSQL);interceptor.addInnerInterceptor(paginationInnerInterceptor);DynamicTableNameInnerInterceptordynamicTableNameInnerInterceptor=newDynamicTableNameInnerInterceptor();MaptableNameHandlerMap=newHashMap<>();tableNameHandlerMap.put(“user_info”,(sql,tableName)->TABLE_NAME.get());dynamicTableNameInnerInterceptor.setTableNameHandlerMap(tableNameHandlerMap);interceptor.addInnerInterceptor(dynamicTableNameInnerInterceptor);returninterceptor;}}
至此，一个根底的分库分表的演练就完结了，但问题依然还未彻底处理。
非分片键查询
咱们对user_info表的分片，是依据biz_id来完结的，也便是意味着假如咱们想查询某张表的数据，有必要先要运用biz_id路由找到对应的表才能查询到。
那么问题来了，假如查询的字段不是分片键（也便是不是biz_id），比方本次分库分表实战事例中，运营端查询就有依据姓名、手机号、性别等字段来查，这时分咱们并不知道去哪张表查询这些信息。
非分片键和分片键树立映射联系
第一种处理方法便是，把非分片键和分片键树立映射联系，比方login_name->biz_id树立映射，相当于树立一个简略的索引，当依据login_name查询数据时，先经过映射表查询出login_name对应的biz_id，再经过biz_id定位到方针表。
映射表的只要两列，能够成再许多的数据，当数据量过大时，也能够对映射表做水平拆分。一起这种映射联系其实便是k-v键值对的联系，所以咱们能够运用k-v缓存来存储提高功用。
一起因为这种映射联系的改变频率很低，所以缓存命中率很高，功用也很好。
用户端数据库和运营端数据库进行别离
运营端的查询或许不止于单个字段的映射来查询，或许更多的会涉及到一些杂乱查询，以及分页查询等，这种查询自身对数据库功用影响较大，很或许影响到用户端关于用户表的操作，所以一般主流的处理计划便是把两个库进行别离。
因为运营端关于数据的共同性和可用性要求不是很高，也不需求实时拜访数据库，所以咱们能够把C端用户表的数据同步到运营端的用户表，而且用户表能够不需求做分表操作，直接全量查表即可。
当然，假如运营端的操作功用实在是太慢了，咱们还能够选用ElasticSearch搜索引擎来满意后台杂乱查询的需求。
实践运用中会遇到的问题
在实践运用中，并不是一开端就会想到未来会对这个表做拆分，因而许多时分咱们面对的问题是在数据量现已到达必定瓶颈的时分，才开端去考虑这个问题。
所以分库分表最大的难点不是在于拆分的方法论，而是在运行了很长时刻的数据库中，怎么依据实践事务状况挑选适宜的拆分方法，以及在拆分之前关于数据的搬迁计划的考虑。而且，在整个数据搬迁和拆分进程中，体系依然需求坚持可用。
关于运行中的表的分表，一般会分为三个阶段。
阶段一，新老库双写
因为老的数据表必定没有考虑到未来分表的规划，一起随着事务的迭代，或许有些模型也需求优化，因而会规划一个新的表来承载老的数据，而这个进程中，需求做几件事情
数据库表的双写，老的数据库表和新的数据库表同步写入数据，事务的成功以老的模型为准，查询也走老的模型
经过守时任务对数据进行核对，补平差异
经过守时任务把历史数据搬迁到新的模型中
阶段二，以新的模型为准
到了第二个阶段，历史数据现已导完了，而且校验数据没有问题。
依然坚持数据双写，可是事务的成功和查询都以新模型为准。
守时任务进行数据核对，补平数据差异
阶段三，结束双写
到了第三个阶段，阐明数据现已彻底搬迁好了，因而。
取消双写，一切数据只需求保存到新的模型中，老模型不需求再写入新的数据。
假如依然有部分老的事务依靠老的模型，所以比及一切事务都改造完结后，再废弃老的模型。
分库分表后带来的问题
分库分表带来功用提高的长处的一起，也带来了许多的费事，
散布式事务问题
分库分表之后，本来在一个库中的事务，变成了跨越多个库，怎么确保跨库数据的共同性问题，也是一个常见的难题。如图6-13所示，用户创立订单时，需求在订单库中保存一条订单记载，而且修正库存库中的产品库存，这儿就涉及到跨库事务的共同性问题。也便是说我怎么确保当时两个事务操作要么一起成功，要么一起失利。
跨库查询
比方查询在合同信息的时分要相关客户数据，因为是合同数据和客户数据是在不同的数据库，那么咱们必定不能直接运用join的这种方法去做相关查询。
咱们有几种首要的处理计划：
字段冗余，比方咱们查询合同库的合同表的时分需求相关客户库的客户表，咱们能够直接把一些经常相关查询的客户字段放到合同表，经过这种方法防止跨库相关查询的问题。
数据同步：比方商户体系要查询产品体系的产品表，咱们干脆在商户体系创立一张产品表，经过ETL或许其他方法守时同步产品数据。
大局表（广播表）比方根底数据被许多事务体系用到，假如咱们放在中心体系，每个体系都要去相关查询，这个时分咱们能够在一切的数据库都存储相同的根底数据。
ER表（绑定表），咱们有些表的数据是存在逻辑的主外键联系的，比方订单表order_info，存的是汇总的产品数，产品金额；订单明细表order_detail，是每个产品的价格，个数等等。或许叫做从属联系，父表和子表的联系。他们之间会经常有相关查询的操作，假如父表的数据和子表的数据别离存储在不同的数据库，跨库相关查询也比较费事。所以咱们能不能把父表和数据和从归于父表的数据落到一个节点上呢？比方order_id=1001的数据在node1，它一切的明细数据也放到node1；order_id=1002的数据在node2，它一切的明细数据都放到node2，这样在相关查询的时分依然是在一个数据库。
上面的思路都是经过合理的数据散布防止跨库相关查询，实践上在咱们的事务中，也是尽量不要用跨库相关查询，假如呈现了这种状况，就要剖析一下事务或许数据拆分是不是合理。假如仍是呈现了需求跨库相关的状况，那咱们就只能用最后一种方法。
体系层组装
在不同的数据库节点把契合条件数据的数据查询出来，然后重新组装，回来给客户端。
排序、翻页、函数核算等问题
跨节点多库进行查询时，会呈现limit分页，orderby排序的问题。比方有两个节点，节点1存的是奇数id=1,3,5,7,9……；节点2存的是偶数id=2,4,6,8,10……
履行select*fromuser_infoorderbyidlimit0,10
需求在两个节点上各取出10条，然后兼并数据，重新排序。
max、min、sum、count之类的函数在进行核算的时分，也需求先在每个分片上履行相应的函数，然后将各个分片的成果集进行汇总和再次核算，终究将成果回来。
大局仅有ID
大局仅有id的问题，前面现已说了，水平分表之后，需求考虑大局仅有id规划问题。
多数据源的问题
分库分表之后，难免会存在一个运用装备多个数据源。
别的，数据库层面有或许会规划读写别离的计划，也使得一个运用会拜访多个数据源，而且还需求完结读写别离的动态路由。
而这些问题在每个运用体系中都会存在而且需求处理，所以为了供给共同的分库分表相关问题的处理计划，引进了许多的开源技能。
分库分表处理计划
现在市面上分库分表的中间件相对来说说比较多，比方
Cobar，淘宝开源的分库分表组件，现在基本上没有保护了。
Sharding-Sphere，当当开源的一个分库分表组件，现已捐献给了Apache基金会
Atlas，奇虎360开源的分库分表组件，也是没怎么保护了
Mycat，从阿里cobar晋级而来，由开源组织保护。
Vitess，谷歌开源的分库分表组件
现在许多公司挑选较多的是Mycat或许Sharding-Sphere，所以我要点介绍Sharding-Sphere的运用和原理。
关于同类技能的挑选，无非便是看社区活跃度、技能的成熟度、以及功用和当时需求是否匹配。关注[跟着Mic学架构]大众号，学习更多精品原创!