首先

由于在实际案例中使用了DynamoDB，所以我总结了一下”基本概念”和”需要注意的事项”（这是我个人的综合文档）。
文中也包含了我的个人理解，并且为了易懂起见，有些描述可能不太准确。
请务必阅读最新的官方文档。

基本的的事情 de huà)

我已经大致阅读了开发指南的内容，但Black Belt的资料最易懂，所以我将参考其摘录并进行解释。
请确保您阅读最新的官方文档以获得准确的信息。

AWS Black Belt Online Seminar 2017 Amazon DynamoDB 详细说明了 DynamoDB 的概要。
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern 阐述了额外功能。

基本特点

在中国使用USB加密狗。

• マネージド型：いわゆる機械運用的なことはAWS側がやってくれる。具体的にはパッチ適用とか。利用者としては楽ちん。ただしブラックボックスになりがちで、自由度は低くなりがち。

 

• NoSQL：NoSQLもいろいろあるけど、DynamoDBはいわゆるKVS（Key Value Store）。キーと値という、連想配列みたいな構造になっている。DBだけでは、キーでしか検索できないし、テーブル間結合もできない。アプリで補ってあげる必要がある。

 

低レイテンシー：レスポンスが早い！ただし、RDBMSと異なりコネクションは都度貼る形となるため、DBリクエストが多くなるような使い方はダサい。

高度可靠性

积分

• 分散DB:3つのAZ（アベイラビリティゾーン：要はデータセンター）を跨いでいるので、安心。

 

• SLA：99.999%（グローバルテーブルの場合）

参考：DevelopersIOさんのブログ – DynamoDBにSLAが設定されGlobal Tablesで99.999%の高可用性になりました

グローバルテーブル：AZ跨ぎじゃなくてリージョン（要は国）を跨げる機能。テーブルを作る時に指定する。途中で変更できない。

参考： AWS公式ブログ – Amazon DynamoDB グローバルテーブルを使用してマルチリージョンアーキテクチャを強化する方法

综合性模型

1. 点数

Note: “ポイント” is borrowed from the English word “point” and commonly used in Japanese to refer to score or points in various contexts. The closest equivalent in Chinese would be “点数.”

• 読み取り整合性は二種類ある。

「結果整合性」と、「強力な整合性」。
デフォルトは、「結果整合性」。

読み取り整合性は、読み取り系APIでDyanmoDBにアクセスするときのオプションとして指定する。

何も指定しないと「結果整合性」が選択される。
テーブル毎に指定するわけではなく、API呼び出しごとに指定することになる。

結果整合性：書き込み直後に読み取ると、古いデータが取れるかもしれない。

メカニズムは公開されていないので、DynamoDBのベースであるCassandraの挙動を元に説明する。
基本的に書き込みは、3箇所のウチ、2つに書き込めれば終了。
残りの1箇所に対しては、しばらくしたらデータがコピーされる。
そのコピーが完了するまでの間に、最新データが書き込まれていない残りの1箇所に運悪く読み込みに行ってしまうと、古いデータが返ってくる。

書き込みが2箇所に対して行われる一方、読み取りは通常、1箇所に対して行われる。

読み込みに行く先は、アプリケーションでは制御できない。

強力な整合性：書き込み直後の読取りでも、最新データを保証してくれる。

メカニズムは公開されていないので、DynamoDBのベースであるCassandraの挙動を元に説明する。
たぶん2箇所見に行って、新しい方のデータ取ってきてるんだと思う。
その分、「キャパシティユニット」っていうDBアクセスのためのリソースを通常の2倍消費する。

要は、2倍、金がかかる。

收费体系

积分

• 「オンデマンドモード」と「プロビジョニングモード」がある。（オンデマンドモードは2018年に追加された）

基本的に性能面に差は無い。コスト面だけを考えれば良い。

性能比較の記事（英語）

オンデマンドモード：従量課金。上限設定ができないので、青天井とも言える。

パーティション/キャパシティユニットの設計をそこまで厳密に行わなくても良くなるので、少し楽になる。

