はじめに

この記事はMongoDBをまったく知らない筆者がゼロからDocumentDBを学んでまとめたものになります。
今までのDBの経験といえば

MySQL(2年とか)
Redis(半年とか)
DynamoDB(3ヶ月とか)
Spanner（１瞬）
ぐらいでNoSQLよリRDBMSの方が歴も長く、得意といった感じです。
DB設計はいくつかのサービスで経験しましたが、設計＆運用をした経験がほとんどないので、
スケールにめっちゃ自信があるわけではないですが、スケールを考えたキーの命名とかはRedis、DynamoDBあたりでは徹底的に議論した覚えがあります。それでは徒然なるままに始めていきたいと思います。

MongoDBとは

NoSQLといえば、シンプルな検索機能が大きなメリットといえます。
KVSのNoSQLであれば、データをキーバリューの連想配列で保持して検索のスピードが速いです。
RedisはKVSで私は主にC向けのサービスを作っていた時はランキング機能に使っていました。
データが単純だが、件数が多いとRedisを使うと良いという認識でした。
また、Redisはキャッシュとしても有名ですよね。
今回のMongoDBはドキュメント指向データベースと呼ばれる種類のデータベースです。
DynamoDBと同じ種類ですね。
ドキュメント指向データベースでは、文字通りデータをドキュメントとして扱います。
ドキュメントのデータ構造は自由で、スキーマレスでスケールがしやすいのがメリットといえます。

そもそもNoSQLってなんで生まれたん？

最後にDynamoDBを触ったのが半年近く前なのでNoSQLについて忘れてしまいました。
簡単に復習します。
NoSQLが生まれた理由はビッグデータの登場が大きいらしいです。
ビッグデータの定義は様々ですが、ここでのビッグデータは３V（Volume,Velocity,Variety）を満たしたデータということにして起きます。
ビッグデータの登場以前は、構造化されたデータを扱うクライアント・サーバサイド型のアプリケーションが主流でした。
古典的なRDMSはACIDプロパティに従います。
Atomic、Consistent、Isolated、Durableでしたね確か。
一貫性を保証するよってことです。
複数の書き込み処理や変更の処理が走ってもどのトランザクションを通してデータが一貫していることが大切です。
ビッグデータの3Vの２つ、Volume（大量のデータ）、Velocity（高頻度で高速）に対応するにはスケールを考える必要があります。
スケールは2種類あって、スケールアップ、スケールアウトの２つです。
スケールアップは個々のDBサーバの性能をあげること（メモリ容量、CPUのスペック上げるorCPUの数を増やす）で、スケールアウトはDBサーバの数を増やして全体の処理性能を上げることです。
並列処理が行われるような設計にする必要がありますが、今のクラウドだと負荷を検知して自動でスケールしてくれるサービスもあるのであまり意識しなくても良いのかもしれません。

DynamoDBと何が違うの？

DynamoDBもDocumentDBと同様にNoSQLです。
1番の違いと言えば、アクセスパターンが多いことです。
具体的にDynamoDBとの1番の優位性はindexに依存しないクエリが可能なことと菊池さんもおっしゃっています。

また、DocumentDBではネストしたデータのフィールドにもインデックスが貼れるらしいです。

DocumentDBのプロコン

プロ

高速＆スケーラブル

ストレージの量がすっごい　６４TB

高可用性

可用性が99.99%
インスタンスに障害が発生したらインスタンスを30秒以内で再起動
マスターインスタンスが死んだらリードレプリカに自動でフェイルオーバー

コン

トランザクションがない

MongoDBのバージョン４以降ではトランザクションの処理が加わるらしいですが、
現在DocumentDBが対応しているMongoDBのバージョンは3.6です。

データ量が多くなりがち

RDBと比べるとデータ量が多くなりがちらしいです。なんでだろう保存の仕方が問題なのか。DB設計上データ量が多くなる？知っている方がいたら教えて欲しいです。

まとめ

DocumentDBは2019年1月に発表されて現在は東京リージョンもあるAWSの完全マネージド型のドキュメント指向データベースです。
インデックスの貼り方をミスらなければかなり良いDBな気がしました。
これから具体的なサービスに落とし込んでいきたいと思います。いい感じにTipsを共有していきっます