2015-08-19

この記事は機械翻訳されたものです。

データポイント

ドキュメントデータベースとは (機械翻訳)

Julie Lerman

Julie Lerman 少なくとも聞いた可能性が高い用語 NoSQL ここの。記事でも書き込みが、ここで MSDN Magazine。非常に尊重する人の多くはそれについて非常に興奮し、成長してリレーショナルデータベースにきたこと私の理解を深める必要としていました。研究のかなりのビットと友人の頭の周りをラップする pestering が行ったし、ここで私は NoSQL データベースの"データベースを文書化します] という名前のサブセットに関する学習内容をご説明別のキーと値のペアのデータベースです。 Windows Azure テーブル私について [2010年 7 月データポイント列に書き込んだストレージを (msdn.microsoft.com/magazine/ff796231)、NoSQL ストアキー-値のペアの例に示します。

私最初 NoSQL の定義を扱う必要があります。それは普及しているし、可能性のある過多の用語のとなっています。関係がなく、したがって、データにアクセスするために SQL を使用してを必要としないデータストレージメカニズムを総称する用語です。ブログの投稿「NoSQL 批判のアドレス指定」(bit.ly/rkphh0)、CouchDB の専門家であり著者有沢利治 Holt という彼「NoSQL 'SQL はありません ' として再定義"の人々聞いたこと彼のポイントはこれではないことです、 アンチ・ SQL による移動します。ジョブに適切なツールを使用するのには、大きな信じて私は、私この観点では、好きです。

非リレーショナルの包括的な共有共通の目標速度とスケーラビリティ] の下に分類されるほとんどのデータベースを指定します。リレーショナルストレージモデルを分割してスキーマの背後のままにすることで、これらのデータベースは、時に密接に結び付けられたスキーマ、およびテーブル間でデータを結合するのには、アプリケーションの必要性に制限の空きです。

多文書データベースの使用可能な私の最も一般的な 2 つの中心に説明： MongoDB (mongodb.org)、CouchDB (couchdb.apache.org)：と RavenDB (ravendb.net)、マイクロソフトの記述されました。NET フレームワークと普及が拡大しています（記事は、"埋め込みの RavenDB には、ASP。を参照してください。NET MVC 3 アプリケーション、「この問題に)。多くの詳細情報については、個々のデータベースと、他の Web サイトにアクセスして、ものを学ぶことができますがこれのままになります。

