adbmrio数据库怎么计
发布网友
发布时间：2023-01-12 16:07
我来回答
共1个回答
热心网友
时间：2023-06-25 23:24
ADB笔记：
目标：主要用于数据分析，后端支持BI报表和数据大屏。mysql协议，学习成本低。
特有名词：
表组，对应RDS的schema。
维度表组（系统自带）：自带维度概念的表（例如省份表等），可以放到维度表组下
普通表组：一般会把需要关联的普通表放在相同普通表组中，建议这个表组中的所有普通表的一级分区数一致，join性能会有很大提升。
维度表：共享表。
普通表：分区表。默认一级分区，可创建二级分区。
分区：普通表才有,一级分区采用hash算法，单表数据量在60亿以内,推荐。
主键：表必须包含主键。由业务id、一级分区键组成，有些情况业务id与一级分区相同。对于记录量特别大的表，从存储空间和insert性能考虑，一定要减少主键的字段数。
数据库创建完毕后，系统会默认创建一个维度表组，所有维度相关的表，可以放到维度表组下。
特殊字段：timestamp timestamp AnalyticDB精确到秒，MySQL支持自定义精度
常用sql连接：
https://help.aliyun.com/document_detail/94859.html?spm=a2c4g.11186623.2.38.22c965313Zwnsd
navicat连接后，无法显示建表语句。
输入导入方式：1、DTS；2、数据集成。
insert插入显示延迟5-10S，可单独提工单修改。
更新数据：AnalyticDB不支持update操作，可以通过主键覆盖的方式进行insert操作来实现和update同等的功能。
数据导出功能较弱，mp方式到OSS/MaxCompute
推荐权限定义方式：https://help.aliyun.com/document_detail/95546.html?spm=a2c4g.11186623.6.578.702d620fyspxAo
索引&扫描原理
AnalyticDB内部采用列存方式，通过单列高效过滤后，可直接通过内部记录指针扫描其他列值，减少其他列的索引查询开销。
子查询修改为表关联
普通表join普通表，尽量包含分区列join条件，如果不包含则，尽量通过where条件过滤掉多余的数据。
维度表join普通表，没有*。
默认是全索引，建表成功后，某列删除索引操作，需提工单解决。
二级分区用于删除数据，对于“回溯表”类场景，避免手动删除。
一级分区键选择：
1、分布均匀，避免数据倾斜。park_record_id？
2、建议选择一级分区列的数据类型为tinyint、smallint、int、bigint或者varchar。
3、如果是多个普通表（不包括维度表）JOIN，则选择参与JOIN的列作为分区列。park_record_id？park_id?
4、选择GROUP BY或DISTINCT包含的列作为分区列
5、如果常用的SQL包含某列的等值或IN查询条件，则选择该列作为分区列。以下列子则选择id作为分区列。
select * from table where id=123 and …;
select * from table where user in(1, 2,3);
使用场景以管理员使用为主，范围扫描较多，park_id分区优势更大。
历史单条数据，管理员查询较少，可忽略。
用户单条查询，在RDS完成。
多参考设计样例：https://help.aliyun.com/document_detail/97587.html?spm=a2c4g.11186623.6.655.207b43c1yl28Kx
https://help.aliyun.com/document_detail/97620.html?spm=a2c4g.11186623.6.656.5ebb12f55cr9Pf
为满足高QPS，从设计上采用大宽表、冗余字段，并且避免表关联。
场景描述：全量sql，查询频率低，以区域统计查询为主。
最佳实践：区域查询、车场查询读扩大，数据分布均匀+聚集列效果。缺点：
PRIMARY KEY (park_record_id,TS)
PARTITION BY HASH KEY (park_record_id) PARTITION NUM 128
SUBPARTITION BY LIST KEY (TS)
SUBPARTITION OPTIONS (available_partition_num = 300)
CLUSTERED BY (area_id,park_id)
单个AnalyticDB最多表数 256
单个表组总表数 256
最大一级分区数 255
不支持存储过程
是否支持修改表的一级分区数：当前不支持动态修改，只能删表重建。
