騙すのが旨い悪徳業者も多いので、私の様なフリーのシステム構築屋に鑑定を依頼するのがベストだと思います。
この妥当性は絵画を買う時をイメージしてもらえれば分かると思います。
鑑定もしなければ幾らでも盗られます。
相手は品質は何も考えておらず、「幾ら取れるか」だけを考えています。
現在はそんな無防備な状態なので、この記事に書かれているような会社が蔓延するのです。
エンドユーザは、兎に角騙されないように気をつけて欲しいです。
システム偽装を甘く見ているエンドユーザは多いですが、「顧客情報流失事件」からも分かるように、システムは企業の生命を左右するので、是非騙されないように気をつけて欲しいです。
これからの時代は文字通りシステムが生命を左右する状況が増えてきますので、エンドユーザーはもっと危機意識を持ってください！

インドリさん、ども。

IT業界のセカンドオピニオン制度はいいです。
それを進めるにはどうしたらいいか考えましょう！っても、ユーザが変わってくれなきゃどうしようもないですね。

それはともかく、皆さんにお相手していただいてるうちに、すごいことが分かったんです！！
次の記事で書きましたけれど、みんな当然、悪意はなく、騙すつもりもなく、「本当に分かってない」のだと思います。

なぜ、みんながSQLを苦手とするのかは、「SQLは魔法と思っている」ということに尽きるようです。

生島さん、ども。
やっぱり、セカンドオピニオンいいですね。
これが実施されれば、エンドユーザーが企業の大きさだけでをみるのではなくて、生島さんの会社の様な、大手でなくとも技術力がある会社が正当に評価されるようになると思います。
エンドユーザーはブランドではなくて、自分の会社に役に立つ本当のシステムを買って欲しいです。
システムは飾りじゃないのです。

>なぜ、みんながSQLを苦手とするのかは、「SQLは魔法と思っている」ということに尽きるようです。

良い意味で予想外です。
私にはその発想は無かったです！
次の記事が非常に楽しみです。

これに気づいたのは1年ほど前なのですけれど、私は「さぁ！アルゴリズムを考えるぞ！」って思ってないのです。
考えなくても勝手に出来てるものなのです。

で、プログラムを教えるのに、そこから教えないといけないということを知りませんでした。バカです（笑）

もしかして、同じようにSQLも、みんなアルゴリズムというか、「どうしたい（実行計画）」がないまま、「文法だけを見て書いてるんじゃないか？」と思い至ったわけです。

サブクエリーを使っている他人が書いたSQLって、

「どう考えたらこんなものが思いつくのか？」

ってナゾだったんですけど、「考えてない」が正解で、「文法に当てはめているだけ」というのが、どうやら正しいのではないかと……。

でないと説明が付かない。

ということは、「どうしたい」を勉強させればいい！と思い至ったわけです。

これはもしかしたら、私の中では大発見かもしれません（笑）

こんにちは、
実はず～っと最初から疑問に思っている事があります。どのように質問しようか迷っていたのですが。
今回は質問と反論しようと思います。

よく話題に出てくるスケーラビリティですが、いったい何のスケーラビリティを言っているのでしょう？
DBサーバ？APサーバ？それともシステムのスケーラビリティ？ハードウェア？
スケーラビリティのなかでも主に規模透過性のことでしょうか？
もっと単純に言うと、スケールアウトのしやすさの事？

スケールアウトという意味であれば、
ＤＢサーバに業務処理を大量に持ち込むとシステムのスケーラビリティは落ちます。
ＡＰサーバで処理をさせるのはシステムのスケーラビリティが上がります。
つまり、システムの規模透過性が上がります。要するにノードの追加だけです。
（DISKの追加などのスケールアップ的な話は省きます）
システムのノードを増やして高いパフォーマンスを得るほうが、チューニングでノードの処理能力を上げるよりも安くつくことが多いからです。つまり、安く、全体としてのスループットを確保するということです。
だからと言って、むやみにノードを追加できるわけではありません。ノードを追加すればするほど、１つのノードに対する利益性は落ちますから。

個々の処理パフォーマンスを最適化した方が、結果としてシステムのスケーラビリティを確保しやすいでしょう？ということであればそうです。ですが、これはAPサーバよりDBサーバの方が良いという説明にはなりません。
なぜなら、これは同時にAPサーバも含めてバランスよく最適化しましょうという事に等しいからです。
DBはパフォーマンス上げるけど、APはほっといてもいいよね？なんていうアプローチはありません。当然、バランス・全体最適が検討されます。

