伴随技术的不断发展，数据分析工具已经从简单的决策支持系统逐渐进化为更加现代化的云数据服务。作为云时代的巨头，亚马逊也提供了两个基于云计算的数据仓库服务：Amazon Redshift和Amazon Relational Database Service（RDS）。

尽管Amazon Redshift和RDS都是面向分析的云服务，但它们的应用场景存在一定的差异。在采用这两项服务之前，你首先需要弄清楚几个问题：

一问：你能否像Amazon Redshift一样把数据加载进来？

如果你的企业已经部署了数据仓库或数据集市系统，那么你肯定花了很多时间和精力开发定制化的ETL脚本来加载数据。如果你想要使用Redshift服务，那么就必须修改脚本代码来适应Redshift的数据加载方式。

将数据加载到Redshift的最佳方式是通过一个远程主机，Simple Storage Service（S3）服务或使用COPY命令的AWS Elastic MapReduce。COPY命令是采用并行的方式来执行数据加载任务的，它还可以在加载的过程中对数据进行压缩。

如果你的ETL脚本中嵌入了比较复杂的业务逻辑，那么你可以将最终的输出重新定向到一个本地文件或S3，然后使用COPY命令来进行加载。

Redshift可能还需要对你的ETL流程进行修改，但如果ETL脚本可以重复利用，只要把修改后的业务逻辑套入的话，那么使用Redshift就不存在任何问题，而且它特别适用于数据量比较大的系统。

二问：你是否愿意改用基于PostgreSQL的数据库？

RDS支持多个类型的数据库，包括MySQL、Oracle、SQL Server和PostgreSQL。如果你的分析数据库使用了一些特定功能，比如Oracle文本查询，那么你就需要慎重考虑是否采用新的服务了。因为你需要把特定的文本搜索代码进行修改，从而能够调用Amazon CloudSearch服务。而且除了Redshift之外，你还需要对CloudSearch进行配置与维护。

这时，你可以通过Amazon RDS来继续使用之前已经部署的关系型数据库和与之相关的特定功能。

除了像搜索这样的高级服务之外，你还可以使用与索引和强制约束这样更细粒度的功能。Redshift使用UTF-8字符，而新版本的SQL Server支持UTF-16，这意味着将数据映射到UTF-8会存在一定的挑战，这个过程中可能会存在一些你意想不到的陷阱。

如果你对使用基于PostgreSQL这样的数据库没有什么特殊需求的话，那么Redshift的优势就能够体现出来了，它将成为你的最佳云数据仓库。

三问：你的数据仓库是否需要扩展性和高可用性？

关系型数据库的扩展是一项非常考验DBA能力的工作。你可以在大型服务器上部署亚马逊数据仓库然后进行纵向的扩展，直到它无法满足你的性能需求。记住，纵向扩展并不会增加可用性，单点故障的隐患将一直存在。

如果你已经精通热备份维护以及采用读复制集来改善查询性能的话，那么一个可扩展的RDS对于你来说就不算什么了。如果不熟悉这些工作的话，那么除了维护RDS之外，你还需要额外进行高可用性和扩展性的维护。

AmazonRedshift采用服务器集群的部署方式，它的扩展更加容易。通过向Redshift集群添加节点，它可以提供线性或接近线性的性能提升。也就是说如果你在双节点的基础上再添加两个节点，那么它的性能也将提升两倍。在节点发生故障的时候，Redshift还会负责恢复的工作。发生故障的节点将被新的节点取代，而数据则可以从S3中自动进行恢复。

如果扩展性和可用性对于你的企业至关重要的话，那么Redshift无疑会是更好的选择。

四问：你的应用是否需要强制进行完整性约束？

你很难想象一个关系型数据库管理系统会不要求完整性约束，但Redshift就没有。这主要是出于性能方面的考虑。在写入操作完成之前，如果对每个节点进行查询然后等待反馈以便进行完整性约束话，那么系统的延时问题就一定会出现。

这使得加载程序需要进行主键、外键以及唯一键约束的检查。如果你的应用必须要进行完整性约束，那么RDS服务将会是更好的选择。

另一方面，Redshift更多的是一款云数据仓库。如果你可以接受Redshift的约束性特质，那么它会是不错的选择。特别是在数据量比较大的情况下，Redshift几乎可以说是你唯一的选择。而RDS对于小一些的数据集市部署更加适合。