Taketoshi Aono

・似た名前のIT企業でも全然違う話 SHIFT（シフト）：上場企業・ソフト開発のテスト業務で急成長・2005年設立 AI Shift（エーアイシフト）：サイバーエージェントのグループ会社・2019年設立 Shif AI（シフトエーアイ）：生成AIのコミュニティを運営・2022年設立 3社とも関係の無い別会社ですよ！

最近FDEという名のただの受託の客先常駐が増えているらしい。自社にプラットフォームがあってこそのFDEだと思うのだけど、採用マーケティング用語として完全に広まっていてしまっている😅

その昔、3000万ユーザー・10億APIヒット/日・米国App StoreでYouTubeやFacebookより上位のトップランカーアプリの裏で動くBaaSを作ってましたがpkeyは意図的に連番でした UUIDによるキャッシュヒット率の低下は大規模システムでは恐怖です 「ただ遅い」ならまだいいのですが、ハードウェアのリソース利用効率が悪くなるのだから、シングルでスケールアップするしかないマスターDBにとっては最悪のトレードオフです readをレプリカに逃がしても4-5万QPS残るような状況で、もしUUIDにしていたら、当時のハードウェア環境ではかなり早い段階でシャーディングせざるをえない状況を自ら招いていたと思います ほぼ自分一人でインフラからバックエンドまで全体を見ていたのでシャーディングしてしまったらもう地獄の始まりでほとんどの時間をDBのお世話に費やすことになったでしょう たかが O(n) でしか性能もスケールしない、稼働率は A^n で指数的に低下していく、必要悪としても最悪の部類のアーキテクチャであるシャーディングのために自分の時間を捧げるのは避けたかった pkeyの空間効率の悪さは増幅します、tuple本体だけでなくインデックス、外部キー、そしてジョインするときの比較演算にCPUのレジスタやL1に乗る乗らないレベルまで、128bit vs 32bitで4倍違うと最終的に8倍16倍の違いへと増幅されます UUIDv7とかで局所性の破壊がふさがれても、DBシステム性能設計の最大の要衝が「空間効率」であることには変わりません というわけで シャーディングが必要な状況を自らまねきデバッグなどの開発体験も下げる自殺行為のUUIDは避けて、最密充填の「普通の連番」をpkeyにすることを、多数のDBの内部アーキテクチャを見てきたDBオタクとして推奨します それでもUUIDっていう人のほとんどが「ユーザーに見える・予想できるIDを使いたくない」という話をしてきます それってURLなどで公開されるIDとして使うイメージだと思うのですが、ユーザーに公開されるテーブルの場合、pkeyとは別にpublic_idをテーブルに追加してrandom_hex(16)とかをセットする（＆ユニーク制約でインデックスを貼る）のがおすすめです なぜcuidやbase62やbase36でなくhexなのか、なぜ16文字なのか、などは聞かれれば答えます、（ヒント：誕生日問題で50%衝突確率ベースでちょうどよい） だいたいYouTubeの動画でさえいまだにpublic_id = base62(11)なんですよ、uuidの32文字なんて愚の骨頂です pkey: integer(32bit or 64bit) public_id: random_hex(16-32 chars, 段階的に増やしてok) で現代のハードウェアならどこまでも行けます（必要になれば最アーキテクトの時間が十分とれる）から安心してください

このあたり不思議で、自分なんかは状態を扱わなくて済む場合の方が例外的だと感じるんだけどなぁ。関数型のアプローチが有効な場面があるのは認めるものの、あくまでサブシステム（や関数型を支えるランタイムの上）でしか使えない印象。