mysqlが分散に弱い。そして殆どの場合で分散なんていらない

「JOIN を使わない」というのは分散を前提とすると是なのですが
http://d.hatena.ne.jp/naoya/20081119/1227089814

はてなとかの、最先端をつっぱしるWEB屋さんの場合って
一寸特殊で大量データをやたらと扱うから仕方が無いんだけれども

mysqlって分散に弱い。
アプリケーション側で結合を行なってあげないダメって
それってRDBとして役目が皆無

リレーショナルを何とかしてあげる部分って
RDBがやってあげる領域なんじゃ無いかと

分散RDBには詳しく無いけれども
テーブルパーテショニングと、テーブルの連結を上手くやってあげるDB
でもそれって案外高速に動作するリンクテーブルだけで何とかなったりしないのかな？

H2DBをフロントエンドDBにしてバックエンドDBをポストグレスとかにして
リンクテーブルしまくって、テーブルパーテショニングする形の運用とかでも
ある程度は何とかなるよーな気がしてきた。

そこが何処まで上手くいくかは実験してみないと微妙だけれども
はてな、みたいな大きなシステムじゃなければ結構上手くいったり
しないかなぁ？

まぁ、それ以前に普通のサービスやってる範囲だと
そこまでRDBの負荷でなやむケースってあまり無い気もする
(参照系で悩む場合は大体の場合データ構造かアルゴリズムかSQLが失敗している場合だし

更新系でパフォーマンスが足り無いケースって、ユーザー数が
相当多いか、若しくはSNSの足跡みたいに、アクセス数に対して
更新処理が大量に行なう様なケースか、更新対象のデータサイズが大きいか
cpuパワー必要な更新処理だろうし

それならファイルとかに出力しておいて、バッチ処理とかで後から処理を行なう
非同期処理にしてしまえばパフォーマンスの問題は大体クリアされないかなぁ？

ただし、サービスとして何処まで遅らせて問題無いかって事が有るだろうけれど
リアルタイムを10秒間隔程度に遅らせてあげるだけでも、相当パフォーマンスは
改善させたりするんじゃぁないかな？

なんて、一寸考えただけでもイッパイ出てくるから
パフォーマンスのプロはもっと、色々な事を考えて実践しているのだろうけれどもネ