「熱脳しゃちょさん、データベースの正規化も知らないんですか？」
って、DBの本読んで覚えたての若造に面と向かって言われたことがある。
データベースの正規化は
はじめの一歩
に過ぎない。
そこから、どのようにデータ登録、利用されるかで、カラム追加したり、中間テーブル作ったり、分散DBならJOINして1テーブルにしたりまでする。
んだよ。
DBがどのように設計されて、どのように処理されているかまで考えるエンジニアに、ほとんど会ったことがない。
オンプレミスRDBであろうが、RDB風分散DBであろうが、正規化＋インデックス張りでJoinJoin程度の設計で、日々、データが増えていって、ある量を超えた途端、極端に性能が落ちて、インスタンスサイズを上げ、インスタンス数を増やして課金額倍増させた挙句、「うちはデータが多いので、〇〇個インスタンスを立ち上げてます」とか、自分の技術力設計力のなさに無自覚なまま自慢げに「僕、空前絶後の無能なんですよ！」語ってくるという、「こういう時、どんな顔をすればいいかわからないの」時空に引き摺り込まれること、結構多いというか、ほとんどの現場でそう。
「分散DBではPKはUUID使わなきゃいけないんですよ。Webサイトのここに書いてあります。知らないんですか？」
と、何回言われたことか。
せっかくクライアントが設定してくれたSKUをデータ空間にぶちまけ、マルチテナントのイベントデータ(場所日時に関わるWriteOnceReadManyデータ)をデータ空間にぶちまけ、お前ら何考えてんの？ 状態なのに、人のことを小馬鹿にしてきやがる。
RDBが専門の、東大の情報系卒業しましたとかいう教科書ガイド的無能とかな。
でかいデータで全てのデータが同等である場合、通常のRDBでは処理が難しいところを分散DBならやれる、って特殊事例について話ししているだけで、この手の分類整列されているデータや、空間時系列データは、パーティションに区切るのが基本中の基本だ。
例えばクライアントAのB支店の2025年3月の売り上げと、クライアントXのY支店の2025年7月の売上を関連づけて処理することなんてないだろ？
これをデータ空間にばら撒いて、効率がいいわけがない。
「いや、でも、それだと処理が特定ノードに偏って……」
1度に1クエリしか処理しないなら、ノードの偏りは避けるのもありだが、Webサービスだろ。95％の効率とはならんが、有効データ濃度激薄で、データの出し入れに時間がかかる非効率な設計よりは、よほど効率的だよ。
クラウドや分散コンピューティングでは、データの移動が一番のコストになるから、処理データブロック内の有効データ濃度をどれだけあげられるかが大事になってくる。
ってことくらい、考えつかないものなのかねぇ……？