NoSQL データベースとは
NoSQL データベースは、特定のデータモデル専用に設計されており、最新のアプリケーションを構築するための柔軟なスキーマを備えています。NoSQL データベースは、開発、機能性、およびパフォーマンスを大規模かつ容易に実現できるという点で広く評価されています。ドキュメント、グラフ、キー値、インメモリ、検索など、さまざまなデータモデルが使用されます。このページには、NoSQL データベースを理解して使用するための参考資料が含まれています。
何十年もの間、アプリケーション開発に使用する主なデータモデルは、Oracle、DB2、SQL Server、MySQL、PostgreSQL などのリレーショナルデータベースで使用するリレーショナルデータモデルでした。他のデータモデルが広く採用され始めたのは、2000 年代半ばから後半にかけてです。これらの新しいクラスのデータベースとデータモデルを区別し、分類するために “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 ドキュメントとして表されます。これは、開発者にとって、データモデルをドキュメントとして考える方が直感的であるためです。アプリケーションコードで使用するのと同じドキュメントモデル形式を使用してデータをデータベースに保持できるため、ドキュメントデータベースの人気が高まっています。DynamoDB と MongoDB は、柔軟で俊敏な開発のための強力で直感的な API を提供する一般的なドキュメントデータベースです。
グラフ: グラフデータベースの目的は、緊密なつながりのあるデータセットを扱うアプリケーションの構築と実行を容易にすることです。グラフデータベースの一般的なユースケースは、ソーシャルネットワーキング、推奨エンジン、詐欺検出、知識グラフなどです。Amazon Neptune は完全マネージド型のグラフデータベースサービスです。Neptune は、Property Graph モデルと Resource Description Framework (RDF) の両方をサポートし、TinkerPop と RDF/SPARQL という 2 つのグラフ API の選択肢を提供しています。一般的なグラフデータベースには Neo4j と Giraph があります。
インメモリ: ゲームや広告技術アプリケーションには、マイクロ秒の応答時間が必要なリーダーボード、セッションストア、リアルタイム分析などのユースケースがあり、いつでもトラフィックが急増する可能性があります。Amazon ElastiCache は Memcached と Redis をサポートし、ディスクベースのデータストアでは処理できない低レイテンシー、高スループットのワークロード (McDonald's など) に適合します。Amazon DynamoDB Accelerator (DAX) は、専用のデータストアの別の例です。DAX を使用すると、DynamoDB の読み込みが 1 桁速くなります。
検索: 多くのアプリケーションは、開発者が問題をトラブルシューティングするのに役立つようにログを出力します。Amazon Elasticsearch Service (Amazon ES) は、半構造化されたログおよび指標のインデックス作成、集約、検索により、機械が生成したデータをほぼリアルタイムで可視化し、分析できるようにする専用サービスです。Amazon ES は、フルテキスト検索ユースケース向けの強力で高性能な検索エンジンです。Expedia では、運用監視とトラブルシューティングから分散アプリケーションスタックのトレースと価格の最適化に至るまで、ミッションクリティカルなさまざまなユースケースに 150 以上の Amazon ES ドメイン、30 TB のデータ、300 億のドキュメントを使用しています。
SQL (リレーショナル) と NoSQL (非リレーショナル) データベースの比較
さまざまな機能を持つ多くのタイプの NoSQL データベースがありますが、次の表は、SQL データベースと NoSQL データベースの違いのいくつかを示しています。
| リレーショナルデータベース | NoSQL データベース | |
|---|---|---|
最適なワークロード |
リレーショナルデータベースは、トランザクショナルで強固な一貫性を持つオンライントランザクション処理 (OLTP) アプリケーション用に設計されており、オンライン分析処理 (OLAP) に適しています。 | NoSQL のキー値、ドキュメント、グラフ、およびインメモリのデータベースは、低レイテンシーアプリケーションを含む多数のデータアクセスパターンの OLTP 用に設計されています。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 に移行するためのベストプラクティスについて学ぶこともできます。