リレーショナルデータベースは運命づけられていますか？

翻訳者のメモ：この記事は非常に古く（2年前に公開された）有名ですが、リレーショナルデータベースとNoSQLデータベースの違い、それらの長所と短所、および非リレーショナルリポジトリの簡単な概要も提供します。

最近、多くの非リレーショナルデータベースが登場しました。 これは、オンデマンドで実質的に無制限のスケーラビリティが必要な場合、非リレーショナルデータベースが必要であることを示唆しています。



これが当てはまる場合、これは強力なリレーショナルデータベースが脆弱になったことを意味しますか？ これは、リレーショナルデータベースの時代が過ぎ去り、まもなく完全に過ぎ去ることを意味しますか？ この記事では、さまざまな状況に関連した非リレーショナルデータベースの一般的な傾向を検討し、これがリレーショナルデータベースの将来に影響を与えるかどうかを確認します。



リレーショナルデータベースは約30年前から存在しています 。 この間に、いくつかの革命が勃発し、リレーショナルリポジトリを終わらせることになっていた。 もちろん、これらの革命はどれも起こらず、そのうちの1つはリレーショナルデータベースの位置を揺るがしませんでした。

基本から始めましょう

リレーショナルデータベースは、テーブル（エンティティ）のコレクションです。 テーブルは列と行（タプル）で構成されます。 制約はテーブル内で定義でき、テーブル間に関係が存在します。 SQLを使用すると、1つ以上のテーブルから取得したデータセットを返すクエリを実行できます。 1つのクエリでは、複数のテーブルからデータを結合（JOIN）して取得します。ほとんどの場合、同じ列を使用して結合し、テーブル間の関係を決定します。 正規化は、データの接続性と冗長性の欠如を提供するデータモデルを構造化するプロセスです。







リレーショナルデータベースへのアクセスは、 リレーショナルデータベース管理システム （RDBMS）を介して行われます 。 私たちが使用するほとんどすべてのデータベースシステムは、Oracle、SQL Server、MySQL、Sybase、DB2、TeraDataなどのリレーショナルシステムです。



この優位性の理由は明らかではありません。 リレーショナルデータベースの存在を通じて、データ管理の分野でシンプルさ、安定性、柔軟性、パフォーマンス、拡張性、互換性の最良の組み合わせを常に提供してきました。



ただし、これらの機能をすべて提供するために、リレーショナルストアは内部で非常に複雑です。 たとえば、単純なSELECTクエリには、クエリの実行中にオプティマイザが直接評価する潜在的な実行パスが何百もある場合があります。 これらはすべてユーザーから隠されていますが、RDBMS内では、コスト計算アルゴリズムなどに基づいて実行計画を作成し、それが要求に最も適合します。

リレーショナルデータベースの問題

リレーショナルストレージは、シンプルさ、安定性、柔軟性、パフォーマンス、スケーラビリティ、互換性の最適な組み合わせを提供しますが、これらの各アイテムのパフォーマンスは、特定の機能に焦点を当てた同様のシステムのパフォーマンスよりも必ずしも高いとは限りません。 リレーショナルDBMSの全体的な優位性が欠陥を上回っているため、これは大きな問題ではありませんでした。 ただし、従来のRDBがニーズを満たしていない場合、代替手段が常に存在していました。



今日、状況は少し異なります。 さまざまなアプリケーションが成長しており、それに伴い、これらの機能の重要性が高まっています。 データベースの数が増えると、1つの機能が他のすべての機能を覆い隠し始めます。 これがスケーラビリティです。 Webサービスなどの高負荷条件下で動作するアプリケーションが増えるにつれて、スケーラビリティ要件は急速に変化し、急速に拡大する可能性があります。 独自のサーバーにリレーショナルデータベースがある場合、最初の問題を解決するのは非常に困難です。 サーバーの負荷が一晩で3倍になったとします。 ハードウェアをどれくらい速くアップグレードできますか？ 2番目の問題の解決策は、リレーショナルデータベースを使用する場合にも問題を引き起こします。



リレーショナルデータベースは、単一のサーバー上にある場合にのみ適切に拡張されます。 このサーバーのリソースが不足した場合、さらにマシンを追加し、それらの間で負荷を分散する必要があります。 そして、ここでリレーショナルデータベースの複雑さがスケーラビリティに反し始めます。 サーバーの数を数台ではなく、数百台または数千台に増やすと、複雑さが一桁大きくなり、リレーショナルデータベースを魅力的なものにする特性が急速に低下し、大規模な分散システムのプラットフォームとして使用される可能性がなくなります。



