# Amazon DynamoDB: 仕組み
以下のセクションでは、Amazon DynamoDB サービスコンポーネントと、それらの対話方法の概要を示します。
**Topics**
+ [DynamoDB のチートシート](CheatSheet.md)
+ [Amazon DynamoDB のコアコンポーネント](HowItWorks.CoreComponents.md)
+ [DynamoDB API](HowItWorks.API.md)
+ [Amazon DynamoDB でサポートされるデータ型と命名規則](HowItWorks.NamingRulesDataTypes.md)
+ [DynamoDB テーブルクラス](HowItWorks.TableClasses.md)
+ [DynamoDB におけるパーティションとデータ分散](HowItWorks.Partitions.md)
+ [SQL から NoSQL に移行する方法について学ぶ](SQLtoNoSQL.md)
+ [Amazon DynamoDB の学習リソースとツール](AdditionalResources.md)
# DynamoDB のチートシート
このチートシートは、Amazon DynamoDB とそのさまざまな AWS SDK を操作するためのクイックリファレンスを提供します。
## 初期セットアップ
1. [ にサインアップします。AWS](SettingUp.DynamoWebService.html#SettingUp.DynamoWebService.SignUpForAWS)
1. プログラムで DynamoDB にアクセスするための [AWS アクセスキーを取得](SettingUp.DynamoWebService.html#SettingUp.DynamoWebService.GetCredentials)します。
1. [DynamoDB 認証情報を設定します](SettingUp.DynamoWebService.html#SettingUp.DynamoWebService.ConfigureCredentials)。
**以下も参照してください。**
+ [DynamoDB (ウェブサービス) の設定](SettingUp.DynamoWebService.html)
+ [DynamoDB の使用開始](GettingStartedDynamoDB.html)
+ [コアコンポーネントの基本概要](HowItWorks.CoreComponents.html)
## SDK または CLI
任意の [SDK](sdk-general-information-section.html) を選択するか、[AWS CLI](/cli/latest/index.html) を設定します。
**注記**
Windows で AWS CLI を使用すると、引用符の中にないバックスラッシュ (\$1) はキャリッジリターンとして扱われます。また、他の引用符の中にある引用符や中かっこはエスケープする必要があります。例については、次のセクションの「テーブルの作成」の **[Windows]** タブを参照してください。
**以下も参照してください。**
+ [AWS CLIDynamoDB での](Tools.CLI.html)
+ [DynamoDB の使用開始 – ステップ 2](getting-started-step-2.html)
## 基本アクション
このセクションでは、基本的な DynamoDB タスクのコードを提供します。これらのタスクの詳細については、「[DynamoDB とAWS SDK の使用開始](GettingStarted.html)」を参照してください。
### テーブルを作成する
------
#### [ Default ]
```
aws dynamodb create-table \
--table-name Music \
--attribute-definitions \
AttributeName=Artist,AttributeType=S \
AttributeName=SongTitle,AttributeType=S \
--key-schema AttributeName=Artist,KeyType=HASH AttributeName=SongTitle,KeyType=RANGE \
--billing-mode PAY_PER_REQUEST \
--table-class STANDARD
```
------
#### [ Windows ]
```
aws dynamodb create-table ^
--table-name Music ^
--attribute-definitions ^
AttributeName=Artist,AttributeType=S ^
AttributeName=SongTitle,AttributeType=S ^
--key-schema AttributeName=Artist,KeyType=HASH AttributeName=SongTitle,KeyType=RANGE ^
--billing-mode PAY_PER_REQUEST ^
--table-class STANDARD
```
------
### テーブルへの項目の書き込み
```
aws dynamodb put-item \ --table-name Music \ --item file://item.json
```
### テーブルから項目の読み込み
```
aws dynamodb get-item \ --table-name Music \ --item file://item.json
```
### テーブルから項目の削除
```
aws dynamodb delete-item --table-name Music --key file://key.json
```
### テーブルに対してクエリを実行する
```
aws dynamodb query --table-name Music
--key-condition-expression "ArtistName=:Artist and SongName=:Songtitle"
```
### テーブルを削除する
```
aws dynamodb delete-table --table-name Music
```
### テーブル名のリスト化
```
aws dynamodb list-tables
```
## 名前付けルール
+ すべての名前は UTF-8 を使用してエンコードする必要があり、大文字と小文字が区別されます。
+ テーブル名とインデックス名の長さは 3～255 文字で、次の文字のみを含めることができます。
+ `a-z`
+ `A-Z`
+ `0-9`
+ `_` (下線)
+ `-` (ハイフン)
+ `.` (ドット)
+ 属性名は 1 文字以上、64 KB 未満のサイズである必要があります。
詳細については、「[命名規則](HowItWorks.NamingRulesDataTypes.html)」を参照してください。
## サービスクォータの基本
**読み込みユニットと書き込みユニット**
+ **読み込みキャパシティユニット (RCU)** – 最大サイズが 4 KB の項目について、読み込みキャパシティユニット = 1 秒あたり 1 回の強力な整合性のある読み込み、あるいは 1 秒あたり 2 回の結果整合性のある読み込み。
+ **書き込みキャパシティユニット (WCU)** – 最大サイズが 1 KB の項目について、書き込みキャパシティユニット = 1 秒あたり 1 回の書き込み。
**テーブルリミット**
+ **テーブルサイズ** – テーブルのサイズには実用的な制限はありません。テーブルは項目数やバイト数について制限がありません。
+ **テーブルの数** – AWS アカウントについては、AWS リージョンごとに 2,500 個のテーブルという初期クォータがあります。
+ **クエリとスキャンのページサイズの制限** – クエリまたはスキャンごとに、1 ページあたり 1 MB に制限されています。クエリパラメータまたはテーブルでのスキャン操作の結果データが 1 MB を超える場合、DynamoDB は最初に一致した項目を返します。また、新しいリクエストで次のページを読むときに使用できる `LastEvaluatedKey` プロパティも返されます。
**インデックス**
+ **ローカルセカンダリインデックス (LSI)** – 最大 5 つのローカルセカンダリインデックスを定義できます。LSI は主に、インデックスがベーステーブルと強い一貫性を持たなければならない場合に役立ちます。
+ **グローバルセカンダリインデックス (GSI)** – デフォルトクォータとして、テーブルごとに 20 個のグローバルセカンダリインデックスがあります。
+ **テーブル毎のセカンダリインデックス属性の射影** – 合計最大 100 の属性を、1 つのテーブルのすべてのグローバルセカンダリインデックスに射影することができます。これは、ユーザー指定の射影された属性だけに適用されます。
**パーティションキー**
+ パーティションキーと値の最小長は 1 バイトです。最大長は 2048 バイトです
+ テーブルまたはセカンダリインデックスについて、パーティションキー値の明確な数に関する実質的な制限はありません。
+ ソートキーと値の最小長は 1 バイトです。最大長は 1024 バイトです
+ 一般的に、パーティションキーの値ごとのソートキーの値の数について、実質的に制限はありません。セカンダリインデックスを持つテーブルは例外です。
セカンダリインデックス、パーティションキー設計、ソートキー設計の詳細については、「[ベストプラクティス](best-practices.html)」を参照してください。
**一般的に使用されるデータ型の制限**
+ **文字列** – 文字列の長さは、項目の最大サイズである 400 KB に制約されます。文字列は、UTF-8 バイナリエンコードの Unicode です。
+ **数値** – 数値は、最大 38 桁の精度であり、正、負、または 0 のいずれかです。
+ **バイナリ** – バイナリの長さは、項目の最大サイズである 400 KB に制約されます。バイナリ属性を操作するアプリケーションは、データを DynamoDB に送信する前に、base64 でエンコードする必要があります。
サポートされているデータ型のリストについては、「[データ型](HowItWorks.NamingRulesDataTypes.html#HowItWorks.DataTypes)」を参照してください。詳細については、「[Service Quotas](ServiceQuotas.html#limits-items)」(サービスクォータ) を参照してください。
### 項目、属性、式パラメータ
DynamoDB の項目の最大サイズは 400 KB で、属性名のバイナリの長さ (UTF-8 の長さ) と属性値の長さ (UTF-8 の長さ) を含みます。属性名はサイズ制限に反映されます。
値を含む項目が 400 KB の制限内である限り、リスト、マップ、またはセットにおける値の最大数の制限はありません。
式パラメータでは、式文字列の最大長は 4 KB です。
項目サイズ、属性、および式パラメータの詳細については、「[Service Quotas](ServiceQuotas.html#limits-items)」(サービスクォータ) を参照してください。
## 詳細情報
+ [セキュリティ](security.html)
+ [モニタリングとログ記録](monitoring.html):
+ [ストリームの使用](streamsmain.html)
+ [バックアップ](Backup-and-Restore.html)と[ポイントインタイムリカバリ](Point-in-time-recovery.html)
+ [他の AWS のサービスとの統合](OtherServices.html)
+ [API リファレンス](/amazondynamodb/latest/APIReference/Welcome.html)
+ [アーキテクチャセンター: データベースのベストプラクティス](https://aws.amazon.com/architecture/databases/)
+ [ビデオチュートリアル](https://youtu.be/Mw8wCj0gkRc)
+ [DynamoDB フォーラム](https://repost.aws/search/questions?globalSearch=dynamodb)
# Amazon DynamoDB のコアコンポーネント
DynamoDB では、テーブル、項目、および属性が、操作するコアコンポーネントです。*テーブル*は*項目*の集合であり、各項目は*属性*の集合です。DynamoDB は、テーブルの各項目を一意に識別するために、プライマリキーを使用します。DynamoDB Streams を使用して、DynamoDB テーブルのデータ変更イベントをキャプチャできます。
DynamoDB には制限があります。詳細については、「[Amazon DynamoDB のクォータ](ServiceQuotas.md)」を参照してください。
次の動画では、テーブル、項目、および属性の概要を説明します。
[テーブル、項目、属性](https://www.youtube.com/embed/Mw8wCj0gkRc)
## テーブル、項目、属性
![\[各 DynamoDB テーブルには、1 つ以上の属性で構成された項目が 0 個以上含まれています。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/HowItWorksTables-2024.png)
基本的な DynamoDB コンポーネントは以下のとおりです。
+ **テーブル** – 他のデータベースシステムと同様、DynamoDB はデータをテーブルに保存します。*テーブル*は、データのコレクションです。たとえば、テーブルの例 (*People*) を参照してください。このテーブルは、友人、家族、関心のある人に関する個人の連絡先情報を保存するのに使用できます。また、その人たちが運転する車に関する情報を保存する *Cars* テーブルを作成することもできます。
+ **項目** – 各テーブルにはゼロ以上の項目が含まれています。*項目*は、他のすべての項目間で一意に識別可能な属性のグループです。*People* テーブルの各項目は、人を表します。*Cars* テーブルの各項目は 1 台の車を表します。DynamoDB の項目は、多くの点で他のデータベースシステムの行、レコード、またはタプルに似ています。DynamoDB では、テーブルに保存できる項目数に制限はありません。
+ **属性** – 各項目は 1 つ以上の属性で構成されます。*属性*は、基盤となるデータ要素であり、それ以上分割する必要がないものです。例えば、*People* テーブルの項目には、*PersonID*、*LastName*、*FirstName* といった名前の属性が含まれます。*Department* テーブルでは、項目が *DepartmentID*、*Name*、*Manager* などの属性を設定することができます。DynamoDB 内の属性は、多くの点で他のデータベースシステムのフィールドや列に似ています。
次の図は、いくつかの項目と属性の例を含む、*People* という名前のテーブルを示しています。
```
People
{
"PersonID": 101,
"LastName": "Smith",
"FirstName": "Fred",
"Phone": "555-4321"
}
{
"PersonID": 102,
"LastName": "Jones",
"FirstName": "Mary",
"Address": {
"Street": "123 Main",
"City": "Anytown",
"State": "OH",
"ZIPCode": 12345
}
}
{
"PersonID": 103,
"LastName": "Stephens",
"FirstName": "Howard",
"Address": {
"Street": "123 Main",
"City": "London",
"PostalCode": "ER3 5K8"
},
"FavoriteColor": "Blue"
}
```
*People* テーブルについて、以下の点に注意してください。
+ テーブルの各項目には一意の識別子があります。これは、テーブルの他のすべての項目からその項目を区別するプライマリキーです。*People* テーブルで、プライマリキーは 1 つの属性 (*PersonID*) で構成されます。
+ プライマリキー以外、*People* テーブルはスキーマレスです。つまり、属性またはデータ型を事前に定義する必要はありません。各項目は、独自の固有の属性を持つことができます。
+ 属性のほとんどは*スカラー*です。つまり、1 つの値のみを持つことができます。文字列と数値はスカラーの一般的な例です。
+ 一部の項目には、ネストされた属性 (*アドレス*) があります。DynamoDB は深さが最大 32 レベルの入れ子の属性をサポートします。
以下は、音楽コレクションを追跡するために使用できる、*Music* という名前の別のサンプルテーブルです。
```
Music
{
"Artist": "No One You Know",
"SongTitle": "My Dog Spot",
"AlbumTitle": "Hey Now",
"Price": 1.98,
"Genre": "Country",
"CriticRating": 8.4
}
{
"Artist": "No One You Know",
"SongTitle": "Somewhere Down The Road",
"AlbumTitle": "Somewhat Famous",
"Genre": "Country",
"CriticRating": 8.4,
"Year": 1984
}
{
"Artist": "The Acme Band",
"SongTitle": "Still in Love",
"AlbumTitle": "The Buck Starts Here",
"Price": 2.47,
"Genre": "Rock",
"PromotionInfo": {
"RadioStationsPlaying": [
"KHCR",
"KQBX",
"WTNR",
"WJJH"
],
"TourDates": {
"Seattle": "20150622",
"Cleveland": "20150630"
},
"Rotation": "Heavy"
}
}
{
"Artist": "The Acme Band",
"SongTitle": "Look Out, World",
"AlbumTitle": "The Buck Starts Here",
"Price": 0.99,
"Genre": "Rock"
}
```
*Music* テーブルについて、以下の点に注意してください。
+ *Music* のプライマリキーは 2 つの属性 (*Artist* および *SongTitle*) で構成されます。テーブルの各項目にはこれら 2 つの属性が必要です。*Artist* および *SongTitle* の組み合わせにより、テーブルの各項目が他のすべての項目から区別されます。
+ プライマリキー以外、*Music* テーブルはスキーマレスです。つまり、属性またはデータ型を事前に定義する必要はありません。各項目は、独自の固有の属性を持つことができます。
+ 項目の 1 つに、入れ子の属性 (*PromotionInfo*) があります。これには、入れ子の他の属性が含まれます。DynamoDB は深さが最大 32 レベルの入れ子の属性をサポートします。
詳細については、「[DynamoDB でのテーブルとデータの操作](WorkingWithTables.md)」を参照してください。
## プライマリキー
テーブルを作成する場合には、テーブル名に加えて、テーブルのプライマリキーを指定する必要があります。プライマリキーはテーブルの各項目を一意に識別するため、テーブル内の 2 つの項目が同じキーを持つことはありません。
DynamoDB は 2 種類の異なるプライマリキーをサポートします。
+ **パーティションキー** – *パーティションキー*という 1 つの属性で構成されたシンプルなプライマリキー。
DynamoDB は、パーティションキーの値を内部ハッシュ関数への入力として使用します。ハッシュ関数からの出力により、項目が保存されるパーティション (DynamoDB 内部の物理ストレージ) が決まります。
パーティションキーのみを含むテーブルでは、2 つの項目が同じパーティションキー値を持つことはできません。
[テーブル、項目、属性](#HowItWorks.CoreComponents.TablesItemsAttributes) で説明されている *People* テーブルは、単純なプライマリキー (*PersonID*) を持つテーブルの例です。*People* テーブル内の任意の項目に直接アクセスするには、その項目の *PersonId* 値を指定します。
+ **パーティションとソートキー** – *複合プライマリキー*と呼ばれるこのキーのタイプは、2 つの属性で構成されます。最初の属性は*パーティションキー*であり、2 番目の属性は*ソートキー*です。
DynamoDB は、パーティションキーバリューを内部ハッシュ関数への入力として使用します。ハッシュ関数からの出力により、項目が保存されるパーティション (DynamoDB 内部の物理ストレージ) が決まります。同じパーティションキー値を持つすべての項目は、ソートキー値でソートされてまとめて保存されます。
パーティションキーとソートキーが存在するテーブルでは、同じパーティションのキーバリューが複数の項目に割り当てられることがあります。ただし、ソートキー値は複数の項目で異なる必要があります。
[テーブル、項目、属性](#HowItWorks.CoreComponents.TablesItemsAttributes) で説明されている *Music* テーブルは、複合プライマリキー (*Artist* および *SongTitle*) を持つテーブルの例です。その項目に *Artist* と *SongTitle* の値を指定すると、*Music* テーブルの任意の項目に直接アクセスできます。
複合プライマリキーは、データのクエリを実行するときに柔軟性を高めます。たとえば、*Artist* の値のみを指定した場合、DynamoDB はそのアーティストのすべての曲を取得します。特定のアーティストの曲のサブセットのみを取得するには、*Artist* の値と *SongTitle* の値範囲を指定します。
**注記**
項目のパーティションキーは、その*ハッシュ属性*とも呼ばれます。*ハッシュ属性*という用語は、DynamoDB が内部のハッシュ関数を使用し、パーティションキーバリューに基づいてパーティション間でデータ項目を均等に分散することに由来しています。
項目のソートキーは、*範囲属性*とも呼ばれます。*範囲属性*という用語は、ソートキーバリューで並べ替えられた順に、DynamoDB が同じパーティションキーを持つ項目同士を物理的に近くに保存する方法に由来しています。
各プライマリキー属性はスカラー値 (単一値のみを保持できる) である必要があります。プライマリキー属性に許可される唯一のデータ型は、文字列、数値、またはバイナリです。他のキー以外の属性では、このような制限はありません。
## セカンダリインデックス
テーブルで 1 つ以上のセカンダリインデックスを作成できます。*セカンダリインデックス*では、プライマリキーに対するクエリに加えて、代替キーを使用して、テーブル内のデータのクエリを行うことができます。DynamoDB では、インデックスを使用する必要はありませんが、インデックスを使用すると、データのクエリを行う際にアプリケーションの柔軟性が高まります。テーブルにグローバルセカンダリインデックスを作成すると、テーブルから行う場合とほぼ同じ方法でインデックスからデータを読み取ることができます。
DynamoDB では、次の 2 種類のインデックスをサポートしています。
+ グローバルセカンダリインデックス – パーティションキーおよびソートキーを持つインデックス。テーブルのものとは異なる場合があります。グローバルセカンダリインデックスのプライマリキーの値は一意である必要はありません。
+ ローカルセカンダリインデックス – パーティションキーはテーブルと同じですが、ソートキーが異なるインデックスです。
DynamoDB では、グローバルセカンダリインデックス (GSI) はテーブル全体にまたがるインデックスであり、すべてのパーティションキーをクエリできます。ローカルセカンダリインデックス (LSI)は、ベーステーブルとパーティションキーは同じで、ソートキーが異なるインデックスです。
DynamoDB の各テーブルには、20 個のグローバルセカンダリーインデックス (デフォルトのクォータ) と、5 個のローカルセカンダリーインデックスのクォータがあります。
前に示した *Music* サンプルテーブルでは、*Artist* (パーティションキー) または *Artist* および *SongTitle* (パーティションキーとソートキー) によってデータ項目にクエリを実行できます。*Genre* および *AlbumTitle* によってデータにクエリを実行する場合はどうでしょうか。これを行うには、*Genre* および *AlbumTitle* にインデックスを作成し、*Music* テーブルのクエリと同様に、インデックスにクエリを実行できます。
次の図表は、*GenreAlbumTitle* という新しいインデックスを持つ *Music* テーブルの例を示しています。このインデックスでは、*Genre* がパーティションキーで、*AlbumTitle* がソートキーです。
| Music テーブル | *GenreAlbumTitle* |
| --- | --- |
|
{
"Artist": "No One You Know",
"SongTitle": "My Dog Spot",
"AlbumTitle": "Hey Now",
"Price": 1.98,
"Genre": "Country",
"CriticRating": 8.4
}
|
{
"Genre": "Country",
"AlbumTitle": "Hey Now",
"Artist": "No One You Know",
"SongTitle": "My Dog Spot"
}
|
|
{
"Artist": "No One You Know",
"SongTitle": "Somewhere Down The Road",
"AlbumTitle": "Somewhat Famous",
"Genre": "Country",
"CriticRating": 8.4,
"Year": 1984
}
|
{
"Genre": "Country",
"AlbumTitle": "Somewhat Famous",
"Artist": "No One You Know",
"SongTitle": "Somewhere Down The Road"
}
|
|
{
"Artist": "The Acme Band",
"SongTitle": "Still in Love",
"AlbumTitle": "The Buck Starts Here",
"Price": 2.47,
"Genre": "Rock",
"PromotionInfo": {
"RadioStationsPlaying": {
"KHCR",
"KQBX",
"WTNR",
"WJJH"
},
"TourDates": {
"Seattle": "20150622",
"Cleveland": "20150630"
},
"Rotation": "Heavy"
}
}
|
{
"Genre": "Rock",
"AlbumTitle": "The Buck Starts Here",
"Artist": "The Acme Band",
"SongTitle": "Still In Love"
}
|
|
{
"Artist": "The Acme Band",
"SongTitle": "Look Out, World",
"AlbumTitle": "The Buck Starts Here",
"Price": 0.99,
"Genre": "Rock"
}
|
{
"Genre": "Rock",
"AlbumTitle": "The Buck Starts Here",
"Artist": "The Acme Band",
"SongTitle": "Look Out, World"
}
|
*GenreAlbumTitle* インデックスについて、以下の点に注意してください。
+ 各インデックスはテーブルに属します。これをインデックスの*基本テーブル*と呼びます。前述の例では、*Music* が *GenreAlbumTitle* インデックスの基本テーブルです。
+ DynamoDB はインデックスを自動的に維持します。基本テーブルの項目を追加、更新、または削除すると、DynamoDB はそのテーブルに属するすべてのインデックスの対応する項目を追加、更新、または削除します。
+ インデックスを作成するときは、基本テーブルからインデックスにコピーまたは*射影*される属性を指定します。少なくとも、DynamoDB は基本テーブルからインデックスにキー属性を射影します。これは `GenreAlbumTitle` のケースで、`Music` テーブルのキー属性のみがインデックスに射影されます。
*GenreAlbumTitle* インデックスにクエリを実行し、特定のジャンルのすべてのアルバム (たとえば、すべての *Rock* アルバム) を検索できます。また、インデックスにクエリを実行して、特定のジャンル内のすべてのアルバムのうち、特定のアルバムタイトル (たとえば、タイトルが文字 H で始まるすべての *Country* アルバム) のみを検索することもできます。
詳細については、「[DynamoDB でのセカンダリインデックスを使用したデータアクセス性の向上](SecondaryIndexes.md)」を参照してください。
## DynamoDB Streams
DynamoDB Streams は、DynamoDB テーブルのデータ変更イベントをキャプチャするオプションの特徴です。これらのイベントに関するデータは、ほとんどリアルタイムに、イベントの発生順にストリームに表示されます。
各イベントは*ストリームレコード*によって表されます。テーブルでストリーミングを有効にすると、DynamoDB Streams は次のいずれかのイベントが発生するたびに、ストリーミングレコードを書き込みます。
+ 新しい項目がテーブルに追加された場合: ストリームは、すべての属性を含む項目全体のイメージをキャプチャします。
+ 項目が更新された場合: ストリームは、項目で変更された属性について、「前」と「後」のイメージをキャプチャします。
+ テーブルから項目が削除された場合: ストリームは、項目が削除される前に項目全体のイメージをキャプチャします。
各ストリームレコードには、テーブルの名前、イベントのタイムスタンプ、およびその他のメタデータも含まれます。ストリームレコードには 24 時間の有効期間があり、その後はストリームから自動的に削除されます。
DynamoDB Streams を AWS Lambda と共に使用して、*トリガー*を作成できます。トリガーは、対象イベントがストリーミングに表示されるたびに自動的に実行されます。たとえば、会社の顧客情報を含む *Customers* テーブルがあるとします。新規の各顧客に、「ようこそ」 E メールを送信するとします。そのテーブルでストリーミングを有効にし、そのストリーミングを Lambda 関数に関連付けます。Lambda 関数は、新しいストリーミングレコードが表示されるたびに実行されますが、*Customers* テーブルに追加された新しい項目のみを処理します。`EmailAddress` 属性を持つ項目について、Lambda 関数は Amazon Simple Email Service (Amazon SES) をコールしてそのアドレスに E メールを送信します。
![\[DynamoDB Streams と Lambda を統合して、新規顧客にウェルカム E メールを自動的に送信します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/HowItWorksStreams.png)
**注記**
この例で、最後の顧客 Craig Roe には `EmailAddress` がないため E メールを受信することはありません。
トリガーに加えて、DynamoDB Streams は AWS リージョン内全体のデータレプリケーション、DynamoDB テーブル内のデータのマテリアライズドビュー、Kinesis のマテリアライズドビューを使用したデータ分析など、数多くの強力なソリューションを可能にします。
詳細については、「[DynamoDB Streams の変更データキャプチャ](Streams.md)」を参照してください。
# DynamoDB API
Amazon DynamoDB を使用するには、アプリケーションでいくつかの簡単な API オペレーションを使用する必要があります。以下に、カテゴリー別にこれらのオペレーションの概要を示します。
**注記**
API オペレーションの完全なリストについては、「[Amazon DynamoDB API リファレンス](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/Welcome.html)」を参照してください。
**Topics**
+ [コントロールプレーン](#HowItWorks.API.ControlPlane)
+ [データプレーン](#HowItWorks.API.DataPlane)
+ [DynamoDB Streams](#HowItWorks.API.Streams)
+ [トランザクション](#HowItWorks.API.Transactions)
## コントロールプレーン
*コントロールプレーン*のオペレーションでは、DynamoDB テーブルを作成および管理できます。また、インデックス、ストリーム、およびテーブルに依存する他のオブジェクトを操作できます。
+ `CreateTable` – 新しいテーブルを作成します。オプションで、1 つ以上のセカンダリインデックスを作成し、テーブルに対して DynamoDB Streams を有効にできます。
+ `DescribeTable` – プライマリキーのスキーマ、スループット設定、インデックス情報など、テーブルに関する情報を返します。
+ `ListTables` – リストのすべてのテーブルの名前を返します。
+ `UpdateTable` – テーブルまたはそのインデックスの設定を変更、テーブルの新しいインデックスを作成または削除、またはテーブルの DynamoDB Streams 設定を変更します。
+ `DeleteTable` – テーブルとそのすべての依存オブジェクトを DynamoDB から削除します。
## データプレーン
*データプレーン*オペレーションでは、テーブルのデータで、作成、読み込み、更新、および削除 (*CRUD* とも呼ばれる) アクションを実行できます。一部のデータプレーンオペレーションでも、セカンダリインデックスからデータを読み込むことができます。
[PartiQL: Amazon DynamoDB 用の SQL 互換クエリ言語](ql-reference.md) を使用してこれらの CRUD オペレーションを実行するか、各オペレーションを個別の API コールに分離する DynamoDB の従来の CRUD API を使用できます。
### PartiQL - SQL 互換クエリ言語
+ `ExecuteStatement` – テーブルから複数の項目を読み込みます。テーブルから単一の項目を書き込むか、更新することもできます。単一の項目を書き込むか、更新する場合は、プライマリキー属性を指定する必要があります。
+ `BatchExecuteStatement` – テーブルから複数の項目を書き込み、更新または読み込みます。これは、`ExecuteStatement` よりも効率的です。アプリケーションで項目を書き込んだり読み込んだりするために、1 回のネットワークラウンドトリップのみで済むためです。
### Classic API
#### データの作成
+ `PutItem` – テーブルに単一の項目を書き込みます。プライマリキー属性を指定する必要がありますが、その他の属性を指定する必要はありません。
+ `BatchWriteItem` – 最大 25 個の項目をテーブルに書き込みます。これは、`PutItem` を複数回呼び出すよりも効率的です。アプリケーションで項目を書き込むために、1 回のネットワークラウンドトリップのみで済むためです。
#### データの読み込み
+ `GetItem` – テーブルから単一の項目を取り出します。目的の項目のプライマリキーを指定する必要があります。項目全体またはその属性のサブセットのみを取り出すことができます。
+ `BatchGetItem` – 1 つ以上のテーブルから最大 100 個の項目を取り出します。これは、`GetItem` を複数回呼び出すよりも効率的です。アプリケーションで項目を読み込むために、1 回のネットワークラウンドトリップのみで済むためです。
+ `Query` – 特定のパーティションキーがあるすべての項目を取り出します。パーティションキーの値を指定する必要があります。項目全体またはその属性のサブセットのみを取り出すことができます。オプションで、ソートキーの値に条件を適用し、同じパーティションキーがあるデータのサブセットだけを取り出すことができます。テーブルにパーティションキーとソートキーの両方を持つテーブルがある場合、テーブルでこのオペレーションを使用できます。また、インデックスにパーティションキーとソートキーの両方がある場合、インデックスでこのオペレーションを使用できます。
+ `Scan` – 指定されたテーブルまたはインデックスのすべての項目を取り出します。項目全体またはその属性のサブセットのみを取り出すことができます。オプションでフィルタリング条件を適用すると、関心のある値のみを返し、残りは破棄できます。
#### データの更新
+ `UpdateItem` – 項目の 1 つ以上の属性を変更します。変更する項目のプライマリキーを指定する必要があります。新しい属性を追加したり、既存の属性を変更または削除したりできます。ユーザー定義の条件を満たす場合にのみ更新が成功するように、条件付きの更新を実行できます。オプションで、アトミックカウンターを実装できます。このカウンタは、他の書き込みリクエストを妨害することなく、数値属性をインクリメントまたはデクリメントします。
#### データの削除
+ `DeleteItem` – テーブルから単一の項目を削除します。削除する項目のプライマリキーを指定する必要があります。
+ `BatchWriteItem` – 1 つ以上のテーブルから最大 25 個の項目を削除します。これは、`DeleteItem` を複数回呼び出すよりも効率的です。アプリケーションで項目を削除するために、1 回のネットワークラウンドトリップのみで済むためです。
**注記**
`BatchWriteItem` は、データの作成とデータの削除の両方に使用できます。
## DynamoDB Streams
*DynamoDB Streams* オペレーションでは、テーブルのストリーミングを有効または無効にし、ストリーミングに含まれるデータ変更レコードにアクセスするように許可します。
+ `ListStreams` – すべてのストリーミングのリスト、または特定のテーブルのストリーミングのみを返します。
+ `DescribeStream` – Amazon リソースネーム (ARN) およびアプリケーションが最初のいくつかのストリーミングレコードの読み込みを開始できる場所など、ストリーミングに関する情報を返します。
+ `GetShardIterator` – *シャードイテレーター*を返します。これは、ストリーミングからレコードを取得するためにアプリケーションが使用するデータ構造です。
+ `GetRecords` – 特定のシャードイテレーターを使用して 1 つ以上のストリーミングレコードを取得します。
## トランザクション
*トランザクション*によって不可分性、一貫性、分離性、耐久性 (ACID) が実現されるため、アプリケーション内でのデータの精度を維持することがさらに容易になります。
[PartiQL: Amazon DynamoDB 用の SQL 互換クエリ言語](ql-reference.md) を使用してこれらのトランザクションオペレーションを実行するか、各オペレーションを個別の API コールに分離する DynamoDB の従来の CRUD API を使用できます。
### PartiQL - SQL 互換クエリ言語
+ `ExecuteTransaction` – テーブル内または複数のテーブル間の複数の項目に対して、オールオアナッシングの結果が保証された CRUD オペレーションを実行できるバッチ操作です。
### Classic API
+ `TransactWriteItems` – テーブル内または複数のテーブル間の複数の項目に対して、オールオアナッシングの結果が保証された `Put`、`Update` および `Delete` オペレーションを実行できるバッチオペレーションです。
+ `TransactGetItems` – 1 つ以上のテーブルから複数の項目を取得する `Get` オペレーションを実行できるバッチ操作です。
# Amazon DynamoDB でサポートされるデータ型と命名規則
このセクションでは、Amazon DynamoDB の命名規則と、DynamoDB がサポートするさまざまなデータ型について説明します。データタイプに適用される制限があります。詳細については、「[データ型](Constraints.md#limits-data-types)」を参照してください。
**Topics**
+ [名前付けルール](#HowItWorks.NamingRules)
+ [データ型](#HowItWorks.DataTypes)
+ [データ型記述子](#HowItWorks.DataTypeDescriptors)
## 名前付けルール
DynamoDB のテーブル、属性、および他のオブジェクトには名前が必要です。名前には意味があり、簡潔でなければなりません。たとえば、*製品*、*ブック*、および*著者*などの名前は一目瞭然です。
DynamoDB の命名規則は次のとおりです。
+ すべての名前は UTF-8 を使用してエンコードする必要があり、大文字と小文字が区別されます。
+ テーブル名とインデックス名の長さは 3～255 文字で、次の文字のみを含めることができます。
+ `a-z`
+ `A-Z `
+ ` 0-9 `
+ `_` (下線)
+ `-` (ダッシュ)
+ `.` (ドット)
+ 属性名は 1 文字以上の長さ、64 KB 未満のサイズにする必要があります。属性名はできるだけ短くすることがベストプラクティスであると考えられています。これにより、属性名がストレージとスループットの使用量の測定に含まれるため、消費される読み取りリクエストユニットを減らすことができます。
以下の例外があります。これらの属性名は 255 文字以下である必要があります。
+ セカンダリインデックスのパーティションキー名
+ セカンダリインデックスのソートキー名
+ ユーザー指定の射影された属性の名前 (ローカルセカンダリインデックスにのみ適用)
### 予約語と特殊文字
DynamoDB には予約語と特殊文字のリストもあります。詳細な一覧については、「[DynamoDB の予約語](ReservedWords.md)」を参照してください。DynamoDB では、**\$1** (ハッシュ) および **:** (コロン) に特別な意味があります。
DynamoDB では、命名目的でこれらの予約語と特殊文字を使用することができますが、お勧めしません。これは、式でこれらの名前を使用するたびに、プレースホルダー変数を定義する必要があるためです。詳細については、「[DynamoDB の式の属性名 (エイリアス)](Expressions.ExpressionAttributeNames.md)」を参照してください。
## データ型
DynamoDB では、テーブル内の属性に対してさまざまなデータ型がサポートされています。データ型は次のように分類できます。
+ **スカラー型** – スカラー型は 1 つの値を表すことができます。スカラー型は、数値、文字列、バイナリ、ブール、および null です。
+ **ドキュメント型** – JSON ドキュメントで見られるように、入れ子の属性を持つ複雑な構造を表すことができます。ドキュメント型は、リストとマップです。
+ **セット型** – セット型は複数のスカラー値を表すことができます。セット型は、文字セット、数値セット、およびバイナリセットです。
テーブルまたはセカンダリインデックスを作成するときは、各プライマリキー属性 (パーティションキーとソートキー) の名前とデータ型を指定する必要があります。さらに、各プライマリキー属性は、文字列、数値、またはバイナリとして定義する必要があります。
DynamoDB は NoSQL データベースであり、*スキーマレス*です。つまり、テーブルを作成する場合、プライマリキー属性を除き、属性やデータ型を定義する必要はありません。これに対して、リレーショナルデータベースでは、テーブルの作成時に各列の名前とデータ型を定義する必要があります。
ここでは、各データ型について JSON 形式の例を挙げて説明します。
### スカラー型
スカラー型は、数値、文字列、バイナリ、ブール、および null です。
#### Number
数値は、正、負、または 0 とすることができます。数値は最大 38 桁の精度を持つことができます。これを超えると例外が発生します。38 桁を超える精度が必要な場合は、文字列を使用できます。
+ 正の範囲: 1E-130～9.9999999999999999999999999999999999999E\$1125
+ 負の範囲: -9.9999999999999999999999999999999999999E\$1125～-1E-130
DynamoDB では、数値は可変長で表されます。先頭と末尾の 0 は切り捨てられます。
すべての数値はネットワーク経由で文字列として DynamoDB に送信され、言語やライブラリ間の互換性が最大になります。ただし、DynamoDB は算術演算では数値を数値型属性として扱います。
数値データ型を使用して、日付またはタイムスタンプを表すことができます。これを行うための方法の 1 つは、1970 年 1 月 1 日 00:00:00 UTC から経過した秒数であるエポックタイムを使用することです。たとえば、エポック時間 `1437136300` は、2015 年 7 月 17 日の 12:31:40 PM UTC を表します。
詳細については、[http://en.wikipedia.org/wiki/Unix\$1time](http://en.wikipedia.org/wiki/Unix_time) を参照してください。
#### String
文字列は、UTF-8 バイナリエンコードの Unicode です。属性がインデックスまたはテーブルのキーとして使用されない場合、文字列の最小長は 0 になります。また、DynamoDB 項目の最大サイズ上限である 400 KB の制約があります。
文字列型として定義されているプライマリキー属性には、さらに以下の制約が適用されます。
+ シンプルなプライマリキーの場合、最初の属性値 (パーティションキー) の最大長は 2,048 バイトです。
+ 複合プライマリキーの場合、2 番目の属性値 (ソートキー) の最大長は 1,024 バイトです。
DynamoDB は、基礎となる UTF-8 文字列エンコードのバイトを使用して文字列を照合し、比較します。たとえば、「`a`」 (0x61) は「`A`」 (0x41) より大きく、「`¿`」 (0xC2BF) は 「`z`」 (0x7A) より大きいです。
文字列データ型を使用して、日付またはタイムスタンプを表すことができます。これを行う 1 つの方法は、これらの例に示すように、ISO 8601 文字列を使用することです。
+ `2016-02-15`
+ `2015-12-21T17:42:34Z`
+ `20150311T122706Z`
詳細については、[http://en.wikipedia.org/wiki/ISO\$18601](http://en.wikipedia.org/wiki/ISO_8601) を参照してください。
**注記**
従来のリレーショナルデータベースとは異なり、DynamoDB は日付と時刻のデータ型をネイティブにサポートしていません。代わりに、Unix エポック時間を使用して、日付と時刻のデータを数値データ型として保存すると便利です。
#### バイナリ
バイナリ型の属性には、圧縮テキスト、暗号化データ、イメージなど、任意のバイナリデータが保存されます。DynamoDB は、バイナリ値を比較するたびに、各バイナリデータを符号なしとして扱います。
属性がインデックスまたはテーブルのキーとして使用されず、DynamoDB 項目の最大サイズ上限が 400 KB に制約されている場合、バイナリ属性の長さは 0 になります。
プライマリキー属性をバイナリ型属性として定義する場合、以下の制約がさらに適用されます。
+ シンプルなプライマリキーの場合、最初の属性値 (パーティションキー) の最大長は 2,048 バイトです。
+ 複合プライマリキーの場合、2 番目の属性値 (ソートキー) の最大長は 1,024 バイトです。
アプリケーションは、DynamoDB に送信する前に、base64 エンコード形式のバイナリ値をエンコードする必要があります。DynamoDB は、これらの値を受信すると、データを符号なしバイト配列にデコードし、それをバイナリ属性の長さとして使用します。
次に示しているのはバイナリ属性の例であり、Base64 でエンコードされたテキストを使用しています。
```
dGhpcyB0ZXh0IGlzIGJhc2U2NC1lbmNvZGVk
```
#### ブール値
ブール型の属性には、`true` または `false` が格納されます。
#### Null
Null は不明または未定義の状態の属性を表します。
### ドキュメント型
ドキュメント型は、リストとマップです。これらのデータ型は、相互に入れ子にして、最大 32 レベルの深さまで複雑なデータ構造を表すことができます。
値を含む項目が DynamoDB のサイズ制限 (400 KB) 内である限り、リストまたはマップの値の最大数の制限はありません。
属性値がテーブルまたはインデックスキーに使用されていない場合、空の文字列または空のバイナリ値にすることができます。属性値は空の文字列または空のセット (文字列セット、数値セット、またはバイナリセット) にすることはできませんが、空のリストとマップは許可されます。リストとマップ内では、空の文字列とバイナリ値が許可されます。詳細については、「[属性](Constraints.md#limits-attributes)」を参照してください。
#### リスト
リスト型の属性には、順序付きの値のコレクションを保存できます。リストは角括弧で囲まれます: `[ ... ]`
リストは JSON 配列に似ています。リスト要素に保存できるデータ型に制限はなく、リスト要素の要素が同じ型である必要はありません。
次の例は、2 つの文字列と数が含まれるリストを示します。
```
FavoriteThings: ["Cookies", "Coffee", 3.14159]
```
**注記**
DynamoDB では、要素が深い入れ子になっていても、リスト内の個々の要素を操作できます。詳細については、「[DynamoDB での式の使用](Expressions.md)」を参照してください。
#### マップ
マップ型属性は、順序なしの名前と値のペアのコレクションを保存できます。マップは中括弧で囲まれます: `{ ... }`
マップは、JSON オブジェクトと同様です。マップの要素に保存できるデータ型に制限はなく、マップの要素が同じ型である必要はありません。
マップは DynamoDB で JSON ドキュメントを保存するのに最適です。以下の例は、文字列、数値、別のマップを含む入れ子のリストを要素とするマップを示しています。
```
{
Day: "Monday",
UnreadEmails: 42,
ItemsOnMyDesk: [
"Coffee Cup",
"Telephone",
{
Pens: { Quantity : 3},
Pencils: { Quantity : 2},
Erasers: { Quantity : 1}
}
]
}
```
**注記**
DynamoDB では、要素が深い入れ子になっていても、マップ内の個々の要素を操作できます。詳細については、「[DynamoDB での式の使用](Expressions.md)」を参照してください。
### セット
DynamoDB は、数値、文字列、またはバイナリ値のセットを表す型をサポートします。セット内の要素はすべて、同じ型である必要があります。例えば、数値セットには数値のみを含めることができ、文字列セットには文字列のみを含めることができます。
値を含む項目が DynamoDB のサイズ制限 (400 KB) 内である限り、セットの値の最大数の制限はありません。
設定内の各値は一意である必要があります。設定内の値の順序は保持されません。したがって、アプリケーションは、設定内の要素の特定の順序に依存することはできません。DynamoDB は空のセットをサポートしていませんが、セット内の空の文字列とバイナリ値は許可されます。
次の例では、文字列セット、設定された numbet とバイナリ設定を示します:
```
["Black", "Green", "Red"]
[42.2, -19, 7.5, 3.14]
["U3Vubnk=", "UmFpbnk=", "U25vd3k="]
```
## データ型記述子
低レベルの DynamoDB API プロトコルは、各属性を解釈する方法を DynamoDB に伝えるトークンとして、*データ型記述子*を使用します。
DynamoDB データ型記述子の一覧を次に示します。
+ **`S`** — 文字列
+ **`N`** — 数値
+ **`B`** — バイナリ
+ **`BOOL`** — ブール
+ **`NULL`** — Null
+ **`M`** — マップ
+ **`L`** — リスト
+ **`SS`** — 文字列セット
+ **`NS`** — 数値セット
+ **`BS`** — バイナリセット
# DynamoDB テーブルクラス
DynamoDB には、コストの最適化に役立つように設計された 2 つのテーブルクラスが用意されています。DynamoDB 標準テーブルクラスがデフォルトで、大半のワークロードで推奨されています。DynamoDB Standard-Infrequent Access (DynamoDB 標準-IA) テーブルクラスは、ストレージが主要なコストとなるテーブル用に最適化されています。例えば、アプリケーションログ、古いソーシャルメディアの投稿、e コマースの注文履歴、過去のゲーム実績など、アクセス頻度の低いデータを格納するテーブルは、標準-IA テーブルクラスの候補として適しています。料金の詳細については、「[Amazon DynamoDB の料金表](https://aws.amazon.com/dynamodb/pricing/on-demand/)」を参照してください。
すべての DynamoDB テーブルは、テーブルクラス (デフォルトでは DynamoDB Standard) に関連付けられます 。テーブルに関連付けられたすべてのセカンダリインデックスは、同じテーブルクラスを使用します。各テーブルクラスで、データストレージと読み込み/書き込みリクエストに対して異なる料金が適用されます。ストレージとスループットの使用パターンに基づいて、テーブルに対して最も費用対効果の高いテーブルクラスを選択できます。
テーブルクラスの選択は永続的ではありません。この設定は、AWS マネジメントコンソール、AWS CLI、または AWS SDK を使用して変更できます。DynamoDB は、シングルリージョンテーブルとグローバルテーブルに対して AWS CloudFormation を使用したテーブルクラスの管理もサポートしています。テーブルクラスの選択の詳細については、「[DynamoDB でテーブルクラスを選択する場合の考慮事項](WorkingWithTables.tableclasses.md)」を参照してください。
# DynamoDB におけるパーティションとデータ分散
Amazon DynamoDB は、データをパーティションに保存します。*パーティション*は、ソリッドステートドライブ (SSD) によってバックアップされ、AWS リージョン内の複数のアベイラビリティーゾーン間で自動的にレプリケートされる、テーブル用のストレージの割り当てです。パーティション管理は DynamoDB によって完全に処理されます。パーティションをご自身が管理する必要はありません。
テーブルを作成するときに、テーブルの最初のステータスは `CREATING` になります。このフェーズの間に、DynamoDB はテーブルに十分なパーティションを割り当て、プロビジョンされたスループット要件に対応できるようにします。テーブルのステータスが `ACTIVE` に変わったらテーブルデータの書き込みと読み取りを開始できます。
DynamoDB は次の状況でテーブルに追加のパーティションを割り当てます。
+ テーブルのプロビジョニングされたスループット設定を、既存のパーティションがサポートできる以上に増やした。
+ 既存のパーティションが容量いっぱいになり、より多くのストレージ領域が必要になった。
パーティション管理は自動的にバックグラウンドで自動的に発生し、アプリケーションに対して透過的です。テーブルは利用可能な状態のままで、プロビジョニングされたスループット要件を完全にサポートします。
詳細については、[パーティションキーの設計](bp-partition-key-design.md)を参照してください。
DynamoDB のグローバルセカンダリインデックスもパーティションで構成されます。グローバルセカンダリインデックスのデータは、基本テーブルのデータとは別に保存されますが、インデックスパーティションはテーブルパーティションと同様に動作します。
## データ分散: パーティションキー
テーブルにシンプルなプライマリキー (パーティションキーのみ) がある場合、DynamoDB はパーティションキーバリューに基づいて、各項目を保存および取得します。
DynamoDB は項目をテーブルに書き込むため、パーティションキーバリューを内部ハッシュ関数への入力として使用します。ハッシュ関数からの出力値によって、項目が保存されるパーティションが決まります。
テーブルから項目を読み込むには、項目のパーティションキーバリューを指定する必要があります。DynamoDB はこの値をハッシュ関数への入力として使用し、項目が見つかるパーティションを提供します。
次の図は、複数のパーティションにまたがる *Pets* という名前のテーブルを示しています。テーブルのプライマリキーは *AnimalType* (このキー属性のみが表示されます。) DynamoDB は、ハッシュ関数を使用して、新しい項目を保存する場所を決定します。この場合は、文字列 *Dog* のハッシュ値に基づいています。項目はソート順に保存されないことに注意してください。各アイテムの場所は、そのパーティションキーのハッシュ値によって決まります。
![\[パーティションキーのハッシュ値に基づく、DynamoDB でのパーティション間のテーブル項目の分散。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/HowItWorksPartitionKey.png)
**注記**
DynamoDB は、パーティション数にかかわらず、項目がテーブルのパーティション全体に渡って均一にディストリビューションされている状態に対して最適化されています。テーブルの項目数に対して大きな個別の値を持つことができるパーティションキーを選択することをお勧めします。
## データ分散: パーティションキーおよびソートキー
テーブルに複合プライマリキー (パーティションキーとソートキー) がある場合、DynamoDB は [データ分散: パーティションキー](#HowItWorks.Partitions.SimpleKey) で説明したのと同じ方法でパーティションキーのハッシュ値を計算します。ただし、パーティションキーの値が同じ項目は互いに近く、ソートキー属性の値によってソートされた順序になる傾向があります。パーティションキー属性の値が同じ項目のセットは、項目コレクションと呼ばれます。項目コレクションは、コレクション内の項目の範囲を効率的に取得できるように最適化されています。テーブルにローカルセカンダリインデックスがない場合、DynamoDB は、データを保存し、読み取りと書き込みのスループットを実現するために必要な数のパーティションに自動的に項目コレクションを分割します。
テーブルに項目を書き込むため、DynamoDB はパーティションキーのハッシュ値を計算し、項目を含めるパーティションを決定します。そのパーティションでは、いくつかの項目で同じパーティションキー値を持つことができます。そのため、DynamoDB には、同じパーティションキーを持つ他の項目とソートキーの昇順で項目が保存されます。
テーブルから項目を読み込むには、パーティションのキーバリューとソートキーのキーバリューを指定する必要があります。DynamoDB は、パーティションキーのハッシュ値を計算し、項目が見つかるパーティションを提供します。
目的の項目に同じパーティションキーバリューがある場合、単一のオペレーション (`Query`) でテーブルから複数の項目を読み取ることができます。DynamoDB は、そのパーティションのキーバリューを持つすべての項目を返します。オプションでソートキーに条件を適用し、特定範囲内の値を持つ項目だけを返すことができます。
*Pets* テーブルに、*AnimalType* (パーティションキー) と *Name* (ソートキー) で構成される複合プライマリキーがあるとします。次の図表は、DynamoDB がパーティションのキーバリューが *Dog* でソートキー値が *Fido* の項目を書き込んでいるところを示しています。
![\[DynamoDB は、複合パーティションキーを持つ項目を保存し、ソートキー属性の値を使用して項目をソートします。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/HowItWorksPartitionKeySortKey.png)
*Pets* テーブルから同じ項目を読み込むために、DynamoDB は、ハッシュ値 *Dog* を計算し、これらの項目が保存されたパーティションを提供します。次に、DynamoDB は、*Fido* が見つかるまで、ソートキーの属性値をスキャンします。
*AnimalType* が *Dog* のすべての項目を読み込むには、ソートキーの条件を指定しないで `Query` オペレーションを発行できます。デフォルトでは、項目は保存されている順序 (つまり、ソートキーによって昇順でソート) で返されます。オプションで、代わりに降順をリクエストできます。
一部の *Dog* 項目のみをクエリするには、ソートキーに条件を適用できます (たとえば、*Name* が `A` から `K` の範囲内の文字で始まる *Dog* 項目のみ)。
**注記**
DynamoDB テーブルには、パーティションキーバリューごとに個別のソートキーバリューの数に上限はありません。何十億もの *Dog* 項目を *Pets* テーブルに保存する必要がある場合、DynamoDB はこの要件を自動的に処理するのに十分なストレージを割り当てます。
# SQL から NoSQL に移行する方法について学ぶ
アプリケーションデベロッパーなら、リレーショナルデータベース管理システム (RDBMS) および構造化クエリ言語 (SQL) を使用した経験があるかもしれません。Amazon DynamoDB を使い始めると、多くの類似点があると同時に、異なる点も多くあることに気づきます。*NoSQL* は、可用性が高く、スケーラブルで、高パフォーマンス用に最適化された、非リレーショナルデータベースシステムについて説明するのに使用される用語です。NoSQL データベース (DynamoDB など) は、リレーショナルモデルの代わりに、キーバリューのペアやドキュメントストレージなど、データ管理のための代替モデルを使用します。詳細については、「[NoSQL とは](https://aws.amazon.com/nosql)」を参照してください。
Amazon DynamoDB は [PartiQL](https://partiql.org/) をサポートしています。PartiQL は、オープンソースの SQL 互換のクエリ言語で、データの格納場所や形式に関係なく、データへの効率的なクエリの実行が簡単に行えます。PartiQL を使用すると、リレーショナルデータベースの構造化データ、オープンデータ形式の半構造化データおよびネストされたデータ、さらには行ごとに異なる属性を許可する NoSQL またはドキュメントデータベース内のスキーマレスデータを簡単に処理できます。詳細については、「[PartiQL Query Language](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html)」(PartiQL クエリ言語) を参照してください。
次のセクションでは、SQL ステートメントを同等の DynamoDB オペレーションと比較および対比しながら、一般的なデータベースタスクについて説明します。
**注記**
このセクションの SQL の例は、MySQL の RDBMS と互換性があります。
このセクションの DynamoDB 例では、JSON 形式のオペレーションのパラメータと共に DynamoDB オペレーションの名前を表示します。
**Topics**
+ [リレーショナル (SQL) または NoSQL の選択](SQLtoNoSQL.WhyDynamoDB.md)
+ [リレーショナル (SQL) データベースと DynamoDB へのアクセスの相違点](SQLtoNoSQL.Accessing.md)
+ [テーブル作成時のリレーショナル (SQL) データベースと DynamoDB の相違点](SQLtoNoSQL.CreateTable.md)
+ [リレーショナル (SQL) データベースと DynamoDB からテーブル情報を取得するときの相違点](SQLtoNoSQL.GetTableInfo.md)
+ [テーブルにデータを書き込むときのリレーショナル (SQL) データベースと DynamoDB の相違点](SQLtoNoSQL.WriteData.md)
+ [テーブルからデータを読み込むときの、リレーショナル (SQL) データベースと DynamoDB の相違点](SQLtoNoSQL.ReadData.md)
+ [インデックスを管理するときのリレーショナル (SQL) データベースと DynamoDB の相違点](SQLtoNoSQL.Indexes.md)
+ [テーブル内のデータを変更するときのリレーショナル (SQL) データベースと DynamoDB の相違点](SQLtoNoSQL.UpdateData.md)
+ [テーブルからデータを削除するときのリレーショナル (SQL) データベースと DynamoDB の相違点](SQLtoNoSQL.DeleteData.md)
+ [テーブルを削除するときのリレーショナル (SQL) データベースと DynamoDB の相違点](SQLtoNoSQL.RemoveTable.md)
# リレーショナル (SQL) または NoSQL の選択
現在のアプリケーションには今までになく厳しい要件があります。たとえば、あるオンラインゲームを、小数のユーザーおよび非常に小さいデータ量で開始するかもしれません。しかし、ゲームが成功すれば、それは基盤となるデータベース管理システムのリソースを簡単に上回ります。ウェブベースのアプリケーションに、数百、数千、数百万の同時ユーザーがいて、テラバイトあるいはそれ以上の新しいデータが毎日生成される、というのはよくあることです。そのようなアプリケーションのデータベースの場合は、1 秒あたり数万 (あるいは数十万) の読み取り/書き込みの処理が必要です。
Amazon DynamoDB は、これらのワークロードに適しています。デベロッパーとして、アプリケーションを小さく開始し、人気が出るにつれて徐々に増加させることができます。DynamoDB は、大量のデータや多数のユーザーの処理をシームレスにスケーリングします。
従来のリレーショナルデータベースモデリングと DynamoDB に適応させる方法の詳細については、「[DynamoDB でリレーショナルデータをモデル化するためのベストプラクティス](bp-relational-modeling.md)」を参照してください。
次の表に、リレーショナルデータベース管理システム (RDBMS) と DynamoDB の高度な相違点を示します。
****
| 特性 | リレーショナルデータベース管理システム (RDBMS) | Amazon DynamoDB |
| --- | --- | --- |
| 最適なワークロード | アドホッククエリ、データウェアハウス、OLAP (オンライン分析処理)。 | ソーシャルネットワーク、ゲーム、メディア共有、Internet of Things (IoT) を含む、ウェブスケールアプリケーションです。 |
| データモデル | リレーショナルモデルには、データを、テーブル、行、列に正規化する、明確に定義されたスキーマが必要です。さらに、関係のすべては、テーブル、列、インデックスおよび他のデータベースのエレメント間で定義されます。 | DynamoDB はスキーマレスです。すべてのテーブルに、各データ項目を一意に識別するプライマリキーが必要ですが、他の非キー属性のような制約はありません。DynamoDB では、JSON ドキュメントを含む構造化データまたは半構造化データを管理できます。 |
| データアクセス | SQL は、データを保存および取得するための基準です。リレーショナルデータベースにはデータベース駆動型アプリケーションの開発を簡素化するためのツールが豊富ですが、これらのツールはすべて、SQL を使用します。 | AWS マネジメントコンソール、AWS CLI、または NoSQL WorkBench を使用して DynamoDB を操作し、アドホックタスクを実行できます。[PartiQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html) は SQL 互換のクエリ言語であり、DynamoDB でデータの選択、挿入、更新、および削除を行うことができます。アプリケーションでは、オブジェクトベースでドキュメント中心、または低レベルのインターフェイスを使用しながら、AWS ソフトウェア開発キット (SDK) を活用し、DynamoDB を操作できます。 |
| パフォーマンス | リレーショナルデータベースは、ストレージに最適化されていますので、パフォーマンスは通常、ディスクサブシステムによって異なります。デベロッパーとデータベース管理者は、ピークパフォーマンスを達成するために、クエリ、インデックスおよびテーブルの構造を最適化する必要があります。 | DynamoDB は、コンピューティングに最適化されていますので、パフォーマンスは主に、基盤となるハードウェアとネットワークレイテンシーの機能です。マネージドサービスとして、DynamoDB は、これらの実装の詳細からアプリケーションを隔離し、堅牢で高パフォーマンスなアプリケーションの設計と構築に集中できるようにします。 |
| スケーリング | より高速なハードウェアでスケールアップするのが最も簡単です。データベーステーブルが分散システムの複数のホストにまたがることは可能ですが、この場合、追加の投資が必要です。リレーショナルデータベースは、スケーラビリティに上限を課すファイルの数とサイズが最大サイズです。 | DynamoDB は、ハードウェアの分散型クラスターを使用してスケールアウトできるように設計されています。この設計により、レイテンシーの増加なしでスループットを強化することができます。顧客がスループット要件を指定すると、DynamoDB は、その要件に対応するために十分なリソースを割り当てます。テーブル単位の項目数、およびそのテーブルの合計サイズに上限はありません。 |
# リレーショナル (SQL) データベースと DynamoDB へのアクセスの相違点
アプリケーションがデータベースにアクセスする前に、アプリケーションがデータベースの使用を許可されるように*認証*する必要があります。アプリケーションで、許可されているアクションのみ実行できるように、*許可*する必要があります。
次の図表は、クライアントのリレーショナルデータベースおよび Amazon DynamoDB とのやり取りを示します。
![\[リレーショナルおよび NoSQL データベースとのやり取り。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/SQLtoNoSQL.png)
次の表にクライアントのやり取りのタスクについての詳細があります。
****
| 特徴 | リレーショナルデータベース管理システム (RDBMS) | Amazon DynamoDB |
| --- | --- | --- |
| データベースにアクセスするためのツール | ほとんどのリレーショナルデータベースは、コマンドラインインターフェイス (CLI) を提供しており、アドホックな SQL ステートメントを入力して、結果をすぐに見ることができます。 | ほとんどの場合、アプリケーションコードを書き込みます。AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、または NoSQL Workbench を使用して、アドホックリクエストを DynamoDB に送信し、結果を表示することもできます。[PartiQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html) は SQL 互換のクエリ言語であり、DynamoDB でデータの選択、挿入、更新、および削除を行うことができます。 |
| データベースに接続 | アプリケーションプログラムは、データベースを使用したネットワーク接続を確立し、維持します。アプリケーションが終了すると、接続を終了します。 | DynamoDB は、ウェブサービスで、その操作はステートレスです。アプリケーションは永続的ネットワーク接続を維持する必要はありません。代わりに、DynamoDB の操作は HTTP(S) リクエストおよびレスポンスを使用して行われます。 |
| 認証 | アプリケーションが認証されるまでデータベースに接続できません。RDBMS は認証自体を実行できますし、ホストのオペレーティングシステムやディレクトリサービスにこのタスクをオフロードすることもできます。 | DynamoDB に対するすべてのリクエストは、その特定のリクエストを認証する暗号署名と共に使用しなければなりません。AWS SDK は、署名の作成とリクエストの署名に必要なすべての論理を提供します。詳細については、「AWS 全般のリファレンス.」の「[AWS API リクエストの署名](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html)」を参照してください。 |
| Authorization | アプリケーションは承認されたアクションのみ実行できます。データベース管理者またはアプリケーション所有者は、SQL GRANT および REVOKE ステートメントを使用して、データベースオブジェクト (テーブルなど)、データ (テーブル内の行など)、特定の SQL ステートメントを発行する機能へのアクセスを制御できます。 | DynamoDB では、AWS Identity and Access Management (IAM) が承認を行います。DynamoDB リソース (テーブルなど) へのアクセス許可を付与する IAM ポリシーを記述し、ユーザーとロールがそのポリシーを使用できるようにします。IAM では、DynamoDB テーブルの個々のデータ項目に対する詳細なアクセス制御といった特徴も備えています。詳細については、「[Amazon DynamoDB の Identity and Access Management](security-iam.md)」を参照してください。 |
| リクエストを送信 | アプリケーションは、実行するすべてのデータベース操作に対する SQL ステートメントを発行します。SQL ステートメントを受信すると、RDBMS は構文を確認し、オペレーションを実行するための計画を作成してから、計画を実行します。 | アプリケーションは、HTTP(S) リクエストを DynamoDB に送信します。リクエストには、パラメータとともに、実行する DynamoDB オペレーションの名前が含まれます。DynamoDB はリクエストを直ちに実行します。 |
| レスポンスを受信 | RDBMS は SQL ステートメントから結果を返します。エラーがある場合は、RDBMS はエラー状況とエラーメッセージを返します。 | DynamoDB は、オペレーションの結果を含む HTTP(S) レスポンスを返します。エラーがあると、DynamoDB は、HTTP エラー状況およびエラーメッセージを返します。 |
# テーブル作成時のリレーショナル (SQL) データベースと DynamoDB の相違点
テーブルは、リレーショナルデータベースおよび Amazon DynamoDB の基本的なデータ構造です。リレーショナルデータベース管理システム (RDBMS) では、作成時に、テーブルのスキーマを定義する必要があります。対照的に、DynamoDB テーブルはスキーマレスであるため、プライマリキーを除いて、テーブルを作成する際に、追加の属性やデータ型を定義する必要はありません。
次のセクションでは、SQL を使用してテーブルを作成する方法と、DynamoDB を使用してテーブルを作成する方法を比較します。
**Topics**
+ [SQL を使用してテーブルを作成する](#SQLtoNoSQL.CreateTable.SQL)
+ [DynamoDB を使用してテーブルを作成する](#SQLtoNoSQL.CreateTable.DynamoDB)
## SQL を使用してテーブルを作成する
SQL では、次の例に示すように、`CREATE TABLE` ステートメントを使用して、テーブルを作成します。
```
CREATE TABLE Music (
Artist VARCHAR(20) NOT NULL,
SongTitle VARCHAR(30) NOT NULL,
AlbumTitle VARCHAR(25),
Year INT,
Price FLOAT,
Genre VARCHAR(10),
Tags TEXT,
PRIMARY KEY(Artist, SongTitle)
);
```
このテーブルのプライマリキーは、*Artist* および *SongTitle* で構成されます。
テーブルの列とデータ型すべて、およびテーブルのプライマリキーを定義する必要があります。(これらの定義は、`ALTER TABLE` ステートメントを使用して、必要に応じて後で変更することができます。)
多くの SQL 実装では、`CREATE TABLE` ステートメントの一部として、テーブルのストレージ仕様を定義することができます。他に明記されていない限り、テーブルはデフォルトのストレージ設定で作成されます。本稼働環境では、データベース管理者は最適なストレージパラメータを特定することもできます。
## DynamoDB を使用してテーブルを作成する
`CreateTable` オペレーションを使用してプロビジョニングモードのテーブルを作成し、次に示すように、パラメータを指定します。
```
{
TableName : "Music",
KeySchema: [
{
AttributeName: "Artist",
KeyType: "HASH" //Partition key
},
{
AttributeName: "SongTitle",
KeyType: "RANGE" //Sort key
}
],
AttributeDefinitions: [
{
AttributeName: "Artist",
AttributeType: "S"
},
{
AttributeName: "SongTitle",
AttributeType: "S"
}
],
ProvisionedThroughput: { // Only specified if using provisioned mode
ReadCapacityUnits: 1,
WriteCapacityUnits: 1
}
}
```
このテーブルのプライマリキーは、*Artist* (パーティションキー) および *SongTitle* (ソートキー) で構成されています。
`CreateTable` に以下のパラメータを提供する必要があります。
+ `TableName` – テーブルの名前。
+ `KeySchema` – プライマリキーに使用する属性。詳細については、「[テーブル、項目、属性](HowItWorks.CoreComponents.md#HowItWorks.CoreComponents.TablesItemsAttributes)」および「[プライマリキー](HowItWorks.CoreComponents.md#HowItWorks.CoreComponents.PrimaryKey)」を参照してください。
+ `AttributeDefinitions` – キースキーマ属性のデータ型。
+ `ProvisionedThroughput (for provisioned tables)` – このテーブルに必要な 1 秒あたりの読み取り/書き込み数。DynamoDB は、スループット要件を常に満たすように、十分なストレージとシステムリソースを確保しています。これらは、`UpdateTable` オペレーションを使用し、必要に応じて後で変更できます。DynamoDB がストレージ割り当てを完全に管理しているため、テーブルのストレージ要件を指定する必要はありません。
# リレーショナル (SQL) データベースと DynamoDB からテーブル情報を取得するときの相違点
テーブルが仕様に従って作成されたことを確認できます。リレーショナルデータベースでは、テーブルのスキーマがすべて表示されます。Amazon DynamoDB テーブルはスキーマレスであるため、プライマリキー属性のみが表示されます。
**Topics**
+ [SQL を使ってテーブルに関する情報を取得する](#SQLtoNoSQL.GetTableInfo.SQL)
+ [DynamoDB でテーブルに関する情報を取得する](#SQLtoNoSQL.GetTableInfo.DynamoDB)
## SQL を使ってテーブルに関する情報を取得する
ほとんどのリレーショナルデータベース管理システム (RDBMS) では、テーブルの構造 (列、データ型、プライマリキー定義など) を記述できます。SQL にはこれを行うための標準的な方法はありません。ただし、データベースシステムの多くが `DESCRIBE` コマンドを提供しています。MySQL の例を以下に示します。
```
DESCRIBE Music;
```
すべての列名、データ型、サイズを含むテーブルの構造が返ります。
```
+------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| Artist | varchar(20) | NO | PRI | NULL | |
| SongTitle | varchar(30) | NO | PRI | NULL | |
| AlbumTitle | varchar(25) | YES | | NULL | |
| Year | int(11) | YES | | NULL | |
| Price | float | YES | | NULL | |
| Genre | varchar(10) | YES | | NULL | |
| Tags | text | YES | | NULL | |
+------------+-------------+------+-----+---------+-------+
```
このテーブルのプライマリキーは、*Artist* および *SongTitle* で構成されます。
## DynamoDB でテーブルに関する情報を取得する
DynamoDB には、同様の `DescribeTable` オペレーションがあります。パラメータは、テーブル名のみです。
```
{
TableName : "Music"
}
```
`DescribeTable` からの返信は、次のようになります。
```
{
"Table": {
"AttributeDefinitions": [
{
"AttributeName": "Artist",
"AttributeType": "S"
},
{
"AttributeName": "SongTitle",
"AttributeType": "S"
}
],
"TableName": "Music",
"KeySchema": [
{
"AttributeName": "Artist",
"KeyType": "HASH" //Partition key
},
{
"AttributeName": "SongTitle",
"KeyType": "RANGE" //Sort key
}
],
...
```
`DescribeTable` は、テーブルのインデックス、プロビジョニングされたスループット設定、概算項目数、その他メタデータに関する情報を返します。
# テーブルにデータを書き込むときのリレーショナル (SQL) データベースと DynamoDB の相違点
リレーショナルデータベースのテーブルには、データの*行*が含まれます。行は*列*で構成されます。Amazon DynamoDB テーブルには、*項目*が含まれています。項目は*属性*で構成されます。
このセクションでは、テーブルに 1 つの行 (または項目) を書き込む方法を説明します。
**Topics**
+ [SQL を使ってテーブルにデータを書き込む](#SQLtoNoSQL.WriteData.SQL)
+ [DynamoDB のテーブルにデータを書き込む](#SQLtoNoSQL.WriteData.DynamoDB)
## SQL を使ってテーブルにデータを書き込む
リレーショナルデータベースのテーブルは、行と列で構成される、2 つのディメンションのデータ構造です。一部のデータベース管理システムは、通常、ネイティブ JSON または XML データ型を使用する半構造化データのサポートを提供します。ただし、実装の詳細はベンダー間で変わります。
SQL では、`INSERT` ステートメントを使用して、テーブルに行を追加します。
```
INSERT INTO Music
(Artist, SongTitle, AlbumTitle,
Year, Price, Genre,
Tags)
VALUES(
'No One You Know', 'Call Me Today', 'Somewhat Famous',
2015, 2.14, 'Country',
'{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}'
);
```
このテーブルのプライマリキーは、*Artist* と *SongTitle* で構成されます。これらの列の値を指定する必要があります。
**注記**
この例では、*Tags* 列を使用して、*Music* テーブル内の曲に関する半構造化データを保存します。*Tags* 列は TEXT 型として定義され、MySQL で最大 65,535 文字を保存できます。
## DynamoDB のテーブルにデータを書き込む
Amazon DynamoDB では、DynamoDB API または [PartiQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html) (SQL 互換のクエリ言語) を使用して、テーブルに項目を追加できます。
------
#### [ DynamoDB API ]
DynamoDB API では、`PutItem` オペレーションを使用して、テーブルに項目を追加します。
```
{
TableName: "Music",
Item: {
"Artist":"No One You Know",
"SongTitle":"Call Me Today",
"AlbumTitle":"Somewhat Famous",
"Year": 2015,
"Price": 2.14,
"Genre": "Country",
"Tags": {
"Composers": [
"Smith",
"Jones",
"Davis"
],
"LengthInSeconds": 214
}
}
}
```
このテーブルのプライマリキーは、*Artist* および *SongTitle* で構成されます。これらの属性の値を指定する必要があります。
この `PutItem` 例に関する主要事項を示します。
+ DynamoDB では、JSON を使用して、ドキュメントのネイティブサポートを提供しています。これにより DynamoDB は *Tags* などの半構造化データを保存する場合に最適になります。また、JSON ドキュメント内からデータを取得および操作できます。
+ *Music* テーブルには、プライマリキー (*Artist* および *SongTitle*) 以外には事前定義された属性はありません。
+ ほとんどの SQL データベースはトランザクション指向です。`INSERT` ステートメントを発行すると、データ変更は、`COMMIT` ステートメントを発行するまで永続的ではありません。Amazon DynamoDB によって、`PutItem` オペレーションの効果は、DynamoDB が HTTP 200 ステータスコード (`OK`) で応答する場合、永続的になります。
次に、`PutItem` の他の例をいくつか示します。
```
{
TableName: "Music",
Item: {
"Artist": "No One You Know",
"SongTitle": "My Dog Spot",
"AlbumTitle":"Hey Now",
"Price": 1.98,
"Genre": "Country",
"CriticRating": 8.4
}
}
```
```
{
TableName: "Music",
Item: {
"Artist": "No One You Know",
"SongTitle": "Somewhere Down The Road",
"AlbumTitle":"Somewhat Famous",
"Genre": "Country",
"CriticRating": 8.4,
"Year": 1984
}
}
```
```
{
TableName: "Music",
Item: {
"Artist": "The Acme Band",
"SongTitle": "Still In Love",
"AlbumTitle":"The Buck Starts Here",
"Price": 2.47,
"Genre": "Rock",
"PromotionInfo": {
"RadioStationsPlaying":[
"KHCR", "KBQX", "WTNR", "WJJH"
],
"TourDates": {
"Seattle": "20150625",
"Cleveland": "20150630"
},
"Rotation": "Heavy"
}
}
}
```
```
{
TableName: "Music",
Item: {
"Artist": "The Acme Band",
"SongTitle": "Look Out, World",
"AlbumTitle":"The Buck Starts Here",
"Price": 0.99,
"Genre": "Rock"
}
}
```
**注記**
`PutItem` に加えて、DynamoDB は、同時に複数の項目に書き込むための `BatchWriteItem` オペレーションもサポートします。
------
#### [ PartiQL for DynamoDB ]
PartiQL では、PartiQL `ExecuteStatement` ステートメントを利用する `Insert` オペレーションを使用して、テーブルに項目を追加します。
```
INSERT into Music value {
'Artist': 'No One You Know',
'SongTitle': 'Call Me Today',
'AlbumTitle': 'Somewhat Famous',
'Year' : '2015',
'Genre' : 'Acme'
}
```
このテーブルのプライマリキーは、*Artist* および *SongTitle* で構成されます。これらの属性の値を指定する必要があります。
**注記**
`Insert` と `ExecuteStatement` を使用したコード例については、[DynamoDB 用の PartiQL 挿入ステートメント](ql-reference.insert.md) を参照してください。
------
# テーブルからデータを読み込むときの、リレーショナル (SQL) データベースと DynamoDB の相違点
SQL では、`SELECT` ステートメントを使用して、テーブルから 1 つ以上の行を取得します。`WHERE` 句を使用して、返されたデータを調べます。
これは、Amazon DynamoDB を使用する場合とは異なります。Amazon DynamoDb は、データの読み取りに次のオペレーションを提供します。
+ `ExecuteStatement` がテーブルから 1 つまたは複数の項目を取得します。`BatchExecuteStatement` が 1 回のオペレーションで異なるテーブルから複数の項目を取得します。どちらのオペレーションでも、SQL 互換のクエリ言語である [PartiQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html) が使用されます。
+ `GetItem` – テーブルから単一の項目を取り出します。これは、項目の物理的な場所に直接アクセスできるため、単一の項目を読み込むうえで最も効率的な方法です。(DynamoDB では、`BatchGetItem` オペレーションを提供し、1 回のオペレーションで最大 100 回の `GetItem` コールを実行できます。)
+ `Query` – 特定のパーティションキーがあるすべての項目を取得します。これらの項目内では、ソートキーに条件を適用し、データのサブセットのみ取得できます。`Query` は、データが格納されているパーティションに、すばやく効率的にアクセスできます。（詳しくは、[DynamoDB におけるパーティションとデータ分散](HowItWorks.Partitions.md) を参照してください）。
+ `Scan` – 指定されたテーブルで、すべての項目を取得します。(大量のリソースシステムを消費するため、このオペレーションは大きなテーブルでは使用しないでください。)
**注記**
リレーショナルデータベースでは、`SELECT` ステートメントを使用して、複数のテーブルからデータを結合し、その結果を返すことができます。結合は、リレーショナルモデルにおいて必須です。結合を効率的に実行するために、データベースおよびアプリケーションは、継続的にパフォーマンスを調整する必要があります。DynamoDB は、テーブル結合をサポートしない非リレーショナル NoSQL データベースです。その代わり、アプリケーションは一度に 1 つのテーブルからデータを読み込みます。
次のセクションでは、データを読み込むための異なるユースケースおよびこれらのタスクをリレーショナルデータベースと DynamoDB を使って実行する方法を説明します。
**Topics**
+ [プライマリキーを使用して項目を読み込むときの相違点](SQLtoNoSQL.ReadData.SingleItem.md)
+ [テーブルのクエリにおける相違点](SQLtoNoSQL.ReadData.Query.md)
+ [テーブルのスキャンにおける相違点](SQLtoNoSQL.ReadData.Scan.md)
# プライマリキーを使用して項目を読み込むときの相違点
データベースの一般的なアクセスパターンの 1 つは、テーブルから単一項目を読み取ることです。目的の項目のプライマリキーを指定する必要があります。
**Topics**
+ [SQL にプライマリキーを使用して項目を読み込む](#SQLtoNoSQL.ReadData.SingleItem.SQL)
+ [DynamoDB でプライマリキーを使用して項目を読み込む](#SQLtoNoSQL.ReadData.SingleItem.DynamoDB)
## SQL にプライマリキーを使用して項目を読み込む
SQL では、`SELECT` ステートメントを使用して、テーブルからデータを取得します。結果の 1 つ以上の列 (`*` オペレーター を使用すれば、すべて) をリクエストできます。`WHERE` 句は返る行を判別します。
以下は、*Music* テーブルから単一の行を取得するための `SELECT` ステートメントです。`WHERE` 句はプライマリキー値を指定します。
```
SELECT *
FROM Music
WHERE Artist='No One You Know' AND SongTitle = 'Call Me Today'
```
列のサブセットのみを取得するようにこのクエリを変更できます。
```
SELECT AlbumTitle, Year, Price
FROM Music
WHERE Artist='No One You Know' AND SongTitle = 'Call Me Today'
```
このテーブルのプライマリキーが、*Artist* および *SongTitle* で構成されていることに注意してください。
## DynamoDB でプライマリキーを使用して項目を読み込む
Amazon DynamoDB では、DynamoDB API または [PartiQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html) (SQL 互換のクエリ言語) を使用して、テーブルから項目を読み込むことができます。
------
#### [ DynamoDB API ]
DynamoDB API では、`PutItem` オペレーションを使用して、テーブルに項目を追加します。
DynamoDB は、プライマリキーにより項目を取得するための `GetItem` オペレーションを提供します。`GetItem` は、項目の物理的な場所への直接アクセスを提供するため非常に効率的です。（詳しくは、[DynamoDB におけるパーティションとデータ分散](HowItWorks.Partitions.md) を参照してください）。
デフォルトでは、`GetItem` は、すべての属性を含む項目全体を返します。
```
{
TableName: "Music",
Key: {
"Artist": "No One You Know",
"SongTitle": "Call Me Today"
}
}
```
一部の属性のみが返されるように、`ProjectionExpression` パラメータを追加できます。
```
{
TableName: "Music",
Key: {
"Artist": "No One You Know",
"SongTitle": "Call Me Today"
},
"ProjectionExpression": "AlbumTitle, Year, Price"
}
```
このテーブルのプライマリキーが、*Artist* および *SongTitle* で構成されていることに注意してください。
DynamoDB `GetItem` オペレーションは非常に効率的です。プライマリキー値を使用して、該当する項目の正確な格納場所を特定し、そこから直接取得します。SQL `SELECT` ステートメントは、プライマリキー値によって項目を取得する場合、同様に効率的です。
SQL `SELECT` ステートメントは、さまざまな種類のクエリとテーブルスキャンをサポートしています。DynamoDB は、[テーブルのクエリにおける相違点](SQLtoNoSQL.ReadData.Query.md) および [テーブルのスキャンにおける相違点](SQLtoNoSQL.ReadData.Scan.md) で説明されている `Query` および `Scan` オペレーションと同様の機能を提供します。
SQL `SELECT` ステートメントは、テーブルの結合を実行でき、同時に複数のテーブルからデータを取得できます。データベーステーブルが正規化され、テーブル間の関係が明確である場合、結合は最も効果的です。ただし、1 つの `SELECT`ステートメントであまりに多くのテーブルを結合すると、アプリケーションパフォーマンスが影響を受けます。データベースレプリケーション、マテリアライズドビュー、またはクエリの書き換えを使用して、このような問題を回避できます。
DynamoDB は、非リレーショナルデータベースのため、テーブルの結合はサポートされません。リレーショナルデータベースから既存のアプリケーションを DynamoDB に移行する場合、結合の必要を排除するためデータモデルを非正規化する必要があります。
------
#### [ PartiQL for DynamoDB ]
PartiQL では、PartiQL `Select` ステートメントを利用する `ExecuteStatement` オペレーションを使用して、テーブルから項目を読みます。
```
SELECT AlbumTitle, Year, Price
FROM Music
WHERE Artist='No One You Know' AND SongTitle = 'Call Me Today'
```
このテーブルのプライマリキーが、Artist および SongTitle で構成されていることに注意してください。
**注記**
選択 PartiQL ステートメントは、DynamoDB テーブルにクエリやスキャンを実行する場合にも使用できます
`Select` と `ExecuteStatement` を使用したコード例については、[DynamoDB 用の PartiQL select ステートメント](ql-reference.select.md) を参照してください。
------
# テーブルのクエリにおける相違点
もう 1 つの一般的なアクセスパターンは、クエリ条件に基づき、テーブルから複数の項目を読み込むことです。
**Topics**
+ [SQL を使用してテーブルのクエリを実行する](#SQLtoNoSQL.ReadData.Query.SQL)
+ [DynamoDB でテーブルのクエリを実行する](#SQLtoNoSQL.ReadData.Query.DynamoDB)
## SQL を使用してテーブルのクエリを実行する
SQL を使用すると、`SELECT` ステートメントは、キー列、非キー列、または任意の組み合わせに対してクエリを実行できます。`WHERE` 句は、次の例に示すように、返る行を決定します。
```
/* Return a single song, by primary key */
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle = 'Call Me Today';
```
```
/* Return all of the songs by an artist */
SELECT * FROM Music
WHERE Artist='No One You Know';
```
```
/* Return all of the songs by an artist, matching first part of title */
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%';
```
```
/* Return all of the songs by an artist, only if the price is less than 1.00 */
SELECT * FROM Music
WHERE Artist='No One You Know'
AND Price < 1.00;
```
このテーブルのプライマリキーが、*Artist* および *SongTitle* で構成されていることに注意してください。
## DynamoDB でテーブルのクエリを実行する
Amazon DynamoDB では、DynamoDB API または [PartiQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html) (SQL 互換のクエリ言語) を使用して、テーブルの項目にクエリを実行できます。
------
#### [ DynamoDB API ]
Amazon DynamoDB では、`Query` オペレーションを使用すると、同様の方法でデータを取得できます。`Query` オペレーションは、データが保存されている物理的な場所にすばやく効率的にアクセスすることができます。詳細については、「[DynamoDB におけるパーティションとデータ分散](HowItWorks.Partitions.md)」を参照してください。
`Query` は任意のテーブルまたはセカンダリインデックスでを使用できます。パーティションキーの値に対して等価条件を指定する必要があります。ソートキー属性が定義されている場合は、必要に応じて別の条件を指定できます。
`KeyConditionExpression` パラメータは、クエリを実行するキー値を指定します。オプションの `FilterExpression` を使用して、結果が返される前に、そこから特定の項目を削除できます。
DynamoDB では、式パラメータ (`KeyConditionExpression` や `FilterExpression` など) で `ExpressionAttributeValues` をプレースホルダーとして使用する必要があります。これは、ランタイム時に実際の値を `SELECT` ステートメントに代入する、リレーショナルデータベースでの*バインド変数*の使用に類似しています。
このテーブルのプライマリキーが、*Artist* および *SongTitle* で構成されていることに注意してください。
次に、DynamoDB `Query` の例をいくつか示します。
```
// Return a single song, by primary key
{
TableName: "Music",
KeyConditionExpression: "Artist = :a and SongTitle = :t",
ExpressionAttributeValues: {
":a": "No One You Know",
":t": "Call Me Today"
}
}
```
```
// Return all of the songs by an artist
{
TableName: "Music",
KeyConditionExpression: "Artist = :a",
ExpressionAttributeValues: {
":a": "No One You Know"
}
}
```
```
// Return all of the songs by an artist, matching first part of title
{
TableName: "Music",
KeyConditionExpression: "Artist = :a and begins_with(SongTitle, :t)",
ExpressionAttributeValues: {
":a": "No One You Know",
":t": "Call"
}
}
```
```
// Return all of the songs by an artist, only if the price is less than 1.00
{
TableName: "Music",
KeyConditionExpression: "Artist = :a",
FilterExpression: "Price < :p",
ExpressionAttributeValues: {
":a": "No One You Know",
":p": 1.00
}
}
```
**注記**
`FilterExpression` は、`Query` が一致する項目を読み取った後に適用されるため、消費される読み取り容量は減少しません。可能な場合は、効率的なクエリのために範囲条件でソートキーに対して `KeyConditionExpression` を使用するようにデータをモデル化します。詳細については、「[DynamoDB のテーブルに対するクエリの実行](Query.md)」を参照してください。
------
#### [ PartiQL for DynamoDB ]
PartiQL では、パーティションキーの `ExecuteStatement` オペレーションと `Select` ステートメントを使用してクエリを実行できます。
```
SELECT AlbumTitle, Year, Price
FROM Music
WHERE Artist='No One You Know'
```
このように `SELECT` ステートメントを使用すると、この特定の `Artist` に関連付けられているすべての曲が返されます。
`Select` と `ExecuteStatement` を使用したコード例については、[DynamoDB 用の PartiQL select ステートメント](ql-reference.select.md) を参照してください。
------
# テーブルのスキャンにおける相違点
SQL では、`SELECT` 句なしの `WHERE` ステートメントは、テーブルのすべての行を返します。Amazon DynamoDB では、`Scan` オペレーションで同様のアクションを行います。どちらの場合も、すべて、または一部の項目を取得できます。
SQL または NoSQL データベースのいずれを使用するにしても、スキャンは大量のシステムリソースを消費するので、控え目に使用する必要があります。スキャンが適切 (小さなテーブルをスキャンするなど) または不可避 (データの一括エクスポートの実行など) な場合はあります。しかし、一般的なルールとして、スキャンを実行しないようアプリケーションを設計する必要があります。詳細については、「[DynamoDB のテーブルに対するクエリの実行](Query.md)」を参照してください。
**注記**
一括エクスポートを実行すると、パーティションごとに少なくとも 1 つのファイルも作成されます。各ファイル内のすべての項目は、その特定のパーティションのハッシュされたキースペースからのものです。
**Topics**
+ [SQL を使用してテーブルをスキャンする](#SQLtoNoSQL.ReadData.Scan.SQL)
+ [DynamoDB でテーブルをスキャンする](#SQLtoNoSQL.ReadData.Scan.DynamoDB)
## SQL を使用してテーブルをスキャンする
SQL を使用すると、`SELECT` 句を指定せずに、`WHERE` ステートメントを使用してテーブルをスキャンし、データのすべてを取得することができます。結果の 1 つ以上の列をリクエストできます。または、ワイルドカード文字「\$1」を使用する場合は、すべての項目をリクエストできます。
以下は `SELECT` ステートメントの使用例です。
```
/* Return all of the data in the table */
SELECT * FROM Music;
```
```
/* Return all of the values for Artist and Title */
SELECT Artist, Title FROM Music;
```
## DynamoDB でテーブルをスキャンする
Amazon DynamoDB では、DynamoDB API または [PartiQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html) (SQL 互換のクエリ言語) を使用して、テーブルに対してスキャンを実行します。
------
#### [ DynamoDB API ]
DynamoDB API では、テーブルまたはセカンダリインデックスの各項目にアクセスして、1 つまたは複数の項目または項目属性を返す `Scan` オペレーションを使用します。
```
// Return all of the data in the table
{
TableName: "Music"
}
```
```
// Return all of the values for Artist and Title
{
TableName: "Music",
ProjectionExpression: "Artist, Title"
}
```
`Scan` オペレーションでは、`FilterExpression` パラメータも指定できます。これを使用して、結果に表示しない項目を破棄することができます。`FilterExpression` は、スキャンの実行後、結果が返されるまでの間に適用されます。(これは、大きなテーブルではお勧めしません。返される一致項目がごく少数でも、`Scan` 全体に対して料金が請求されます。)
------
#### [ PartiQL for DynamoDB ]
PartiQL では、`Select` ステートメントを使用するテーブルに対してすべての内容を返す `ExecuteStatement` オペレーションを使用してスキャンを実行します。
```
SELECT AlbumTitle, Year, Price
FROM Music
```
このステートメントは、Music テーブルのすべての項目を返すことに注意してください。
`Select` と `ExecuteStatement` を使用したコード例については、[DynamoDB 用の PartiQL select ステートメント](ql-reference.select.md) を参照してください。
------
# インデックスを管理するときのリレーショナル (SQL) データベースと DynamoDB の相違点
インデックスは代替のクエリパターンへのアクセスを付与し、クエリを高速化できます。このセクションでは、SQL と Amazon DynamoDB におけるインデックスの作成と使用を比較します。
リレーショナルデータベースまたは DynamoDB のいずれを使用するにしても、インデックスの作成は慎重に判断する必要があります。テーブルに書き込みが発生するたびに、テーブルのインデックスはすべて、更新する必要があります。大きなテーブルでの書き込み量が多い環境では、大量のシステムリソースを消費する可能性があります。読み取り専用または読み取りがほとんどの環境では、これは大きな問題にはなりません。ただし、インデックスがアプリケーションによって実際に使用されており、ただ容量を取っていることがないよう確認する必要があります。
**Topics**
+ [インデックスを作成するときのリレーショナル (SQL) データベースと DynamoDB の相違点](#SQLtoNoSQL.Indexes.Creating)
+ [インデックスのクエリとスキャンをするときのリレーショナル (SQL) データベースと DynamoDB の相違点](#SQLtoNoSQL.Indexes.QueryAndScan)
## インデックスを作成するときのリレーショナル (SQL) データベースと DynamoDB の相違点
SQL の `CREATE INDEX` ステートメントを Amazon DynamoDB の `UpdateTable` オペレーションと比較します。
**Topics**
+ [SQL を使ってインデックスを作成する](#SQLtoNoSQL.Indexes.Creating.SQL)
+ [DynamoDB でインデックスを作成する](#SQLtoNoSQL.Indexes.Creating.DynamoDB)
### SQL を使ってインデックスを作成する
リレーショナルデータベースのインデックスは、テーブルの異なる列に対して高速にクエリを実行できるデータ構造です。`CREATE INDEX` SQL ステートメントを使用して、既存のテーブルにインデックスが追加し、インデックスを作成する列を指定します。インデックスの作成後は、通常どおりテーブルのデータにクエリを実行できますが、テーブル全体をスキャンする代わりに、テーブルの指定された行を迅速に検索するため、データベースがインデックスを使用することができます。
インデックスの作成後は、データベースが維持します。テーブルのデータを変更した場合は、インデックスが自動的に変更され、テーブル内の変更を反映します。
MySQL では、次のようなインデックスを作成します。
```
CREATE INDEX GenreAndPriceIndex
ON Music (genre, price);
```
### DynamoDB でインデックスを作成する
DynamoDB では、同様の目的のために、*セカンダリインデックス*を作成して使用できます。
DynamoDB のインデックスはリレーショナルな対応物とは異なります。セカンダリインデックスを作成する際、そのキー属性 (パーティションキーとソートキー) を指定する必要があります。セカンダリインデックスを作成したら、テーブルと同じように `Query` または `Scan` を実行できます。DynamoDB にはクエリオプティマイザーがないため、セカンダリインデックスは `Query` または `Scan` の場合にのみ使用されます。
DynamoDB では、次の 2 種類のインデックスをサポートしています。
+ グローバルセカンダリインデックス – インデックスのプライマリキーは、テーブルからの任意の 2 つの属性になります。
+ ローカルセカンダリインデックス – インデックスのパーティションキーは、テーブルのパーティションキーと同じである必要があります。ただし、ソートキーは、他の任意の属性にすることができます。
DynamoDB を使えば、セカンダリインデックスのデータは結果的にテーブルと整合性が取れます。テーブルまたはローカルセカンダリインデックスでの強い整合性を持つ `Query` または `Scan` オペレーションをリクエストできます。ただし、グローバルセカンダリインデックスは結果整合性のみをサポートします。
`UpdateTable` オペレーションを使用し、`GlobalSecondaryIndexUpdates` を指定して、既存のテーブルにグローバルセカンダリインデックスを追加できます。
```
{
TableName: "Music",
AttributeDefinitions:[
{AttributeName: "Genre", AttributeType: "S"},
{AttributeName: "Price", AttributeType: "N"}
],
GlobalSecondaryIndexUpdates: [
{
Create: {
IndexName: "GenreAndPriceIndex",
KeySchema: [
{AttributeName: "Genre", KeyType: "HASH"}, //Partition key
{AttributeName: "Price", KeyType: "RANGE"}, //Sort key
],
Projection: {
"ProjectionType": "ALL"
},
ProvisionedThroughput: { // Only specified if using provisioned mode
"ReadCapacityUnits": 1,"WriteCapacityUnits": 1
}
}
}
]
}
```
`UpdateTable` に以下のパラメータを提供する必要があります。
+ `TableName` – インデックスが関連付けられるテーブル。
+ `AttributeDefinitions` – インデックスのキースキーマ属性用のデータ型。
+ `GlobalSecondaryIndexUpdates` – 作成するインデックスに関する詳細。
+ `IndexName` – インデックスの名前。
+ `KeySchema` – インデックスのプライマリキーに使用する属性。
+ `Projection` – テーブルからインデックスにコピーされる属性。この場合、`ALL` は、すべての属性がコピーされることを意味します。
+ `ProvisionedThroughput (for provisioned tables)` – このインデックスに必要な 1 秒あたりの読み取り/書き込み数。(これは、テーブルのプロビジョニングされたスループット設定とは異なります。)
このオペレーションの一部は、テーブルから新しいインデックスにデータをバックフィリングすることを含みます。バックフィリング中、テーブルは使用可能なままになります。ただし、インデックスは `Backfilling` 属性が true から false に変わるまで、準備ができていません。`DescribeTable` オペレーションを使用して、この属性を表示できます。
## インデックスのクエリとスキャンをするときのリレーショナル (SQL) データベースと DynamoDB の相違点
SQL の SELECT ステートメントを使用したインデックスのクエリとスキャンを Amazon DynamoDB の `Query` および `Scan` オペレーションと比較します。
**Topics**
+ [SQL を使ってインデックスのクエリを実行してスキャンする](#SQLtoNoSQL.Indexes.QueryAndScan.SQL)
+ [DynamoDB でインデックスのクエリを実行してスキャンする](#SQLtoNoSQL.Indexes.QueryAndScan.DynamoDB)
### SQL を使ってインデックスのクエリを実行してスキャンする
リレーショナルデータベースでは、インデックスを直接使用しません。代わりに、`SELECT` ステートメントの発行により、テーブルでクエリを実行し、クエリオプティマイザは任意のインデックスを利用できます。
*クエリオプティマイザ*は、使用できるインデックスを評価し、クエリを高速化するためにそれらを使用できるかを決定するリレーショナルデータベース管理システム (RDBMS) のコンポーネントです。クエリを高速化するためにインデックスが使用できる場合、RDBMS は最初にインデックスにアクセスし、それを使用してテーブルのデータを特定します。
*GenreAndPriceIndex* を使用してパフォーマンスを向上できる SQL ステートメントを次に示します。ここでは、*Music* テーブルに十分なデータがあり、クエリオプティマイザが、テーブル全体にスキャンするのではなく、このインデックスを使用することを前提にします。
```
/* All of the rock songs */
SELECT * FROM Music
WHERE Genre = 'Rock';
```
```
/* All of the cheap country songs */
SELECT Artist, SongTitle, Price FROM Music
WHERE Genre = 'Country' AND Price < 0.50;
```
### DynamoDB でインデックスのクエリを実行してスキャンする
DynamoDB では、テーブルに対して実行するのと同じように、インデックスに対して直接 `Query` および `Scan` オペレーションを実行します。DynamoDB API または [PartiQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html) (SQL 互換のクエリ言語) を使用して、インデックスにクエリやスキャンを実行できます。`TableName` と `IndexName` の両方を指定する必要があります。
以下は、DynamoDB の *GenreAndPriceIndex* に対するいくつかのクエリです。(このインデックスのキースキーマは、*ジャンル*と*価格*で構成されています。)
------
#### [ DynamoDB API ]
```
// All of the rock songs
{
TableName: "Music",
IndexName: "GenreAndPriceIndex",
KeyConditionExpression: "Genre = :genre",
ExpressionAttributeValues: {
":genre": "Rock"
},
};
```
この例では `ProjectionExpression` を使用して、属性すべてではなく、一部のみを結果に表示することを示します。
```
// All of the cheap country songs
{
TableName: "Music",
IndexName: "GenreAndPriceIndex",
KeyConditionExpression: "Genre = :genre and Price < :price",
ExpressionAttributeValues: {
":genre": "Country",
":price": 0.50
},
ProjectionExpression: "Artist, SongTitle, Price"
};
```
次に示すのは、*GenreAndPriceIndex* に対するスキャンです。
```
// Return all of the data in the index
{
TableName: "Music",
IndexName: "GenreAndPriceIndex"
}
```
------
#### [ PartiQL for DynamoDB ]
PartiQL では、`Select` ステートメントを使用して、インデックスに対してクエリとスキャンを実行します。
```
// All of the rock songs
SELECT *
FROM Music.GenreAndPriceIndex
WHERE Genre = 'Rock'
```
```
// All of the cheap country songs
SELECT *
FROM Music.GenreAndPriceIndex
WHERE Genre = 'Rock' AND Price < 0.50
```
次に示すのは、*GenreAndPriceIndex* に対するスキャンです。
```
// Return all of the data in the index
SELECT *
FROM Music.GenreAndPriceIndex
```
**注記**
`Select` を使用したコード例については、「[DynamoDB 用の PartiQL select ステートメント](ql-reference.select.md)」を参照してください。
------
# テーブル内のデータを変更するときのリレーショナル (SQL) データベースと DynamoDB の相違点
SQL 言語は、データを変更するための `UPDATE` ステートメントを提供します。Amazon DynamoDB は、この `UpdateItem` オペレーションを使用して同様のタスクを実行します。
**Topics**
+ [SQL を使用してテーブルのデータを変更する](#SQLtoNoSQL.UpdateData.SQL)
+ [DynamoDB でテーブルのデータを変更する](#SQLtoNoSQL.UpdateData.DynamoDB)
## SQL を使用してテーブルのデータを変更する
SQL では、`UPDATE` ステートメントを使用して、1 つ以上の行を変更します。`SET` 句は、1 つ以上の行に新しい値を指定し、`WHERE` 句は変更する行を決定します。以下はその例です。
```
UPDATE Music
SET RecordLabel = 'Global Records'
WHERE Artist = 'No One You Know' AND SongTitle = 'Call Me Today';
```
`WHERE` 句に行が一致しない場合、`UPDATE` ステートメントは何も実行しません。
## DynamoDB でテーブルのデータを変更する
DynamoDB では、クラシック API または [PartiQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html) (SQL 互換のクエリ言語) を使用して、単一の項目を変更できます。複数の項目を変更する場合は、複数のオペレーションを使用する必要があります。
------
#### [ DynamoDB API ]
DynamoDB API では、`UpdateItem` オペレーションを使用して、単一の項目を変更します。
```
{
TableName: "Music",
Key: {
"Artist":"No One You Know",
"SongTitle":"Call Me Today"
},
UpdateExpression: "SET RecordLabel = :label",
ExpressionAttributeValues: {
":label": "Global Records"
}
}
```
属性値を指定するには、変更する項目の `Key` 属性および `UpdateExpression` を指定する必要があります。`UpdateItem` は、「アップサート」オペレーションのように動作します。テーブルに項目が存在する場合は更新され、存在しない場合は新しい項目が追加 (挿入) されます。
`UpdateItem` は、*条件付き書き込み*をサポートしており、特定の `ConditionExpression` が true と評価された場合のみ、オペレーションが成功します。たとえば、次の `UpdateItem` オペレーションは、曲の価格が 2.00 以上でない限り、更新を実行しません。
```
{
TableName: "Music",
Key: {
"Artist":"No One You Know",
"SongTitle":"Call Me Today"
},
UpdateExpression: "SET RecordLabel = :label",
ConditionExpression: "Price >= :p",
ExpressionAttributeValues: {
":label": "Global Records",
":p": 2.00
}
}
```
また、`UpdateItem` は*アトミックカウンター*、または増加減少する `Number` 型の属性をサポートしています。アトミックカウンターは多くの点で SQL データベースのシーケンスジェネレーター、IDENTITY 列、または自動インクリメントフィールドと似ています。
`UpdateItem` オペレーションを使用して、新しい属性 (*Plays*) を初期化し、曲の再生回数を追跡する例を次に示します。
```
{
TableName: "Music",
Key: {
"Artist":"No One You Know",
"SongTitle":"Call Me Today"
},
UpdateExpression: "SET Plays = :val",
ExpressionAttributeValues: {
":val": 0
},
ReturnValues: "UPDATED_NEW"
}
```
`ReturnValues` パラメータは、更新された任意の属性の新しい値を返す、`UPDATED_NEW` に設定されています。この場合は、0 (ゼロ) を返します。
ユーザーがこの曲を再生するたびに、次の `UpdateItem` オペレーションを使用して *Plays* を 1 ずつ増分できます。
```
{
TableName: "Music",
Key: {
"Artist":"No One You Know",
"SongTitle":"Call Me Today"
},
UpdateExpression: "SET Plays = Plays + :incr",
ExpressionAttributeValues: {
":incr": 1
},
ReturnValues: "UPDATED_NEW"
}
```
------
#### [ PartiQL for DynamoDB ]
PartiQL では、`Update` ステートメントを利用する `ExecuteStatement` オペレーションを使用して、テーブル内の項目を変更します。
このテーブルのプライマリキーは、*Artist* および *SongTitle* で構成されます。これらの属性の値を指定する必要があります。
```
UPDATE Music
SET RecordLabel ='Global Records'
WHERE Artist='No One You Know' AND SongTitle='Call Me Today'
```
また、次の例のように、複数のフィールドを一度に変更することもできます。
```
UPDATE Music
SET RecordLabel = 'Global Records'
SET AwardsWon = 10
WHERE Artist ='No One You Know' AND SongTitle='Call Me Today'
```
また、`Update` は*アトミックカウンター*、または増加減少する `Number` 型の属性をサポートしています。アトミックカウンターは多くの点で SQL データベースのシーケンスジェネレーター、IDENTITY 列、または自動インクリメントフィールドと似ています。
次は、曲が再生された回数を追跡するための新しい属性 (*Plays*) を初期化する `Update` ステートメントの例です。
```
UPDATE Music
SET Plays = 0
WHERE Artist='No One You Know' AND SongTitle='Call Me Today'
```
ユーザーがこの曲を再生するたびに、次の `Update` ステートメントを使用して *Plays* を 1 ずつ増分できます。
```
UPDATE Music
SET Plays = Plays + 1
WHERE Artist='No One You Know' AND SongTitle='Call Me Today'
```
**注記**
`Update` と `ExecuteStatement` を使用したコード例については、[DynamoDB 用の PartiQL 更新ステートメント](ql-reference.update.md) を参照してください。
------
# テーブルからデータを削除するときのリレーショナル (SQL) データベースと DynamoDB の相違点
SQL では、`DELETE` ステートメントを使用してテーブルから 1 つ以上の行を削除します。Amazon DynamoDB では、この `DeleteItem` オペレーションを使用して一度に 1 つの項目を削除します。
**Topics**
+ [SQL を使ってテーブルからデータを削除する](#SQLtoNoSQL.DeleteData.SQL)
+ [DynamoDB でテーブルからデータを削除する](#SQLtoNoSQL.DeleteData.DynamoDB)
## SQL を使ってテーブルからデータを削除する
SQL では、`DELETE` ステートメントを使用して、1 つ以上の行を削除します。`WHERE` 句は、変更する行を決定します。以下はその例です。
```
DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';
```
`WHERE` 句を変更して、複数行を削除できます。たとえば、次の例に示すように、特定のアーティストのすべての曲を削除できます。
```
DELETE FROM Music WHERE Artist = 'The Acme Band'
```
## DynamoDB でテーブルからデータを削除する
DynamoDB では、クラシック API または [PartiQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ql-reference.html) (SQL 互換のクエリ言語) を使用して、単一の項目を削除できます。複数の項目を変更する場合は、複数のオペレーションを使用する必要があります。
------
#### [ DynamoDB API ]
DynamoDB API では、`DeleteItem` オペレーションを使用して、テーブルからデータを一度に 1 項目ずつ削除します。項目のプライマリキー値を指定する必要があります。
```
{
TableName: "Music",
Key: {
Artist: "The Acme Band",
SongTitle: "Look Out, World"
}
}
```
**注記**
`DeleteItem` に加えて、Amazon DynamoDB は、同時に複数の項目を削除するための `BatchWriteItem` オペレーションをサポートしています。
`DeleteItem` は、*条件付き書き込み*をサポートしており、特定の `ConditionExpression` が true と評価された場合のみ、オペレーションが成功します。たとえば、次の `DeleteItem` オペレーションは *RecordLabel* 属性がある場合のみ項目を削除します。
```
{
TableName: "Music",
Key: {
Artist: "The Acme Band",
SongTitle: "Look Out, World"
},
ConditionExpression: "attribute_exists(RecordLabel)"
}
```
------
#### [ PartiQL for DynamoDB ]
PartiQL では、`ExecuteStatement` オペレーションでの `Delete`ステートメントを使用して、テーブルからデータを一度に 1 項目ずつ削除します。項目のプライマリキー値を指定する必要があります。
このテーブルのプライマリキーは、*Artist* および *SongTitle* で構成されます。これらの属性の値を指定する必要があります。
```
DELETE FROM Music
WHERE Artist = 'Acme Band' AND SongTitle = 'PartiQL Rocks'
```
オペレーションには、追加の条件を指定することもできます。次の `DELETE` オペレーションは、11 を超える *Awards* が項目に含まれる場合にのみ、その項目を削除します。
```
DELETE FROM Music
WHERE Artist = 'Acme Band' AND SongTitle = 'PartiQL Rocks' AND Awards > 11
```
**注記**
`DELETE` と `ExecuteStatement` を使用したコード例については、[DynamoDB 用の PartiQL 削除ステートメント](ql-reference.delete.md) を参照してください。
------
# テーブルを削除するときのリレーショナル (SQL) データベースと DynamoDB の相違点
SQL では、`DROP TABLE` ステートメントを使用して、テーブルを削除します。Amazon DynamoDB では、`DeleteTable` オペレーションを使用します。
**Topics**
+ [SQL を使用してテーブルを削除する](#SQLtoNoSQL.RemoveTable.SQL)
+ [DynamoDB でテーブルを削除する](#SQLtoNoSQL.RemoveTable.DynamoDB)
## SQL を使用してテーブルを削除する
不要になったテーブルを完全に廃棄する場合、SQL の `DROP TABLE` ステートメントを使用します。
```
DROP TABLE Music;
```
テーブルは削除された後、復元できません。(一部のリレーショナルデータベースは `DROP TABLE` オペレーションを取消すことができますが、これはベンダー固有の機能であり、一般的には実装されていません。)
## DynamoDB でテーブルを削除する
DynamoDB には、`DeleteTable` が同様のオペレーションです。次の例では、テーブルは完全に削除されます。
```
{
TableName: "Music"
}
```
# Amazon DynamoDB の学習リソースとツール
以下に示すその他のリソースを使用して、DynamoDB について理解し、作業を行うことができます。
**Topics**
+ [コーディングと可視化のツール](#AdditionalResources.Tools)
+ [「規範的ガイダンス」の記事](#AdditionalResources.PrescriptiveGuidance)
+ [ナレッジセンターの記事](#AdditionalResources.KnowledgeCenter)
+ [ブログ投稿、リポジトリ、ガイド](#AdditionalResources.Guides)
+ [データモデリングと設計パターンのプレゼンテーション](#AdditionalResources.DataModeling)
+ [トレーニングコース](#AdditionalResources.Training)
## コーディングと可視化のツール
次のコーディングおよび視覚化ツールを使用して DynamoDB を操作できます。
+ [Amazon DynamoDB 用の NoSQL Workbench](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/workbench.html) – DynamoDB テーブルの設計、作成、クエリ、管理に役立つ、統合されたビジュアルツールです。このツールは、データモデリング、データの視覚化、クエリ開発機能を備えています。
+ [Dynobase](https://dynobase.dev/) – DynamoDB テーブルの表示と操作、アプリケーションコードの作成、リアルタイム検証を伴うレコードの編集を簡単に行うデスクトップツール。
+ [DynamoDB Toolbox](https://github.com/jeremydaly/dynamodb-toolbox) – データモデリング、JavaScript および Node.js での作業に役立つユーティリティを提供する Jeremy Daly 氏のプロジェクト。
+ [DynamoDB Streams Processor](https://github.com/jeremydaly/dynamodb-streams-processor) – [DynamoDB Streams](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html) の操作を簡単にするために使用できるシンプルなツール。
## 「規範的ガイダンス」の記事
「AWS の規範的ガイダンス」には、プロジェクトを加速させるのに役立つ、実績のある戦略、ガイド、パターンが記載されています。これらのリソースは、お客様のビジネス目標の達成を支援してきた長年の経験に基づいて、AWS テクノロジーのエキスパートと AWS パートナーのグローバルコミュニティによって開発されました。
**データモデリングと移行**
+ [DynamoDB の階層型データモデル](https://docs.aws.amazon.com/prescriptive-guidance/latest/dynamodb-hierarchical-data-model/introduction.html)
+ [DynamoDB によるデータのモデリング](https://docs.aws.amazon.com/prescriptive-guidance/latest/dynamodb-data-modeling/welcome.html)
+ [ を使用して Oracle データベースを DynamoDB に移行するAWS DMS](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-oracle-database-to-amazon-dynamodb-using-aws-dms.html)
**グローバルテーブル**
+ [Amazon DynamoDB グローバルテーブルを使用する](https://docs.aws.amazon.com/prescriptive-guidance/latest/dynamodb-global-tables/introduction.html)
**サーバーレス**
+ [ を使用してサーバーレス Saga パターンを実装するAWS Step Functions](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html)
**SaaS アーキテクチャ**
+ [複数の SaaS 製品間のテナントを単一のコントロールプレーンで管理する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/manage-tenants-across-multiple-saas-products-on-a-single-control-plane.html)
+ [C\$1 と AWS CDK を使用するサイロモデル用の SaaS アーキテクチャでのテナントオンボーディング](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/tenant-onboarding-in-saas-architecture-for-the-silo-model-using-c-and-aws-cdk.html)
**データ保護とデータ移動**
+ [Amazon DynamoDB へのクロスアカウントアクセスを設定する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)
+ [DynamoDB のフルテーブルコピーオプション](https://docs.aws.amazon.com/prescriptive-guidance/latest/dynamodb-full-table-copy-options/)
+ [ でのデータベースのディザスタリカバリ戦略AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-database-disaster-recovery/)
**雑則**
+ [DynamoDB でタグ付けを適用するのに役立ちます](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/help-enforce-dynamodb-tagging.html)
**規範ガイダンスの動画チュートリアル**
+ [サーバーレスアーキテクチャを使用したデータパイプラインの作成](https://youtu.be/JiWHomdh1oI?)
+ [Novartis - 購買エンジン: AI を活用した調達ポータル](https://youtu.be/vp8oPiHN4cA)
+ [Veritiv: インサイトを活用して AWS データレイクで売上需要を予測](https://youtu.be/jg85DzUZ9Ac)
+ [mimik: AWS を活用してエッジマイクロサービスメッシュをサポートするハイブリッドエッジクラウド](https://youtu.be/-S-R7MWRpaI)
+ [Amazon DynamoDB を使用した変更データキャプチャ](https://youtu.be/6YVjzD-70p4)
DynamoDB に関するその他の規範的ガイダンスの記事と動画については、「[規範的ガイダンス](https://tiny.amazon.com/fiui3cog/ForinternaldemoofnewpageExternalURLwillbeneededforlive)」を参照してください。
## ナレッジセンターの記事
AWS ナレッジセンターの記事と動画には、AWS のお客様から寄せられるよくある質問やリクエストが網羅されています。DynamoDB に関連した特定のタスクに関する最新のナレッジセンターの記事を、いくつか以下に示します。
**コスト最適化**
+ [Amazon DynamoDB を使用してコストを最適化する方法を教えてください。](https://repost.aws/knowledge-center/dynamodb-optimize-costs)
**スロットリングとレイテンシー**
+ [Amazon DynamoDB テーブルでレイテンシーが高い場合のトラブルシューティング方法を教えてください。](https://repost.aws/knowledge-center/dynamodb-high-latency)
+ [DynamoDB テーブルがスロットリングされているのはなぜですか?](https://repost.aws/knowledge-center/dynamodb-table-throttled)
+ [オンデマンド DynamoDB テーブルがスロットリングされているのはなぜですか?](https://repost.aws/knowledge-center/on-demand-table-throttling-dynamodb)
**Pagination (ページ分割**
+ [DynamoDB にページネーションを実装するにはどうすればよいですか](https://repost.aws/knowledge-center/dynamodb-implement-pagination)
**トランザクション**
+ [DynamoDB で `TransactWriteItems` API コールが失敗するのはなぜですか?](https://repost.aws/knowledge-center/dynamodb-transactwriteitems)
**トラブルシューティング**
[]()
+ [DynamoDB 自動スケーリングの問題を解決する方法を教えてください。](https://repost.aws/knowledge-center/dynamodb-auto-scaling)
+ [DynamoDB の HTTP 4XX エラーをトラブルシューティングする方法を教えてください](https://repost.aws/knowledge-center/usererrors-dynamodb-table)
DynamoDB に関するその他の記事や動画については、[ナレッジセンターの記事](https://repost.aws/search/knowledge-center?globalSearch=dynamodb)を参照してください。
## ブログ投稿、リポジトリ、ガイド
「[DynamoDB デベロッパーガイド](Introduction.md)」の他に、DynamoDB を使用するうえで役立つリソースが多数あります。DynamoDB を使用するためのブログ投稿、リポジトリ、ガイドをいくつか紹介します。
+ さまざまな AWS SDK 言語での [DynamoDB コード例](https://github.com/aws-samples/aws-dynamodb-examples)のAWSリポジトリ: [Node.js、](https://github.com/aws-samples/aws-dynamodb-examples/tree/master/examples/SDK/node.js)[Java、](https://github.com/aws-samples/aws-dynamodb-examples/tree/master/examples/SDK/java)[Python、](https://github.com/aws-samples/aws-dynamodb-examples/tree/master/examples/SDK/python)[.Net、](https://github.com/aws-samples/aws-dynamodb-examples/tree/master/examples/SDK/dotnet)[Go、](https://github.com/aws-samples/aws-dynamodb-examples/tree/master/examples/SDK/golang)[Rust](https://github.com/aws-samples/aws-dynamodb-examples/tree/master/examples/SDK/rust)。
+ [DynamoDB ブック](https://www.dynamodbbook.com/) – [Alex DeBrie](https://twitter.com/alexbdebrie) 氏からの包括的なガイドで、DynamoDB を使用したデータモデリングに対する戦略主導型のアプローチについて説明します。
+ [DynamoDB ガイド](https://www.dynamodbguide.com/) – [Alex DeBrie](https://twitter.com/alexbdebrie) 氏からのオープンガイドで、DynamoDB NoSQL データベースの基本的な概念と高度な機能について説明します。
+ [How to switch from RDBMS to DynamoDB in 20 easy steps](https://www.jeremydaly.com/how-to-switch-from-rdbms-to-dynamodb-in-20-easy-steps/) – [Jeremy Daly](https://twitter.com/jeremy_daly) 氏からデータモデリングを学ぶために役立つステップのリスト。
+ [DynamoDB JavaScript DocumentClient cheat sheet](https://github.com/dabit3/dynamodb-documentclient-cheat-sheet) – Node.js または JavaScript 環境で DynamoDB を使用してアプリケーションの構築を開始するのに役立つデータシート。
+ [DynamoDB Core Concept Videos](https://www.youtube.com/playlist?list=PLJo-rJlep0EDNtcDeHDMqsXJcuKMcrC5F) – このプレイリストでは、DynamoDB の多くの重要な概念が説明されています。
## データモデリングと設計パターンのプレゼンテーション
DynamoDB を最大限に活用するには、データモデリングと設計パターンに関する次のリソースを使用できます。
+ [AWSre:Invent 2019: DynamoDB を使用したデータモデリング](https://www.youtube.com/watch?v=DIQVJqiSUkE)
+ DynamoDB データモデリングの原則の使用開始に役立つ、[Alex DeBrie](https://twitter.com/alexbdebrie) 氏の講演
+ [AWSre:Invent 2020: DynamoDB を使用したデータモデリング – パート 1](https://www.youtube.com/watch?v=fiP2e-g-r4g)
+ [AWSre:Invent 2020: DynamoDB を使用したデータモデリング – パート 2](https://www.youtube.com/watch?v=0uLF1tjI_BI)
+ [AWS re:Invent 2017: Advanced design patterns](https://www.youtube.com/watch?v=jzeKPKpucS0)
+ [AWS re:Invent 2018: Advanced design patterns](https://www.youtube.com/watch?v=HaEPXoXVf2k)
+ [AWS re:Invent 2019: Advanced design patterns](https://www.youtube.com/watch?v=6yqfmXiZTlM)
+ このセッションでは、Jeremy Daly が [12 の重要ポイント](https://www.jeremydaly.com/takeaways-from-dynamodb-deep-dive-advanced-design-patterns-dat403/)を説明しています。
+ [AWS re:Invent 2020: DynamoDB advanced design patterns – Part 1](https://www.youtube.com/watch?v=MF9a1UNOAQo&index=1)
+ [AWS re:Invent 2020: DynamoDB advanced design patterns – Part 2](https://www.youtube.com/watch?v=_KNrRdWD25M&index=2)
+ [Twitch での DynamoDB の営業時間](https://amazondynamodbofficehrs.splashthat.com/)
**注記**
各セッションでは、さまざまなユースケースと例について説明しています。
## トレーニングコース
DynamoDB についてさらに学ぶためのさまざまなトレーニングコースや教育オプションがあります。現在の例をいくつかご紹介します。
+ [Developing with Amazon DynamoDB](https://www.aws.training/Details/Curriculum?id=65583) – AWS による設計で、Amazon DynamoDB のデータモデリングを使用して実際のアプリケーションを開発する初心者をエキスパートに育成します。
+ [DynamoDB deep dive course](https://www.pluralsight.com/courses/aws-dynamodb-deep-dive-2019) – Pluralsight のコース。
+ [Amazon DynamoDB: Building NoSQL database-driven applications](https://www.edx.org/course/amazon-dynamodb-building-nosql-database-driven-app) – edX でホストされる AWS トレーニングと認定チームのコース。