NoSQL データベースとは
NoSQL データベースは、特定のデータモデル専用に設計されており、最新のアプリケーションを構築するための柔軟なスキーマを備えています。NoSQL データベースは、開発、機能性、パフォーマンスを大規模かつ容易に実現できるという点で広く評価されています。このページには、NoSQL データベースを理解して使用するための参考資料が含まれています。
NoSQL (非リレーショナル) データベースの仕組み
NoSQL データベースでは、さまざまなデータモデルを使用してデータのアクセスや移行を実行します。このようなタイプのデータベースは特に、他のデータベースのデータ一貫性の制限の一部を緩和することで達成される大容量のデータボリューム、低レイテンシー、柔軟なデータモデルを必要とするアプリケーション向けに最適化されています。
単純な書籍データベースのスキーマをモデリングする例を考えてみましょう。
- リレーショナルデータベースでは、書籍レコードはしばしば分解 (「正規化」) されて別々のテーブルに格納され、それらの関係がプライマリキーと外部キーの制約によって定義されます。この例では、Books テーブルには ISBN、Book Title、Edition Number の列があり、Author テーブルには AuthorID と Author Name の列があり、最後に Author-ISBN テーブルに AuthorID と ISBN の列があります。リレーショナルモデルは、データベース内のテーブル間で参照整合性を維持し、正規化して冗長性を減らし、全般的にストレージを最適化できるように設計されています。
- NoSQL データベースでは、書籍レコードは通常、JSON ドキュメントとして保存されます。書籍ごとに、ISBN、Book Title、Edition Number、Author Name、AuthorID の各項目が、属性として単一のドキュメント内に格納されます。このモデルでは、データが、直感的な開発と水平スケーラビリティのために最適化されています。
NoSQL データベースを使用する必要がある理由
NoSQL データベースは、柔軟でスケーラブル、高性能かつ高機能なデータベースを必要とするモバイル、ウェブ、ゲームなどの最新のアプリケーションに最適で、優れたユーザーエクスペリエンスを実現します。
- 柔軟性: NoSQL データベースは、一般的に、より迅速で反復的な開発を可能にする柔軟なスキーマを提供します。NoSQL データベースの柔軟なデータモデルは、半構造化データおよび非構造化データに最適です。
- スケーラビリティ: NoSQL データベースは通常、高価で堅牢なサーバーを追加することによってスケールアップするのではなく、分散したハードウェアクラスターを使用してスケールアウトするように設計されています。一部のクラウドプロバイダーは、これらの操作を完全マネージド型サービスとしてバックグラウンドで処理します。
- 高性能: NoSQL データベースは、特定のデータモデルと、リレーショナルデータベースと同様の機能を実現しようとするよりも高いパフォーマンスを実現できるアクセスパターンに最適化されています。
- 高機能: NoSQL データベースは、それぞれのデータモデルごとに専用に設計された機能性に優れた API とデータ型を提供します。
NoSQL データベースのタイプ

キー値: キー値データベースは高度なパーティション化に対応しており、他のタイプのデータベースでは達成できない大規模な水平スケーリングが可能です。ゲーム、広告技術、IoT などのユースケースは、キー値データモデルに特に適しています。Amazon DynamoDB は、あらゆる規模のワークロードでレイテンシーを 10 ミリ秒未満に維持するように設計されています。この一貫したパフォーマンスは、Snapchat の最大のストレージ書き込みワークロードを含む Snapchat Stories 機能が DynamoDB に移行した大きな理由になっています。