競争力を維持するために、クラウドサービスベンダーはこの制限に何らかの方法で対処する必要があります。これは、スケーラブルなデータストレージを持たないクラウドプラットフォームの種類だからです。 したがって、データを格納するスケーラブルな場所をユーザーに提供する場合、ベンダーには1つのオプションしかありません。 リレーショナルデータベースで利用可能な他の機能を犠牲にしてはいますが、スケーラビリティの高い他の種類のデータベースを使用する必要があります。



これらの利点は、それらに対する既存の需要とともに、新しいデータベース管理システムの波をもたらしました。

ニューウェーブ

このタイプのデータベースは、一般にキー値ストアと呼ばれます。 実際、正式な名前はないので、ドキュメント指向、属性指向、 分散データベース （リレーショナルでも可能）、シャードソート配列、 分散ハッシュテーブル 、ストレージのコンテキストで見つけることができます。キー値タイプ。 また、これらの名前はそれぞれシステムの特定の機能を示していますが、それらはすべてキーバリューストレージと呼ばれるトピックのバリエーションです。



しかし、あなたがそれを何と呼んでも、この「新しい」タイプのデータベースはそれほど新しいものではなく、主にリレーショナルデータベースの使用が不適切なアプリケーションに主に使用されてきました。 ただし、スケーラビリティのためにWebとクラウドを必要とせずに、これらのシステムはあまり需要がありませんでした。 ここでのタスクは、特定のシステムに適したストレージのタイプを決定することです。

リレーショナルデータベースとキーバリューストレージは根本的に異なり、さまざまな問題を解決するように設計されています。 特性の比較では、特性の違いを理解することしかできませんが、これから始めましょう。



ストレージ機能

リレーショナルデータベース	キーバリューストレージ
データベースはテーブルで構成され、テーブルには列と行が含まれ、行は列の値で構成されます。 1つのテーブルのすべての行には、単一の構造があります。	ドメインの場合、テーブルとの類似性を引き出すことができますが、ドメインのテーブルとは異なり、データ構造は定義されていません。 ドメインとは、好きなものを入れることができるボックスです。 同じドメイン内のエントリは、異なる構造を持つことができます。
データモデル1は事前定義されています。 強く型付けされ、データの整合性を確保するための制限と関係が含まれています。	レコードはキーで識別され、各レコードにはそれに関連付けられた動的な属性セットがあります。
データモデルは、アプリケーションの機能ではなく、含まれるデータの自然な表現に基づいています。	一部の実装では、属性は文字列のみです。 他の実装では、属性には、プログラミングで使用される型（整数、文字列の配列、リスト）を反映する単純なデータ型があります。
データモデルは、データの重複を避けるために正規化されます。 正規化により、テーブル間の関係が生まれます。 リレーションは、異なるテーブルのデータを関連付けます。	ドメイン間および同じドメイン内では、関係は明確に定義されていません。

参加しない

キーバリューストレージはレコード指向です。 これは、このレコードに関連するすべての情報が一緒に保存されることを意味します。 ドメイン（テーブルと考えることができます）には、無数の異なるレコードを含めることができます。 たとえば、ドメインには顧客と注文に関する情報が含まれる場合があります。 つまり、データは通常、異なるドメイン間で複製されます。 ディスク容量が安いため、これは受け入れられるアプローチです。 主なことは、関連するすべてのデータを1か所に保存できることです。これにより、異なるテーブルのデータを結合する必要がなくなるため、スケーラビリティが向上します。 リレーショナルデータベースを使用する場合、接続を使用して必要な情報を1か所にグループ化する必要があります。







キーと値のペアを保存するための関係の必要性は劇的に低下しますが、関係は依然として必要です。 このような関係は通常、コアエンティティ間に存在します。 たとえば、注文システムには、顧客、製品、注文に関するデータを含むレコードがあります。 このデータが同じドメインにあるか、複数のドメインにあるかは関係ありません。 一番下の行は、買い手が注文するときに、ほとんどの場合、買い手と注文に関する情報を1つのレコードに保存したくないということです。

代わりに、注文入力には、対応する顧客および製品レコードを指すキーが含まれている必要があります。 情報はレコードに格納でき、データモデル自体には関係が定義されていないため、データベース管理システムは関係の整合性を制御できません。 これは、顧客と注文した製品を削除できることを意味します。 データの整合性の確保は、アプリケーションに完全にかかっています。



