Agile Cat — in the cloud

Database Sharding _1

Posted in Big Data, Database Sharding by Agile Cat on June 28, 2009

Database Sharding とは、"Shared-Nothing" のアプローチである

http://www.codefutures.com/database-sharding/

David Chappell さんの Blog に、Sharding という言葉があり、ずっと気になっていましたが、それを説明してくれるドキュメントを見つけましたので、4~5 回に分けて抄訳を連載していきます。

Hadoop のときもそうでしたが、Azure を正しく理解するためには、Microsoft 以外から提供される情報にも、目を通さなければならないのだなぁ、、、と感じてしまいますね

端的に言って、Database Sharding とは、"Shared-Nothing" のアプローチだそうです。今回の訳にも ”割れたガラス" の例えありますが、従来からのパーティショニングのテクニックとは一線を画した、思い切った分割が Sharding なのでしょう。

――― A.C.

ーーーーーーーーーーーーーー

The Rise of Database Sharding

Database Sharding のコンセプトとは、ビジネス・アプリケーション・データベースにおける、膨大なトランザクション量とサイズのに対応するためものであり、この数年の間に利用されるケースが増えてきている。そして、オンライン・サービス・プロバイダーのビジネスや、Software as a Service (SaaS) 、SNS Web サイトなどを成功させるものとして評価されている。

Database Sharding は、数多くのサーバーをまたぐ大規模データベースのための、"shared-nothing" パーティション・スキーマであるとシンプルに定義できる。それにより、データベースのパフォーマンスとスケーラビリティを、新しいレベルで達成可能にしていくことになる。 Sharding のコンセプトを理解したいなら、割れたガラスについて考えるべきである。つまり、データベースを “shards” と呼ばれる小さなチャンクに分解し、分散された多数のサーバー上に、それらをばら撒くことである。

用語としての "sharding" は、Google のエンジニアたちが造り出したものであり、彼らの Big Table アーキテクチャ・パブリケーションを介しての普及してきた。 ただし、"shared-nothing" データベース・パーティショニングの概念は、10年前あるいは、それ以前から存在していた。そして、それ以降の何年かで数多くのサービスに実装されてきたわけだが、eBay や、Amazon、Digg、Flickr、Skype、YouTube、Facebook、Friendster、Wikipedia といったインターネット・リーダーたちによる、高度なプロファイル構築ソリューションにおける利用が顕著である。

このドキュメントは、Database Sharding の必要性および、データベース・パーティショニングで利用可能な選択枝、そして、Sharding 実装を成功させるための主要な考察ポイントにフォーカスしている。

What Drives the Need for Database Sharding?

Database Sharding は、膨大なトランザクションにおけるスループットとパフォーマンスを改善し、大規模なデータベースを中心とするビジネス・アプリケーションを構築するための、きわめてスケーラブルなアプローチである。リレーショナル・データベースの初めから、アプリケーションのエンジニアとアーキテクトは、長い時間をかけてビジネス・データベースが成長していくという単純な観点に基づき、パフォーマンスとキャパシティが、とめどもなく増大していくことを要求してきた。そして、インターネット経済と、情報時代、イーコマースの高まりによる、ビジネス・データの急速な膨張が、その傾向を加速している。

経験豊かなデータベース・アドミニストレータやアプリケーション・デベロッパーが、その全てを理解しているように、データベース層のサイズ(GBs)とトランザクション(Tx)のボリュームがリニアに成長するににつれて、その応答時間(Rt)が対数的に増大する傾向にあることは明白である。それを、以下の図で示す:

Database Sharding 1

Figure 1. The growth in database transactions and volumes has a large impact on response times.

パフォーマンスとスケーラビリティに取り組まなければならない理由は、データベース管理システム自身の、基本的なデザインからもたらされるものである。あらゆるコンピュータ上のデータベースが、以下の 3つのコンポーネントに大きく依存している:

  • CPU
  • Memory
  • Disk

