AWSRedshiftとSnowflakeのユースケース
AWS RedshiftとSnowflakeの両方を使用したことがあり、どちらかが優れているユースケースがあるかどうか疑問に思いました。私はRedshiftを使用しましたが、最近誰かがSnowflakeを良い代替手段として提案しました。私のユースケースは基本的に小売マーケティングデータであり、SQLにあまり精通しておらず、レポートツールが最上位にある可能性が高い少数のアナリストが使用します。
Redshiftは優れた製品ですが、Snowflakeよりも優れているユースケースを考えるのは難しいです。スノーフレークが優れている理由は次のとおりです。
- 管理コンソールは素晴らしく、Redshiftには何もありません。
- スケールアップ/ダウンは数秒から数分で発生し、Redshiftは数分から数時間かかります。
- 両方の製品のドキュメントは優れていますが、Snowflakeはより適切にレイアウトされ、アクセスしやすくなっています。
- スノーフレークをうまく機能させるには、「秘密のソース」をあまり知る必要がありません。 Redshiftでは、少なくとも、配布キーや並べ替えキーなどのパフォーマンスへの影響を理解しておく必要があります。
- Snowflakeのロードプロセスは、Redshiftよりもエレガントです。 Redshiftは、データがすでにS3にあることを前提としています。 SnowflakeはS3をサポートしていますが、JDBC、ODBC、およびdbAPIの拡張機能があり、取り込みプロセスを本当に簡素化して保護します。
- Snowflakeはデータベース内のJSONを強力にサポートしており、XMLを急速に強化しています。 RedshiftはJSONに対してより複雑なアプローチを採用しており、小規模なユースケースを除くすべてのユースケースでJSONを推奨せず、XMLをサポートしていません。
Redshiftが手に負えない2つのケースしか考えられません。 1つは地理的な可用性です。RedshiftはSnowflakeよりもはるかに多くの場所で利用できるため、データ転送とステートメントの送信時間に違いが生じる可能性があります。もう1つは、複数のステートメントのバッチを送信する機能です。 Snowflakeは、一度に1つのステートメントしか受け入れることができません。これにより、バッチが多数のステートメントで構成されている場合、特にサーバーの別の大陸にいる場合は、バッチの速度が低下する可能性があります。
Ajilius で、開発者はRedshift、Snowflake、およびAzure SQL DataWarehouseを毎日使用しています。 3つのプラットフォームすべてに顧客がいます。その選択があっても、すべての開発者は、頼りになるクラウドDWとしてSnowflakeを好みます。
Redshift（S3を使用したRedshfitスペクトル）とSnowFlakeの両方を評価しました。
私の概念実証では、snowFlakeはRedshiftよりもはるかに優れています。 SnowFlakeは、リレーショナル/ NOSQLデータとうまく統合されます。先行インデックスやパーティションキーは必要ありません。それは、その日にアクセスする方法を心配することなく、驚くほど機能します。
Redshiftは非常に制限されており、jsonはサポートされていません。パーティションを理解するのは難しいです。あなたは何かを成し遂げるためにたくさんの仕事をしなければなりません。 jsonのサポートはありません。 S3にアクセスするための絆創膏としてredshiftspecturmを使用できます。事前に分割して頑張ってください。 S3バケットにパーティションを作成したら、それで完了です。すべてのデータを新しい構造に再度処理しない限り、変更する方法はありません。実際のビジネス上の問題の修正に取り組む代わりに、これらの問題を修正するための時間を送ることになります。
スマートフォンとモールス信号のメカニズムを比較するようなものです。 Redshiftはモールス信号のような実装であり、mordern開発用ではありません
最近、次の理由でRedshiftからSnowflakeに切り替えました。
- リアルタイムのデータ同期
- 同時クエリの処理
- データベース管理の最小化
- さまざまなLookerユーザーにさまざまな量のコンピューティングパワーを提供する
より詳細な記事は、 データブログ にあります。
RedshiftとSnowflakeを評価し、AthenaとSpectrumも少し評価しました。後者の2つは、メモリが不足するため、大きな結合があった場合は初心者ではありませんでした。 Redshiftの場合、いくつかの理由で、実際にはパフォーマンスに対する価格の比率を上げることができました。
- 同じ場所に配置された結合に巨大な配布キーを選択できます
- 3年間の予約価格の大幅な割引が可能になるため、リーズナブルなコストでコンピューティングを実際にアップサイズできます
ほとんどの場合、Redshiftを使用するとパフォーマンスを向上させることができますが、物理スキーマを適切にセットアップするには、MPPに関する十分な知識が必要です。専門知識と複雑さのコストは、製品コストの一部を相殺します。
RedshiftはJSONをVARCHAR列に格納します。これにより、VARCHAR列のサイズが大きすぎる大きなテーブル全体でJSON要素のサブセットをクエリするときに問題（OOM）が発生する可能性があります。私たちの場合、非常に大きなJSONドキュメントを持ついくつかのレコードに対応するために、VARCHARを非常に大きなものとして定義する必要がありました。
スノーフレークの機能は驚くべきものです。
- オブジェクトのクローンを作成する機能
- jSONデータを処理するための深い機能
- 低メンテナンス負荷、自動スケーリング負荷、トリクルアップデートのためのスノーパイプ
- 自家製ETLのストリームとタスク
- ストレージを拡張し、個別に計算する機能
- データ移行を必要とせず、1分以内にコンピューティングをスケーリングする機能
- などなど
Snowflakeについて私が注意したいことの1つは、システムを実行するためにスキルの低い開発者/ DBAを雇いたくなるかもしれないということです。悪いスキーマ設計でのパフォーマンスは、巨大なコンピューティングクラスターを使用して回避できますが、それはコストに見合う最高の価値ではない可能性があります。とにかく、スノーフレークの機能は素晴らしいです。