首先

因为要处理DynamoDB案件，所以我想边学习边实践一下。（没有相关书籍，而且AWS官方文档也很难读懂…）
这只是我个人的理解笔记，正确的信息请参考AWS官方文档。
（如果有错误，请指正，我会很高兴的）

解读「概要」

由于我不太理解「概要」中所宣传的说法，所以去解读它。

一级

「快速！方便！安全！」

第二级

默认情况下，并非所有事情都是有效的，但可以做很多事情。
感觉有点混乱，但应该是想提出6个各自的好处。

以AWS服务的组合形式，强调了大规模性能和流式触发的优势感。

与Cassandra相比，完全托管（全托管）的方式更注重“易用性”。

我对「自适应容量」和「自动伸缩」之间的区别不太了解。
自适应容量是指在数据结构上的问题，当访问偏向特定区域时，性能通常不会很好。但通过一些手段能够稍微提升性能，这只是一种临时的应对措施。如果持续存在自适应容量问题，那就意味着设计不太合理。
自动伸缩则类似一般意义上的自动伸缩。由于DynamoDB本身就是分布式服务器，它会根据事务量自动调整以获得最佳性能。

大型企業可使用。
雖然對於安全性部分並沒有特別注意，但似乎相當不錯。
最重要的是符合PCIDSS標準，很令人高興。

解读「费用」

我不太理解「料金」的概念。

摘要

在中文中进行释义：

似乎取决于数据量、写入/读取事务的数量。
其他的则取决于使用的选项有多少。

只是为了表示单位，才写了”wcu”和”rcu”之类的词。

费用明细

听说要事先宣布某事。

让我们也注意以下事项。

在有大型项的表格情况下，可能需要更多的单位来处理相同的请求次数。

事前に宣言があるけれども、もし超過した場合はどうするのだろうと思ったら、以下に書き込みや読み込みなどの「リクエストが失敗する」と書いてありました。DynamoDBにおけるスループット超過の対策について 〜 フォールバックキューイングパターン ※公式情報ではないですが、お世話になっているサイトです。

阅读「开发者指南」

由于「开发者指南」太长，阅读的积极性被削弱，所以希望尽可能地提炼重点进行书写。
（还有很多未涵盖的页面）

机能

核心组件

基本用词

引起了我的兴趣

• プライマリキー以外、People テーブルはスキーマレスです。つまり、属性またはデータ型を事前に定義する必要はありません。（公式文書そのまま）

RDBMSみたいに事前に決めた型しか入らないってことは無いよってことか。ってことは、レコード毎にカラム定義するってことかな？（解釈）

項目の一部には、入れ子の属性 (Address) があります。DynamoDB は深さが最大 32 レベルの入れ子の属性をサポートします。（公式文書そのまま）

主键（Primary Key）的作用是唯一标识一个条目（类似于关系数据库管理系统的记录）。看起来有两种类型。

由于没有其他的说明，似乎不支持通过三个以上属性来唯一确定。

引起关注的要点

• プライマリキー属性に許可される唯一のデータ型は、文字列、数値、またはバイナリです。他のキー以外の属性では、このような制限はありません。（公式文書そのまま）

• 物理的な領域としてのデータの距離を近くするために、パーティションという考え方があるらしい。性能改善目的？（解釈）

パーティションキーの値に基づいてパーティション間でデータ項目を均等に分散する。（抜粋）
ソートキー値で並べ替えられた順に、同じパーティションキーを持つ項目どうしを物理的に近くに保存する。（抜粋）

次回の伝記のベストセラー『セカンダリインデックス』をお楽しみください。『セカンダリインデックス』は、テーブルにおける主キー（プライマリキー）に対して、別のキーをサブ的に配置することを意味します。しかし、主キーがどこに行ったのかという疑問が残ります。インデックス自体の概念がまだ理解できていないのですが、「検索用のデータ」として実データとは別にインデックスが存在することを知りました。