私たちが実施したベンチマーク・テストを介して、それらの要素は、シングル・サーバーにおいてのみスケールするものであり、他の基準を取り込まなければならないことが分かった。ディスク I/O が主要なボトルネックであることが明確になった一方で、データベース管理システムが改善されるにつれて、CPUとメモリのアドバンテージについても、さらに高いものが求められる。現実において、最大の性能を決定するものは、それたの 3つの要素と一致するものであることが観察されたわけである。 言い換えれば、無限の CPU(コア)を加えることは不可能であり、また、メモリ容量とディスク・ドライブ・サブシステムのパフォーマンスを改善することなく、通信におけるパフォーマンスを高めることはできない。つまり、シングル・データベース・サーバーにリソースを追加していくにつれて、そこから得られるリターンは減少していく。この傾向は、膨大な Read/Write トランザクションを実行するシステムにおいて、つまり、複雑なビジネス・トランザクションにおいて顕著である。 そして、ビジネス・レポート・タスクのサポートにおいても、それは同様である。

それ故に、ビジネス・アプリケーションが洗練され、需要にしたがって成長するにつれて、アーキテクトと、デベロッパー、データベース・アドミニストレータに、継続的な課題が与え続けられてきた。それは、ミッション・クリティカル・システムにおいて、データベース・パフォーマンスを維持することである。 こうした背景が、Database Sharding の必要性を促進している。

<続く>

 

Database Sharding _1
Database Sharding _2
Database Sharding _3
Database Sharding _4
Database Sharding _5

Tagged with: ,

Database Sharding _2

