Relational Databases Are Not Designed For Scale(拡張向けに設計されていないリレーショナルデータベース)

リレーショナルデータベースは、テーブルマッピングの整合性を維持し、分散コンピューティングの問題を回避するために、1台のサーバー上で実行するように設計されています。

私たちは今、データ量について転換点を迎えています。前の記事で、デジタルユニバースが2013年の4.4ゼタバイトから、2020年には44ゼタバイトに増加する見込みであるというEMCの統計を紹介しました(参考までに、ゼタバイトは1兆ギガバイトです)。これは、ホッケースティック型の急増であり、私たちはこのカーブの最初の部分にいます。組織には、数百万人のユーザーと数ペタバイトのデータがあります。また、クラウド内でアプリケーションを実行しており、さまざまな場所にある数百台ものデスクトップ、タブレット、モバイルデバイスに対して動的コンテンツを提供しています。

今日のビジネスのデジタル化

今ではもはや、紙のファイルは記録システムではなく、データベースにすべてを保存するという大きな変化が生じています。私は以前、大規模な政府機関の製品管理を担当しており、そこでかなり大きな「最新化」への取り組み(業務変革プロジェクト-概要はこちら)を経験しています。その取り組みには、旧式の紙ベースのプロセス(ドキュメントをFAXするなりスキャンするなりしてレガシーメインフレームやリレーショナルデータベースに保存するような作業)から、すべてをオンデマンドで電子的に実行するプロセスへの移行作業も含まれていました。このような政府機関ではかつて、ドキュメントから少数の主要項目を電子的に保存していましたが、こうした変革によって、現在では各フォーム、レター、規制、プロファイル、メール、通話、チャット、調査、意思決定などのすべてのデータを保存する必要が生じています。


デジタル変革


こうした変革は、あらゆる業界で過去または現在において発生しています。現在のビジネスの運営方法は、10年前とはまったく異なっています。紙の記録に大きく依存していた時代から、私たちは転換期を経験しているのです。成功を収めている企業は現在、業務のあらゆるものをデジタル化しています。『Leading Digital(デジタルへの導き)』という書籍では、「デジタルマスター」である組織(テクノロジーを上手に活用してビジネスを変革している組織)を対象として実施した調査について説明しています。こうした組織は、同業者よりも26%多い利益幅を達成しています。

ビジネスのあらゆるものをオンラインで実行する必要があるという、こうした新たな現実に対処するには、拡張性(データやユーザーの増加に伴う容量の追加)に加え、弾力的な拡張性(システムの拡張しやすさ。通常はユーザーの需要が消失した場合に縮小できる機能を示す)が必要になります。

リレーショナルデータベースの拡張は困難

拡張性と、弾力的な拡張性の実現は、リレーショナルデータベースにとっての大きな課題です。リレーショナルデータベースは、データが小容量で整理され、規則に従って作成されている時代に設計されたものであり、もはや状況は異なっています。すべてのデータベースベンダーは、大規模な拡張が可能であると主張しています。生き残るためには、そうする必要があるのです。しかし、実際に機能しているものとしていないものを詳しく見てみると、リレーショナルデータベースの基本的な問題がより明確になってきます。


デジタル変革

リレーショナルデータベースは、高コストの単一マシン上で拡張できるように設計されています


リレーショナルデータベースは、テーブルマッピングの整合性を維持し、分散コンピューティングの問題を回避するために、1台のサーバー上で実行するように設計されています。こうした設計では、システムの拡張が必要になると、処理能力が高く、より大容量のメモリとストレージを備えた大型で複雑な高コストの専有ハードウェアを、お客様が購入する必要が生じます。さらに、アップグレードも課題となります。取得プロセスに時間がかかるうえ、実際に変更するには、通常、システムをオフラインにする必要があるためです。これらすべてが、ユーザー数が増加し続けている最中で発生するため、リソース不足の環境では、負担とリスクがより一層増加します。

新しいアーキテクチャへの変更は内在している問題を隠すのみ