データアクセス

リレーショナルデータベース	キーバリューストレージ
データは、構造化照会言語（SQL）を使用して作成、更新、削除、および照会されます。	APIメソッド呼び出しを使用して、データが作成、更新、削除、および照会されます。
SQLクエリは、接続（結合）を使用して、単一のテーブルまたは複数のテーブルの両方からデータを取得できます。	一部の実装は、フィルター条件を設定するためのSQLのような構文を提供します。
SQLクエリには、集計と複雑なフィルターを含めることができます。	多くの場合、基本的な比較演算子（= 、! =、<、>、<= And =>）のみを使用できます。
通常、リレーショナルデータベースには、トリガー、ストアドプロシージャ、関数などの埋め込みロジックが含まれています。	すべてのビジネスロジックとデータの整合性をサポートするロジックは、アプリケーションコードに含まれています。

アプリケーションの相互作用

リレーショナルデータベース	キーバリューストレージ
ほとんどの場合、OLE DBやODBCなどのネイティブAPIが使用または一般化されています。	ほとんどの場合、データへのアクセスにはSOAPおよび/またはREST APIが使用されます。
データは自然な構造を表示する形式で保存されるため、アプリケーション構造とリレーショナルデータベース構造のマッピングが必要です。	アプリケーションの構造内でデータをより効率的に表示できます。オブジェクトにデータを書き込むために必要なのはコードのみです。

Key-Valueストレージ：利点

このようなシステムには、リレーショナルストレージに比べて2つの明確な利点があります。

クラウドサービスに適しています

キーと値のストレージの最初の利点は、シンプルなことです。つまり、リレーショナルデータベースよりも拡張性が高いことです。 独自のシステムを一緒にホストし、データウェアハウスの背後で、増加する負荷に対処する必要のある数十または100台のサーバーをホストする計画がある場合、キーバリューストレージが選択されます。



このようなストレージは簡単かつ動的に拡張されるため、マルチユーザーWebストレージプラットフォームを提供するベンダーにも役立ちます。 このようなデータベースは、データストレージの比較的安価な手段であり、スケーラビリティの大きな可能性があります。 ユーザーは通常、使用した分だけ料金を支払いますが、ニーズは増大する可能性があります。 ベンダーは、負荷に基づいて、プラットフォームのサイズを制限なく動的かつ実際的に増やすことができます。

より自然なコード統合

リレーショナルデータモデルとコードオブジェクトモデルは、通常、さまざまな方法で構築されます。これにより、非互換性が生じます。 開発者は、リレーショナルモデルをオブジェクトモデルにマッピングするコードを記述することにより、この問題を解決します。 このプロセスには明確で迅速に達成できる価値はなく、アプリケーション自体の開発に費やすことができるかなりの時間がかかる可能性があります。 一方、多くのキーバリューストアは、より自然にオブジェクトにマッピングされる構造でデータを保存します。 これにより、開発時間を大幅に短縮できます。



「リレーショナルデータベースが不器用になる可能性がある」などの、キーと値のストレージを使用することを支持する他の議論（これはどういう意味かわかりません）はあまり説得力がありません。 しかし、そのようなリポジトリの提案者になる前に、次のセクションをチェックしてください。

Key-Valueストレージ：欠点

リレーショナルデータベースの制約は、最低レベルでのデータの整合性を保証します。 物理的に制限を満たさないデータは、データベースにアクセスできません。 キーと値のストレージにはこのような制限はないため、データ整合性の制御は完全にアプリケーションにあります。 ただし、コードにはエラーがあります。 通常、正しく設計されたリレーショナルデータベースのエラーがデータの整合性の問題につながらない場合、キー値ストアのエラーは通常そのような問題につながります。



リレーショナルデータベースのもう1つの利点は、データモデルの開発プロセスを強制的に実行することです。 モデルを適切に設計した場合、データベースには、格納されたデータの構造を完全に反映するが、アプリケーションの構造とは異なる論理構造が含まれます。 したがって、データはアプリケーションに依存しなくなります。 これは、別のアプリケーションが同じデータを使用でき、ベースモデルを変更せずにアプリケーションロジックを変更できることを意味します。 キーと値のストレージで同じことを行うには、リレーショナルモデルを設計するプロセスを、自然なデータ構造に基づいて共通のクラスを作成するクラス設計に置き換えてみてください。



