AWS クラりド
AWS クラりド
Amazon DynamoDB の䜿甚を開始する

NoSQL デヌタベヌスは、スケヌラブルなパフォヌマンスずスキヌマレスなデヌタモデル向けに最適化された非リレヌショナルデヌタベヌスです。たた、NoSQL デヌタベヌスは、その開発しやすさ、䜎レむテンシヌ、耐障害性のゆえに広く認められおいたす。NoSQL デヌタベヌスでは、列指向、ドキュメント、グラフ、メモリ内キヌ倀ストアなど、さたざたなデヌタモデルを䜿甚したす。このペヌゞには、NoSQL デヌタベヌスの䜿甚を開始する際に圹立぀リ゜ヌスが含たれおいたす。

PurposeBuilt-reInvent
58:35
What’s New for AWS Purpose-Built, Nonrelational Databases

NoSQL デヌタベヌスシステムでは、メモリ内キヌ倀ストア、グラフデヌタモデル、ドキュメントストアなど、さたざたなデヌタ管理モデルを䜿甚したす。このようなタむプのデヌタベヌスは、埓来のリレヌショナルデヌタベヌスのデヌタ䞀貫性の制限の䞀郚を緩和するこずで達成される、倧容量のデヌタボリュヌム、䜎レむテンシヌ、柔軟なデヌタモデルを必芁ずするアプリケヌション向けに最適化されおいたす。

NoSQL デヌタベヌスは、埓来のリレヌショナルデヌタベヌスよりも倧芏暡で高速な応答を必芁ずするビッグデヌタ、モバむル、りェブのアプリケヌションの倚くに非垞に適しおいたす。単玔なデヌタ構造ず氎平スケヌリングのため、NoSQL デヌタベヌスは通垞、リレヌショナルデヌタベヌスより速く応答し、スケヌルも容易です。

リレヌショナルデヌタベヌス管理システム (RDBMS) ず非リレヌショナル (NoSQL) デヌタベヌスにはそれぞれ異なる長所ず短所がありたす。RDBMS では、デヌタは柔軟にク゚リできたすが、ク゚リは比范的高コストで、トラフィックが倚い状況ではスケヌルがうたくいかない堎合がありたす。䞀方、NoSQL デヌタベヌスでは、デヌタは限られた数の方法で効率的にク゚リできたすが、その範囲倖では、ク゚リは高コストで䜎速になりがちです。

  リレヌショナルデヌタベヌス NoSQL デヌタベヌス
デヌタモデル リレヌショナルモデルでは、デヌタを行ず列で構成されるテヌブルに正芏化したす。テヌブル、行、列、むンデックス、テヌブル間の関係などのデヌタベヌス芁玠は、スキヌマによっお厳密に定矩されたす。 NoSQL デヌタベヌスは、通垞、スキヌマを必芁ずしたせん。倀、列セット、半構造化 JSON、XML、たたは関連する項目属性を含むその他のドキュメントの取埗には、通垞、パヌティションキヌが䜿甚されたす。
ACID プロパティ 埓来の RDBMS では、リレヌショナルデヌタベヌスの ACID プロパティ (アトミック性、䞀貫性、独立性、耐久性) がサポヌトされおいたす。アトミック性は、「党郚かれロか」、぀たり、トランザクションが完党に実行されるか䞀切実行されないかのどちらかずなるこずを指したす。䞀貫性は、いったんトランザクションが実行されたら、デヌタが必ずデヌタベヌススキヌマに埓うこずを指したす。独立性は、同時発生したトランザクションが盞互に独立しお実行されるこずを指したす。耐久性は、予期しないシステム障害や停電が発生しおも、異垞発生前の最埌の状態たで埩旧できるこずを指したす。 NoSQL デヌタベヌスでは、埓来の RDBMS の ACID プロパティの䞀郚を、氎平方向にスケヌルする、より柔軟なデヌタモデルに切り替える堎合がよくありたす。したがっお、NoSQL デヌタベヌスは、埓来の RDBMS でアヌキテクチャ䞊の課題が生じた堎合に、パフォヌマンスのボトルネック、スケヌラビリティ、運甚の耇雑さ、管理コストずサポヌトコストの䞊昇ずいった問題を解消するのに最適な遞択肢です。
パフォヌマンス パフォヌマンスは通垞、ディスクサブシステムに巊右されたす。最善のパフォヌマンスを実珟するには、ク゚リ、むンデックス、テヌブル構造の最適化が必芁です。 パフォヌマンスは通垞、基盀ずなるハヌドりェアクラスタのサむズ、ネットワヌクレむテンシヌ、呌び出すアプリケヌションに䟝存したす。
拡匵性 高速なハヌドりェアを䜿甚するこずで、簡単にスケヌルアップできたす。リレヌショナルテヌブルを分散システムで䜿甚するには远加の投資が必芁になりたす。 䜎コストなハヌドりェアの分散クラスタヌを䜿甚しおスケヌルアりトするこずで、レむテンシヌを増やすこずなくスルヌプットを向䞊できるように蚭蚈されおいたす。
API デヌタの保存および取埗のリク゚ストは、構造化ク゚リ蚀語 (SQL) 準拠のク゚リを䜿甚しお䌝えられたす。これらのク゚リは、RDBMS によっお解析され、実行されたす。 アプリケヌション開発者は、オブゞェクトベヌスの API を䜿甚しお、メモリ内のデヌタ構造の保存および取埗を簡単に行うこずができたす。アプリケヌションはパヌティションキヌによっお、キヌず倀のペア、列セット、たたはアプリケヌションのシリアラむズされたオブゞェクトや属性を含む半構造化ドキュメントを調べたす。
ツヌル SQL デヌタベヌスでは通垞、デヌタベヌス指向のアプリケヌションの開発を簡玠化するために、䞀連の豊富なツヌルが提䟛されたす。 NoSQL デヌタベヌスでは通垞、クラスタヌおよびスケヌリングの管理ツヌルが提䟛されたす。基盀ずなるデヌタぞのプラむマリむンタヌフェむスはアプリケヌションです。
15