こうした懸念事項に対応するため、リレーショナルデータベースのベンダーはさまざまな改善を行った製品を市場に導入しています。現在、リレーショナルデータベースの進化により、従来よりも複雑なアーキテクチャを使用できるようになり、「マスタースレーブ」モデルを使用できるようになりました。「スレーブ」は追加サーバーであり、並列処理やレプリケーションデータに加え、「分断されている」(複数のサーバーやホストに分割および分散されている)データを処理して、マスターサーバーのワークロードを軽減できます。

共有ストレージ、インメモリ処理、レプリカの有効活用、分散キャッシュをはじめとしたリレーショナルデータベースのその他の機能の強化と、新しい「革新的な」アーキテクチャにより、リレーショナルデータベースの拡張性は確実に向上しています。しかし、単一システムや単一障害点を見つけることは、難しいことではありません(例えば、Oracle RACはクラスタ認識型のファイルシステムを使用する「クラスタ化された」リレーショナルデータベースですが、依然として共有ディスクサブシステムが存在しています)。通常、こうしたシステムは非常にコストが高く、単一のデータウェアハウスをセットアップすると、たやすく百万ドルを超えます。

リレーショナルデータベースの機能の強化は、同時に多大なトレードオフを生じさせています。例えば、データがリレーショナルデータベースに分散される際には、パフォーマンスを維持するために、通常は事前定義されたクエリに基づいて分散されます。言い換えると、パフォーマンスを確保するために柔軟性が犠牲にされます。

また、リレーショナルデータベースは縮小できる設計になっておらず、弾力性に欠けています。データが分散され、追加スペースが割り当てられると、そのデータを「再分散」することはほぼ不可能になります。

拡張向けに設計されているNoSQLデータベース


デジタル変革

MarkLogicは拡張性と弾力的な拡張性を実現するよう設計されています


NoSQLデータベースは、単一サーバーアーキテクチャの制限に縛られることなく、分散システムに大規模に拡張できるよう設計されています(通常は数十ギガバイトではなく数百テラバイト)。NoSQLデータベースは「水平拡張(スケールアウト)」、つまり、複数のサーバーを連携して実行し、各サーバーに負荷の一部を担当させることが可能です。

このアプローチを用いて、NoSQLデータベースは数百台のサーバー、数ペタバイトのデータ、数十億件のドキュメントを運用できるほか、毎秒数万件のトランザクションの処理を管理できます。さらにこれらすべてを、あらゆる環境(クラウド向けに最適化された環境)で低コストの(より安価な)コモディティハードウェアを使用して実行できます。もう1つの利点は、1つのノードに障害が発生すると、他のノードがワークロードを引き受けるため、単一障害点をなくすことができるという点です。

大規模な拡張はすばらしいものですが、さらに重要なのは弾力的な拡張性です。NoSQLデータベースのすべてに、弾力的な拡張性が備わっているわけではありません。MarkLogicには、データベースがパフォーマンスのニーズに継続的に対応できるようにするため、クラスタ内でノードを迅速かつ簡単に追加または削除できる独自のアーキテクチャがあります。データの複雑な分断やアーキテクチャの回避策は不要であり、ノードの追加や削除が行われるとデータがクラスタに自動的にリバランシング(再分配)されます。そのため管理が非常に簡単になり、DBAがそれ自体でデータを管理することで問題を減らすことができます。


このシリーズの次のブログでは、リレーショナルデータベースが混合ワークロード向けに設計されていない理由について説明していますので、ご一読ください。また、『Beyond Relational(リレーショナルを超えて)』というホワイトペーパーをダウンロードして、リレーショナルデータベースが機能しない理由についての詳細をご確認ください。

このシリーズの記事の一覧は、以下のとおりです。

  1. 変更処理向けに設計されていないRDBMS
  2. 混合データ向けに設計されていないRDBMS
  3. 拡張向けに設計されていないRDBMS
  4. 混合ワークロード向けに設計されていないRDBMS
  5. 最新のアプリケーション開発には適していないRDBMS