Mitani

生成AIでなぜ格差が拡大するかというと、「学ぶ理由としての活用」と「学ばない言い訳としての怠惰」で二極化するからです。 AIがあるから英語やプログラミングはもう勉強する必要がない。と、自分が楽なほうの世界を夢想して何もしない。これこそが格差を固定化させる罠。 AIがあるから英語やプログラミングの勉強が簡単になった。これまでなら60点止まりだった人たちが、AI家庭教師のおかげで80点90点取れるようになった。というのが本当の価値。 どちらを選ぶかはあなた次第ですが、人類の歴史において真剣勝負から逃げて熱量の低い人生を選択した人が勝ったことは一度もありません。

その昔、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) で現代のハードウェアならどこまでも行けます（必要になれば最アーキテクトの時間が十分とれる）から安心してください