Posted in Database Sharding by Agile Cat on June 26, 2009

    Database Sharding とは、"Shared-Nothing" のアプローチである

    Database Partitioning Options

    データベース・パーティショニングが、リレーショナル・データベースのパフォーマンスとスケーラビリティを改善するための回答であることは、これまでにも認識されていることである。以下の各項目を含む、数多くのテクニックが進化してきた:

  • Master/Slave: 数多くの組織で利用される最もシンプルな選択肢であり、すべての Write(Create Update or Delete, or CRUD)オペレーションのためのシングル Master サーバーと、Read-Only オペレーションを提供する複数の Slave サーバーで構成される。 Master は Slave サーバーに対して、標準的データベース・リプリケーションを、near-real-time で使用する。 この Master/Slave モデルは、Slave サーバー群に対する Read 集約的なプロセスを顕現するという点で、全体的なパフォーマンスを高めるが、いくつかの限界を持つアプローチでもある:

    • Write のためのシングル Master サーバーは、スケーラビリティに対する明確な限界があり、すぐにボトルネックになってしまう。

    • Master/Slave リプリケーション・メカニズムは、"near-real-time" であり、Slave サーバーが Master の最新のデータを、保持することが保証されない。 いくつかのアプリケーションに対しては極めて適切なるが、対象となるアプリケーションが最新データを必要とする場合は、このアプローチは受け入れ難い。

    • 高可用性を前提とした Master・Slave アプローチが、数多くの組織で利用されるだろうが、Slave サーバーが Master と必ずしも同期する必要がないという前提に、苦しめられることになる。 Master サーバーが大きな障害を引き起こすケースは、リプリケーション前のトランザクションが失われることであり、大半の商取引アプリケーションでは受け入れ難いことである。

  • Cluster Computing: クラスタ・コンピューティングは、グループ内で運用される数多くのサーバーを利用し、クラスタにおけるノード間でメッセージを共有する。 このシナリオにおける大半のケースでは、センタライズされた Storage Area Network(SAN)などの、共用ディスク・ファシリティに依存する。クラスタ内の個々のノードは、データベース・サーバーのシングル・インスタンスを、多様なモードで実行する:

    • 高可用性を実現するために、クラスタ内の多数のノードを Read において使用できるが、Write(CRUD)操作では 1つのノードしか使えない。 それにより、Read は速くなるが、Write トランザクションにはメリットが生じない。 1つのノードが失敗する場合には、クラスタ内の別のノードが引継ぎを行い、共有ディスク・ファシリティに対する操作を継続する。 このアプローチは、CRUD 操作にシングル・ボトルネックを持つため、スケーラビリティが制約される。 さらに、そのメリットが得られる前に、集中化された共有ディスクが大量の付加を振りまくため、そのセンタライズされた共有ディスク・ファシリティの Readも、最終的にはパフォーマンスの限界に突き当たるだろう。とりわけ、アプリケーションが複雑な結合を必要とする場合や、最適化されていない SQLステートメントを含む場合に、Read における限界が明白になる。

    • さらに進歩したクラスタリング・テクニックは、ノード間でリアルタイムにメモリをリプリケーションする方式であり、リアルタイム・メッセージ交換システムにより、クラスタ内のノードにおけるメモリ・イメージをアップデートしていく。 この方式は、Read/Write のモードにおいて、個々のノードに適用されるが、ノード間で(一般てきなネットワークや、高速の通信メカニズムを使って)送信ができるトラフィック量により、最終的には制限を受ける。 したがって、ノードが追加されるにつれて、コミュニケーションとメモリにおけるリプリケーション・オーバーヘッドが幾何学的に増大し、比較的に少数のノードであっても、スケーラビリティの限界に突き当たる。さらに、集中的なディスク I/O を増やしていく、大規模なシングル・データベースの成長を考えれば、このソリューションも従来からのクラスタにおける、共有ディスクの限界に苦しむことになる。

  • Table Partitioning: 数多くのデータベース/マネージメント・システムが、テーブルの分割をサポートする。そこでは、ディスク I/O 利用を改善するために、太容量のシングル・テーブル内のデータが、マルチ・ディスクに分割される。一般的に、パーティショニングは水平方向に行われるが(ディスク・パーティションをまたぐレンジで Row を分割)、いくつかのシステムでは、主意直方向に行われる(分離されたパーティション上に別の Column を配置)場合もある。 このアプローチでは、前提となるテーブルに対して、ディスク I/O のボトルネックを低減するのに役立つが、結合などの操作を、さらに遅くする可能性を持つ。 このアプローチも、データベース・マネージメント・システム上のシングル・サーバー・インスタンスに依存するため、その他すべての CPU と メモリにおける制約が生じるだけではなく、スケーラビリティも制限される。

  • Table Partitioning: Table Partitioning の派生物である Federated テーブル・アプローチでは、多数のサーバーに分散されたテーブルにアクセスできる。 このアプローチにおいては、アドミニストレーションが極めて困難なものとなり、連携するテーブル間でネットワーク・アクセスが増えるににつれて、効率が低下していく。 このアプローチは、レポーティングや分析で機能するだろうが、一般的な Read/Write のトランザクションのための選択肢とはならない。

    これらのアプローチに共通する欠点は、共有されたファシリティとリソースに対する依存性にある。共用メモリ二依存しても、また、集中化されたディスクやプロセッサキャのパシティに依存しても、スケーラビリティの限界で苦しむことになる。そこには、複雑なアドミニストレーションや、クリティカルなビジネス要件に対するサポートの欠如、高い可用性の限界などが含まれることは、言うまでもない。

    <続く>

 

Database Sharding _1
Database Sharding _2
Database Sharding _3
Database Sharding _4
Database Sharding _5

Tagged with: ,

Database Sharding _3

Posted in Database Sharding by Agile Cat on June 25, 2009

Database Sharding とは、"Shared-Nothing" のアプローチである

Database Sharding, The "Shared-Nothing" Approach

Database Sharding は、それぞれが CPU とメモリとディスクを持つ、複数の独立したサーバー全体をカバーするスケーラビリティのための方式を提供する。高度なデータベース・パフォーマンスを達成するための、従来からの方式と比較して、それらのアプローチがもたらすような、数多くの典型的な制約に苦しまないで済むことになる。 "shared-nothing" データベース実装のコンセプトは、15 年以上にもわたって研究中であり、ディスカッションが継続されている。しかし。この何年かの間にデータ量が急速に増大してきたため、ビジネス・アプリケーション市場が一般的な必要性を見いだそうとしているのが、それらの機能であると思われる。

Database Sharding の基本的なコンセプトは、非常に簡単なものである。つまり、大規模なデータベースを、複数のサーバー全体に分散された、小規模なデータベースに分解するものである。そのコンセプトについて、以下の図に示す:

Database Sharding 2

