本文主要介绍如何实现子库和子表(子库和子表的连接)，下面一起看看如何实现子库和子表(子库和子表的连接)相关资讯。
转载:
每个优秀的程序员和架构师都应该掌握子库表，这是我的看法。
在移动互联网时代，海量的用户每天都会产生海量的数据，比如:
用户表、订单表、交易流水表，以支付宝用户为例，8亿；用户甚至超过10亿。订单单更夸张，比如美团外卖，每天都是几千万单。淘宝 的历史订单总量应该是数百亿，甚至数千亿。这些海量数据远不是一张表就能容纳的。实际上mysql单个表可以存储10亿条数据，但此时性能相对较差。mysql单表容量在1kw以下是业界公认的，因为它的btree索引树在3-5之间。
因为一张桌子可以 t不固定，那就尽量把数据放在多个地方。目前，有三种常见的方案:
分区；子库和子表；nosql/newsql；注意:只有子库，或只有子表，或子库与子表的集成方案都被认为是子库与子表方案，因为子库或子表只是一种特殊的子库与子表。nosql更能代表mongodb和es。tidb是newsql的代表。
为什么不是nosql/纽什尔？首先，为什么不选择第三方案nosql/newsql？我认为rdbms有以下优点:-rdbms有完善的生态；-rdbms绝对稳定；-关系数据库管理系统的交易特征；
作为一个新生儿，nosql/newsql可以 当我们把可靠性作为主要研究对象时，它是无法与rdbms相比的。rdbms发展了几十年，凡是有软件的地方都是核心存储的首选。
目前大部分公司的核心数据都是以rdbms存储为主，nosql/newsql存储为辅！互联网公司以mysql为主，国有银行等有钱的企业以oracle/db2为主！无论nosql/newsql宣传的多么，现在都被各大公司定位为rdbms的补充，而不是替代品！
为什么不分区？让 让我们再来看看分区表方案。在理解这个方案之前，先理解它的原理:
分区表是由几个相关的底层表实现的，底层表也是用handle对象表示的，所以我们也可以直接访问所有分区。存储引擎和普通表一样管理分区的所有底层表(所有底层表必须使用同一个存储引擎)，分区表的索引只是给每个底层表增加相同的索引。从存储引擎 的角度来看，底层表与普通的表没有什么不同，存储引擎不需要知道是这样的。普通表也是分区表的一部分。其实这个方案也不错，对用户屏蔽了harding的细节，即使查询条件没有sharding列也能正常工作(只是此时性能一般)。但是它的缺点也是显而易见的:很多资源都受到了单机的限制，比如连接数、网络吞吐量等等！虽然每个分区都可以独立存储，但是分区表的总条目还是mysql的例子。结果它的并发能力很一般，远远达不到互联网高并发的要求！
至于网上提到的其他一些缺点，比如:无法使用外键，不支持全文索引。我不 我不认为这是一个缺点。如果21世纪的项目仍然使用数据库的外键和全文索引，我赢了 不要抱怨了！
因此，如果您使用分区表，您的业务应该具有以下两个特征:
数据不海量(分区数量有限，存储容量有限)；对并发能力要求不高；为什么要分库分表？最后，我想介绍一下互联网行业处理海量数据的通用方法:子数据库和子表。
虽然大家都用分库分表的方案来处理海量的核心数据，但是没有一个中间件来统一江湖。作者在这里列举了一些知名的子数据库和子表中间件:
阿里的tddl、drds和科巴尔，开源社区的哈丁-jdbc(3 . x已经改名为哈丁-球体)；mycat非组织；图集；360的；斑马；美团的；备注:sharding-jdbc的作者sean原来在当当，现在在京东金融。但是sharding-jdbc的版权属于开源社区，而不是公司 s或肖恩 s！其他公司，如网易、58和jd.com，都有自己的中间件。总之，各自为战，也可以说是百花齐放。
然而，如此多的子数据库和子表中间件都可以归为两种类型:
客户端模式；代理模式；客户端模式以阿里 开源社区的tddl和哈丁-jdbc(sharding-sphere，哈丁-jdbc的3.x版本，已经支持代理模式)。其结构如下:
代理模式以阿里的cobar和非组织的mycat为代表。其结构如下:
但是，无论是客户端模式还是代理模式。几个核心步骤是相同的:sql解析、重写、路由、执行和结果合并。
笔者更倾向于客户端模式，架构简单，性能损失少，运维成本低。接下来以几个常见的大表为案例来说明子数据库和子表如何落地！更多首发文章，请关注官方账号:【阿飞 的博客]
划分实战案例数据库和表格的第一步，也是最重要的一步，就是分片列的选择，分片。ing列的选择将直接决定整个子数据库和子表方案最终能否成功。哈丁专栏的选择与商业密切相关。笔者认为选择harding列的方法主要是分析你的api流量，优先选择流量大的api，提取流量大的api对应的sql，将这些sql公共条件作为harding列。比如一般的oltp系统为用户提供服务，这些api对应的sql都有条件用户id，所以用户id是一个非常好的分片列。
下面是子数据库和子表的几种主要处理思路:
子库和子表只选择了一个分片列；多个分片列、多个子库和子表；分片列子库子表《企业it架构转型之道：阿里巴巴中台战略思想与架构实现》)。它选择三列作为三个独立的分片列，即order_id、user_id和merchant_code。user_id和merchant_code是买家id和卖家id，因为在阿里 的订单系统中，买卖双方的查询流量都很大，并且查询要求实时性很高。而且根据order_id，应该会有更多基于order_id的查询。
这里还有一点需要提一下。多分片列的子数据库表是冗余的还是只有冗余的关系索引表需要我们自己权衡。
冗余总量的情况如下——每个sharing-column对应的表的数据为总量，优点是不需要二次查询，性能更好，缺点是浪费存储空间(浅绿色字段为harding-column):
冗余关系索引表的情况如下——只有一个harding列 的子数据库表有完整的数据，其他子数据库表只有这个harding列的关系表。这样做的好处是节省空间，但缺点是除了第一个以外，所有其他harding列查询都需要二次查询。这三个表之间的关系如下图所示(浅绿色字段为harding列):
冗余满量程主键。冗余关系表
速度对比:冗余全尺度更快，冗余关系表需要二次查询，即使引入缓存，仍然多耗费一个网络；存储成本:冗余满刻度的存储成本是冗余关系表的几倍；维护成本:冗余满量程维护成本更高。当涉及数据变更时，需要修改多个表。总结:选择冗余的全刻度或索引关系表，这是一种架构上的权衡。两者的优缺点都很明显。阿里 的顺序表是多余的满刻度。用户表用户表的几个核心字段一般如下:
一般用户登录场景可以通过mobile_no、email、username登录。但是，一些用户相关的api都包含user_id，所以可能需要根据所有四列来划分数据库和表，即所有四列都是sharding-column。
科目表科目表的几个核心字段一般如下:
一般与account表相关的api都有account_no，所以account_no可以作为sharing-column。
上面提到的复杂查询是条件中带有分片列的sql执行。但是，总有一些查询条件不包含分片列，同时，对于这些请求较低的查询，我们不可能无限制地划分数据库和表。那么在这种情况下，没有分片列的sql会怎么样呢？以sharding-jdbc为例，有多少个子库和子表，就要路由到多少个子库和子表执行，然后合并结果。具体如何合并，可以看作者sharding-jdbc系列文章，用分析源代码来解释合并的原理。
与使用分片列的条件查询相比，这种条件查询的性能明显会下降很多。如果有几十个甚至上百个子数据库、子表，只要一个表的执行因为某些因素变慢，整个sql的执行响应就会变慢，这非常符合木桶理论。
什么？;s更多的是操作系统中那些模糊的条件查询，或者是十个条件的筛选。在这种情况下，即使是单个表也不容易创建索引，更不用说子数据库和子表了。那么我们该怎么办呢？这时候著名的elasticsearch，也就是es就派上用场了。将子数据库和子表中的所有数据冗余给es，将那些复杂的查询交给es处理。
淘宝我的所有订单页面如下，多重过滤条件，产品标题模糊匹配，可以 即使是一张表也无法解决(索引可以 t遇到这种情况)，更不用说按子数据库和子表了:
所以，以订单表为例，整个结构如下:
具体情况具体分析:除非绝对必要，最好不要使用多分片柱，成本高。上面提到的用户表不是作者推荐的。因为用户表有一个很大的特点就是它的上限是肯定的，即使全世界70亿人都是你的用户，数据量也不大，所以作者推荐使用single harding c。专栏 spm = 5176.124785 . con 1 . 2c 0 cz 7 bj 2 .
es hbase的原理刚才已经讨论了以mysql为核心的上述方案，数据库和表es是分开的。随着数据量越来越大，虽然数据库和表还能继续指数级膨胀，但这时候压力就落到es身上了，这种架构会慢慢暴露问题！
一般顺序表、整数表等需要分库分表的核心表会有几十列甚至上百列(假设有50列)，但整个表可能真的需要参与条件索引(假设有10列)。此时将50列和所有字段的数据索引到es中，会对es集群造成很大的压力，而且需要很长时间才能从es分片失败中恢复过来。
这时可以考虑降低es的压力，让es集群有限的资源尽可能的保存条件检索所需的最有价值的数据，即只将可能参与条件检索的字段索引到es中，这样整个es集群的压力降低到原来的1/5(核心表有50个字段，只有10个字段参与条件)，50个字段的完整数据保存在hbase中。这是es hbase经典的组合方案，也就是将索引与数据存储分离的方案。
我们都知道hbase在hadoop系统下的存储容量是海量的，按照它的rowkey查询性能来说，堪称快如闪电。专家系统的多条件检索能力非常强大。该方案充分发挥了es和hbase的优点，同时避免了它们的缺点，可以说是扬长避短的最佳方案。很好的练习。
它们之间的交互大概是这样的:先根据用户输入的条件去es查询得到符合过滤条件的rowkey值，再用rowkey值去hbase查询。后一个查询步骤的时间几乎可以忽略，因为这是hbase最擅长的场景，交互示意图如下:
hbase检索能力扩展图来自hbase技术社区-hbase应用实践专场-hbase for solr总结。最后总结了几个方案如下(分片列缩写为sc):
-单个sc，多个scsc ssc，h bas:，官方账号】和lufax hbas:，官方账号】为本文提出宝贵意见。
写完这篇文章，作者第一时间把初稿发给了右军。大禹耐心的看完，和我沟通，当天下午给了我一些有价值的改进建议，才有了这个修订版。
风神对hbase有很深的了解，维护着hbase技术社区，为无数hbase学者提供了很好的学习平台。修改这篇文章的时候，我和沈峰讨论了很多。另外，还有一个在*1信用卡待过的朋友，他们的hbase出了问题，运维没做多久。最后，咨询沈峰，简单一碰就搞定了！对hbase感兴趣的同学可以去社区学习交流，不会让你失望的！
标签:
冗余是关于
了解更多如何实现子库和子表(子库和子表的连接)相关内容请关注本站点。