データ共有を使用すると、Amazon Redshift クラスター間でライブデータを安全かつ簡単に共有できます。 データ共有の使用を開始する方法、および AWS Management Consoleを使用してデータ共有を管理する方法については、「データ共有タスクの管理」 を参照してください。 Amazon Redshift のデータ共有ユースケース Amazon Redshift のデータ共有は、次のユースケースで特に便利です。 さまざまな種類のビジネスクリティカルなワークロードのサポート – 複数のビジネスインテリジェンス (BI) クラスターまたは分析クラスターとデータを共有する一元的な抽出、変換、およびロード (ETL) クラスターを使用します。このアプローチは、個々のワークロードに対して読み込みワークロードの分離とチャージバックを提供します。料金とパフォーマンスのワークロード固有の
Amazon Redshift のデータ共有により、データを手動で移動またはコピーすることなく、Amazon Redshift クラスター、ワークグループ、AWS アカウント、および AWS リージョン 間で、ライブデータへのアクセスを安全に共有できます。データはライブであるため、すべてのユーザーは更新後すぐに、一貫性のある最新情報をAmazon Redshift で確認できます。 プロビジョニングされたクラスター、サーバーレスワークグループ、アベイラビリティーゾーン、AWS アカウント および AWS リージョン の間でデータを共有できます。クラスタータイプ間およびプロビジョニングされたクラスターとサーバーレス間で共有できます。 Amazon Redshift でのマルチウェアハウス書き込み (プレビュー) 読み取りと書き込みの両方のデータベースオブジェクトは、同一の AWS アカウント
以下の日時形式の文字列のリファレンスを参照してください。 以下の形式の文字列は、TO_CHAR などの関数に適用されます。これらの文字列には、日時区切り記号 ('-'、'/'、':' など)、および次の「日付部分」と「時間部分」を含めることができます。
AWS では、異種データベースの移行を予測可能、高速、安全、かつシンプルにするために、2 つのスキーマ変換ソリューションを提供しています。お客様は、次のいずれかを選択することができます。1) AWS Database Migration Service (AWS DMS) コンソールにログインして、AWS DMS Schema Conversion (DMS SC) ワークフローを開始し、フルマネージドな体験をするか、2) AWS Schema Conversion Tool (AWS SCT) ソフトウェアをローカルドライブにダウンロードするか、を選択することが可能です。 どちらのオプションも、ソースデータベースのスキーマと、ビュー、ストアドプロシージャ、関数などのデータベースコードオブジェクトの大部分を自動的に評価し、ターゲットデータベースと互換性のある形式に変換します。自動的に変換で
Amazon Redshift Serverless は、データウェアハウスをプロビジョニングして管理することなく、分析を実行してスケーリングしやすくします。Amazon Redshift Serverless によって、データアナリスト、デベロッパー、およびデータサイエンティストは、Amazon Redshift を使用して、データウェアハウスにデータをロードしてレコードをクエリすることで、データからのインサイトを数秒で取得できるようになります。Amazon Redshift は、データウェアハウス容量のプロビジョニングとスケーリングを自動的に実行して、要求が厳しく、予測不可能なワークロードのための高速なパフォーマンスを実現します。料金については、使用した容量のみのお支払いです。既存の分析アプリケーションやビジネスインテリジェンスアプリケーションに変更を加えることなく、この単純化によるメ
Amazon Redshiftがマテリアライズドビューの正式サポート開始。頻繁に実行されるクエリなどがより高速に Amazon Web Services(AWS)が提供しているデータウェアハウス向けデータベースのAmazon Redshiftで、新機能としてマテリアライズドビューの正式サポートが発表されました。 New #AWSLaunches! AWS Resource Access Manager is Now Available in the Middle East (Bahrain) Region Amazon Redshift introduces support for materialized views (Generally Available)https://t.co/lB0bBYdvnl pic.twitter.com/JRVhK3ekRc — Amazon Web S
Use the STV_SESSIONS table to view information about the active user sessions for Amazon Redshift. To view the session history, use the STL_SESSIONS table, rather than STV_SESSIONS. STV_SESSIONS is visible to all users. Superusers can see all rows; regular users can see only their own data. For more information, see Visibility of data in system tables and views. Some or all of the data in this tab
はじめに こんにちは、yokatsukiです。 先日6月18日、第五回ゲームサーバ勉強会に参加してきました。 そこで、トレジャーデータのサポートエンジニアマネージャー高橋様から、直前の6月15日にオープンソース化されたばかりのDigdagの説明がありました。その時の発表スライドは下記です。 Digdagは弊社でも何名かが既に触ってブログで公開(下記)しているので、名前と目的は知ってましたが、説明とデモを見るうちに自分でも試してみたくなりました。 Embulk界隈で話題になっている分散ワークフローエンジン「DigDag」について調べてみた #digdag Treasure Data社のOSSワークフローエンジン『Digdag』を試してみた #digdag|Developers.IO という訳で、簡単ではありますが共有します。 テーブル定義の無いTSVファイルをRedshiftへロードする 通
手順で説明しているマージオペレーションを実行するときは、一時的なステージングテーブルの作成と削除のステップを除き、すべてのステップを 1 つのトランザクションにまとめます。いずれかのステップが失敗した場合でも、トランザクションはロールバックされます。トランザクションを 1 つにすると、ほかにもコミットの回数が減るため、時間とリソースの節約になります。 既存の行を置き換えてマージ操作を実現するには、以下の手順を実行します。 次の疑似コードに示すように、ステージングテーブルを作成し、マージの対象となるデータを移します。 create temp table stage (like target); insert into stage select * from source where source.filter = 'filter_expression'; MERGE を使用してステージングテ
問題の例 COPY コマンドなどの長いクエリを実行すると、データベースへのクライアント接続がハングまたはタイムアウトしているように見えます。この場合、Amazon Redshift コンソールにはクエリが完了したと表示されますが、クライアントツール自体はまだクエリを実行しているように見えることがあります。接続がいつ停止したかに応じて、クエリの結果がないか、不完全になる可能性があります。 考えられる解決策 この問題は、Amazon EC2 インスタンス以外のマシンから Amazon Redshift に接続するときに発生します。この場合、アイドル状態の接続は、一定期間非アクティブになった後、ファイアウォールなどの中間ネットワークコンポーネントによって終了します。このような動作は、Virtual Private Network (VPN) やローカルネットワークからログインした場合によく発生し
はじめに Redshift における Sort Key の1つである Interleaved Srot Key について解説をします。公式ドキュメントにはさらっとしか記述がないのですが、私が確認した公開された情報のなかでは AWS Blog が一番詳しく解説されていました。本稿はこちらの Blog を理解することを目的とします。 Sort Style 大きく分けて 3 つあります。 Single-column Sort Key column 単位で設定された Key。 Compound Sort Key table 単位で設定されたもので、2つ以上の column に対してセットされた Key。いわゆる複合 Key で Primary, Secondary と Key 間に優先順位があります。 Interleaved Sort Key table 単位で設定されたもので、1つ以上の col
データウェアハウスの容量とパフォーマンスのニーズが変わるため、クラスターサイズを変更して、Amazon Redshift のコンピューティングとストレージオプションを最大限に活用することができます。 サイズ変更操作には次の 2 つのタイプがあります。 伸縮自在なサイズ変更 - クラスターにノードを追加または削除できます。DS2 ノードから RA3 ノードへの変更など、ノードタイプを変更することもできます。伸縮自在なサイズ変更は、通常は短時間で完了し、平均で 10 分かかります。このため、最初のオプションとしてお勧めします。伸縮自在なサイズ変更を実行すると、データスライスを再分配します。データスライスは、各ノードにメモリとディスク領域に割り当てられるパーティションです。伸縮自在なサイズ変更は、次のような場合に適しています。 既存のクラスターにノードを追加または削減するが、ノードタイプは変更し
Redshiftのパフォーマンスで重要になる分散キーとソートキーについてまとめました。 分散キー(DISTKEY) テーブルにデータをロードすると、そのテーブルの分散スタイルに従って、テーブルの行が各ノードスライスに分散されます。Redshift では1ノードの中で実際に処理を行うプロセスが複数動いており、このプロセスをノードスライスといいます。並列処理の単位はノードではなくノードスライス単位です。スライスの数は、次のようにノード上のプロセッサコアの数と同じになります。 均等分散 均等分散はデフォルトの分散スタイルです。リーダーノードは、特定の列の値に含まれている値にかかわらず、ラウンドロビン方式によって複数のスライス間で行を分散させます。例えば 8スライスのテーブルに 8行 insert した場合、各ノードスライスへ順番に 1行ずつ配布されます。均等分散は、テーブルが結合に関与していない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く