PostgreSQL 两大数仓大比拼！ADB PG 与 Redshift 谁更胜一筹？

作者

云计算当代之际，因选择而产生困扰之症候：当直面具备独特不同功能的云数据仓库之时，企业究竟应当怎样来做出取舍呢，该如何去抉择呢？

架构基础对比

采用了PostgreSQL内核引擎的AWS Redshift，和同样采用该内核引擎的阿里云ADB PG，底层架构有着显著差异。Redshift是基于较老的PostgreSQL 8.2版本，而ADB PG却是基于更新的PostgreSQL 9.4版本，这表明ADB PG在基础功能方面更具现代性。两者都运用了MPP（大规模并行处理）架构，能够达成横向扩展，不过版本差异致使功能支持程度有所不同。

优势在于全面兼容PostgreSQL生态系统这事是ADB PG的，这其中包括支持PostGIS地理信息处理，还包括支持MADlib机器学习库等扩展，这种兼容性让现有PostgreSQL用户迁移成本大幅降低，而Redshift因为内核版本较旧，所以需要额外适配才可使用新版PostgreSQL的特性。

存储引擎差异

PostGIS_ADB PG与Redshift数据迁移指南_阿里云AnalyticDB for PostgreSQL迁移AWS Redshift

Redshift只支持那种是以列来存储的表，这样的设计格外契合OLAP场景当中的聚合查询操作。列存格式能够迅速开展大规模数据的扫描以及统计方面的运算，然而在那些需要频繁进行更新的场景里表现并不出色。这样的一种局限性致使Redshift更适宜于数据仓库的读密集型工作负载。

ADB PG同时支持行存、列存这两种不同的存储格式，行存表具备PostgreSQL原本所拥有的、那种用于高吞吐数据更新的能力，此优势适合用于需要进行频繁的增加、删除以及修改操作场景，列存表是专门针对分析查询这一行为进行了优化处理的，它与Redshift在这方面具有相似之处，这样的双存储引擎设计为企业给予了更为灵活的选择空间。

功能特性比较

CREATE TABLE schema1.table1(
    filed1 VARCHAR(100) ENCODE lzo,
    filed2 INTEGER DISTKEY,
    filed3 INTEGER,
    filed4 BIGINT ENCODE lzo,
    filed5 INTEGER,)
INTERLEAVED SORTKEY (
    filed1,
    filed2);

在SQL语法兼容性这块儿，二者对于PostgreSQL标准都有着高度的兼容性，然而却存在着细微的差别不一样，相较于这个，ADB PG还额外支持一部分Oracle语法，这对于那些从Oracle数据库迁移过来的用户而言，更具备吸引力。与之不同的是，Redshift维持着相对更为纯粹的PostgreSQL语法体系，不过增添了一些独有的扩展语法。

关于事务支持这块，ADB PG在这方面全面支持ACID事务特点，这就表明它能够应对更为繁杂的事务性质的工作负载。Redshift虽说也给予了一定程度的事务支持，不过主要是针对分析情形做了优化，在事务完整性这方面相对没那么严格。

CREATE TABLE schema1.table1
(
    filed1 VARCHAR(100) ,
    filed3 INTEGER,
    filed5 INTEGER
)
WITH(APPENDONLY=true,ORIENTATION=column,COMPRESSTYPE=zlib)
DISTRIBUTED BY (filed2)
SORTKEY
(
    filed1,
    filed2
)

数据迁移方案

从Redshift转移至ADB PG得历经好些步骤。其一，要预备好Amazon S3以及阿里云OSS的存储资源，去保证数据能够实现跨云平台传送。其二，运用OSSImport工具能够把S3里CSV格式的数据文件迁移到OSS对象存储当中。

在目标端那里的ADB PG里，要预先创建相应的数据库对象，这其中涵盖表结构、视图以及函数定义。因为语法存在着差异，所以部分对象有可能得进行调整。最终利用外部表功能，将OSS里的数据加载到ADB PG中，以此来完成迁移。

CREATE TABLE schema2.table2
(
    filed1 VARCHAR(50) ENCODE lzo,
    filed2 VARCHAR(50) ENCODE lzo,
    filed3 VARCHAR(20) ENCODE lzo,
)
DISTSTYLE EVEN
INTERLEAVED SORTKEY
(
    filed1
);

性能优化特性

CREATE TABLE schema2.table2(
    filed1 VARCHAR(50),
    filed2 VARCHAR(50),
    filed3 VARCHAR(20))
WITH(APPENDONLY=true, ORIENTATION=column, COMPRESSTYPE=zlib)
DISTRIBUTED randomly
SORTKEY
(
    filed1
);

Redshift给出了ENCODE压缩选项，以及SORTKEY排序键等独具的性能优化功能， 这些特性能够助力用户优化存储空间，以及查询性能， 但要留意这些专用语法在迁移至其他平台时需重新去实现。

ADB PG提供了优化方式，这种方式更符合PostgreSQL标准，涵盖索引策略、表分区等技术，还支持云存储数据直接访问，能方便地与OSS进行数据交互，这些特性让性能调优变得更加灵活。

适用场景分析

Redshift适宜纯分析型工作负载，尤其是那些要执行复杂聚合查询的情形，其列式存储设计于扫描大量数据之际表现优异，然而不太契合需要频繁更新的操作型应用，。

使 ADB PG 的混合存储架构得以同时支持 OLTP 与 OLAP 工作负载，这种灵活性致使企业能够于一个平台之上运行多种类型的应用，进而降低了系统复杂度以及运维成本，尤其在需要实时更新的场景当中优势显著。

当您去考量对云数据仓库进行选择的这个行为时，是会觉得更加应当重视存储架构所具备的先进性呢亦或是生态系统所拥有的完整性呢？欢迎您来把您开展的实践经验予以分享！

发表评论