２１世紀のビジネスは、テクノロジーに支えられています。なのでデータを適切に扱い、保存し、活用する方法を学ぶことは、あらゆる業種の企業にとって不可欠です。そして近年では、組織の BI（ビジネスインテリジェンス）を高め、より適切な意思決定を行うために、データウェアハウスを活用する企業が増えてきています。

ビジネスニーズに合ったデータウェアハウスを見つけるのは、特に最初のうちは難しいものですが、幸い、Integrate.io が、ビジネス目標に適したデータウェアハウスを見つけるお手伝いとともに、組織のニーズを満たす優れたデータマネジメントサービスを提供できます。

そこで本記事では、データウェアハウスについての詳細と、Redshift と Postgres でどちらのデータウェアハウスを取り入れるべきかについて見ていきます。

目次

Redshift と Postgres の概要

組織の成長に伴い、データの保存、監視、分析の量は飛躍的に増加します。そこで多くの企業は、すべてを一元化し、データ分析チームの仕事をよりシンプルにすべく、データウェアハウスを設けるでしょう。

PostgreSQL（通称：Postgres）もその1つです。Postgresは１９９６年から存在しているため、多くの人に慣れ親しまれていますが、最初のクラウドデータウェアハウスである Amazon Redshift は、２０１２年のリリース以来、多くの支持を集めています。Redshift と Postgres の比較を深く掘り下げる前に、以下で両データウェアハウスの主な違いを確認しましょう。
 
関連記事：What Is a Data Warehouse and Why Are They Important?

Redshift と Postgres の主な違い５点：

  1. データの格納および構造法：Postgres は行順のアプローチでテーブルを構築するのに対し、Redshift は列順のデータベースである。
  2. Postgres は無償のオープンソース（無料）データベースであり、Redshift は有料サービスである。
  3. Postgres はトランザクションデータの処理に適しているのに対し、Redshift は分析向けである。
  4. Redshift と Progres は「行ストア型データベース」と「列ストア型データベース」であることから、制約とインデックスの実装が異なる。
  5. Redshift はクラスタ上で動作するのに対し、Postgres はシングルノードのデータベース上で動作する

Redshift は Postgres 上に構築された

Redshift は Postgres 8.0.2 をベースに作られましたが、両者は同じものではありません。Redshift の元々の開発者によって、重要な変更がいくつか加えられましたが、その変更は、どのデータウェアハウスが組織の目標により適しているかを決定する際に、極めて重要な意味を持ちます。

その変更点は、以下に関連しています：

  • データアーキテクチャ 
  • 価格 
  • 言語 
  • 速度＋クエリ最適化 
  • 分散処理

Postgres と Redshift を比べると、構文や機能には馴染みがありますが、各オプションの構造とパフォーマンスに関しては、明確な違いがあります。そこで、両データウェアハウスを詳しくご紹介し、その真価を明らかにしていきます。

関連記事：What Is a Data Warehouse and Why Are They Important?

Redshift を詳しく見てみよう

Amazon のサービスとして提供される Redshift は、クラウド上で完全に管理されたカラム格納型のデータウェアハウスです。つまり、Redshift は、各カラムが独自のファイルで表現されるように設定されているということであり、単一列や少数列のクエリを望む場合、クエリが完了する前にテーブル全体を読み込む必要がないということです。Redshift には、特定の列に移動して、関連する行からデータを抽出する機能があるのです。

また、Redshift は、数百万行を超えるような複雑なクエリに対応できるように設計されていることから、企業が増大するデータ需要に基づいてスケールアップする必要がある場合、従来のオンプレミスウェアハウスのソリューションや代替案として注目されています。

Amazon は ParAccel という会社に投資し、PADB（ParAccel Analytic Database）のコード使用のライセンスを取得しました。PADB は Postgresをベースにしていたため、Redshift にも主要な類似性が見られますが、明確な違いも多くあります。

大規模なデータを扱うのに設計された Amazon Redshift は、そのスピードが売りであり、大規模なデータセットに対して高速なクエリ速度を実現する Redshift は、かなりの量のオンデマンドクエリを実行するアプリケーションにとって最良の選択肢の１つです。また、Redshift のスケーラビリティは、後述するクラスタベースのアーキテクチャに基づいています。

Redshift のクエリ層は Postgres に似ていますが、Postgres の標準クエリ層が提供する機能の多くが欠けています。とはいえ、Redshift の機能不足は、スケーラビリティや大量のデータを処理する能力の面で補うことができます。

Integrate.io のネイティブ Redshift コネクタの詳細については、こちらをご覧ください。

Redshift の主なメリット：

  • 一般速度とクエリ速度の一部を高速化する
  • 使いやすさとアクセシビリティの高さが売り
  • スケーラビリティ 
  • 性能に見合った費用対効果

関連記事：Amazon Redshift - Comprehensive Guide

Postgres を詳しく見てみよう

