最新のログもすぐクエリできる速くて容量無限の最強ログ基盤をRedshift Spectrumで作る - クックパッド開発者ブログ
こんにちは。去年の今頃は Rust を書いていました。 インフラストラクチャー部データ基盤グループの id:koba789 です。 背景 クックパッドではデータ基盤の DBMS として Amazon Redshift を利用しています。 既存のデータ基盤について詳しいことは クックパッドのデータ活用基盤 - クックパッド開発者ブログ を参照してください。 今まで、ログは数時間に1度、定期実行ジョブで Redshift 内のテーブルにロードしていました。 ロードジョブの実行間隔が "数時間" と長めなのは、Redshift のトランザクションのコミットが遅いためです。 クックパッドでは数百ものログテーブルがあるため、仮に1分おきにすべてを取り込もうとすると秒間数回以上のコミットを行わなければなりません。 このような頻繁なコミットは Redshift 全体のパフォーマンスを悪化させてしまいます
Amazon RedshiftとEC2のインスタンスタイプに於ける”MTU”の関係について | DevelopersIO
RedshiftとEC2に関するちょっとした小ネタです。 Redshiftに対してEC2サーバからのアクセス確認を行っていた所、『インスタンスタイプによってRedshiftにアクセス出来るものと出来ないものがある』という事象に直面しました。分かってみると『なるほど〜』という内容でしたのでここにその経緯と対応をまとめてみたいと思います。 当エントリについて結論から先に申しますと『EC2にはMTU(Maximum Transmission Unit: 最大トランスミッション単位)というものがあり、インスタンスタイプ毎にその値は異なる』『EC2からAmazon Redshiftにアクセスする際、そのMTUの値が影響する(インスタンスタイプによってアクセス出来るものと出来ないものがある)』のです。 当該問題の言及箇所 インスタンスタイプ毎のMTU値に関する言及はこちら。 インスタンスタイプ - A
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon Redshiftによるリアルタイム分析サービスの構築