Figure 2. Database Sharding takes large databases and breaks them down into smaller databases.

Database Sharding の "shared-nothing" における明白なアドバンテージは、数多くのサーバーがネットワークに加えられるときでも、ほとんどリニアに成長していく、改善されたスケーラビリティである。そして、小規模なデータベースへと分解していく、sharding ソリューションについて検討するとき、見落としてはならない、いくつかのアドバンテージが存在する:

  • Smaller databases are easier to manage. プロダクション環境におけるデータベースは、通常のバックアップや、データベースの最適化などの共通のタスクに対して、完全に管理されなてはならない。 大規模なシングル・データベースを用いて、限られた時間の中だけで、それらのルーチンタスクを達成することは、きわめて困難なものになり得る。 ルーチン化されたテーブルとインデックスの最適化は、何時間あるいは何日かにまたがる場合もあり、定期的なメンテナンスを実施できなくしてしまうこともある。 この sharding アプローチを用いることにより、それぞれの "shard" を個別にメンテナンスすることが可能となり、はるかに処理しやすいシナリオの提供と、平行したメンテナンス・タスクの実施が可能となる。

      • Smaller databases are faster. そのプロセスが、ネットワーク上に配置された多数の shard とサーバーをまたいで処理されるため、sharding のスケーラビリティは見た目にも明らかなものとなる。 それほど明白なものではないが、それぞれの shard データベースのサイズが小さいため、大規模なシングル・データベースを凌ぐパフォーマンスを実現するという事実もある。 サーバー上で個々の shard データベースをホストすることで、ディスク上のデータとメモリの比率が大きく改善され、ディスク I/O が低減される。それは、リソース競合の低減および、結合パフォーマンスの向上、インデックス検索の高速化、データベース・ロックの結果である。 したがって、shard されたシステムのスケールが、キャパシティにおける新しいレベルの能力をもたらすだけではなく、それぞれのトランザクションにおけるパフォーマンスも向上する。

          • Database Sharding can reduce costs. 大半の Database Sharding 実装においては、より低コストのオープンソース・データベースの利用もしくは、商用のデータベースの "workgroup" バージョンの利用が可能となる。 さらに、 sharding では、ハイエンドのマルチ CPU サーバーや SAN と比較して、よりはるかに低価格の普及品マルチコア・サーバ-を利用できる。多大なライセンス費用や、ソフトウェア・メンテナンス、ハードウェア投資において全体的なコストの低減が図られる。 他のソリューションとの比較において、70% 以上の低減が実現する場合もある。

          Database Sharding が、数多くの組織において利用可能なソリューションであることに、疑いの余地はない。そして、このテクノロジーを実装している、数多くの大手オンライン・ベンダー(Amazon、eBay、Google など)により、Database Sharding はサポートされている。

          <続く>

          Database Sharding _1
          Database Sharding _2
          Database Sharding _3
          Database Sharding _4
          Database Sharding _5

          Tagged with: ,

          Database Sharding _4

          Posted in Database Sharding by Agile Cat on June 20, 2009

          Database Sharding とは、"Shared-Nothing" のアプローチである

          Practicalities of Database Sharding

          Database Sharding がハイ・スケーラブルで、経済的で、パフォーマンスを改善するなら、このテクノロジーは何ゆえに、もっと広範囲で採用されないのか? そして、あなたの組織において、それは実行できるのか?

          Database Sharding はきわめて有用なテクノロジーなのだが、他のアプローチと同様に、実装の成功を保証するには、数多くの要因について検討しなければならないという現実がある。さらに、いくつかの限界がある。 つまり、Database Sharding は、すべてのタイプのビジネス・アプリケーションに適したものではないということだ。このチャプタでは、それらの重要な検討ポイントと、この画題に取り組んでいくための課題について説明する。

          Database Sharding Challenges

          それぞれのデータベースに分配される性質があるため、数多くの重要な要素について検討する必要がある:

          • Reliability : 何よりも第一に、プロダクション環境のビジネス・アプリケーションは信頼性が高く、フォールト・トレラントなはずであり、また、そして頻繁にダウンするものでは困る。 大半のケースにおいて、そのデータベース層は、あらゆる信頼性を考慮したデザインにおける、最もクリティカルで唯一の要素である。したがって、Database Sharding の実装も例外とはならない。 現実に、多数の shard データベースに分配された性質があるため、適切に設計されたアプローチが持つ重要性は、さらに大きなものとなる。 フォールト・トレラントで信頼性の高いアプローチを保証するためには、以下の各項目が必要とされる:

            • それぞれの Database Shards における、自動的なバックアップ。

            • Database Shard における冗長性、つまり、それぞれの shard における、少なくとも2つの "live" なコピーが、システム・ダウンやサーバー障害の場合に、利用できることを保証する。そこでは、ハイ・パフォーマンスで、効率的で、信頼性の高いリプリケーション・メカニズムが必要とされる。

            • それぞれのサーバーに配置され、サーバー群をまたぐ、費用効果が高いハードウェア冗長性。

            • システムダウンやサーバー障害が発生した場合の、自動的なフェイルオーバー。

            • 災害時を想定した、リカバリーのメカニズム。

          • Distributed queries 分散クエリーを用いることで、それぞれの shard サーバーで、一時的な結果が並列に処理されるため、多様なクエリーがはるかに速く処理される。このテクニックは、パフォーマンスの向上において桁違いの改善を達成し、多くのケースにおいて 10倍以上の結果を生み出す。対象となるアプリケーションへ向けて、スムーズな方式で分散クエリーを実現するためには、それぞれの shard 上にクエリーのセグメントを処理するための機能を持ち、そのアプリケーション層へ向けて、複数の結果をコンソリデートしていくことが重要となる。 分散プロセッシングから利益を得ることができる、共通のクエリーとは:

            • システム全体をまたいで、広範囲でのデータ検索を必要とする、統計値の集合体。 通常ではデータベース全体の評価を必要とする、プロダクトごとの販売量の計算などが、このようなケースの例となる。

            • 日/週/月などの範囲で、所定のプロダクトを購入した、すべての顧客リストなどの、包括的なレポートサポートするためのクエリー。

            • Avoidance of cross-shard joins内部的な結合を用いて、shard されたシステムをまたぐクエリーなどのステートメントは、きわめて非能率であり、また、実施が難しい。 正しいテクニックが適用されている限り、このような内部結合が実際のアプリケーションに必要とされることはないと、大半のケースにおいて検証されている。その主要なテクニックは、Global Tables のリプリケーションである。一般的に、この相対的に静的な参照用テーブルは、きわめて大規模なプライマリー・テーブルと結合するときに利用される。このテーブルに含まれるのは、Status Codes、Countries、Types などの値であり、Products が、このカテゴリーに分類される場合もある。 必要とされるものは、自動化されたリプリケーションのメカニズムである。それにより、Global Tables 値の、すべての shard 間での同期が保証され、クロス shard 結合へのニーズが、最小化されるか、また、完全に除去される場合もある。

                • Auto-increment key management一般的に、DBMS が提供する自動的なインクリメント機能は、シーケンシャルなキーを、データベースにインサートされる新しい Row に対して生成していく。 この考え方は、シングル・データベース・アプリケーションにとっては素晴らしいものだが、Database Sharding を使うときは、調和した形式において、すべての shard をまたぐかたちで、それらのキーを管理しなくてはならなくなる。 ここで要件は、キー生成のためのシームレスで自動化された方式を、アプリケーションに提供することである。システム全体を網羅したかたちで、キーがユニークであることを保証し、すべての shard をまたいだ運用を実現する。

                    • Support for multiple Shard Schemes : Database Sharding が効果的なのは、スケーラビリティとパフォーマンスの大幅な改善という観点で、アプリケーションに対して特定されたテクノロジーを提供するためである。 その点を指摘しておくことは、重要である。 現実的に言って、その効果の度合いは、sharding アルゴリズム自身が、アプリケーションにおける問題へ向けて直接的に、どのくらいフィットしているかという点に左右される。 そこで必要とされるものは、それぞれのアプリケーション固有の問題に取り組むようにデザインされた、多数の、柔軟な、shard スキーマのセットである。 そして、特定の問題ドメインに適用されるとき、それぞれのスキーマは、本来のパフォーマンスおよび、アプリケーションに対する特性とアドバンテージを持つことになる。実際に、不適切な shard スキーマを用いると、パフォーマンスを損なう可能性が生じ、その結果が、実際に得ようとするものになってしまう。ひとつのアプリケーションに、複数の shard スキーマを用いるのも、また、一般的ではない。 アプリケーションの特定部分に適用されるスキーマが、最適な結果を達成する。 以下に、一般的な共有 shard スキーマのリストを示す:

                        • Session-based sharding : 個別のユーザーやプロセスが、そのセッションの期間中に、特定の shard とインタラクトするケース。 これは、実装において最もシンプルなテクニックであり、全体的なパフォーマンスに対する実質的なオーバーヘッドもゼロになる。なぜなら、sharding を用いた判断は、セッションごとに一回しか行われないからである。 このアプローチからメリットを得るアプリケーションは、大半のケースにおいて顧客セントリックなものとなる。その理由は、前提となる顧客のすべてのデータが、ひとつの shard に含まれ、それ自体が、対象となる顧客が必要とする全てのデータになるからである。

                            • Transaction-based sharding:前提となるデータベース・トランザクションの最初の SQL Statement を調べることで、その shard について判断する。 一般的に、対象となるステートメントで用いられる "shard key" 値(Order Number など)を評価することで、その処理は完了する。続いて、そのトランザクション内の全てのステートメントを、同一の shard に方向付ける。

                                • Statement-based sharding: すべてのタイプの中で、最もプロセス集約的なものである。それぞれの SQL Statement を評価して、方向付けを行うべき適切な shard を判断する。再び、対象となる shard Key の値を評価しなければならない。 このオプションは、電話の通話記録などの、データ量が大きくトランザクションが粗いケースで用いられる。

                                • データを sharding するための、最適な方式を決定する。 このフィールドは、アプリケーションごとに変化するものであり、きわめて可変的な別の領域である。 そして、前述の Database Shard Schem での選択と、緊密に結び付けられる。 どのようにしてデータの shard を決定するかについては、数多くの方式が存在する。そして重要なことは、トランザクション・レートおよび、テーブル・ボリューム、キー・ディストリビューション、そして対象となるアプリケーションの特徴を理解することだ。 最適の sharding 戦略を決定するために、以下のデータが必要とされる:

                                    • Shard by a primary key on a table: 最も簡単な選択枝であり、前提となるアプリケーションへのマップも、最も容易になる。 ただし、データの配布が適度に行われる場合のみ、効果的な手法となる。 たとえば、Customer ID (シーケンシャルな数値)による shard を選んでも、トランザクションの大半が新規の顧客のためのものとなるなら、データベースの sharding から何かが得られても、それは少しになってしまう。 その一方で、充分にして必要な分散トランザクションを実行するキーを選択すれば、きわめて大きなメリットが具体化される。

                                        • Shard by the modulus of a key value:モジュール機能をキーの値に適用し、その値の計算に基づいてトランザクションを分散することで、この選択枝は数多くの状況に当てはまる。 本質的に、いかなる数の shard であっても、前もって定めることが可能となり、また、“round-robin” ベースの shard をまたいで、モジュール機能が効果的に分散されるため、新しいキー値の充分な分散をもたらすことができる。

                                            • Maintain a master shard index table :このテクニックは、特定の shard に各種の値をマップする、ひとつのマスター・テーブルの利用を伴う。 それは、きわめて柔軟であり、多種多様なアプリケーションの状況に合致する。ただし、それぞれの shard された SQL Statement のために、余計な参照が必要になるににつれて、このオプションは低いパフォーマンスを示すことになる。

                                          これまでに見てきたように、費用効果が高い方式で、新しいレベルのスケーラビリティとパフォーマンスを提供するには、Database Sharding 実装を効果的に成功させなければならない。 そのためには、数多くの考慮すべきポイントと、必要とされる機能がある。

                                          <続く>

                                          Database Sharding _1
                                          Database Sharding _2
                                          Database Sharding _3
                                          Database Sharding _4
                                          Database Sharding _5

                                           

                                          Tagged with: ,

                                          Database Sharding _5

                                          Posted in Database Sharding by Agile Cat on June 19, 2009

                                          Database Sharding とは、"Shared-Nothing" のアプローチである

                                          When Database Sharding is Appropriate

                                          Database Sharding は、汎用的なデータベース要件を持つビジネス・アプリケーションに、適切にフィットする。さらに、Data Warehousing アプリケーションに対して効果的に利用することも可能である。また、それを達成するために利用可能な、数多くのプロダクトとテクノロジーがするとき、ここでフォーカスしている要素について、考える必要もなくなるだろう。

                                          Sharding にフィットする、汎用目的のデータベース用件は、以下の項目を含む:

                                          • 高度なトランザクションを持つデータベース・アプリケーション
                                          • 複数のワークロードを組み合わせたデータベース利用
                                            • 複雑なクエリーと結合を取り込んだ、頻繁な Read
                                            • Write に集約されるトランザクション(INSERT, UPDATE, DELETE を含むCRUDステートメント)
                                            • 共通のTableおよびRowに関する競合
                                          • 汎用のビジネス・アプリケーション
                                            • 典型的な"repeating segment" のレポート生成
                                            • 何らかのデータ分析(他のワークロードとの組み合わせ)

                                          特定のアプリケーションや環境に、Database Sharding が適用するかどうかを判断するために、評価すべき最も重要なことは、そのデータベース・スキーマが sharding に対して、適切な結果をもたらすことである。 本質的に、Database Sharding は “horizontal” なパーティショニングのための手法である。 つまり、シングル・スキーマ・テーブルのためのデータベース Row(Column の対極)が、多数の shard をまたいで配布されることを意味している。 前提となる状況に対して、上手くフィットする sharding の特徴を理解するために、決定すべき重要なポイントを以下にまとめる:

                                          • スキーマ内の、すべてのトランザクション集約型のテーブルを識別する
                                          • その時点でデータベースが操作している(操作すると思われる)トランザクション・ボリュームを判断する。
                                          • すべての共有 SQLステートメント(SELECT, INSERT, UPDATE, DELETE)と、それぞれに組み合わされる量を識別する。
                                          • スキーマ内に含まれる"table hierarchy" への理解を発展させる。言い換えれば、主要なparent-child の関係のことである。
                                          • 大ボリューム Table上のトランザクションへ向けた、"key distribution" を判断する。つまり、広範囲へのムラのない配布なのか、狭い範囲に集中した配布なのか、その点を判断する。

                                          上記の情報を用いることで、アプリケーションに対する sharding における、価値と適用性の査定を速やかに得ることができる。 以下の例では、シンプルな Bookstore スキーマにおいて、データが shard される様子を示す:

                                          Database Sharding 3

                                          Figure 3. Example Bookstore schema showing how data is sharded.

                                          この Bookstore の例では、Primary Shard Table が ‘customer’ のエンティティである。 それが、対象となるデータを shard するために用いられるテーブルである。この ‘customer’ テーブルは、’customer_order’ エンティティと ‘order_item’ エンティティを子テーブルとして持つ、shard 階層の親である。対象となるデータは ‘customer.id’ の属性によりsharded され、’customer.id’ と関連する子テーブル内の、すべての関連する Row も同様に shard される。 Global Tables は、共通の参照テーブルであり、そのアクティビティは相対的に低い。そして、これらのテーブルは、cross-shard 結合を回避するために、すべての shard に対してリプリケートされる。

                                          この例は、きわめて基本的なものであるが、前提となるデータベース・アプリケーションを shard する方式を、決定するために必要な考察点を提供している。 この、評価のためのアプローチを用いることで、特定の環境に対して sharding が適用できるのかどうか、その点を判断できる。 そして、Database Sharding を実装することで、どのようなメリットがもたらされるのかについても判断できるだろう。

                                          <終わり>

                                           

                                          Database Sharding _1
                                          Database Sharding _2
                                          Database Sharding _3
                                          Database Sharding _4
                                          Database Sharding _5

                                          Tagged with: ,
                                          %d bloggers like this: