Name: Amazon Web Servicesチュートリアル - AWSでDynamoDBを使う (Amazon Web Services Tutorial - Using DynamoDB with AWS)
Uploaded: 2025-08-03T18:38:31.000Z
Duration: 8 min 10 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

程度の副詞

Let's imagine you have just built a promising app that the world has never seen before.

世界が見たこともないような有望なアプリを開発したとしよう。

New users are coming in, but can your database scale to handle all the incoming requests?

新しいユーザーが入ってきていますが、データベースはすべてのリクエストに対応できますか？

基礎受動態

Amazon DynamoDB is built to handle internet-scale applications as traditional databases cannot handle millions of requests per second during Black Fridays or Cyber Mondays kind of scenarios.

Amazon DynamoDBは、インターネットスケールのアプリケーションを処理するために構築されている。従来のデータベースでは、ブラックフライデーやサイバーマンデーのようなシナリオでは、毎秒数百万のリクエストを処理できないからだ。

You can store hundreds of terabytes of data in DynamoDB and can expect great performance.

DynamoDBには数百テラバイトのデータを保存でき、素晴らしいパフォーマンスを期待できる。

So let's discuss key features of DynamoDB.

それでは、DynamoDBの主な機能について説明しよう。

DynamoDB is a fully managed, multi-region, multi-master and highly available database.

DynamoDBは、完全に管理された、マルチリージョン、マルチマスター、高可用性データベースです。

And all your data is replicated across three availability zones and you don't have to worry about patching and upgrading.

また、すべてのデータは3つのアベイラビリティ・ゾーンにレプリケートされるため、パッチやアップグレードを心配する必要もない。

That means it's not a relational database.

つまり、リレーショナル・データベースではないということだ。

Amazon DynamoDB is primarily designed to manage semi-structured data.

Amazon DynamoDBは主に半構造化データを管理するために設計されている。

DynamoDB tables do not have a fixed schema.

DynamoDBのテーブルは固定スキーマを持っていません。

So each data item can have a different number of attributes, which is very different to a relational database, which does require the attributes in a table to be consistent.

これは、テーブル内の属性に一貫性が求められるリレーショナル・データベースとは大きく異なる。

It will scale through massive workload and will be distributed and that's what makes it scale.

大規模なワークロードを通してスケールし、分散される。

You can issue on it millions of requests per second.

1秒間に何百万ものリクエストを出すことができる。

The really good thing about DynamoDB is that you get fast and consistent performance.

DynamoDBの本当に良いところは、高速で一貫したパフォーマンスが得られることだ。

So that means every retrieval will be low latency, usually in the single-digit millisecond.

つまり、すべての検索が低レイテンシー、通常は1桁ミリ秒ということになる。

It will be integrated with IAM for security and authorization, which is the best practice in AWS to manage security anyway.

これは、セキュリティと認可のためのIAMと統合され、AWSにおけるセキュリティ管理のベストプラクティスとなる。

On top of it, we can enable event-driven programming for your DynamoDB streams, where we can reply to events that happen to our table and see in real time that what we want to do about it.

その上、DynamoDBストリームに対してイベント駆動プログラミングを有効にすることができ、テーブルに発生したイベントに応答し、それに対して何をしたいかをリアルタイムで確認することができる。

It's a low cost and has auto-scaling capabilities, which makes it the perfect serverless database.

低コストで自動スケーリング機能を備えており、サーバーレス・データベースとして最適だ。

Now let's log into AWS console and see how DynamoDB dashboard looks like.

では、AWSコンソールにログインして、DynamoDBのダッシュボードがどのようになっているか見てみよう。

So basically DynamoDB is a database, but you don't need to create databases as they are already there for you.

つまり、基本的にDynamoDBはデータベースだが、データベースを作る必要はない。

では、ここに新しいテーブルを作ってみよう。

Each table will have a primary key and you can also define a composite key by including a sort key.

各テーブルは主キーを持ち、ソートキーを含めることで複合キーを定義することもできる。

So let's define player ID as the primary key and country as a sort key.

そこで、プレーヤーIDを主キー、国をソートキーとして定義してみよう。

Each table can have infinite number of rows and each row may have different number of attributes, which we don't need to define at the table creation, which is in contrast to any RDBMS.

各テーブルは無限の行数を持つことができ、各行は異なる数の属性を持つことができる。

The maximum size of a row can be up to 400 kilobytes.

行の最大サイズは400キロバイトまで。

However, you can have any number of rows of this magnitude.

しかし、この大きさの行をいくつでも持つことができる。

So this is really important decision while designing for your storage that what kind of data it holds.

そのため、ストレージを設計する際には、どのようなデータを保存するのかが重要な判断材料となる。

