「Amazon Redshift」を使ってみた ～使いどころと、つまずきがちなポイント
はじめに Amazon Redshiftは、Amazon Web Services（AWS）が提供するデータウェアハウス（DWH）サービスで、2013年2月に正式リリースされ、同6月4日には東京リージョンでも利用可能になりました。既存のDWHと比較しても安価で、PostgreSQLベースで容易に高速なデータ分析が可能であることなどが知られており、注目も高まっています。 ところが、日本国内では「使ってみた」という情報は非常に少ないです。幸運にも筆者は、限定プレビューの段階からRedshiftに触れる機会に恵まれました。そこで、今回は「こんな使い方をしてみました」「こんなところでつまずいた」といったことを中心に紹介したいと思います。 なお、本記事は限定プレビュー～サービス開始当初の米国東部リージョンでの使用結果を元に執筆しており、当時のAPIバージョンは2012-12-01です。東京リージョン
fluent-plugin-redshiftとその他pluginを組み合わせてredshiftへデータ保存
http://aws.amazon.com/jp/redshift/ AWSから安価で使用可能なDWH製品Redshiftが公開されてしばらく立ちます。 非常に興味深いサービスなのですが、Redshiftへのデータの登録が独特(S3に置いたCSV/TSVをcopyコマンドを用いて登録）という事もあり、ちょっと面倒くさく感じていました。 最近、掲題のようにredshiftへのデータ保存が行えるFluentdプラグインがあるのを発見したので、こちらと他プラグインを組み合わせて、Fluentdを用いたRedshiftへのデータ保存を試してみました。 ◯fluent-plugin-redshift https://github.com/hapyrus/fluent-plugin-redshift BufferedOutputプラグインの一つで、仕組みとしてはchunk単位でS3にデータを書き込んだ
Amazon Redshift DB開発者ガイド – テーブル設計のベストプラクティス | DevelopersIO
データベース設計を考える上で、あなたが下さなければならない重要な決定があります。その決定はクエリパフォーマンス全体に影響を与える可能性があります。これら設計に関する決定はまた、I/Oオペレーションの数を削減したりクエリを処理するのに必要なメモリを最小化する事でクエリのパフォーマンスに影響を与えるストレージ要件に大きな影響を及ぼします。 テーブル作成の際にクエリのパフォーマンスに最も大きな影響を与えるであろう決定次項は以下のとおりです。 最善のソートキー(sort key)を選択する 最善の分散キー(distribution key)を選択する 最善の圧縮戦略(compression strategy)を選択する 制約を定義する あなたが下す決定は、データベースが行なっている作業の種類に依存して来ます。全ての状況に効果的な『最高のソートキー』は無いのです。 このセクションでは最も重要な設計上
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSSSLIDE
SSSSLIDE
