独り言v6 » RDBMSにおける5つの並列可能性 – L.star的デザイン(2)
前回、と言ってもずいぶん前になるが 超並列RDBMSは成立するか – L.star的デザイン（１） にてある程度の考察をしているRDBMSのデザイン。kumoFSどうだろうとか寄り道しつつ、自分なりの次のステージまで煮詰めることができたので、それについてメモとして書き留めたい。 まず目標として掲げるのは、 標準的なストレージしか持たないサーバ群を使う。 単純CRUDクエリのスケールアウト。読み書き両方 JOIN構文のサポート。特に１TB程度の複数テーブルをINNER JOINして集計できる 1つのクエリ内部を複数サーバに分割させることによる性能向上。スケールアウトというわけではないが。 というところである。かなり無茶な要求と思うが、ここまでサポートできるとデザイン上で納得できれば悪くなかろう。現実に実装する場合には、随所で発生するボトルネックとの戦いになるだろうし。前回は「ストレージノード
独り言v6 » 超並列RDBMSは成立するか – L.star的デザイン（１）
前回Oracle exadataについて書いたが、そのとき同時に「L.starにも考えていることがあった」と書いた。一つはpgclusterで培った経験を元に、クエリベースのレプリケーションをまともに動かそうというものなのだが、もう一つがexadataに近い、超並列を可能にするかもしれないRDBMSのアイデアだった。ここではそれを簡単にまとめることで、実際に可能かどうかをあらためて考えてみたい。 あくまで個人的な意見としてだが、超並列超高性能DBを作るうえで、考えたことは以下の通りである。 原則シェアードナッシングしかあり得ない。 読み込みディスクI/Oは、ディスクを増やせばいくらでも高速化可能 書き込みの高速化はシェアードナッシングしか他にない 分散後のデータをレプリケーションさせれば、読み込みの負荷分散まで可能である クエリの今以上の高速化には、複数ノードで１クエリを実行することが可能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hadoop Security