オンデマンドモードでもパーティション/キャパシティユニットの使われ方は変わらないので、パーティション/キャパシティユニットなどを意識しておいた方が良い設計であることに変わりはない。

上記記事でも触れられているが、設計コストや運用コスト、将来の機能追加なども考えると、圧倒的にオンデマンドモードがオススメ。

プロビジョニングモード：事前に使用量を予約しておくヤツ。オンデマンドモードより安い。ただ、予約量を超過するとエラーが返ってくる。

S3のエクスポート/インポートを利用したい場合は、プロビジョニングモードが必要。
ギリギリを狙うよりは、やや余裕をもって設定するのが基本となる。オートスケールにも対応しているため、ある程度柔軟に設定が可能。
参考： AWS Data Pipeline を使用して DynamoDB データをエクスポートおよびインポートする

補充
在第32至34幻片中有關計算容量單位的說明。

构成要素

积分

• HTTPベースのAPIでアクセス可能。

 

• 一般的なRDBMSと異なり、都度コネクションを貼ることになる。そのため、アクセスのオーバーヘッド比較的大きいため、アクセス回数を減らすことが求められる。

KVSという形式であることからも、1回で全てのデータをとってこれるようなテーブル構成が望ましい。

操作桌子

积分

• PutItem：SQLのInsertと近しいが、異なる。Insertはキーが同じレコードが存在したら、登録失敗になる。一方、PutItemはキーが同一のitem:項目が存在したら、上書き。

Conditionというパラメータで条件を指定できるため、「キーが同一のitem:項目が存在していたらエラー」という指定は可能。（指定しないと、上書き扱いになる。）

Scan/Query：SQLのSELECTが近いが、異なる。DynamoDBでは「パーティションキー」と「ソートキー」という二種類を「プライマリキー」として利用ができる。Queryで指定できるのはその二種類のみ。それ以外のattributes:属性（RDBMSで言う所のカラム）では、検索できない。

じゃぁどうすればいいかと言うと、データを全部取ってきて、その後アプリケーションのロジックで絞り込む感じ。
RDBMSがやっていてくれた部分を、DynamoDBとアプリケーションで協力して実現する感じ。
検索画面とかの要件があるなら、RDBMSにレプリケーションして、RDBMSを検索したほうが良いかも。

表格设计的基础知识 (Biaogedesign de jichu zhishi)

积分

如果用关系数据库管理系统来表达的话。

• table（テーブル）：テーブル。

 

• items（項目）：レコード。

 

• attributes（属性）：カラム。

 

• Partition Key：プライマリキー。必須。

 

Sort Key：プライマリキー。オプション。複合プライマリキーを実現したい時に、Partition Keyと合わせて実現するためのモノ。

分区

积分

• データは、パーティションに分割されて格納される。

 

• パーティションキーをハッシュ化して、どのパーティションに格納するか決まる。（DynamoDBが勝手に決める）

 

• パーティション数は、DynamoDBが勝手に決める。以下を元に決めている。

テーブルのデータサイズ
キャパシティユニットの数

如果您想更详细地了解一些内容，请查看第36-45张幻灯片。

特点：属性

重点

• RDBMSと異なり、事前にカラムを定義しておく必要はない。

 

• item:項目（レコード）毎に、attributes:属性（カラム）が異なっても良い。

 

パーティションキーは必須。ソートキーを利用している場合は、ソートキーも必須。

缩放

积分

• RDBMSだとDB単位でスループット（コネクション数など）を決めていたが、DynamoDBではテーブル単位でスループット（キャパシティユニット）を決める。

 

• キャパシティユニットは、パーティションで等分されてしまう。そのため、特定のパーティションにアクセスが偏った場合、「テーブル全体で見るとキャパシティユニットは余っているのに、特定のパーティションは枯渇してしまったために、エラーが返される」という現象が発生してしまう。

バーストキャパシティというセーフティーネット的な機能をAWSが用意してくれているが、これは発生させないことを前提に設計したほうが良い。

本地次要索引（LSI: Local Secondary Index）

积分

