列ストア形式のDBはなぜ分析ワークロードに適しているのか
行ストアの場合 テーブルが行ストア形式で書かれている場合、各行のデータは一緒に保存されます。この図では、2019年シーズンの0~17歳のグループのデータをブロック1に配置しています。この形式は、コンピュータ・システムが新しいデータを新しいブロックに書き込むことでテーブルに追加できるため、トランザクション作業には最適です。しかし、「2019年シーズン、全年齢層の平均入院率はどのくらいか」という質問に関心がある場合、システムは2019年のデータを含む各ブロックを読み込む必要があります。この単純化した例では、3ブロックのデータを読み込む必要があります。この保存方法は、多くのデータ行の要約を必要とすることが多い分析ワークロードでは、比較的時間がかかる可能性があります。 列ストアの場合 カラム・ストア形式では、カラムのデータをまとめて保存します。例えば、年の列のデータは図のブロック1に示されています
AWS S3へのログの蓄積はとりあえずJSONにしましょう - Librabuch
アプリケーションのログファイルをfluentdでS3に転送、S3からRedshiftに読み込んで集計、という流れはもはや鉄板パターンです。 これまではTSV形式で蓄積されているケースが多かったと思うのですが、2014年03月25のリリースでCOPY文がJSONフォーマットに（一応）対応したこともあり、とりあえずJSONで が最新のベストプラクティスになります。 おさらい 〜 fluentdを使ってJSON形式でS3にログを蓄積する 必要なもの fluentd本体 fluent-plugin-tail-ex fluent-plugin-s3 fluent-plugin-s3-alternative s3-alternativeを使うのは、 output_include_time false output_include_tag false 上記の設定を有効にして、純粋なJSON形式のフォーマ
「RedshiftはHadoopキラーになる」、FlyDataの藤川氏に聞く
藤川幸一氏がシリコンバレーで起業した米フライデータ（FlyData）は、様々なデータソースから米アマゾン・ウェブ・サービス（AWS）のデータウエアハウス（DWH）サービス「Amazon Redshift」にデータを転送するというサービス「FlyData」を提供する。藤川氏はAWSのRedshiftが「Hadoopキラーになりつつある」との見方を示す。 フライデータのビジネスの現状はどうか？ 当社はもともとハピルス（Hapyrus）という社名で、「Hadoop」のPaaS（プラットフォーム・アズ・ア・サービス）を提供することを目指して起業した。しかしHadoopのPaaSが増えてきたことを考え、現在の「FlyData」の事業にピボット（事業転換）し、社名もFlyDataへと変更した。 事業を転換したもう一つの理由が、AWSが2013年初めにRedshiftを開始したことだ。Redshiftを
ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift
最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 この本は、データベースのための本ということで、データベース設計、SQL、MySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に本格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、本ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Using Redshift’s late binding views with dbt
