RedShift で、なるべく書き込み性能を落とさない設計

土 30 6月 2018

分析用データベースでは、一度に大量のデータを投入して (例えば一日ごと)、データ解析に利用するのが一般的な使い方だと思いますので、書き込み性能が問題になるようなケースはあまりないと思います。

ただ、私が開発したセミリアルタイム KPI システム(delay, cycle 共に五分)では、5分毎にある程度のデータを取り込む仕組みのため、書き込み性能がボトルネックになっていました。これは、カラムナーデータベース (列指向 DB) では、カラム単位で I/O が発生するためで、 保存しているデータ量に応じて レコード挿入時のパフォーマンスが劣化してゆくからです。

レコード挿入の模式図

レコード挿入の模式図

書き込み性能劣化の解決策として、頻繁に書き込みするテーブル (追加データ用) と、あまり更新しないテーブル (古いデータ用) に分離する方式を採用しました。テーブル構造は同じです。これを hot & cold 方式と呼んでます。

hot & cold 方式のデータフロー

hot & cold 方式のデータフロー

新しいデータの追加は hot テーブルに対して行い、過去のデータ (例えば一週間を過ぎたもの) は、一日に一度ぐらいの頻度で cold テーブルに移します。このような設計にしておけば、 hot テーブルに入るデータは最大で一週間分となり、書き込み性能の一定以上の劣化を防ぐことができます。

select 時に二つのテーブルを参照しなければならないため、クエリーが複雑になるデメリットがあり、万能ではありませんが、どうしても書き込み性能の劣化を抑えたい時には有効です。

By Degino Inc., Category: TechBlog

Tags: aws / aws redshift /

Other articles

RedShift で重複レコードのうち新しい方を採用する定石

金 15 6月 2018

RedShift では、プライマリーキーやユニーク制約を無視してデータを投入することができます。 select 時は制約を加味した最適化が行われるようですが、書き込みにおいては制約は無視されます。また、解析用のデータベースでは、データの正規化はあまり重要ではありません。

最近まで関わっていたセミリアルタイム KPI システム(delay, cycle 共に五分)では、高速化のためにプライマリキーが重複してしまうことを許容し、後から入って来たレコード (batched_at が新しい方) を有効レコードとする設計を採用しました。

create table sometable (
    id bigint,
    created_at timestamp with time zone,
    sales bigint,
    batched_at timestamp with time zone
);

RedShift は Window関数が使えます。そこで、同じ ID のレコードに batched_at の降順に番号を振り、最初のレコードだけを抜き出します。

select id …

By Degino Inc., Category: TechBlog

Continue reading …

RedShift におけるユニバーサルタイム対応の定石

日 10 6月 2018

世間ではサマータイム導入の話題が上がってますが、それはともかく…。

いつでも国際化できるように、データベースに保存するデータは、常にユニバーサルタイムに対応するようにしています。

RedShift には timestamp with time zone 型がありますので、これを使います。タイムゾーン付きですが、 UTC しか格納できません。

create table sometable (
    created_at timestamp with time zone,
    sales bigint
);

select する時には注意が必要で、フィルターは JST -> UTC への変換を行い、表示データは逆に UTC -> JST への変換を行います。そして convert_timezone は timestamp with time zone に対応してないため timestamp にキャストする必要もあります。

select convert_timezone('UTC', 'Asia …

By Degino Inc., Category: TechBlog

Continue reading …