よって一般論としての【「スケーラビリティ」は、「SQL（DB）の技術がない」の逃げ口上でウソですから。】というのは嘘です。

観点を変えて、システム運用を考えると
ＤＢの処理が複雑になればなるほど、システムで問題があった場合の極小化が難しくなります。
（問題が発生しないシステムを想定するのはナンセンスです）
アプリケーション資産の運用（バージョンニングなど）も通常ＡＰサーバに対してのみで済むところが、ＡＰ／ＤＢ両サーバに対してとなります。これは、資産の運用上煩雑になります。
例えば、ＡＰがヘボで（ストプロがヘボで）メモリを異常に消費する場合、ＡＰサーバだけで済んだはずが、データストアとしてのＤＢにも影響がでるのでよろしくありません。

つめり、ＤＢに業務処理(の大部分)を持ち込み規模としてのスケーラビリティが上がるのは限定的なシナリオだけです。

前の記事にあった
>APサーバで処理してスケーラビリティが上がるとしたら、
>緑の部分 ＞ 赤の部分
といのは、結果として、APDB双方に得意な処理をバランスよく配置させるのが理想ですという意味と取れて（内容には共感できますが）
スケーラビリティが確保できるかどうかの説明になっていないと思います。
そもそも、なんでもかんでもDBに詰め込むなんでことはできないわけですから。
もちろんAPにすべてをというのも問題です。

oumi さん ども。

何度も釣ってしまってすみません。

大前提として、何度も書いていますけれど、シミュレーションなどUIの要件はAPサーバで処理すべきですよ。UIと内部を分けるべきと言ってるわけですから。

>緑の部分 ＞ 赤の部分

ごく小さな範囲で見て処理量がひっくり返らないなら、大きくしたらもっとひっくり返らなくなりますね。
複雑になればなるほど差は開きます。

スケーラビリティということを考えると、増強しにくいDBサーバがウィークポイントになるのは確かですから、できる限りDBサーバの処理量を減らさなければなりません。だから、「APサーバで処理させます」というのは一見正しい意見に見えます。

しかし、DBで処理しようと、APで処理しようと処理全体で必要なデータ量は同じです。

ですから、DBはどんな手順であっても、処理全体を見れば必要なデータすべてにアクセスします。だから、基本的な処理量は変わらないのです。

その上で、APで処理するなら、分割して依頼書（SQL）が来て分割して渡したり、不要な転送が発生します。

結果、減る処理量は「四則演算とソート」しかないのです。
で、四則演算は誤差とも言える処理量で、ソートはシビアな処理ですが、ORDER BYを禁止するプロジェクトは残念ながらほぼないです（見たことはありますけど）

結果的に

APサーバに処理をさせた場合
　　APサーバの処理量 増加、DBサーバの処理量 増加
DBサーバに処理させた場合
　　APサーバの処理量 減少、DBサーバの処理量 減少

となります。
どちらがスケーラビリティが高いでしょう？

更に、何度も何度も書いてますけれど、DBサーバで処理させようとすると、目を覆いたくなるような、とんでもないヘマをする人が確かに大勢出ます。

しかし、ヘマをする人のリスクは経営者が考えるべきで、技術者が（自分達がヘマをするから）という理由をいうのはおかしいでしょう？

と言ってるわけです。

現実問題、私も一応、経営者ですから、メンツを見て「とてもDBサーバでの処理は無理」と判断することはありますが、それは技術者なら否定して欲しいわけです。

私の中には2人の人格がいて、いつもケンカしてます（笑）

何度も言いますように、スケーラビリティの話になっていないのです。
生島さんの説明は、
ネットワークに負荷のかからないように(またはその範囲で)、DBでできることはDBでやるようにしたほうが良いということであって、スケーラビリティの話にはなっていないと思います。

「良い＝ハードを増設するまでも無い事」が多々あるでしょう？それを考えなさいよ！といっているようにしか取れないのです。だとすればスケーラビリティの話ではありませんね。

