Windows Azure Table の利用 ～ 特性とパフォーマンスの検証4. Windows Azure Table を使ったストレージ設計
目次
※この内容は 2011 年 4 月時点での情報を元に執筆されたものです。 スキーマレスとエンティティ グループ トランザクションの利点を活かすことを考えると、テーブルをあまり細かく分割するのは有効な戦略ではないことがわかります。例えば、Person と Friends ならば、テーブルを同じにし、同じ人 (aPerson) のデータは同じパーティションに入れるような使い方が良いでしょう。 このデータ構造は、各個人のデータはトランザクショナルに処理されるが、人と人との間の通信はトランザクショナルではないことが前提になっています。例えば、A さんから B さんへメールを送ったときに、A さんのメールボックスの送信箱にはトランザクショナルに入れますが、B さんの受信箱には、非同期に非トランザクショナルに入れます。B さんの受信箱への送信処理は、Windows Azure Queue に A さんの送信箱のメールの ID を入れるようにします。 このような非同期処理はインターネットで使われているメール配信に似ており、スケーラブルな実装です。
Person、Payment、Order などのアプリケーション オブジェクトは、Data に入れます。Data 内には複数のクラスのインスタンスが入るので、Rowkey の先頭に Type を付けて区別します。 ページのトップへ なぜ分割せずに Data に入れるのかなぜ、Person、Payment などのクラス毎に異なるテーブルを使わずに、Data という 1 つのテーブルに入れるのでしょうか。従来の RDBMS などでは、データは正規化してテーブルに入れるのが普通でした。Windows Azure Table は下記の特徴を持ったストレージ エンジンになっており、従来とは異なった設計パターンが適しています。
スキーマレスなので、エンティティ毎に別々のプロパティ (カラム) を持つことができ、同一のテーブル (Windows Azure Table) に複数のクラスのインスタンスを永続化することができます。Windows Azure Table では永続化する領域のことをテーブルと呼んでいますが、それはエンティティを入れる袋 (Bag) のようになんでも入れることができます。 テーブルとパーティションが同じエンティティは、同一のパーティション サーバーで処理され、ACID トランザクションを適用することができます。これらのことを考えると、ストレージの特性上、あまり複数のテーブルに分割するより、まとめてしまった方が柔軟に問題に対応することができると言えるでしょう。 Windows Azure Table でテーブルを分割した場合に有利なのは、一括削除ができることと管理面11 だけだと思います。
ページのトップへ パフォーマンスの問題はないのか?パフォーマンスの問題を読み替えて、データ量の問題として考えてみます。実際ほとんどの処理の問題は「大量のデータ」と共に存在します12。典型的なストレージ関連の問題として、データの読み込みのときにインデックスが使えないパターン (全件読み出し) や、大量にデータがあったときの B ツリー インデックスの作成、更新でのコストなどがあります。これらの問題には、データ量を減らす戦略が有効です。 そのための分割の戦略を考えると、「種別ごとにデータを分割する方法」と「データを各個人、期間 (など) に分割する方法」が考えられます。前者は正規化と言われる方法で、後者はパーティショニングと言われる方法です。今回想定している SNS などの場合、各個人毎に別のデータとして分割してしまうと大きく個々のデータを減らすことができるので、パーティショニングが非常に有効です。両者を比較すると、テーブルで分割してデータを減らすより、パーティションを分割してデータを減らす方法が有効だと言えます。 つまり、「有効なパーティション分割が出来れば、1 つのテーブルに入れてもパフォーマンスの問題はなく、SNS などでは、人毎にパーティションを分けるのが有効である」と言えます。 Windows Azure Table は、個人データが集積するようなコンシューマー向けのシステムには適した性質をもったストレージで、スケーラビリティにも優れています。サービスがスケーラビリティとトランザクションの両方を必要とする場合は、Windows Azure Table が良い選択肢だと言えます。
ページのトップへ |
.jpg)