ドキュメント: アプリケーションコードでは、開発者にとって効率的で直感的なデータモデルであるため、オブジェクトまたは JSON のようなドキュメントとしてデータが表現されることがよくあります。ドキュメントデータベースを使用すると、開発者はアプリケーションコードで使用しているのと同じドキュメントモデル形式を使って、簡単にデータをデータベースに保存し、クエリできるようになります。ドキュメントおよびドキュメントデータベースは柔軟性があり、半構造化され、階層的な性質を持つため、アプリケーションのニーズに合わせて進化させることができます。ドキュメントモデルは、カタログ、ユーザープロファイル、コンテンツ管理システムなど、各ドキュメント固有のものであり、時間の経過とともに進化する場合うまく機能します。Amazon DocumentDB (MongoDB 互換) と MongoDB は、柔軟で反復的な開発のための強力で直感的な API を提供する人気ドキュメントデータベースです。

グラフ: グラフデータベースの目的は、緊密なつながりのあるデータセットを扱うアプリケーションの構築と実行を容易にすることです。グラフデータベースの一般的なユースケースは、ソーシャルネットワーキング、推奨エンジン、詐欺検出、知識グラフなどです。Amazon Neptune は完全マネージド型のグラフデータベースサービスです。Neptune は、Property Graph モデルと Resource Description Framework (RDF) の両方をサポートし、TinkerPop と RDF/SPARQL という 2 つのグラフ API の選択肢を提供しています。一般的なグラフデータベースには Neo4j と Giraph があります。

インメモリ: ゲームや広告技術アプリケーションには、マイクロ秒の応答時間が必要なリーダーボード、セッションストア、リアルタイム分析などのユースケースがあり、いつでもトラフィックが急増する可能性があります。 Amazon MemoryDB for Redis は、Redis と互換性があり、耐久性のあるインメモリデータベースサービスで、ミリ秒の読み取りレイテンシー、数ミリ秒台の書き込みレイテンシーと、マルチ AZ の耐久性を提供します。MemoryDB は、超高速なパフォーマンスと耐久性を提供することを目的として構築されており、最新のマイクロサービスアプリケーションのプライマリデータベースとして使用することができます。 Amazon ElastiCache は、Redis と Memcached の両方と互換性のある、フルマネージドインメモリーキャッシングサービスで、低レイテンシーで高スループットのワークロードに対応します。Tinder のように、アプリケーションからのリアルタイムレスポンスを必要とするお客様は、ディスクベースのデータストアではなく、インメモリデータストアに依存しています。 Amazon DynamoDB Accelerator (DAX) は、専用のデータストアの別の例です。DAX を使用すると、DynamoDB の読み込みが 1 桁速くなります。

