PostgreSQL 作为一个开源且功能强大的关系型数据库管理系统，在 OLTP 系统中得到了广泛应用。很多企业利用其卓越的性能和灵活的架构，应对高并发事务、快速响应等需求。
然而对于 OLAP 场景，PostgreSQL 可能并不是最佳选择。
为了实现庞大规模数据的数据分析场景，企业会选择使用专业数据仓库产品。例如：ClickHouse、Doris、SelectDB、Greenplum、Redshift 等。选择数仓不得不考虑查询性能和存储效率，而 SelectDB 在这两个方面表现优异，在查询性能方面，SelectDB 采用先进的列存储和向量化执行引擎，能够高效处理复杂查询，提供卓越的查询性能；在存储效率方面，SelectDB 的列存储结构和高效压缩算法，大大减少了磁盘占用和 I/O 开销。
表的初始化：SelectDB 端是不是要先创建一个和源端一致的表结构？然后才能从源端接收数据。手动进行初始化的情况下，如果 PostgreSQL 端有成百上千个表，你又该如何应对？
数据结构的映射：PostgreSQL 和 SelectDB 两者数据结构不同，这点很重要，需要确保数据从源端同步过去后还是完整的。很负责任地说一句，除非你对两者的数据模型的理解非常极致，且保证绝对不出错，才可能达到理想的结果。
实时同步的速率：让 SelectDB 端的数据时刻与源端的 PostgreSQL 保持一致。通过 SelectDB 进行数据实时分析的大前提是，当前 SelectDB 中的数据必须是最新的，分析结果才有意义。
源端 DDL 语句的联动：实时捕获源端 PostgreSQL 的 DDL 变更，并及时在目标端的 SelectDB 中同步执行。这绝对不能算是一个轻松的工作，大多数情况下，源端的数据结构发生变化时，同步链路会中断，导致迁移失败。
同步任务的稳定性：试想如果需要长期在线同步 PostgreSQL 和 SelectDB，什么最重要？当然是同步任务的稳定性。你得考虑在网络、服务器出现异常的情况下，应该怎么保证任务可用。
结构复制：基于目标端数据源的特性，自动高效地完成表的创建、数据结构的映射等工作。
复制性能：基于动态攒批、并行复制、Stream Load 等技术，复制性能轻松达到 200 MB/S。
DDL 捕获与执行：实时检测源端中的 DDL 操作，并同步在目标端中执行，保证其他业务变更能够稳定地进行。
其实像异构数据迁移这样的事，只要选对了工具，真的没那么难，属于有手就行。就好像本文的 PostgreSQL 迁移到 SelectDB 的场景，一顿操作下来，任务马上就起来了，数据也立刻就过去了，新的增量数据一眨眼功夫就可以在 SelectDB 端查询到了，回想一下好像自己什么也没干，但却发现数据分析的前置工作都已经完成了。