As DynamoDB has a limitation of 400 KB while S3 can store objects up to five terabytes in size.

S3は最大5テラバイトのオブジェクトを保存できるのに対し、DynamoDBは400KBという制限があるからだ。

So here either we can simply create table with default settings or can provide customized configurations.

つまり、デフォルトの設定でテーブルを作成するか、カスタマイズした設定を提供するかのどちらかだ。

And key thing to define here is the throughput you need in terms of read and write capacity units.

ここで重要なのは、必要なスループットを読み取りと書き込みの容量単位で定義することだ。

Read capacity unit or RCU is the number of elements you will read per second while write capacity unit or WCU is number of elements you will write per second.

リード・キャパシティ・ユニット（RCU）は、1秒間に読み込むエレメントの数であり、ライト・キャパシティ・ユニット（WCU）は、1秒間に書き込むエレメントの数である。

And you have a capacity calculator here where you can calculate the required read and write capacity.

また、ここに容量計算機があり、必要な読み書きの容量を計算することができる。

So if your item size is 1 KB and you want to read and write one item per second, you will need one one read and write capacity units.

つまり、アイテムのサイズが1KBで、1秒間に1つのアイテムを読み書きしたい場合、1つの読み書き容量ユニットが必要になる。

However, if your item size is let's say 300 KB and you want to read and write one one item per second, then you will need 38 read capacity units and 300 write capacity units.

しかし、アイテムのサイズが例えば300KBで、1秒間に1つのアイテムを読み書きしたい場合、38の読み取り容量ユニットと300の書き込み容量ユニットが必要になる。

And worth noticing here that it will also increase the cost.

そして、ここで注目すべきは、コストも上がるということだ。

You can also turn on scaling and impose encryption on your DynamoDB data.

また、スケーリングをオンにしたり、DynamoDBのデータに暗号化をかけたりすることもできます。

So let's go ahead and create this table with default settings.

では、デフォルトの設定でこのテーブルを作成してみよう。

And now let's try to add some data in this table.

では、このテーブルにデータを追加してみよう。

So as we can see here, this table is being created.

ここにあるように、このテーブルが作成されている。

この表をリフレッシュしてみよう。

だから、我々はそれが利用可能であることがわかる。

And this is where we can create records into this table.

そしてここで、このテーブルにレコードを作成することができる。

So let's say player ID is P01 and it represents country USA.

例えば、選手IDがP01で、アメリカという国を表しているとしよう。

Let's try to add another row here with player ID P02 representing country as India.

選手IDをP02、国をインドとして、ここに別の行を追加してみよう。

And here we also want to add another attribute as city that this player is from Delhi city in India.

さらに、この選手がインドのデリー出身であることを示す都市属性も追加したい。

So here we can see that we have two rows and both the rows has different number of attributes.

ここでは、2つの行があり、両方の行が異なる数の属性を持っていることがわかります。

So you can have any number of rows in your DynamoDB table with varied number of attributes.

そのため、DynamoDBテーブルには、さまざまな属性の行をいくつでも持つことができます。

Now you might be thinking that how DynamoDB relate in data engineering.

さて、DynamoDBがデータエンジニアリングにどう関係するのか、とお考えかもしれない。

Well, there are some very common use cases that includes mobile apps, gaming, digital ad service, live voting, audience interaction for live events, sensor network, log ingestion, access control for web-based content, metadata storage for Amazon S3 objects, e-com, web session management, etc.

モバイルアプリ、ゲーム、デジタル広告サービス、ライブ投票、ライブイベントの観客とのインタラクション、センサーネットワーク、ログの取り込み、ウェブベースのコンテンツのアクセス制御、Amazon S3オブジェクトのメタデータストレージ、e-com、ウェブセッション管理など、非常に一般的なユースケースがある。

In terms of anti-patterns where DynamoDB is not a good choice for, for example, RDS like fixed schema, complex joins or complex transactions or large size objects.

DynamoDBが、例えば固定スキーマ、複雑な結合、複雑なトランザクション、大きなサイズのオブジェクトのようなRDSに適していないアンチパターンについて。

And in general, if you have large data that has low IO rate, so few write or very few read, then S3 is going to be a much better storage option for you.

一般的に、大容量データでIOレートが低く、書き込みや読み出しが少ない場合は、S3の方がはるかに優れたストレージ・オプションになる。

そのため、使用例は多岐にわたる。

But basically, that means that any time if you have some data that need to be very hot, small in size and needs to be ingested at scale within a database, then DynamoDB is going to be a great fit for that.

しかし、基本的には、非常にホットで、サイズが小さく、データベース内で大規模に取り込む必要があるデータがあれば、いつでもDynamoDBはそれに最適だということだ。