検索: 多くのアプリケーションは、開発者が問題をトラブルシューティングするのに役立つようにログを出力します。Amazon OpenSearch Service は、半構造化されたログおよび指標のインデックス作成、集約、検索により、機械が生成したデータをほぼリアルタイムで可視化し、分析できるようにする専用サービスです。Amazon OpenSearch Service は、フルテキスト検索ユースケースのための強力で高パフォーマンスの検索エンジンでもあります。Expedia では、運用監視とトラブルシューティングから分散アプリケーションスタックのトレースと価格の最適化に至るまで、ミッションクリティカルなさまざまなユースケースに 150 以上の Amazon OpenSearch Service ドメイン、30 TB のデータ、300 億のドキュメントを使用しています。
SQL (リレーショナル) とNoSQL (非リレーショナル) データベースの比較
何十年もの間、アプリケーション開発に使用する主なデータモデルは、Oracle、DB2、SQL Server、MySQL、PostgreSQL などのリレーショナルデータベースで使用するリレーショナルデータモデルでした。他のデータモデルが広く採用され始めたのは、2000 年代半ばから後半にかけてです。これらの新しいクラスのデータベースとデータモデルを区別し、分類するために “NoSQL” という用語が登場しました。多くの場合、“NoSQL” という用語は「非リレーショナル」と同じ意味です。
さまざまな機能を持つ多くのタイプの NoSQL データベースがありますが、次の表は、SQL データベースと NoSQL データベースの違いのいくつかを示しています。
リレーショナルデータベース | NoSQL データベース | |
---|---|---|
最適なワークロード |
リレーショナルデータベースは、トランザクショナルで強固な一貫性を持つオンライントランザクション処理 (OLTP) アプリケーション用に設計されており、オンライン分析処理 (OLAP) に適しています。 | NoSQL のデータベースは、低レイテンシーアプリケーションを含む多数のデータアクセスパターン用に設計されています。NoSQL 検索データベースは、半構造化データの分析用に設計されています。 |
データモデル | リレーショナルモデルでは、データを行と列で構成されるテーブルに正規化します。テーブル、行、列、インデックス、テーブル間の関係などのデータベース要素は、スキーマによって厳密に定義されます。テーブル間の関係によってデータベースの参照整合性が維持されます。 |
NoSQL データベースでは、キー値、ドキュメント、グラフなどのさまざまなデータモデルを利用できます。これらのデータモデルはパフォーマンスと規模に応じて最適化されています。 |
ACID 特性 | リレーショナルデータベースには、アトミック性、一貫性、分離性、および耐久性 (ACID) の特性があります。
|
NoSQL データベースでは、多くの場合、リレーショナルデータベースの ACID 特性の一部を緩和することと引き換えに、水平方向に拡張できるもっと柔軟なデータモデルを実現しています。これによって、NoSQL データベースは、単一インスタンスの制限を超えて水平方向に拡張する必要のある、高スループット、低レイテンシーユースケースの優れた選択肢になっています。 |
パフォーマンス | パフォーマンスは通常、ディスクサブシステムに左右されます。最善のパフォーマンスを実現するには、多くの場合、クエリ、インデックス、テーブル構造の最適化が必要です。 | パフォーマンスは通常、基盤となるハードウェアクラスターのサイズ、ネットワークレイテンシー、呼び出すアプリケーションに依存します。 |
拡張性 | リレーショナルデータベースでは通常、ハードウェアの演算機能を増強してスケールアップするか、読み取り専用ワークロードのレプリカを追加してスケールアウトします。 | NoSQL データベースでは通常、分散型アーキテクチャを使用したアクセスパターンのスケールアウトに基づくパーティション化が可能で、これにより、ほぼ無限の規模でスループットを高め、一貫したパフォーマンスを維持することができます。 |
API | データの保存および取得のリクエストは、構造化クエリ言語 (SQL) 準拠のクエリを使用して伝えられます。これらのクエリは、リレーショナルデータベースによって解析されて実行されます。 | アプリケーション開発者は、オブジェクトベースの API を使用して、データ構造の保存および取得を簡単に行うことができます。アプリケーションはパーティションキーによって、キーと値のペア、列セット、またはアプリケーションのシリアライズされたオブジェクトや属性を含む半構造化ドキュメントを調べます。 |
SQL とNoSQL の用語
次の表は、SQL データベースによって使用される用語と主要な NoSQL データベースで使用される用語を比較したものです。
SQL | MongoDB | DynamoDB | Cassandra | Couchbase |
---|---|---|---|---|
テーブル | コレクション | テーブル | テーブル | データバケット |
行 | ドキュメント | 項目 | 行 | ドキュメント |
列 | フィールド | 属性 | 列 | フィールド |
プライマリキー | ObjectId | プライマリキー |
プライマリキー | ドキュメント ID |
インデックス | インデックス | セカンダリインデックス | インデックス | インデックス |
ビュー | ビュー | グローバルセカンダリインデックス | マテリアライズドビュー | ビュー |
ネストされたテーブルまたはオブジェクト | 埋め込まれたドキュメント | マップ | マップ | マップ |
配列 | 配列 | リスト | リスト | リスト |
リスト |
リスト |
プライマリキー |
DynamoDB の開始方法
DynamoDB の使用を開始するのは簡単です。DynamoDB 入門ガイドのウェブページを参照して、数回のクリックで最初のテーブルを作成できます。AWS のホワイトペーパーをダウンロードして、ワークロードをリレーショナルデータベース管理システム (RDBMS) から DynamoDB に移行するためのベストプラクティスについて学ぶこともできます。