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: ,

2 Responses

Subscribe to comments with RSS.

  1. pgmyuri said, on July 18, 2012 at 3:10 pm

    Reblogged this on pgmyja.

  2. agilecat.cloud said, on July 18, 2012 at 9:11 pm

    有難うございます。これからも、よろしくお願いしま~す。


Comments are closed.

%d bloggers like this: