放置しても壊れない！運用負荷を激減させるDBパーティショニング設計術

データベースのパーティショニング設定に追われて疲弊していませんか？本記事では、後から手動でメンテしなくても運用が回り続ける、真に効率的なDBパーティショニングの設計思想について解説します。運用自動化のヒントがここにあります。

それかkdb+を使えば、1日10億行なんて当たり前だよ。

このトピックに興味があるなら、Snowflake ID [https://en.wikipedia.org/wiki/Snowflake_ID] かuuid7について調べてみることをおすすめする。記事にあるパターンもそのまま応用できるよ。bigintは64ビットだけど、uuidは128ビットだしね。他にも注意点は色々あるけど、結局はトレードオフの問題だよ。

あるいは、日次のデータをClickHouseみたいなものに保存して、毎日リセットしちゃうのも手だね。こういうワークロード向けに作られてるし、大規模環境で驚くような分析パフォーマンスを発揮するよ。うちは月額170ドルのVPSで運用してるけど、1日5000億行以上のクエリを問題なく処理できてる。そうなると、肥大化し続けるOLTPテーブルをパーティショニングするほうが面倒に思えてくるよ。

すごく興味があるテーマなんだけど、Postgresを使うアプリを触り始めてから意外に思うことが多くてさ。例えば、なぜIDが優れたプライマリキーになるのか？JOINはよくあるけど、自分のアプリではIDで検索する人なんていないし、そもそもユーザーに見せる必要すらない。作成日時でやるほうがいい気がするし、IDでやるとユーザーの検索がすべてパーティションインデックスを参照することにならないのかな。