Agile Cat — in the cloud

Jackson ファンたちが Web を軋ませた

Posted in Out Of Scope by Agile Cat on June 29, 2009

The Web Creaks as Jackson Fans Mourn
June 25th, 2009 : Rich Miller
Datacenter Knowldge より

Keynote Systems が Michael Jackson が死んだ夕刻の、インタネット・レスポンスにおける需要/供給バランスに関するレポートを発表した。 調査対象は、ABC、AOL、CBS、 MSNBC、NBC、SF Chronicle、Yahoo! News とのこと。

news-site-index-470

赤い線が供給を示し、青い線が需要を示している。ピークへと転ずる最初のクロスが17:45 で、平常へと戻る二番目のクロスが 18:45。

Google と、Yahoo と、Bing に、マイケルがくれたもの

Posted in Out Of Scope by Agile Cat on June 29, 2009

SEARCH ENGINE JOURNAL より

Google News は Michael の死をキャッチできなかった。ただ、Google News Universal Search Onebox に1行だけ、そのことを示すヘッドラインがあったとか。

michael-jackson-google

Yahoo は、見事にキャッチした。。。

michael-jackson-yahoo

Bing は、ずっとスクロールしたところでキャッチしているが、リンクは Fail だったという。

michael-jackson-bing

Tagged with: , , ,

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

最期まで Michael はスーパーだった

Posted in Out Of Scope by Agile Cat on June 27, 2009

空前のトラフィック by Michael

アメリカの各サイトは、Michael に関連するニュースやメッセージで、空前のトラフィックだったそうです。
以下は、Alexa の Hot URLs (6/27/2009, 12:40 PM)です。③ と ⑦ 以外は、すべて Michael 関連です。

Michael

以下は、Long Tail World からです。。。

Google:  自動攻撃と勘違いし、約25分間エラーページを出してしまった
Yahoo:「マイケル・ジャクソン病院に急行」は10分でクリック80万回、訃報も10分でクリック56万回
Flickr: マイケル・ジャクソン関連の写真が、1日で4000枚投稿された
Twitter: マイケル・ジャクソン関連のつぶやきは、ピーク時で5000件/1分を記録した
AOL: インスタントメッセージAIMは、木曜午後に
約40分間のダウン

最期までスーパーだった  Michael に合掌です。。。

初めての New SQL Data Services

Posted in Microsoft by Agile Cat on June 27, 2009

Eugenio Pace – Cloud Computing Guidance

Windows Azure のセールス・ポイントとして注目される New SDS ですが、Eugenio さんのブログで新しいポストを見つけました。 それと、以前の Eugenio さんの LitwareHR ですが、カテゴリ Eugenio Tracker に整理しましたので、そちらもご覧ください。   --- A.C.

Clouds: one thing we really know about here in Redmond, WA, USA
Published Friday, June 12, 2009 12:03 PM by eugeniop

Pasted from <http://blogs.msdn.com/eugeniop/archive/2009/06/12/first-experiments-with-new-sql-data-services.aspx>

First experiments with (new) SQL Data Services

 
Last week I got my new login to the new SQL Data Services. As a reminder for all readers:
SDS accelerates its plans to offer relational capabilities

May 11, 2009 – Based on customer feedback, SDS has accelerated its plans and will be offering true relational capabilities through SQL Server’s existing network protocol, Tabular Data Stream (TDS) and existing query language Transact-SQL (T-SQL). This will provide customers direct access to the familiar relational model, T-SQL programming language and the existing development and management tools, while continuing to deliver on our key value props of fault tolerance, high availability, friction free provisioning and pay as you grow scaling. For more information, see the SDS product site and the MSDN Library.

May 11, 2009 – カスタマー・フィードバックに基づき、SQL Server における既存のネットワーク・プロトコルである Tabular Data Stream(TDS)を介して、また、既存のクエリー言語である Transact-SQL(T-SQL)を介して、SDS の計画を加速し、本当のリレーショナル機能を実現していく。 そこで顧客に提供されるのは、T-SQL プログラミング言語と、開発と管理のための既存のツールで構成される、親しみのあるリレーショナル・モデルへのダイレクトなアクセスであるが、フォールト・トレランスと、高可用性、スケールの成長に応じたプロビジョニングと支払いなどへの、支援に関する提供は継続される。 詳細な情報については、SDS プロダクト・サイトと MSDN Library を見てほしい。

 

————————-

What I’ve done? After some initial “hello world-ish” tests, I wanted to try something more interesting so I decided to port IssueTracker into SDS.

私がしたことについて、説明しよう。 最初に行った何パターンかの “hello world-ish”  テストの後に、もっと面白いことをやりたいと思った。 そして、SDS で IssueTracker をポートすることに決めた。

As you know, IssueTracker was originally designed for SDS’ previous ACE model (Authority, Container, Entity), so my first task was to re-write the data access layer to use SQL Server.

