つらい点はいくつもありましたが、大半はRedshiftの機能強化によってすでに解決されてしまいました。

- 細かい更新を高頻度で行うと書き込みが詰まる → Spectrumで解決
- ログを毎日vacuum sort onlyするのが面倒すぎる → Spectrumで解決（パーティションがあるため）
- varcharの文字列長をしくじって伸ばしたいときテーブルの書き直しが必要 → Spectrum（Parquet）とalter table alter columnで解決
- ログに配列を含めたい、配列を行に展開したい → super型とPartiQLで解決しそう
- MySQLからのテーブル取り込みのセットアップが煩雑でセルフサービス化しにくい → FederatedQueryで解決
- MySQLからのインポート遅延を短縮したい → FederatedQueryで解決
- BIからの重いクエリーがすべてのリソースを食ってしまう → Concurrency Scalingで軽減
- クエリーの優先度がないために重要バッチが個人のクエリーに潰される → AutoWLMで軽減

現在残っている最も大きい不満はワークロード管理です。AutoWLMで多少よくなりましたが、もっと細かく「この処理にはリソース何%まで使ってよい」みたいな制限ができたら最高ですね。

チューニングというのはsortkeyとdistkeyの話かと思いますが、クックパッドで最も重くて苦しんでいる処理はログに対するアドホッククエリーで、その手のクエリーにはdistkeyがほとんど効果がないので、蓄積バッチに変えるなどの別の方法で解決しています。

たべみるのようなフロントDBとして使う部分については多少チューニングはしましたが、大量にあるわけではないですし、やることはだいたい決まっているのでさほど悩みませんでした。

分散並列DBのパフォーマンスチューニングは分散キーに始まって分散キーに終わると言っても過言ではなく、そこのチューニングができるなら十分ではないかと個人的には思います。マテリアライズドビューはもう1つの有力な選択肢ではありますが、あれは副作用も強いので、使いどころは限られますね。