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

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

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

レコード挿入の模式図

レコード挿入の模式図

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

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

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

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

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

links

social