皆が知っているように、IssueTracker は以前の SDS が提供していた、ACE モデル(Authority、Container、Entit)のためにデザインされたため、最初の作業は SQL Server をように、そのデータ・アクセスレイヤをリライトすることだった。

One of my goals in this experiment was to test SDS “impedance match” with on-premises SQL Server. Also, I wanted to develop independently of the availability of SDS. Not that SDS is unreliable, but currently it is available only inside Microsoft’s corporate network. I didn’t want to VPN into corpnet for this when working from home.

この実験における目的にひとつは、オンプレミスの SQL Server を用いた、SDS の  “impedance match”をテストすることにあった。また、SDS の可用性とは切り離されたところで、開発を行いたいと望んだ。 SDS が信頼できないということではないが、現時点においては、Microsoft のコーポレート・ネットワークの中だけで利用できるというものである。 そして、コーポレート・ネットワークに依存したくなかったのは、家でも仕事をするからだ。

So I chose to develop exclusively against my local SQL Express instance first and then make a switch to the real SDS.

そこで私が選んだのは、ローカルな SQL Express インスタンスで最初に作業した後に、本物の SDS にスイッチする形態である。

Fortunately, the app was designed with a couple of layers that isolated the persistence details, so writing the new data tier was a fairly mechanical process.

幸いなことに、このアプリケーションは永続的に分離される、2 つの層の組み合わせを用いてデザインされていたため、新しいデータ層の記述は、機械的なプロセスで進んだ。

This diagram roughly captures the architecture:

そのアーキテクチャについて、以下の図に示す:

New SDS 1The repository classes implement a common interface the app uses, the Model is just a collection of rather simple C# objects with no knowledge of the database being used. The Mappers are responsible for the transformations between the application model and the entities that do have knowledge of the database.

そのリポジトリ・クラスはアプリケーションが使う普通のインターフェイスを実装する。そして、この Model は単純な C# オブジェクトというより、単なるコレクションであり、データベースの知識は必要ない。 また、Mappers に課せられた責任は、アプリケーション・モデルと、データベースの知識を持つエンティティの間での変換となる。

In the diagram, classes marked with * are new, the numbers indicate variability points in the implementation, meaning that I can switch between one implementation and the other. Because I used LINQ to SQL, the types in the box labeled as “SQL Model” were generated automatically by the LINQ to SQL designer.

この図で、* マークが付いているのは新しいクラスであり、また、数が記されているのは、実装を切り替えられる可変のポイントである。 SQL に対して LINQ を使用したため、ボックス内に記された “SQL Model” であるというラベルは、LINQ to SQL デザイナーにより自動的に生成された。

When my unit tests compiled again, I switched the connection string to point from the “.\SQLEXPRESS” to the SDS instance in our network and…it worked! First attempt! 

単体テストのために再コンパイルしたとき、接続文字列のポイントを、 “.\SQLEXPRESS” から、ネットワーク上の SDS インスタンスに切り替えた。それが、そのまま動いた。 それが、最初のトライである!

New SDS 2

Overall, it was a rather painless and pleasant experience. Of course the data model in the app is simple and I’m not using any advanced queries or any sophisticated features in SQL yet.

もちろん、アプリケーションのデータモデルはシンプルであり、また、SQL の洗練されたクエリーや、先進的なキューは使っていない。

Things missing and Possible next steps:

The original implementation had 2 requirements that leveraged features in SDS previous ACE model:

1- Multi-tenant isolation: achieved through containers. Each tenant got its own container.

2- Schema flexibility: tenants could customize the application, extending the schema of some core entities. Flexible entities made this very easy, because they are essentially property bags.

このオリジナルの実装は、以前の SDS ACE モデルにおける 2つの機能を活用するという用件を持っていた:

1- Multi-tenant isolation: コンテナを介して達成されるものであり、それぞれのテナントが自身のコンテナを持つ。

2- Schema flexibility: いくつかのコア・エンティティを拡張することで、テナントによるアプリケーションのカスタマイズを実現する。柔軟なエンティティにより実現可能な理由は、それらが、本質的にプロパティ・バッグだからである。

For #1, I considered two options:

1- Partitioning by tenant
2- Do not partition at all and have all tenants on the same database (single-instance, multi-tenant)

#1 については、2つのオプションを検討した:

1-  テナントによるパーティショニング
2- パーティショニングは全く行わずに、すべてのテナントを同一のデータベース上に持つ(single-instance, multi-tenant)
The first option is fairly straight forward. Each tenant gets its own database that is created at provisioning time. The “tenant id” is part of the calling context in the application, so I dynamically connect to each database as needed. Two advantages of this approach: there’s high isolation between tenants (no data from one can leak into another), and the application code is simpler, because from the data perspective, the application is “single-tenant”.

