# 支持与限制 实时数仓兼容所有列存语法，具体情况如下： 表1支持的语法 | 语法 | 是否支持 | |:---|:---| | CREATE TABLE | 支持 | | CREATE TABLE LIKE | 支持 | | DROP TABLE | 支持 | | INSERT | 支持 | | COPY | 支持 | | SELECT | 支持 | | TRUNCATE | 支持 | | EXPLAIN | 支持 | | ANALYZE | 支持 | | VACUUM | 支持 | | ALTER TABLE DROP PARTITION | 支持 | | ALTER TABLE ADD PARTITION | 支持 | | ALTER TABLE SET WITH OPTION | 支持 | | ALTER TABLE DROP COLUMN | 支持 | | ALTER TABLE ADD COLUMN | 支持 | | ALTER TABLE ADD NODELIST | 支持 | | ALTER TABLE CHANGE OWNER | 支持 | | ALTER TABLE RENAME COLUMN | 支持 | | ALTER TABLE TRUNCATE PARTITION | 支持 | | CREATE INDEX | 支持 | | DROP INDEX | 支持 | | DELETE | 支持 | | ALTER TABLE 其他 | 支持 | | ALTER INDEX | 支持 | | MERGE | 支持 | | SELECT INTO | 支持 | | UPDATE | 支持 | | CREATE TABLE AS | 支持 | #### 约束限制 - 当需要使用HStore表时，需要同步修改以下几个参数的默认值，否则会导致HStore表性能严重劣化。 9.1.1.100集群版本开始推荐的参数修改配置是：autovacuum_max_workers_hstore=3，autovacuum_max_workers=2，autovacuum_max_workers_col=2，autovacuum=true。 - 8.2.1及以上版本支持列存btree索引脏数据清理，频繁更新入库的场景下能有效控制索引空间，提高入库与查询性能。实时场景不应该对列存使用psort索引原因如下： 1. psort没有索引清理，索引空间会持续膨胀。 2. psort只对攒批入库的数据进行排序，实时场景性能提升有限。 - 9.1.1.100集群版本hstore表脏页清理依赖列存vacuum和异步排序两个机制协同工作，默认小于1000行的CU被定性为小CU。脏页中小CU会通过异步排序的机制完成合并，非小CU通过列存vacuum重写到新的文件。列存vacuum受阈值参数colvacuum_threshold_scale_factor（该参数需联系技术支持修改）控制。 - 当使用HStore异步排序功能时，异步排序期间可能会阻塞部分数据的DML操作，最大的阻塞粒度为异步排序的行数阈值，因此在反复DML的场景下不建议使用此功能。 #### 列存表的Delta表差异 表2HStore表与列存表的辅助Delta表差异 | 数仓类型 | 列存的delta表 | HStore的delta表 | HStore Opt的delta表 | |:---|:---|:---|:---| | 表结构 | 与列存主表的表定义一致。 | 与主表定义不一致。 | 不同于主表，与HStore表相同。 | | 功能 | 用于暂存小批量insert的数据，满阈值后再merge到主表，避免直接insert到主表产生大量小CU。 | 用于持久化存储update/delete/insert信息。在产生故障后用于恢复内存更新链等管理并发更新的内存结构。 | 用于持久化存储update/delete/insert信息。在产生故障后用于恢复内存更新链等管理并发更新的内存结构。相比HStore进一步优化。 | | 缺陷 | 来不及merge导致delta表膨胀，影响查询性能，同时无法解决并发update的锁冲突问题 | 依赖后台常驻autovacuum来做merge操作。 | 依赖后台常驻autovacuum来做merge操作。 | | 规格差异 | 不支持同一CU的并发，适合并发更新较少的情况。 | 1. 插入和更新限制 - MERGE INTO操作不支持并发更新同一行或对同一键进行重复更新。 - 不支持并发update或delete同一行，会触发报错。 2. 索引和查询限制 - 索引不支持数组条件过滤、IN 表达式过滤、部分索引或表达式索引。 - 索引不支持失效处理。 3. 表结构和操作限制 - 在进行分区交换或 relfilenode 操作时，确保交换的表都是 HStore表。 - 不支持update修改分布列，不建议update修改分区列（不报错，但性能非常差）。 | 1. 插入和更新限制 - MERGE INTO操作不支持并发更新同一行或对同一键进行重复更新。 - 不支持并发update或delete同一行，会触发报错。 - hstore_opt不支持跨分区upsert更新。 2. 索引和查询限制 - 支持bitmap索引。 - 支持全局字典。 - bitmap_columns 必须在建表时确定，一旦设置后不允许修改。 - opt 版本不支持 SMP streaming 透传参数。在需要分区剪枝的多表关联查询中，避免使用复制表或设置 query_dop。 3. 表结构和操作限制 - 不支持update修改分布列，不支持update修改分区列。 - enable_hstore_opt 属性需在创建表时设定，且不可更改。 | | 入库建议 | 1. 综合入库、查询和空间情况，建议选择hstore_opt表，微批copy无更新入库场景性能要求高的情况下选择hstore表。 2. HStore/HStore Opt共同点： - update入库性能差，建议修改为upsert。 - delete入库，确定计划走索引扫描即可，用JDBC batch方式入库最佳。 - merge into入库建议在单次入库数据量超过100W/dn，且无并发数据保证无重复的情况下使用。 - 尽量避免对冷分区的数据进行修改和新增。 ||| | 点查建议 | 1. 综合点查场景，建议使用HStore Opt表。 2. HStore/HStore Opt共同点： 在等值过滤条件使用最多且distinct值分布相对均匀的一个列上创建二级分区。 3. HStore的点查建议： - 使用主键之外的索引加速不能得到预期效果，不建议开启。 - 如果数据类型多为numeric或者16字节以内的字符串，建议使用turbo加速。 4. HStore Opt的点查建议： - 除了二级分区之外的等值过滤列，如果过滤条件涉及的列在查询中基本固定，使用cbtree索引，如果不断变化建议使用GIN索引，注意创建索引的列数不要超过5列。 - 所有涉及等值过滤的字符串列，都可以建表时指定bitmap索引，不限列数，但后续不可修改。 - 时间范围过滤的列，指定为分区列。 - 点查返回数据量超过10W/dn的场景，索引扫描的性能提升有限，建议针对这种情况使用guc参数enable_seqscan对比测试，灵活选择。 |||