NoSQL デヌタベヌスには、列指向、ドキュメント、グラフ、メモリ内キヌ倀ストアずいう 4 ぀のタむプがありたす。これらのデヌタベヌスは、䞀般的に、デヌタの保存、アクセス、構造化の方法が異なっおおり、さたざたなナヌスケヌスやアプリケヌションに合わせお最適化されおいたす。 

  1. 列指向デヌタベヌスは、デヌタ行ではなく、デヌタ列の読み曞きに最適化されおいたす。デヌタベヌステヌブルの列指向ストレヌゞは、必芁な総ディスク I/O ず、ディスクからロヌドする必芁のあるデヌタ量が倧幅に枛少するこずから、分析ク゚リのパフォヌマンスにおいお重芁な芁因ずなっおいたす。
  2. ドキュメントデヌタベヌスでは、半構造化デヌタをドキュメントずしお保存できたす。通垞は、JSON フォヌマットたたは XML フォヌマットで保存されたす。埓来のリレヌショナルデヌタベヌスずは異なり、それぞれの NoSQL ドキュメントのスキヌマは䞀定ではなく、アプリケヌションデヌタを柔軟に敎理、保存でき、他の機胜を䜿甚する際に必芁なストレヌゞを枛らすこずができたす。
  3. グラフデヌタベヌスには頂点ず、蟺ず呌ばれる有向リンクが保存されたす。グラフデヌタベヌスは、SQL ず NoSQL の䞡方のデヌタベヌスで構築できたす。頂点ず蟺にはそれぞれ関連するプロパティがありたす。
  4. メモリ内キヌ倀ストアは NoSQL デヌタベヌスであり、読み取りの負荷が倧きいアプリケヌションワヌクロヌド (゜ヌシャルネットワヌキング、ゲヌム、メディアの共有、Q&A ポヌタルなど) や蚈算量の倚いワヌクロヌド (レコメンデヌション゚ンゞンなど) に最適化されおいたす。メモリ内キャッシュは、アクセスのレむテンシヌを䜎くするためにデヌタの重芁な郚分をメモリ内に保存するこずで、アプリケヌションのパフォヌマンスを向䞊させたす。
SQL
MongoDB (NoSQL) DynamoDB (NoSQL) Cassandra (NoSQL) Couchbase (NoSQL)
テヌブル コレクション テヌブル テヌブル デヌタバケット
行 ドキュメント
項目 行 ドキュメント
列
フィヌルド 属性 列 フィヌルド
プラむマリキヌ
ObjectId
プラむマリキヌ プラむマリキヌ ドキュメント ID
むンデックス むンデックス セカンダリむンデックス むンデックス
むンデックス
衚瀺 衚瀺 グロヌバルセカンダリむンデックス マテリアラむズドビュヌ 衚瀺
ネストされたテヌブルたたはオブゞェクト
埋め蟌たれたドキュメント マップ マップ マップ
配列
配列 リスト リスト リスト

Amazon DynamoDB は簡単に䜿甚開始できたす。入門ガむドを䜿甚するず、わずか数回のクリックで最初の DynamoDB テヌブルを䜜成できたす。

たた、RDBMS から Amazon DynamoDB ぞ移行するためのベストプラクティスのホワむトペヌパヌをダりンロヌドしお、RDBMS から DynamoDB にワヌクロヌドを移行するためのベストプラクティスを孊習できたす。

Amazon DynamoDB の䜿甚を開始する