MySQL分库分表,一般只能按照一个维度进行查询.
成都创新互联主要从事网站设计制作、成都网站设计、网页设计、企业做网站、公司建网站等业务。立足成都服务温县,10年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:13518219792
以订单表为例, 按照用户ID mod 64 分成 64个数据库.
按照用户的维度查询很快,因为最终的查询落在一台服务器上.
但是如果按照商户的维度查询,则代价非常高.
需要查询全部64台服务器.
在分页的情况下,更加恶化.
比如某个商户查询第10页的数据(按照订单的创建时间).需要在每台数据库服务器上查询前100条数据,程序收到 64*100 条数据,然后按照订单的创建时间排序,截取排名90-100号的10条记录返回,然后抛弃其余的6390条记录.如果查询的是第100页,第1000页,则对数据库IO,网络,中间件CPU,都是不小的压力.
分库分表之后,为了应对多维度查询,很多情况下会引入冗余.
比如两个集群,一个按照用户ID分库分表,另外一个按照商户ID分库分表.
这样多维度查询的时候,各查各的.
但是有几个问题,一样不好解决.
比如,
每扩展一个维度,就需要引入一个集群.
集群间的数据,如何保证一致性.
冗余占用大量磁盘空间.
从朋友那里看到的订单表结构.做冗余会占用大量的磁盘空间.
create table TS_ORDER
(
ORDER_ID NUMBER(8) not null,
SN VARCHAR2(50),
MEMBER_ID NUMBER(8),
STATUS NUMBER(2),
PAY_STATUS NUMBER(2),
SHIP_STATUS NUMBER(2),
SHIPPING_ID NUMBER(8),
SHIPPING_TYPE VARCHAR2(255),
SHIPPING_AREA VARCHAR2(255),
PAYMENT_ID NUMBER(8),
PAYMENT_NAME VARCHAR2(50),
PAYMENT_TYPE VARCHAR2(50),
CREATE TABLE IF NOT EXISTS `teacher` (
`id` int(10) NOT NULL AUTO_INCREMENT COMMENT 'tesacherID',
`name` varchar(255) NOT NULL DEFAULT '''''' COMMENT 'tesacherName',
`age` int(10) NOT NULL DEFAULT '0' COMMENT 'teacherAge',
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='teacherInfo' AUTO_INCREMENT=1 ;
CREATE TABLE IF NOT EXISTS `student` (
`id` int(10) NOT NULL AUTO_INCREMENT COMMENT 'studentID',
`t_id` int(10) NOT NULL COMMENT 'teacherID',
`name` varchar(255) NOT NULL DEFAULT '''''' COMMENT 'studentName',
`age` int(10) NOT NULL DEFAULT '0' COMMENT 'studentAge',
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='studentInfo' AUTO_INCREMENT=1 ;
以上是创建的表结构 看不懂就在phpmyadmin里sql栏执行一下以上sql 就能看到了
teacher表 老师的信息 包括姓名和年龄 已经备注
student表 分别对应学生id t_id是老师的ID,就是这个学生的老师在老师表里的ID填进这里 学生的姓名,年龄
你说的数据表中的数据表 指的是关联表的对应关系
使用数据透视表和数据透视图向导即可创建。mysql的er图创建二维表使用ER图设计数据库数据库实体联系模型与关系模型。
topic为order中数据格式
order_detail表ddl
order_detail表数据
流表：创建data source去消费kafka中topic数据（此处创建了流对应的视图，简化后边join操作的sql书写。sql写法和阿里云的写法完全一致）
此处kafka地址为虚拟机集群地址（三台节点的集群）
维表：创建mysql维表
流表join维表，并打印输出信息
1.flink任务进行维表join操作时，会将当前维表的数据都加载到flink内部(内存或磁盘)。那么当维表的数据十分庞大时，维表全量数据都加载到flink内部可能导致flink任务无法进行或者join操作十分缓慢。(解决方案：使用LRU最少使用缓存淘汰算法。能够保证flink内部保存的维表数据是最新和使用最多的数据，旧数据或者未被使用到的数据都会被淘汰，大大减少flink缓存压力)
更多解决方案见
