ここから本文です

デジタル変革とデータベースのスケーラビリティ

12/5(火) 17:45配信

@IT

 私たちは今、データ量についての転換点を迎えています。デジタルの世界は2013年の4.4ゼタバイトから、2020年には44ゼタバイトに増加する見込みです(ゼタバイトは1兆GB)。これは、ホッケースティック型の急増であり、私たちはこのカーブの最初の部分にいます。多くの組織が運用しているサービスは、数百万人のユーザーと数ペタバイトのデータを対象としています。また、クラウドでアプリケーションを実行しており、さまざまな場所にある数百台ものデスクトップ、タブレット、モバイルデバイスに対してダイナミックなコンテンツを提供しています。

●デジタル化でスケーラビリティが重要に

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

 こうした変革は、あらゆる業界で発生しています。現在のビジネスの運営方法は、10年前とは全く異なっています。紙の記録に大きく依存していた時代から、私たちは大きく変わりました。成功を収めている企業は現在、あらゆる業務をデジタル化しています。

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

●リレーショナルデータベースの拡張における課題

 スケーラビリティと、弾力的な拡張性(エラスティシティ)の実現は、リレーショナルデータベースにとって大きな課題です。リレーショナルデータベースは、データが少量できれいに整理され、規則に従っていた時代に設計されましたが、もはや状況は異なっています。全てのデータベースベンダーは、大規模な拡張が可能であると主張しています。競争に勝ち残るためには、当然そのように主張するでしょう。しかし、実際にできることとできないことを詳しく見てみると、リレーショナルデータベースの基本的な問題がより明確になってきます。

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

●リレーショナルデータベースは進化している、だがバラ色ではない

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

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

 リレーショナルデータベースの機能強化には、トレードオフもあります。例えば、データをリレーショナルデータベースで分散する際、パフォーマンスを維持するために、通常は事前定義されたクエリを利用します。つまり、パフォーマンスのために柔軟性が犠牲にされます。

 また、リレーショナルデータベースはその設計上、縮退ができません。データがいったん分散された後に容量を追加した場合、そのデータの「分散をやめて元に戻す」ことはほぼ不可能です。

●NoSQLデータベースは拡張で有利

 NoSQLデータベースは、シングルサーバアーキテクチャに制約されることなく、分散システム上で大規模拡張できるよう設計されています(通常は数十GBではなく数百TB)。NoSQLデータベースは「水平拡張(スケールアウト)」です。つまり、複数のサーバを連携して実行し、各サーバが負荷を分担します。

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

 大規模な拡張は素晴らしいものですが、さらに重要なのは「弾力的な拡張性」(エラスティシティ)です。NoSQLデータベースの全てに弾力的な拡張性が備わっているわけではありませんが、例えばMarkLogicには、クラスタ内でノードを迅速かつ簡単に追加・削除できる独自のアーキテクチャがあります。これはデータの複雑な分散やアーキテクチャによる回避策などではなく、ノードの追加や削除が行われるとデータがクラスタ全体に自動的にリバランス(再分配)されるようになっています。

●筆者紹介
○マット・アレン(Matt Allen)
 MarkLogic 米国本社プロダクトマーケティングマネージャー/ディレクター。MarkLogicのあらゆる機能とメリットに関するマーティング活動を、業界の別なく行う。製品/エンジニアリングのチームとセールス/マーケティングの間を取り持ち、MarkLogicに関する教育活動および啓蒙活動のためのコンテンツやイベントを担当する

最終更新:12/5(火) 17:45
@IT