Other articles


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

    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 …
    read more
  2. RedShift におけるユニバーサルタイム対応の定石

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

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

    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 …
    read more

links

social