互換性についても忘れないでください。 リレーショナルデータベースとは異なり、クラウド中心のストレージには一般的な標準がはるかに少ない。 概念的には違いはありませんが、それらはすべて異なるAPI、クエリインターフェイス、および独自の仕様を持っています。 したがって、ベンダーを信頼する方が適切です。その場合、別のサービスプロバイダーに簡単に切り替えることができないためです。 そして、ほとんどすべての最新のキーバリューストアがベータ²にあるという事実を考えると、信頼はリレーショナルデータベースを使用する場合よりもさらに危険になります。

限定的なデータ分析

通常、すべてのクラウドストレージは、 複数のリースのタイプに基づいて構築されます。つまり、同じシステムが多数のユーザーとアプリケーションによって使用されます。 システム全体の「キャプチャ」を防ぐために、ベンダーは通常、リクエストの実行を何らかの形で制限します。 たとえば、SimpleDBでは、クエリを5秒より長く実行することはできません。 Google AppEngine Datastoreでは、1回のリクエストで1000件を超えるレコードを取得することはできません³ 。



これらの制限は、単純なロジック（少数のレコードの作成、更新、削除、および取得）にとって怖いものではありません。 しかし、アプリケーションが人気になったらどうでしょうか？ たくさんの新しいユーザーとたくさんの新しいデータを手に入れたので、今度はユーザーに新しい機会を提供するか、何らかの形でデータを活用したいと考えています。 ここでは、データ分析のための単純なクエリでさえ、分割するのが難しい場合があります。 アプリケーションの使用パターンの追跡や、ユーザーの履歴に基づいた推奨システムなどの機能は、実装が困難な場合があります。 そして最悪の場合、それらは単に不可能です。



この場合、分析のために、キーと値のストレージからのデータが入力される別のデータベースを作成することをお勧めします。 これをどのように行うことができるかを事前に考えてください。 サーバーをクラウドまたは自宅でホストしますか？ あなたとあなたのプロバイダーとの間の信号遅延による問題はありますか？ ストレージはそのようなデータ転送をサポートしていますか？ 1億件のレコードがあり、一度に1,000件のレコードを取得できる場合、すべてのデータを転送するにはどれくらいかかりますか？



ただし、スケーラビリティを優先しないでください。 ユーザーが別のサービスのサービスを使用することに決めた場合は、より多くのオプションと設定が提供されるため、役に立ちません。

クラウドストレージ

多くのWebサービスプロバイダーは、マルチテナントのキーと値のストレージを提供しています。 それらのほとんどは上記の基準を満たしていますが、それぞれに独自の特徴があり、上記の標準とは異なります。 SimpleDB、Google AppEngine Datastore、SQL Data Servicesなどの特定のサンプルリポジトリを見てみましょう。

Amazon：SimpleDB

SimpleDBは、Amazon WebServicesの一部である属性ベースのキーと値のストレージです。 SimpleDBはベータ版です。 ユーザーは、ニーズが特定の制限を超えない限り、無料で使用できます。



SimpleDBにはいくつかの制限があります。 まず、クエリの実行時間は5秒に制限されています。 第二に、文字列以外のデータ型はありません。 すべてが文字列として保存、取得、比較されるため、日付を比較するには、それらをISO8601形式に変換する必要があります。 3番目に、行の最大サイズは1024バイトです。これにより、属性として保存できるテキストのサイズ（製品の説明など）が制限されます。 ただし、データ構造は柔軟であるため、属性「Product Description1」、「Product Description2」などを追加することにより、この制限を回避できます。 ただし、属性の数も制限されています-最大256個の属性。 SimpleDBはベータ版ですが、ドメインサイズは10ギガバイトに制限されており、データベース全体が1テラバイトを超えることはできません。



SimpleDBの重要な機能の1つは、 結果整合性モデルの使用です。 このモデルはマルチスレッド作業に適していますが、一部のレコードの属性値を変更した後、これらの変更は後続の読み取り操作で表示されない可能性があることに注意してください。 このようなイベントの発生の可能性は非常に低いですが、覚えておく必要があります。 販売時にデータに一貫性がなかったという理由だけで、最後のチケットを5人の顧客に販売したくありません。

Google AppEngineデータストア

GoogleのAppEngine Datastoreは 、 Googleの内部構造化データストレージシステムであるBigTableの上に構築されています。 AppEngine DatastoreはBigTableへの直接アクセスを提供しませんが、BigTableとやり取りするための単純化されたインターフェイスとして認識できます。



