 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| どこにどんなデータを配置するか | ||||||||||||
|
繰り返しますが、データベースは基本的に共有データを扱うので、データをどこにどのように配置するかが一番重要になります。データの配置を決める上で、次の2つの考え方があります。
前回解説したように、同じ共有データを複数の場所に記録した場合、データを書き換える際にはどこで処理するべきかをきちんと1ヶ所に決めておかないと、データに矛盾が生じてしまいます。実際には複数のSQLが同時に実行されています（毎秒数10から数100といった具合）。 SQL文では、同じデータを見たり書いたりすることがあります。こういった場合にもSQLの相互間に悪影響がないようにしておかなければならないのです。スケールアウトしていないデータベースでも、これらは重要です。 bの場合ではさらに複雑になり、残念なことにデータを複数の場所に記録することはなかなか難しいのです。今回の解説では、必要に応じてデータのコピーを持てることで話を進めますが、具体的なやり方はaの場合を中心に解説することにし、bについては、次回以降で詳しく解説することにします。 データベースに格納するデータは、アプリケーションが使うユーザデータだけではなく、データベースの内部構造を調べるためのカタログ（例えば、どんなテーブルがあるか、そのテーブルの構造はどうなっているか、高速化のためのインデックスはあるかなど）もありますが、ここではユーザデータに的を絞って解説することにします。 |
||||||||||||
| データの分割のしかた | ||||||||||||
|
リレーショナルデータベース（RDB）を考えます。RDBでは、すべてのデータは図2に示すような「表（テーブル）」で表すことになっています。  図2：RDBではすべてのデータは表（テーブル）になる 格納のやり方として、まずテーブル単位に分けて、それぞれのサーバにどれかのテーブルを格納することが考えられます。これはNFSなど、ファイルシステムの考え方と類似していて、理解しやすい考え方です。 問題は実際のデータベースでは、特定のテーブルが大変大きなサイズになることが多いということです。 例えば、銀行の場合には口座のテーブルとその取引のテーブルが大きくなりやすいですし、オンラインショップの場合は注文のテーブルや顧客のテーブルが大きくなりやすいでしょう。サイズも半端ではなく、数百万、数千万件のデータになることもあります。 そのため、テーブル単位で個別のサーバにデータを格納しようとすると、たくさんのサーバにデータを分割することが難しくなりますし、格納するデータの量もサーバによってかたよりが出てしまうことになります。 実際のアプリケーションでは、別々のテーブルで互いに関連する情報を同時に読んだり書いたりすることがあります。これらは、SQLの処理の中で行われることが多いので、例えばデータを格納しているサーバ間のデータのやり取りが増えてしまうことも考えられます。こういったことをなくして、それぞれのサーバの中で閉じて処理ができるようにすることが、効率を上げる上で重要なのです。 そこで、テーブル単位に格納するサーバを変えるのではなく、テーブル自身を複数のサーバに分割して格納することを考えます。図3に示したのがそのやり方です。 このような分割方法は、「分散データベース」という分野で長年にわたって研究がなされているものです。興味のある読者は下記の文献を参照ください。
参考文献：
M.T.Ozsu、P.Valduriez、「Principles of Distributed Database Systems」、1999、Prentice Hall、ISBN: 0136597076（残念ながら日本語の同等の文献は見当たりません）
|
||||||||||||
|
||||||||||||
 図3：テーブル分割の2つの方法 （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||||
| このうち水平分割のほうが、それぞれのサーバに閉じた処理を考えやすいので、ここでは水平分割を行うことを考えていきます。 |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
