Nicholas Carr vs. Google

Nicholas Carr 対 Google の熾烈な戦い

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

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

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

そうしたら、Google site:roughtype.com を消されてしまったとのことです。

（Google site:agilecat.wordpress.com でさえあるのだから、いくら何でも、それはまずいでしょう。。。）

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

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

 

 

Database Sharding _2

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