スケーラビリティを確保するということは、システムリソース（等）の増大や減少に応じて、リソースの増減を容易に行えるということです。
ですので、
>APサーバに処理をさせた場合
>　APサーバの処理量 増加、DBサーバの処理量 増加
>Bサーバに処理させた場合
>　APサーバの処理量 減少、DBサーバの処理量 減
ということにしても、スケーラビリティを確保できるか否かの話にはなりません。
単に増加するか減少するかという現象の話です。
何のスケーラビリティの話なのでしょう？APサーバ？DB？システム全体？
何か勘違いしておられるようですが、スケーラビリティは、現在、システムの負荷が何処にかかるから確保できる出来ないといった事ではありません。仕組みによる話題です。

例えば、３層モデル上でデータアクセス層が物理的に
APサーバ・DBサーバ両者に分散している。
　この場合、ネットワーク上は生データが大量に飛び交う可能性が高い。
DBサーバにある
　DBサーバ上のデータアクセス層から、業務に必要なデータのみが渡されるため、ネットワークに対する負荷は緩やかである。

ということであれば、これはアーキテクチャの話ですから、スケーラビリティを確保する話となり得ます。（基本的にSQL文ができるできないの話は関係ありません）

DBサーバ上に理想的なデータアクセス層を構築するために、高度なSQLの知識が必要か、当然必要です。
AP-DB間のネットワークトラフィックを軽減するために、高度なSQLの知識が必要か、当然必要です。

しかし、これはスケーラビリティを確保することを実現するための要素であって、スケーラビリティの話ではありませんね。
ですので
>「スケーラビリティ」は、「SQL（DB）の技術がない」の逃げ口上でウソですから。
は嘘だと申し上げているのです。

スケーラビリティの話と、
実際にヘボが多くてぐだぐだになり、結果としてスケーラビリティも考えられていない、実現できない、という話は別問題で同時に語るのはどうかと思います。
〇〇な作りの場合は、スケーラビリティ自体も考えられてないケースが多いといった話にすべきだと思います。

いや、逃げ口上を言う人は実際にいるでしょうけど・・・
スケーラビリティをいう奴は全部DBの技術がないやつだって・・・ないですよね

おっしゃってることが判らないわけではないというか、共感できる部分は多いですが、人に誤解を与えてしまいそうで心配です。

「APサーバで処理するのはスケーラビリティをあげるため」に対する反論です。
両方できる人にとってはDBサーバで処理した方が工数が下がります。
両方できる人にとってはDBサーバで処理した方がメンテナンス性も高いです。
両方できる人にとってはDBサーバで処理した方が拡張もできます。
両方できる人にとってはDBサーバで処理した方がマシンに対する負荷も下がります。

例えば、ストアドプロシージャにしておけば、社内ではC/Sでリッチアプリケーション。社外には同じものを一部分だけWeb公開ということも、最小限の工数できますね。

どういうときにDBサーバで処理したら、スケーラビリティが下がるのでしょう？

私は両方出来ますけれど、APサーバで処理した方がスケーラビリティが上がる具体的な例は、【技術者の確保】以外で思いつきませんけれど……。

スケーラビリティを言い訳や詐欺と言われると困ってしまいます。

生島さんの提示する例は「上手く作ったDB中心のシステム」と「下手に作ったAP-DBの分散システム」の比較になっていて、フェアな議論になっていません。
比較するなら上手く作ったもの同士で行うべきです。APに計算量を移転できていない例を挙げても説得力はありません。

前のエントリにコメントしましたが、私の言うスケーラビリティの確保というのは、1年後の秒間リクエスト数が1000倍になるようなケースにDB中心のアーキテクチャで対応できますか、という話です。
生島さんにとっては現実味のない言い訳のようなケースかも知れませんが、実際にあるからこそ計算量をどう移転するかに頭を悩ませるわけです。
私が携わっている比較的小規模なシステムでもこの位のことはあるわけで、GoogleやYahoo!、FacebookやMySpaceといった超大規模サイトかつトラフィックの伸びが膨大なサイトともなれば、拡張性の低いDBサーバに負荷を集中させるなんて怖くてできないでしょう。

ちなみに私の経験にある規模であれば、そこで必要とされる技術は特殊でも高コストでもありません。ごく当たり前の技術を組み合わせるだけです。
何を特殊とするかは、その人の経験や文化に依存します。限定的、高コストと決めつける前に、ご自分の経験が限られたものである可能性を考えてみては如何ですか。決めつけはお嫌いのようですから。

もう一点、論点がずれるので言及しませんでしたが、RDBMSを使わないというのも現実的な選択肢です。

「キー・バリュー型データストア」開発者が大集合した夜
http://itpro.nikkeibp.co.jp/article/OPINION/20090226/325527/

に、いい記事が出ていますね。

tripod さん

ほぼ、完璧に作ったもの同士を比べています。
前提条件として、UIはAPでするということも忘れないでください。

緑 ＞ 赤

とならないなら、1000倍にしようと、1億倍にしようと、APサーバの方がスケーラビリティが落ちるので、是非、

緑 ＞ 赤

になる具体例を示していただければと思います。

緑 ＜ 赤

だけれど、1000倍にしたらAPサーバで処理した方がよいという例でもよいですけれど、ミクロで見て処理量が増えるのに1000倍したら処理量が減るというのは、私の頭のでは理解不能です。

APサーバで処理したら、APサーバもDBサーバも処理が増えますから、

DBサーバで処理していたら
　　　AP20台 1000リクエストまで耐えれる。
APサーバで処理していたら
　　　AP10台 300リクエストまでしか耐えれない。

ってことになります。

マスタなどをキャッシュするってあったけれど、それは確かに減りますが、スケーラビリティを確保するなら、APサーバの同期は不可欠になりますしね。これをやってなくって言ったら……。

極めて単純な話をしているのですけれど、ある処理に必要なデータ量は変わらないのです。変わったらおかしいでしょう？

そのデータがDBに保存されているなら、APにデータをキャッシュしていない限り、
DBサーバは必要なすべてのデータにアクセスする必要があります。

APサーバで処理する以上、DBは加工しないデータを渡す必要があるので、データの転送量は増えます。
そして、DBは加工しない ＝ 単純なSQL をで実現となるので、SQLの実行回数も増えます。

DBサーバの処理を肩代わりできるとしたら「ソートと四則演算」のみです。

DBを使わない選択肢は、私も捨てていませんよ。

追加。

DBサーバで処理したら、DBサーバのピークは高くなりますが処理時間は短いです。
APサーバで処理したら、DBサーバのピークは低くなりますが処理時間は長いです。

しかし、アクセスの増加を考えると、掛け算で考える必要がありますね。

高いピーク × 短い時間 × リクエスト数
低いピーク × 長い時間 × リクエスト数

を比べるのですけれど、

高いピーク × 短い時間
低いピーク × 長い時間

と同じですね。
だから、処理をミクロに分解して、増えた処理と減った処理を比べればよいのです。

多くの技術者は高いピークにビビリます。
そして、まともなSQLを書けないから、APサーバを選ぶのです。

tripodさんの書き込みを見てもまだ気がつかないようですね。
あいかわらず、スケーラビリティを確保するとか、スケーラビリティそのものの話にはなっていませんね。

そもそも、スケーラビリティを確保するために物理3層モデルや3層モデルアプローチが登場したことすらわかってないのではないですか？（すこし疑いを持ち始めました）まさか、わかっているでしょうね。
とすれば、多くの処理をストプロへ移動するということ、それ自体が、データアクセス層の中の問題でしかないということも当然の事ですね。ビジネスロジック層にSQL文は存在しませんからね。
データアクセス層の効率を云々するのは、スケーラビリティ確保の話とは別問題で、効率的なデータアクセスをするか否かの話ですね。もしくは、スケーラビリティを阻害しない効率的なアクセスという事ですね。

あながが出会ったヘボ技術者に対する不満と、スケーラブルなシステムをいかにして作るかの話をごっちゃにしないでください。

私が最初に書いた、
>スケールアウトという意味であれば、
>ＤＢサーバに業務処理を大量に持ち込むとシステムのスケーラビリティは落ちます。
>ＡＰサーバで処理をさせるのはシステムのスケーラビリティが上がります。
>つまり、システムの規模透過性が上がります。要するにノードの追加だけです。
業務処理って言ってるでしょ？わかりますか？
ビジネスロジックはAPでやったほうがいいって言ってますね？

これを踏まえて、APサーバで処理、DBサーバで処理を云々してこられますから、当然データアクセス層の中で、部分的にAPサーバにデータアクセス層の一部（フロントエンド）があるというモデルを言っているんだなと想定しますね。
（まさか、ヘボなシステムでビジネスロジック層に生ＳＱＬがごろごろしてる事を話題にしてもしょうがないですね）
そして、終始ストプロへもってったほうが良い、スケーラビリティがあがる、と言っています。
スケーラビリティがあがる？スケーラビリティを確保するための３層モデルにおけるデータアクセス層の話で、スケーラビリティが上がる？
変だ・・・あなたも、その逃げ口上を言う人と同じ過ちを犯していませんか？

>どういうときにDBサーバで処理したら、スケーラビリティが下がるのでしょう？
もしかするとスケーラビリティを本当に理解されていない？読み違えただけかな？

>例えば、ストアドプロシージャにしておけば、社内ではC/Sでリッチアプリケーション。ストプロだからRIA？謎すぎます。
そして、ここでスケーラブルではないC/Sシステムを持ち出してくるか・・謎
>社外には同じものを一部分だけWeb公開ということも、最小限の工数できますね。
ストプロだからDBでWEBサービス？これも違うね。

実は、ストプロを中心にした、何かビジネスロジック自体もDBで処理させるという新しいモデルを話しているのに私が気がついていないだけってこともありますがね。（でもそれだとDB主体になったC/S System と何が違うわけ？ですね）
SOA的な色合いは持つかもしれませんね。

「スケーラビリティの話を持ち出したがために、言いたいことがちゃーんと伝わっていないかもしれませんよ。」

スケーラビリティを確保するには、言語が云々ではなく、そのシステムの仕組み（アーキテクチャ）が重要なのです。そして、それを支える要素技術を正しく理想的に使うことが大事なのです。ストアドプロシジャは要素技術の一つではあり得ます。
秒間数万トラフィックのシステムがあったとして、それを支えるシステムがつくられていたとしても、そのシステムがスケーラブルであるかどうかは、処理能力と密接に関係しているわけではありません。ましてや、ストプロが関係するわけでもありません。規模透過性がシステムの処理能力によってその確保と実現を左右されることがあってはいけないのです。つまり、処理能力があろうがなかろうが、スケーラビリティであることが要求される場合は、スケーラブルな仕組みにしなくてはならないのです。（ちょと通じにくいかなこの言い方）

DBサーバは、その性格上、スケーラビリティのなかでも規模透過性は低いのです。そして、位置、他接続、それぞれの透過性については、もっと低いですね。（最近はＤＢが直接ＷＥＢサービスを公開するなんてこともできるようになってきましたが）ですから、スケールアップで何とかしようとします。
また、RDBMSの設計においては、各RDBMSの特色がありますから、もとより、スケールアウトの必要のない構成にしましょうといRDBMSもあれば、無限ではないがノードの追加可能なRDBMSも最近ではあります。

>>スケールアウトという意味であれば、
>>ＤＢサーバに業務処理を大量に持ち込むとシステムのスケーラビリティは落ちます。
>>ＡＰサーバで処理をさせるのはシステムのスケーラビリティが上がります。
>
> つまり、システムの規模透過性が上がります。要するにノードの追加だけです。
> 業務処理って言ってるでしょ？わかりますか？
> ビジネスロジックはAPでやったほうがいいって言ってますね？

tripod さんはシングルポイントのDBを気にされています。
ノードを追加するというのは、DBも分けるということでしょうか？

GoogleやYahooは、別ノードになっているけど、非同期ですからダンスしますよね。
それが許されるシステムです。

通常の業務システムではダンスは許されませんから……。

分けるとしたら、マスターDBサーバ、AトランDBサーバ、BトランDBサーバ……と分けるべきとおっしゃっているのでしょうか？
これは確かにやりますし、GoogleやYahooならキー毎に別サーバにはしてますね。

DBが分散してないならって最初から言ってるし、分けるときも、分け方は設計段階で決まりますから、きっちりお互いの処理量を測れないとエライことになりますけどね。

蛇足かもしれませんが。。。

BL（ビジネスロジック層）==>　DA層{FRONT-END →　各種DBへの効率的なアクセッサ → ストプロによるIO（生SQL発行もある）}
==> 以降右は、データアクセス層の話

この仕組みをうまく作ると、RDBMSのアーキテクチャに左右されないデータアクセス層を構築することができる。データアクセス層のなかで、分散・パラレルすることも可能。データアクセス層事態が多層階層になっても良い。２フェースコミットモ許可できる。（２PCの場合はBLがコンテキストルートでないとダメな場合もありますが・・）

BLとDA層のインタフェースは、サービス型、メモリ共有型（通常のメソッドコールやプロセス間通信）など、複数のアプローチを行うことができる。