• RDBMSのインデックスと同じようなモノ。

 

• パーティションキーは、元となるテーブルと同じという制約がある。

 

• ソートキーは、元のテーブルとは異なるものが設定可能。

 

「強力な整合性」が利用できるため、整合性を求める要件の場合でも、利用できる。

GSI: 全球次要索引

积分 (jī

• RDBMSのインデックスと同じようなモノ。

 

• パーティションキーもソートキーも、元のテーブルとは異なるものが設定可能。

 

• 一方で、「結果整合性」しか利用できない。整合性を求める要件の場合は、こちらは利用不可。

 

感覚的にはLSIよりもGSIの方が使う機会が多いかも。

使用LSI/GSI时的注意事项

积分

スライドそのまま。

TTL：生存时间

积分

• RDBMSと異なり、TTLという「データ有効期限」が指定できる。

 

有効期限が切れると、自動的にデータが削除されるよ！（データクリーニングバッチとか要らないよ！）

DAX：DynamoDB加速器

积分

• おまけ機能だよ！

 

• DAXを使うと、読取りが早くなるよ！（要はキャッシュ）

 

• 「結果整合性」しか用意してないので、「強力な整合性」を求める場合は使えないよ。

 

この記事では深掘りしないので、細かい説明は資料見てね。

DynamoDB流

积分

• おまけ機能だよ！

 

• 書き込みとかを検知して、イベントを発火させることができるよ！

そういう性質上、他のサービスと連携する時に、めちゃくちゃよく使う機能だよ！
具体的には、Lambdaとかと連携して、レプリケーション機能とかも実装できるよ！

公式ブログ：Amazon DynamoDB ストリームを使用して、順序付けされたデータをアプリケーション間でレプリケーションする方法
個人的な解説：【AWS公式ドキュメントを噛み砕く】DynamoDB Stream

この記事では深掘りしないので、細かい説明は資料見てね。

DynamoDB 事务

积分

• 2018年に追加された機能。

 

• RDBMS（JDBC）ほどではないが、ある程度のトランザクション制御が可能。

 

• 詳細を知りたい場合は以下へ。

DevelopersIOさんのブログ：DynamoDBのトランザクションを試してみた #reinvent

备份

重点

• バックアップはいくつか手段があるよ。という話。

 

• なお、2018updateでイントインタイムリカバリがサポートされています。（静止点でのバックアップが可能になった）

DevelopersIOさんのブログ：DynamoDBで継続的バックアップとポイントインタイムリカバリーが可能になりました

请注意

实际使用后遇到的困难部分之类的。
有些内容与上面总结的内容有重复。

内容

• トランザクション制御

 

• 採番方式

 

• 強力な整合性

 

• テーブルとかパーティションキーの設計

 

• RDS(Aurora)へのレプリケーション

 

バックアップ（災害対策）＠大阪

交易控制

详细内容：DevelopersIO先生的博客：尝试使用DynamoDB的事务 #reinvent

DynamoDBTransactions这个功能于2018年发布，但与关系型数据库管理系统（RDBMS）的事务管理不同。
首先，在DynamoDB中无法实现像在RDBMS中那样对事务进行控制。（就像“如果在应用程序的途中发生错误，进行回滚！”这样的操作在DynamoDB中是不存在的。）

可以做的事情

• 複数のクエリをまとめて発行。（発行タイミングは1回にまとめる）

 

頭から順に発行していき、途中で失敗したらロールバック。

不能做的事情 zuò de

アプリケーションの処理のいろんなところで、発行したクエリをまとめてロールバック。

我该怎么办呢？（建议）

• ひとまず書き込み系処理に関しては、アプリケーション処理の最後に回す。

 

なおかつ、DynamoDBTransactionsを利用する。

取号方式

DynamoDB开发指南详解：原子计数器
详细信息：Qiita：全面的ID生成办法

在DynamoDB中，没有序列对象或类似的东西。
如果想要在数据库中实现编号，可以使用原子计数器。
然而，我觉得这与DynamoDB的性质不太相符，所以最好还是利用应用程序内部的编号机制。
例如使用flake等。

结果整合性/强大的整合性（ hé / de hé ）

※ 这是在「基本的讲话」中提到的内容。

基本上，DynamoDB根据”结果一致性”作为标准，如果要使用”强一致性”，则会增加限制。
“结果一致性”被定义为”数据在所有存储位置上最终达到一致性(通常在1秒内)”。
然而，并没有说明最长时间，所以若业务需要关注一致性，我认为”强一致性”是必需的。

使用”强制一致性”的缺点。

• DAXという読取り高速化オプションが利用できない

 

• グローバルセカンダリインデックスが利用できない（ローカルセカンダリインデックスは使える）

 

金がかかる

设计表和分区键

详细信息：DynamoDB开发指南：分区键设计
详细信息：DynamoDB开发指南：最佳实践＞时间序列数据

在NoSQL中，无法在数据库端进行表之间的连接。如果需要表之间的连接，就需要将相关表的所有数据都取出来，在应用程序端进行连接。
因此，除非有特殊原因，一对一的“应用程序：表”是理想的情况。

除了表分割之外，还有其他可以吸收访问频率差异的实践方法。
有关详细信息，请参见幻灯片49至63。
2018年AWS Black Belt在线研讨会 Amazon DynamoDB高级设计模式。

根据获取数据的单位进行表格分割
只使用分区键/排序键可能无法实现期望的获取数据单位，考虑通过表格分割来实现可能是一个好主意。
然而，如果可以通过上述黑带资料（第49至63张幻灯片）中提到的解决方案来应对，那可能更好？

「パーティションキーの設計」
より分散されたアクセスを実現するため、適切な「パーティションキー」を指定することが望ましいです。
例えば、「日付」の場合、最近の日付にアクセスが集中する傾向があるため、一般的にパーティションキーとしては適していません。
一方、「商品ID」のような場合、一般的には適していますが、極端に人気な商品がある場合は、パーティションキーとしては適さない可能性があります。

在本地环境中进行开发

请参考以下内容，设置本地环境。
但是，如果要在生产环境部署应用程序，需要对代码进行微调以使用DynamoDB Web服务。
基本上，我认为可以使用Maven等来进行控制，但使用本地版本还是基于具体情况而定。
AWS开发者指南 – 设置DynamoDB本地版本（可下载版本）

将数据复制到RDS（Aurora）

在中文中，经常听到RDBMS和Lambda之类的东西不兼容的说法。
因此，适合解决这个问题的是”kinesis firehose”。（虽然也有kinesis Datastream，但在这里只提到firehose。）

我希望你能仔细阅读开发指南，但总的来说，它就是一个队列服务（如SQS、SNS、MQ等都属于同一类别）。

由于「Kinesis Firehose」与其他服务的最大区别在于它可以“将请求合并到一定程度”，并且可以批量释放60秒的数据。通过这样做，可以降低与RDS（Aurora）的连接数。

如果使用 SQS-Lambda 等组合时，连接可能会成为一个令人困扰的问题，但是使用 “kinesis firehose” 就没问题了。

备份（灾害应对）＠大阪

当考虑到灾害防范策的备份时，我们可以考虑将数据存储在其他地区，这样就能在需要的时候进行恢复。
从直觉上而言，如果可以使用全球表格，那就再好不过了。

但是，如果有日本国内的限制，由于大阪并不支持全球表，限制会更多。我想现在的选择可能是使用”Data Pipeline”与”S3″进行协作。但是，在这种情况下，需要将容量模式设置为”预置模式”。

如果是“配置模式”，则需要基于容量进行预测，因此不适用于不具备这种要求的业务。

通过使用“点时间恢复”，将其作为备份表进行恢复，并将新创建的表配置为“配置模式”，同时使用数据管道，可能可以实现“按需模式”。

最后

请再次确认并仔细阅读最新的官方文件。
如果一直保持关系型数据库的思维，可能会带来许多困惑，所以请确保能够切换到DynamoDB的思维模式。
如果有任何错误，请通过评论或编辑请求告知我。

以上就是。