独り言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は、ディスクを増やせばいくらでも高速化可能 書き込みの高速化はシェアードナッシングしか他にない 分散後のデータをレプリケーションさせれば、読み込みの負荷分散まで可能である クエリの今以上の高速化には、複数ノードで１クエリを実行することが可能
MySQL ABのディレクターが明かす「MySQL 5.1」の魅力
企業システムにおけるオープンソースソフトウェア（以下、OSS）の活用が叫ばれて久しい。一部では大規模な基幹システムへの採用事例もあるが、全般的に導入は進んでいない。特に、企業システムのエンジンとなるRDBMSとなると商用製品がほとんどである。 しかし、ミクシィや楽天をはじめとするWeb系企業の多くでは、RDBMSを含めOSSを中心にシステムが構築されている。せっかくの公共財である。一般企業においても利用できる場面がないか、いま一度目を向けてみてはどうだろう。そこで注目したいのが、Web系企業ではRDBMSの業界標準となってきたMySQLである。 処理性能こそ高いが、商用製品に比べると機能的に劣るとされてきたMySQLだが、ここにきて急速にキャッチアップしようとしている。2008年に登場予定の最新バージョン「MySQL 5.1」ではその機能差が改善される見込みで、データウェアハウス（以下、D
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