無料のオープンソースのデータベースである Postgres は、行ストア型データベースです。つまり、テーブルは「行」と呼ばれるエンティティで構成され、列ベースのデータを抽出するのにパース（解析）しないといけません。また、Postgres では、ユーザー定義型、主キー、外部キーなど、トランザクションデータベースに期待される機能がすべて提供されます。

さらに、カラムの数に関係なく、Postgres を使うと、多くの行をクエリするのが簡単です。

これは、非常に広いテーブルがあり、探索的なデータ分析を行う場合に便利です。例えば、全データを俯瞰的に見たいとすると、Postgres では明確なパターンがあるかどうかを確認することができます。Postgres と Redshift を比べると、この部分は Redshift の新米アナリストには大変かもしれませんね。

これには、基本的に無料で大量の列からデータを受信できるという利点もありますが、ビッグデータと 4 つの V （volume, veracity, variety, and velocity）となると、問題が浮き彫りになります。以下の例では、行数はボリュームを、列数はバラエティを表しています。

例えば、２００のカラムと５００万行のクエリを持っているが、実際には１０カラムにしか望んでないとします。Postgres を使うと、その５００万行に関連する２００カラムすべてに関連するデータをフェッチする必要があり、これは、データ開発者にとってはクエリの速度が低下する結果になります。ここでも、Redshift が際立ちますね。ただし、一度に多くのカラムを探索しようとすると、同じことは言えず、広いテーブルをクエリする際にスケーラビリティが悪くなってしまいます。

RedshiftとPostgresの比較

Redshift と Postgres を並べてみると、両者の間には明確な違いがいくつもあります。

スケーリング（拡張）

スケーリング（拡張）をお考えなら、Redshift はシームレスなスケーリングを念頭に置いて設計されています。数分で拡張できるため、そのプロセスはシンプルで、ノードの追加、ノード構成のアップグレード、またはその両方の組み合わせによって実現され、AWS によって全て管理されます。Redshift の基本的なアーキテクチャは MPP（超並列処理）ですが、それによって拡張が非常に効率的になります。MPP データベースは、より高価な個々のサーバーにアップグレードする必要がある垂直方向の拡張ではなく、コンピュートノードを追加することで水平方向に拡張します。Redshiftでは、クラスタにノードを追加すればするほど、クエリを高速に完了できるようになるのです。

対する Postgres は単一サーブのデータベースであるため、スケーリングは強みの一つではありません。スケーリングしたい場合は、データをすべて新しいディスクにコピーしないといけないでしょう。

アーキテクチャと性能

主なアーキテクチャの違いは、Redshift が「列指向の OLAP データベース」であるのに対し、Postgres が「行指向の OLTP データベース」であることです。つまり、Redshift の『列』に対して、Postgres では『行』が基本的なデータオブジェクトとして機能します。ちなみに列指向データベースであるのは、従来のリレーショナル・データベースよりも使用するスペースが少なくて済むというところに利点があります。

また、Redshift は分析に適しているため、データウェアハウスのプラットフォームとしてもより適切と見なされており、この違いは、基本的な SELECT 文のクエリパフォーマンスに大きく影響します。

これは、インデックスと制約の実装方法に影響します。Redshift では、PostgresだけでなくSQLite や MySQL でも対応している共通機能である「インデックス」が存在しません。その代わりに、Redshift では SORT KEY と DIST KEY が使われ、それによって、一般的なクエリを最適化することができますが、外部キー制約は技術的に認められていないため、これは stull の欠点です。さらに、Redshiftではマテリアライズドビューを必要としないため、スペースの節約という点ではより有利になります。

数百万、数十億行のデータを管理できるように、Redshift は Postgres のようにシングルノードのデータベースではなく、クラスタ上で動作し、単一のリーダーノードと、ユーザーが選択した多数のコンピュートノードをベースに動作します。リーダーノードは、コンピュートノードにタスクを委譲する役割を担い、コンピュートノードはクエリプランを実行します。

本来は、コンピュートノードの数が多いほどクエリが高速になり、その分コストがかかりますが、Redshift では、性能要件や予算に応じてさまざまなタイプのノードを選択し、カスタマイズすることができます。なので Redshiftのクエリ速度だけでも、スケーラビリティだけでも、多くのデベロッパーがすでに Postgres から移行しています。

Redshift は性能に特化していますが、スキャン範囲が広く、複雑で高度な分析が必要なワークロードに最適です。一方、Postgres はデータ範囲が短い、よりシンプルなクエリに最適です。これは、Redshift が洗練されたクエリのオプティマイザで構築されているためですが、単純なクエリだけでいい場合、このオプティマイザは実際の実行時間よりも多くの時間を要することがあります。

言語

言語に関しては、Postgres も Redshift も SQL がネイティブ言語として使われていますが、特にその構文に関連して、明確な違いがあります。コマンドを比べると、コマンドリストそのものとそのシンタックスの両方で、明確な違いがあります。

例えば、Redshift の［CREATE TABLE］コマンドでは、テーブルの分散やソートのアルゴリズムを確定することができます。これに対して、Redshift はテーブルのパーティショニング、テーブルスペース、継承などに対応しておらず、［INSERT］、［UPDATE］、［DELETE］に重点を置きながら、「WITH」句に対応していません。これはほんの二例です。

