Redshiftのテーブル定義がアレだったときの、最後に残った道しるべ - Librabuch
Redshift使い始めたは良いけど、運用後に以下の点に気付いてしまうことがあるかも知れません。 SORTKEYやDISTKEYの設計を間違えた。寧ろそんなものがあったことを知らなかった。 INSERTでレコードを挿入していたのでデータが圧縮されていなかった。 人生をもう一度やりなおしたい。 MySQLやPostgreSQLだと数千万～億のレコードが入った状態でテーブルの設計ミスをなかったことにするのは骨が折れます。Indexの張り直しだけでも、億レコードのオーダーではソウルジェムが黒化すること間違いないです。 Redshiftなら、ほむらちゃんに時間遡行をお願いするまでもなくリカバリーできます。 そう、Redshiftならね。 手順 テーブルのデータをS3に逃がしてあげます。 UNLOAD ('SELECT * FROM table_name') TO 's3://tmp-hoge/'
Amazon Redshift DB開発者ガイド – データのロード処理(1).データロードのベストプラクティス ｜ Developers.IO
Amazon Redshift DB開発者ガイド – データのロード処理(1).データロードのベストプラクティス 先週末『パシフィック・リム』を3D字幕版で観て、これは吹替版でも新たに観るべきか…と若干迷っている今日この頃、皆様いかがお過ごしでしょうか？しんやです。 先週、RedshiftではAmazon Redshift DB開発者ガイド – テーブル設計のベストプラクティスをエントリとしてアップしましたが、もう1つ『ベストプラクティス』がありましたので同じように切り出してご紹介したいと思います。それがこちらの『データロードのベストプラクティス』です。このエントリ情報を含む『Loading Data』に関しては、その他にも有用な情報が散りばめられていますので、何回かに分けてこちらに展開して行ければと思っております。 はじめに 非常に大規模なデータセットをロードするには、とても長い時間が掛
Amazon Redshift DB開発者ガイド – テーブル設計のベストプラクティス | DevelopersIO
データベース設計を考える上で、あなたが下さなければならない重要な決定があります。その決定はクエリパフォーマンス全体に影響を与える可能性があります。これら設計に関する決定はまた、I/Oオペレーションの数を削減したりクエリを処理するのに必要なメモリを最小化する事でクエリのパフォーマンスに影響を与えるストレージ要件に大きな影響を及ぼします。 テーブル作成の際にクエリのパフォーマンスに最も大きな影響を与えるであろう決定次項は以下のとおりです。 最善のソートキー(sort key)を選択する 最善の分散キー(distribution key)を選択する 最善の圧縮戦略(compression strategy)を選択する 制約を定義する あなたが下す決定は、データベースが行なっている作業の種類に依存して来ます。全ての状況に効果的な『最高のソートキー』は無いのです。 このセクションでは最も重要な設計上
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