AppEngine Datastoreは、単一レコード内でSimpleDBよりも多くのデータ型をサポートしています。 たとえば、レコード内にコレクションを含むリスト。



ほとんどの場合、Google AppEngineを使用して開発するときに、この特定のデータウェアハウスを使用します。 ただし、SimpleDBとは異なり、Googleのウェブサービス以外ではAppEngine Datastore（またはBigTable）を使用できません。

Microsoft：SQL Data Services

SQL Data Servicesは、Microsoft Azureプラットフォームの一部です。 SQL Data Servicesは無料でベータ版であり、データベースサイズの制限があります。 SQL Data Servicesは独立したアプリケーションです。データを保存する多くのSQLサーバーのアドオンです。 これらのストレージはリレーショナルにすることができますが、SDSはキーバリューストレージであり、上記の製品でもあります。

クラウドストレージ

また、クラウドの外部で独自にインストールすることで使用できるストレージも多数あります。 これらのプロジェクトのほとんどすべては若く、アルファ版またはベータ版であり、オープンソースです。 オープンソースを使用すると、おそらくクローズド製品よりも潜在的な問題や制限をよりよく理解するでしょう。

Couchdb

CouchDBは、無料のオープンソースのドキュメント指向データベースです。 データストレージ形式として、JSONが使用されます。 CouchDBは、「ビュー」を使用してドキュメント指向データベースとリレーショナルデータベースのギャップを埋めるように設計されています。 このようなビューには、表のような形式のドキュメントのデータが含まれており、インデックスを作成してクエリを実行できます。



CouchDBは現在 、真に分散されたデータベースではありません。 サーバー間でデータを同期できるレプリケーション機能がありますが、これは非常にスケーラブルな環境を構築するために必要なものと同じディストリビューションではありません。 ただし、CouchDB開発者はこれに取り組んでいます。

ヴォルデモートプロジェクト

Voldemortプロジェクトは、多数のサーバーでの水平スケーリング用に設計された分散Key-Valueデータベースです。 LinkedInの開発プロセスで生まれたこの製品は、高いスケーラビリティが要求されるいくつかのシステムで使用されていました。 ヴォルデモートプロジェクトでは、有限一貫性モデルも使用しています。

モンゴ

Mongoは、Geir MagnussonとDwight Merriman（DoubleClickから知ることができる）によって10genで開発されたデータベースです。 CouchDBと同様に、MongoはデータをJSON形式で保存するドキュメント指向のデータベースです。 ただし、Mongoは純粋なキー値ストレージよりもオブジェクトベースである可能性が高くなります。

ドライブン

Drizzleは、Key-Valueストアが対処するために設計された問題を解決するためのまったく異なるアプローチを提示します。 Drizzleは、MySQL 6.0ブランチの1つとして始まりました。 開発者は後で、よりシンプルで高速なDBMSを作成する目的で、多くの関数（ビュー、トリガー、コンパイル式、ストアドプロシージャ、クエリキャッシュ、ACL、および一部のデータ型を含む）を削除しました。 ただし、Drizzleはリレーショナルデータの保存に引き続き使用できます。 開発者の目標は、16以上のコアを持つシステムで実行されるWebアプリケーションおよびクラウドアプリケーション向けに設計された準リレーショナルプラットフォームを構築することです。

解決策

最終的に、アプリケーションに非リレーショナルキーバリューストレージを選択できる理由は4つあります。

1. データはドキュメント指向性が高く、リレーショナルモデルよりもキーバリューデータモデルにより適しています。
2. ドメインモデルは高度にオブジェクト指向であるため、キー値ストレージを使用すると、データ変換用の追加コードのサイズが削減されます。
3. データウェアハウスは、ベンダーのWebサービスと安価かつ簡単に統合できます。
4. 主な関心事は、オンデマンドでの高いスケーラビリティです。

ただし、決定を行う際には、特定のデータベースの制限と、非リレーショナルデータベースを使用することを選択する際に遭遇するリスクに注意してください。



他のすべての要件については、古き良きリレーショナルDBMSを選択することをお勧めします。 それで彼らは運命づけられているのでしょうか？ もちろん違います。 少なくともまだ。

---

^1-私の意見では、ここでは「データ構造」という用語の方が適していますが、元のデータモデルはそのままです。

^2-おそらく、著者は、非リレーショナルデータベースの機能がリレーショナルデータベースよりも劣っていることを念頭に置いていました。

^3-データはすでに古くなっている可能性があります。記事の日付は2009年2月です。