データ型と機能

以下のデータ型は Postgress で対応されていますが、Redshift では対応されていません。また、これは以下に挙げたものに限定されるものではありません：

  • Arrays （配列）
  • BIT, BIT VARYING
  • TIME と INTERVAL のような日付と時間の型（Redshift はタイムスタンプデータに対応）
  • ジオメトリック型
  • JSON
  • MONEY、SERIALなどを含む数値型。
  • 擬似型 
  • 範囲型
  • XML

一方、Redshift が対応しているデータ型は、TIMESTAMP から DECIMAL、DOUBLE PRECISION、SMALLINT まで多数存在します。

対応対象外の機能の一覧はこちらです。

機能に関しては、Redshift が対応していない Postgres の 機能の全リストがあります。それには、テーブルスペース、（ユニーク、外部、プライマリなどの）制約、データベースロール、照合、インデックス、値表現、トリガー、シーケンスなどが含まれますが、その限りではありません。

まとめると、Redshift には Postgres によくある機能がないのですが、それを補って余りある膨大な量のデータを処理する能力があります。その意味では、ビッグデータを望まないのであれば、Postgres にこだわるのもありでしょうが、拡張する準備が整えば、Redshift は移行する価値があります。

Redshift に加えられたアーキテクチャーの変更に基づけば、Redshift は分析クエリには最適です。Postgresは、少量のデータのデータウェアハウスとしての役割を果たすことは間違いありませんが、性能だけを見れば、Redshift とは比べものになりません。あと、もし Redshift に移行する準備ができたら、コマンドとコンセプトは十分に似ているので、言語はわかるでしょう。

料金設定

Postgres は無料なので、価格面では負けないですね。ただ、Postgres を動かすためのハードウェアの購入が必要です。そうなると、Redshift の性能に耐えうる  Postgres ベースのデータウェアハウスを構築するのであれば、サーバー代が高くついてしまうかもしれません。

これに対し、Redshift は有料サービスであり、ゼロからデータウェアハウスを作るとすると、コスト算出は厄介ですが、「オンデマンド価格」と「リザーブドインスタンス価格」の２つのスキームが提供されており、価格に関しても柔軟です。

［オンデマンド価格］だと、コミットメントや初期費用は不要であり、このオプションは、テストや開発に最適です。各ノードに対して１時間あたりの料金を支払い、その場合の価格は、ノードの種類と地域に基づいて決定されます。例えば、５００GB未満のデータサイズに最適な「高密度計算ノード」は、５００GBを超えるデータサイズに最適な「高密度ストレージノード」よりも安いです。それに対し、［リザーブドインスタンス価格］を選択した場合、先払いで最大７５％の節約が可能ですが、その場合は契約へのコミットが必要です。価格は、データウェアハウスのサイズ、ひいては使用するノードに基づいて決定されます。また、追加機能には費用がかかります。

価格設定も Redshift のクラスタベースのアーキテクチャに関連しているため、Redshift のデータウェアハウスを設定する際には、最小限のサイズとそれに伴う価格が設けられています。つまり、もしかなり小規模なデータ運用を行っているのであれば、本当に必要な金額以上を支払うことになるかもしれないということです。

Amazon Redshift の価格に関する完全なガイドはこちらをご覧ください。

どちらを選ぶべきか

自分や自身のニーズに合った最適なオプションを選ぶ際は、次のことを考慮しましょう：

  • データ量がペタバイトに達し、ワークロードが主に分析的で、多くのカラム処理を必要とする場合は、Redshift を選びましょう。ただし、一意のキー制約を確保するのに責任を担う必要があります。また、データウェアハウスの性能を最大限に引き出すために、［SORT KEYS］と［DIST KEYS］を使ったデータ構造の設計が必要になります。

  • データ量がテラバイト単位で、近い将来にデータ量の大幅な増加が見込まれない場合や、データをネットワーク内に保存したい場合、トランザクション処理を主な目的とする場合には、Postgres を選びましょう。ただしこのオプションは、クエリがよりシンプルで、スキャン範囲があまり大きくなく、主に完全な行と限られた数の列を扱う場合にのみ十分であることに留意しましょう。

関連記事：How to Offload ETL from Redshift to Integrate.io

Integrate.io ができること

Redshift や Postgres が自社に合っていると判断しても、貴重な企業データの取り扱いや活用をスムーズにするための「データ管理プラットフォーム」は必要です。そこで、Integrate.ioの出番となるわけです！

Integrate.io のプラットフォームを使うと、経験がなくても ETL パイプラインを設計、構築、実行することができるようになります。このような機能とIntegrate.io のツールキット全体で、会社のデータ管理がより効率的かつ効果的になることでしょう。

Integrate.ioのプラットフォームがもたらす多くのメリットについて、詳しくご覧になりたい方は、 ７日間のデモやトライアルにお申込みください。早速今日から、目標達成のために Integrate.io がどのようにお手伝いできるかぜひご体験ください