(これはこの記事では指摘されます）いくつかのひねりの例外、これらのデータベースが HTTP 経由の最も一般的なデータを提供する、JavaScript オブジェクト表記法 (JSON) ドキュメントとしてのデータの格納し、Api を複数の言語で提供します。全体的な懸念は、シンプルさ、速度およびスケーラビリティです。同様に重要な 3 つのすべてオープンソースプロジェクトです。

私の研究では、MongoDB の専門家を聞いたパフォーマンス製品の主な懸念であることを言います。シンプルさと信頼性の ("、データベースのホンダ Accord を行う") に、CouchDB の専門家を指します。 Ayende Rahien、RavenDB の作成者が「書き込みの高速、高速読み取りと世界平和を」こと目的と RavenDB 言った、各文書データベースにどのようなこれらの音響の提案よりもよりがあります。

代わりに、代わり、リレーショナルデータベース用

NoSQL と文書データベースの代わりにリレーショナルデータベースでは、代わりに提供します。その代わりがありますだけで、その他のオプションを選択するとサポートします。選択する方法か。重要なゲージは、整合性、可用性、およびパーティションの許容範囲 (CAP) の定理です。分散システムで作業する場合は、のみ 2 つ、3 つのことが表示 (、C、A、または P)、何が重要かを選択することが保証されます。整合性の最も重要な場合は、リレーショナルデータベースを移動する必要があります。

一般的な例としては、一貫性保証の最も重要なことの銀行業務アプリケーションなど、核施設を実行されました。これらのシナリオでは、すべてのデータを 1 つのすべての瞬間に考慮だことが重要です。他の支払になる場合は、本当に彼の口座の残高を探している場合はそれについて知っている必要があります。そのため、おそらく、高レベルの制御は、トランザクションがリレーショナルデータベース必要があります。頻繁に聞くことは、用語「最終的な一貫性、」またはとして、RavenDB に記述されたサイト：「より古いよりオフラインします。"他のドメインでは、最終的な一貫性は十分です。ミリ秒までに取得しているデータではない場合は、[ok] をされて正確な。

おそらく、いくつかのバージョンのデータキャッチして、トランザクションのすべての待機中ではなくであるより重要です。これに関連しています (可用性) CAP です集中サーバーの稼働時間を。データベースへのアクセスは、常に必要があることを知ることが優先されるため、データベースのパフォーマンスには大きなメリットが提供されます (文書データベース高速です!)。 P では、パーティションの公差も特に水平方向に拡大/縮小するとドキュメントのデータベースには、重要であることがあります。

RESTful HTTP API-多くの場合

NoSQL データベースの多くは、URI によってデータベース接続を作成し、クエリやコマンドを HTTP 呼び出しをするために RESTful の方法では、アクセス可能です。 MongoDB は例外です。少なくとも 1 つの HTTP API 使用もデータベースの相互作用は、TCP を使用する既定値です。 CouchDB と MongoDB を作成し、HTTP の呼び出しを直接書き込みについて心配することなくが、クエリや更新を実行するための言語固有の Api を提供します。 RavenDB が、します。データベースとの対話を簡単に NET クライアント API。

1 つのレコードに関連するデータ

多くの人々が正しくしました非リレーショナルデータベースがフラットファイルであります。ドキュメントはデータベースに格納されているドキュメントをデータの形を収容できるは: ツリーのノードを持つ。データベース内の各レコードにはドキュメントであり、自律的なデータのセットを指定できます。自己を説明するには-その可能性があります一意のスキーマを含む-その他のドキュメントに必ずしも依存していません。

レコード (サンプル、学生を表す MongoDB のチュートリアルからを盗むでしょう)、ドキュメントのデータベースでどの可能性がありますの典型的な例を次に示します。

{
  "name" : "Jim",
  "scores" : [ 75, 99, 87.2 ]
}

ここで 1 つ CouchDB 紹介資料本の記述から。

{
  "Subject": "I like Plankton"  
  "Author": "Rusty"  
  "PostedDate": "5/23/2006"  
  "Tags": ["plankton", "baseball", "decisions"]
  "Body": "I decided today that I don't like baseball.
I like plankton."
}

これらの単純な構造にデータを文字列、数値、配列です。オブジェクトは、このブログのポストの例より複雑なドキュメント構造内のオブジェクトを埋め込むこともできます。

{
  "BlogPostTitle”: “LINQ Queries and RavenDB”,
  "Date":"\/Date(1266953391687+0200)\/",
  "Content":”Querying RavenDB is very familiar for .NET developers who are already
    using LINQ for other purposes”,
  "Comments":[
             {
             "CommentorName":"Julie",
             "Date":"\/Date(1266952919510+0200)\/",
             "Text":"Thanks for using something I already know how to
               work with!",
             "UserId":"users/203907"             
             },
  ]
}

ユニーク・キー

すべてのデータベースには、キーが必要です。指定しない場合は、内部のいずれかを作成します。キーのインデックスは、データベースの機能に不可欠ですが、独自ドメインのキーがわかっている必要があります。前のブログ投稿の例で、「ユーザー/203907」への参照があることを確認します。これは、RavenDB のキー値を活用する方法と、ドキュメント間の関係を定義することができますです。

JSON 形式のストレージ

これらのサンプルレコードのすべての共通は、JSON のデータの格納に使用していることです。実際に CouchDB と RavenDB (や他の多くのデータで JSON を格納しないでください。 MongoDB バイナリ JSON (バイナリシリアル化を実行するには、BSON) と呼ばれる JSON では、ひねりを使用します。 BSON は、データの内部表現は、プログラミングの観点からは、任意の違いを確認するべきではないため、します。

JSON のシンプルさに JSON オブジェクトの構造体のほぼすべての言語を入れ替えるを容易にします。したがって、アプリケーションでオブジェクトを定義し、データベースに直接保存することができます。これは、開発者は、オブジェクトリレーショナルマッパー (ORM) を使用して、データベーススキーマとクラスのオブジェクトはスキーマ間での変換が常にする必要がなくなります。

フルテキスト検索エンジン： Lucene (lucene.apache.org) になる RavenDB の依存-高パフォーマンスをこのテキスト・ベースのデータの検索を提供します。

ブログの投稿の例の日付を確認します。日付型は JSON はありませんが、データベースの各言語でコーディングしているから日付のタイプを解釈する方法が用意されています。データ型と、規則の一覧を MongoDB BSON の API をチェックする場合 (bit.ly/o87Gnx)、日付型、いくつかの他、JSON の使用が具体化すると共に追加されたことがわかります。

パフォーマンスおよびスケーラビリティ上のメリットを保存して 1 つの単位に関連するデータを取得することができます。データベースは、周りはすべて一緒にされているので、一般的に関連するデータを検索する方には必要ありません。

コレクションの種類

データベースとやり取りする場合は、アプリケーション 1 つの項目を学生されて、他の本が、他のブログの投稿がどのはか。データベースは、コレクションの概念を使用します。特定のコレクションに関連付けられているスキーマ、関係なく、任意のドキュメント-学生コレクションなど：コレクションからデータを要求するときに取得できます。またフィールドの種類を示すために使用するは珍しくありません。これだけの検索はとても容易しますが、コレクションに移動するべきではないし、する必要があります適用するアプリケーションです。

データベースのスキーマを使用しません。

説明「学生」以前は独自スキーマが含まれます。各レコードは、そのスキーマは、1 つのデータベースまたはコレクションに含まれるのです。また、学生の 1 つのレコードは、必ずしも別の学生のレコードと一致する必要はありません。もちろん、ソフトウェアはすべての違いに対応する必要があります。単にこのような柔軟性の効率性を活用すること。たとえば、null 値を格納なぜですか。「Most_repeated クラス」プロパティ値があるない場合、次の操作を行います。

"name" : "Jim",
"scores" : [ 75, 99, 87.2 ]
"name" : "Julie",
"scores" : [ 50, 40, 65 ],
"most_repeated_class" : "Time Management 101"

はい、バージニア、トランザクションをサポートして

各データベースのトランザクションのサポートレベルが用意されています-いくつかの詳細よりも、他の人- がうまくどのようなリレーショナルデータベースでは実現できるとは。私はマニュアルを延期して、追加調査をフォローすることができます。

データベースとドメイン駆動開発をドキュメントします。

ドメイン駆動開発の中核となる概念の 1 つは、集計ルートを使用して、ドメインモデルの作成に関連しています。ドメインクラスは、データベース内のドキュメントになる可能性があります) を計画するときは、ほとんどのデータを検索できます (たとえば、その行アイテムを注文) は自己完結型と焦点は、個々のデータ構造体。注文システムには、おそらく学習もお客様との製品があります。注文は、顧客情報がなくてもアクセス可能性があるし、製品を使用するには、注文、使用へのアクセスを必要とせずことがあります。必要性または特定のシナリオでの外部キーからデータを結合する機能を排除しない、自己完結型のデータ構造体 (その行アイテムを注文) などに多くの機会がありますが、意味します。

可能だし、どのユーザーが、最も大きな成功がある、さまざまなパターンでは、データベースのガイダンスを提供します。たとえば、配列をアクセスアップ関連のデータをドキュメントに参加すると高速化先祖と呼ばれるパターンに関する MongoDB ドキュメントを説明します。

リレーションシップのナビゲーションの懸念ということ、sin は、繰り返しデータをリレーショナルデータベースにバインドされています。データベースは、そのために正規化されます。 NoSQL データベースでは、特に配布されている場合、データの正規化や許容範囲です。

照会および更新

各データベース Api とクエリ、および更新に付属しています。コア API の一部ではなく、言語 Api のさまざまなアドオンを通じて提供されます。。Net エントリ文書データベースの世界に、RavenDB 使用 LINQ クエリに — という素晴らしい利点。NET 開発者です。

その他のクエリは、定義済みのビューとマップ/削減というパターンによって異なります。ビューではこのプロセスのマップを使用して、データベース間でのマップの責任とは異なります。マップでは、データベースを複数のプロセッサで処理するクエリを配布することもできます。小さく、マップクエリ (またはクエリでは、配布されている場合) の結果と集計データがクライアントに返される結果に。

マップまたは軽減にパターンをさまざまなデータベース実装。 Rob Ashton の RavenDB、CouchDB マップ/削減を実行する方法は興味深い比較を提供する bit.ly/94OCME。

CouchDB の定義済みマップ/縮小、ビューを介して（ビュー」および「マップまたは軽減をも使用） MongoDB を照会すること必要ですがまた、アドホッククエリを実行する機能が用意されています。 RavenDB 定義済みインデックスクエリしますが、もアドホッククエリをサポートでき、実行時の実際のクエリに基づいて、インデックスが自動的に作成されます。ほとんどの場合、ただし、既知のスキーマとリレーショナル性質の SQL データベースから移動すると、アドホッククエリを実行できる、失うの機能の 1 つです。厳密な制御、クエリを実行することで、ドキュメント、データベース、高速なパフォーマンスを約束することができます。

データベース革命

、 NoSQL 日よけの下で世の中の多くのリレーショナルデータベース。ドアを開いたことがないが、そのチームが利用可能ですがファイルの場所し、夢の方法は、向上のためにより多くの道です。私は RavenDB があることを彼はそれを改善したりする方法についての夢を続行またはユーザーが発端になったようにどのように Rahien が進化を見ることができると考えます。

これらのデータベースについて、intrigue が広がりであると思います。私確かにさらに本格的に取りかかるとさらに学習しております。きました 3 つもは、現時点では、好奇心の問題とは、実際のビジネス問題ではありませんを解決してリレーショナルデータベースに発生する現在のプロジェクトに適合するために選択するには、この Libra のハードである興味深い点です。

Julie Lerman マイクロソフト MVP です。NET の指導者とバーモントの丘に住んでいるコンサルタント。世界中のユーザーグループやカンファレンスで、データアクセスなどの Microsoft .NET トピックについてプレゼンテーションを行っています。彼女のブログは thedatafarm.com/blog (英語) で、彼女が執筆した『Programming Entity Framework』(O'Reilly Media、2010 年) は絶賛を浴びました。彼女に従って Twitter で twitter.com/julielerman。

確認するこの資料では、次のテクニカル・エキスパートに感謝： Ted Neward とSavas Parastatidis