最初のオプションは、かなり単刀直入なものである。 それぞれのテナントが、プロビジョニング時に作成される。自身のデータベースを取得する。 その “tenant id” が、アプリケーションにおけるコール・コンテキストの一部となるため、個々のデータベースとの動的な接続が、必要に応じて実現される。 このアプローチにおける のアドバンテージは、テナント間の分離が強化されることである。 また、アプリケーション・コードもシンプルになる。 その理由は、データの視点から見ると、対象となるアプリケーションが “single-tenant” になる点にある。

I haven’t implemented the extensibility feature yet, but I’m planning on reusing some techniques we did some research on in the past, probably through extension tables.

拡張された機能については、まだ実装していないが、いくつかのテクニックを再利用したいと考えている。それは、おそらく、過去において研究してきた、拡張テーブルを介したものとなるだろう。

There’re other interesting areas for research such as:


そのほかの、研究すべき領域としては、以下のような面白い分野がある:

1- Strategies for partitioning: in discussions with Ryan, he suggested I should consider more sophisticated ways of partitioning the information: by tenant, by tenant + project, etc. and I agree this would be interesting .

1- Strategies for partitioning:  Ryan とのディスカッションにおいて、情報のパーティショニングについて、もっと洗練された方式を考えるべきだとの示唆があった。それは、 by tenant や by tenant + project などであり、それらが興味深いものであることに、私は同意している。

2- Unit of Work: currently I’m simply reusing the original ACE implicit UoW that comes with each interaction. This is, each time you called Create, Delete or Update on SDS, the operation was completed in the context of a unit of work. You could not logically group multiple operation (say, 2 creates and 1 delete). This is suboptimal with the SQL implementation, because the new SDS supports transactions and I would like to leverage that.

2- Unit of Work: 現時点では、それぞれの相互作用に伴って生じる、オリジナルの ACE における暗黙の UoW を再利用しているだけである。 それは、SDS 上で Create/Delete/Update がコールされるたびに、unit of work のコンテキストの中で、オペレーションが完了するというものだ。 多数のオペレーションを、論理的にまとめることはできない(たとえば、2つの create と、1つの delete)。 それが、SQL 実装における次善である。なぜなら、新しい SDS がサポートするトランザクションを、活用したいと思っているからだ。

3- Performance and scalability issues: I haven’t spent any time looking at the application’s “chattiness” with the database that might lead to degraded performance, or any other data access optimizations. This is a whole area in itself, but not very different from “regular” application development. The only exception perhaps is that, in theory at least, the app and the database can be hosted in different datacenters (say the app in Amazon and the data in SDS). I’m not sure that would be a good idea anyway, probably not for this scenario. If the app was hosted in Windows Azure and used SDS, then they would be close in terms of network distance (low latency & high bandwidth). 

3- Performance and scalability issues: このアプリケーションとデータベースの間での “chattiness” については、時間を割いてこなかった。そのため、パフォーマンスの低下を招いているかもしれないし、データアクセスの最適化が必要かもしれない。 それは、アプリケーションの全域におよぶものであるが、“regular”  なアプリケーション開発と、そう変わるものでもない。 唯一の例外と思われるのは、少なくとも理論上において、アプリケーションとデータベースが別のデータセンターにホストされる可能性があることだ(たとえば、アプリケーションは Amazonで、データは SDS)。 それが適切な考え方だとは、確信していない。そして、このシナリオのためのものでもない。 このアプリケーションが Windows Azure 上にホストされ SDS を使うなら、ネットワーク・ディスタンスの観点から、両者の距離は近いものとなる(low latency & high bandwidth)。

Published Friday, June 12, 2009 12:03 PM by eugeniop

Pasted from <http://blogs.msdn.com/eugeniop/archive/2009/06/12/first-experiments-with-new-sql-data-services.aspx>

Tagged with: , , ,

Nicholas Carr vs. Google

Posted in Google, Nicholas Carr by Agile Cat on June 26, 2009

Nicholas Carr 対 Google の熾烈な戦い

どうも Google がビットマップを使った広告を画策しているらしい、、、という情報をつかんだ Nicholas Carr さん、そんな非人道的な Google で良いのでしょうかと、ROUGHTYPE で強烈な噛み付き

なんでも、2001年には、心臓に病気を持つ人が  、他の検索エンジンで病院を探したところ、バナーのダウンロードでページが開かず、Google に切り替えて一命を取り留めたとか、、、 そんなエピソードを持ち出してキャンペーンを展開。

「いまでも、ダイアルアップで Google を使う人が、世界中にたくさんいるんです!」

そうしたら、Google site:roughtype.com を消されてしまったとのことです。(Google site:agilecat.wordpress.com でさえあるのだから、いくら何でも、それはまずいでしょう。。。)

googlesearch-thumb

そこで Caar さん、命乞いならぬ、Google 乞い。決め手は「もう Bing は使いません」の一言。

そして、めでたく、Google site:roughtype.com は復帰しましたと。。。

 

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: ,
          %d bloggers like this: