CTCの人が書いた記事に突っ込む

まぁ、なんというか、突っ込むっていうか、記事の文字数制限とかの関係で
かけなかっただけだとは思うんですけど、ちょっと違和感があったので、
突っ込んでみます。

では元記事を。

では、ノードを増やした分に比例してパフォーマンスが向上するか？というと、100％そうではありません。RACはシングル構成に比べて、次のようなオーバヘッドがあります。

1つ目が「マスター問い合わせ処理」です。RACでは、各データに対して「どのノードが最新データを持っているか？」を管理しているノードがいます。そのノードをマスターといいますが、アクセスを行うノードはそのマスターに問い合わせを行います。

2つ目が「分散ロック管理処理」です。更新中のデータがほかのノードに更新されないよう、ノード間にまたがって管理されるロックです。

3つ目が「インターコネクト経由のデータ転送処理」で、物理的な転送処理です。
http://www.thinkit.co.jp/article/96/2/3.html

どこに違和感を感じるかというと、
この３つって、確かにRACのオーバーヘッドではあるんですが、
100%スケールしないことの説明として３つ並べるのはおかしいと思うんです。
じゃあ、１こずつ説明を。

マスター問い合わせ処理

RACの場合、たとえば、なにかデータをSELECTするとして、
必要なブロックを探す手順は一番コストのかかる場合で下記のようになります。

そのブロックのマスターノードにブロックがどこにあるか問い合わせる。
↓
マスターノードがブロックを保持しているノードに対して、
要求してきたノードにブロックを飛ばせと命令する。
↓
ブロックを保持してるノードが要求ノードにブロックを飛ばす。

待機イベントでいうところの「gc current block 3-way」ってやつですね。
で、ここで注目してほしいのは、ノードが３つしか出てきてないってことです。
ひとつのブロックに対して、
要求ノード、マスターノード、ホルダーノードの３つしか出てきていません。
で、これはどれだけノード数が多くなっても変わりません。３つ以上になることはありません。
1024ノードのRACであっても、ひとつのブロックを読み込むためにやり取りが必要なノードは
３ノードなんです。

ノード数が増えると、自分がマスターやホルダーでなくなる可能性が増えますので、
確かにパフォーマンスは下がるとは思うんですが、
２ノード→３ノードにしたときより、
３ノード→４ノードにするほうが、影響は少なくなります。
同様に、４→５、５→６って考えていくと、ノード数が増えていくごとに、
この要素がスケーラビリティに与える影響は少なくなっていきます。

よって、100%スケールしないってのは確かにそうなんですけど、
このあたりの説明がないので、ちょっと減点ですよね。

分散ロック管理処理

おっしゃるとおりです。
スケールしない理由としてはこれが一番多いと思います。
ここに関しては違和感ないです。

インターコネクト経由のデータ転送処理

「マスター問い合わせ処理」でデータを転送することになったときに、
インターコネクト経由でデータ転送が行われます。
で、これがスケールしない理由になっているのが、
さっぱりわからないんですよね・・・。
全体としての転送量がスイッチの限界を超えるとかそういうことなんですかね？
たしかにシングルと比べたときのオーバーヘッドにはなると思うんですけど、
これをスケールしない理由といわれるとちょっと？？？なんです。

ということで、突っ込んでみました。
私もそこまでスペシャリストではないので、
突っ込みどころがあれば、どなたでもよろしくお願いいたします。

ではでは。