引起兴趣的要点

テーブルあたり最大 5 個のグローバルセカンダリインデックスと 5 個のローカルセカンダリインデックスまで定義できます。

DynamoDB流式处理是一个可以捕获表数据变更事件的选项功能。

• insert: 登録される属性「全て」をキャプチャする。（1レコードまるっと）

• update: 「変更対象の属性に限り」、変更前後の属性を取得する。（変更したカラムだけ）

delete: 削除された属性「全て」をキャプチャする。（1レコードまるっと）

引起了我注意的要点

• 各ストリームレコードには、テーブルの名前、イベントのタイムスタンプ、およびその他のメタデータも含まれます。ストリームレコードには 24 時間の有効期間があり、その後はストリームから自動的に削除されます。（公式文書そのまま）

DynamoDB ストリーム は AWS Lambda と共に使用してトリガーを作成できます。これは、ストリームで関心のあるイベントが発生するたびに自動的に実行されるコードです。（公式文書そのまま）

数据类型

「セット」和「リスト」看起来好像是下位互换的关系，但它们在什么情况下使用呢？

引起了我的兴趣的要点

• 全般的に

プライマリキー属性として利用する際には、最大1024ないしは2048byteという制約が追加される。（解釈）
DynamoDB では、要素が深い入れ子になっていても、リスト内の個々の要素を操作できます。（公式文書そのまま）

数値

「数値の精度が重要な場合は、数値型から変換する文字列を使用して、DynamoDB に数値を渡します。」ってあるけど、どういうことだ？

バイナリ

DynamoDB に送信する前に、base64 エンコード形式のバイナリ値をエンコードする必要があります。（公式文書そのまま）

リスト・マップ

リスト・マップ要素に保存できるデータ型に制限はなく、リスト・マップ要素の要素が同じ型である必要はありません。（公式文書ほぼそのまま）

セット

値を含む項目が DynamoDB のサイズ制限 (400 KB) 内である限り、セットの値の最大数の制限はありません。（公式文書そのまま）

读取的一致性

总而言之，如果使用默认设置，则无法在更新后的1秒内获取最新数据。
实际上，使用dynamoDB时，基本上应该假设结果一致性为前提。
另外，因为”强一致读取”会消耗容量单位，所以会变得更昂贵（实际上是两倍）。

引起了我的关注的要点

• アプリケーションが DynamoDB テーブルにデータを書き込み、HTTP 200 応答 (OK) を受け取ると、書き込みが開始され、継続します。（公式文書そのまま）

• データは、すべてのストレージの場所で結果的に整合性が保たれます (通常は 1 秒以内)。（公式文書そのまま）

1 つの読み込みキャパシティーユニットは、最大サイズ 4 KB の項目について、1 秒あたり 1 回の強力な整合性のある読み込み、あるいは 1 秒あたり 2 回の結果的に整合性のある読み込みを表します。（公式文書そのまま）

SQL和noSQL

可以看一下下面的一般关系型数据库和DynamoDB的比较表，可能会很有用。
＞AWS 文档 » Amazon DynamoDB » 开发者指南 » 什么是 Amazon DynamoDB » 从SQL到NoSQL

让我感到困惑的要点

DynamoDB は、非リレーショナル NoSQL データベースのため、テーブルの結合はサポートされません。 その代わり、アプリケーションは一度に 1 つのテーブルからデータを読み込みます。

限制

以下是总结的内容。
AWS 文件 » Amazon DynamoDB » 开发者指南 » DynamoDB 的限制

最后

通过将自己的话语进行重新替换，我感觉对理解有了更深的认识。（所以，大家也要输出）
（最佳实践文档也想要进行解释和输出。）

然后仔细阅读下来，非常容易理解。得多读些官方文件。虽然有些地方的日语翻译可能不太清晰，但反过来说，也正因为如此。

以上

2018年8月21日补充

写了
【剖析AWS官方文档】DynamoDB最佳实践