BLで生SQLを単発＝よくないこれはほんとダメです。
だからといって、ストプロということでは、スケーラビリティを阻害する可能性を払拭したことにはならない。なぜなら、BLとデータアクセスとの関係は密のままである。ただし、旧来型のC/S型システムでは、リソースの有効利用・アプリケーションの単純化という観点からも有効な手段となりえる。
もちろん、C/Sを発展させて。RIA型UIとDBが提供するサービスとの接続というケースも昨今ではありうる。

ノード追加：RDBMSによっては、データベースサーバ群にサーバを接続するだけでスケールアウトできる仕組みを持つものがある。OracleのRACはその仕組みを実現しようとしている。
一方、SQL Server では、目的や特色に合わせてDBサーバを適宜分割して設計することを推奨している。効率的に細分化されたデータベースはスケールアウトの必要が無いという考えたかた。
その他エンタープライズ向けRDBMSも特色を持っている。

このへんで、終りにしておきます。
結構盛り上がったと思う！（自分だけ？ m(_ _)m失礼しました)

ビガーです。

tripodさんやoumiさんの話は「都心の」SI事情という意味で当然のことを発言されていますね。
非常に共感できます。

ただ、これまでの生島さんの長い話をさらっと見る限りは、アプリケーション(ソフトウェア)に
関してはスケーラビティではなくパフォーマンスであるのはほぼ間違いないことで皆さん、
理解されているはず。揚げ足とっても実りはないです。
ハードウェアのスケーラビティとゴッチャになっちゃってるのがうまく伝わっていない原因でしょうか。

私自身、都心と地方両方でSIしてきた所感から、地方ではアプリケーションアーキテクチャの重要性を本当に理解している技術者が圧倒的に少なく、理解していても費用対効果(特にイニシャルコストについて)を適切にお客さんに伝えられない実情があると思います。
このあたりがアプリケーションのスケーラビティを上げられない本質でしょう。

ビガーさん、ども。

SEがきっちり前提を書くのは、相手が杓子定規のコンピュータだからであって、人間を相手にするのに、読んだら分かる前提は書かないですよ。
タダでさえ長いのですから。

万能の解などないからSIerに仕事があるわけで、一つの文章で全部に適応なんてできるわけがないですから、適宜あてはめて読んでいただければと思います。

で、細かい話ですがパフォーマンスの問題ではないのです。
シングルポイントのDBに負荷は掛けれないから、パフォーマンスを犠牲にしてもスケーラビリティを上げるためにAPサーバで処理します。
つまり、DBは簡単に増設できないから、APサーバに処理させてDBのパンクを防ぎます。という人に対して書いています。

oumiさんが言われるように、Oracleっぽい拡張と、SQLServerっぽい拡張とありますけれど、DBを分けないといけない可能性があるなら、分け方を先ず検討して、どこまで非同期にできるか、1ユーザアクションで複数のDBを参照する可能性があるかなどなどを検討しなければいけません。

1ユーザアクションで複数のDBを参照しなければならない要件（Google検索エンジンなど）があるなら、ストアドプロシージャはまずいです。

ただ、将来、複数のDBになるけれど、今は、1DB（クラスタリング含む）という設計は私は賛同しかねるな。
将来、分ける予定があるなら、マシンのグレードを落としてでも、最初から複数のDBにしておくべきで、複数のDBになった状態でDBでできることはDBにやらせるべきです。

MixiとかMySQLを使っていた？と聞いた気がします。

どんな処理をしているのか知りませんが、1ユーザアクションで複数のDBを参照しなければならない処理は避ける設計にするな……。
そういう処理がないように非正規化して、どのDBサーバに情報があるかのインデックスだけを持っているDBサーバ（これも複数にする）って設計にする。
MySQLでは、ストアドプロシージャ使えなかったでしょうけれど、その状態で個別のDBはストアドプロシージャで処理するな。
そうすると、スケーラビリティは無限に近くできますからね。

マスターは全部のDBに持っても知れているし、Mixiなら、マスターはマルチフェーズコミットしなくてもよい気もするし……。って考えるとストアドプロシージャでやってても、スケーラビリティは確保できるのですけどね。
プログラムの変更量は多少大きくなりますが、予想してたらストアドプロシージャを直に叩かずに、共通クラスを通します（私はログ取るために共通クラスにするけど）。
シングルから、マルチになるときは、共通クラスの中でインデックスサーバに問い合わせる処理を加えればよいわけです。

もっとも、そんな規模で予算があるなら、RDBMSみたいなオーバーヘッドのでかいものは使わないけれど。