DynamoDBのユースケースを考えてみる

DynamoDBに限定しないが、KVSやドキュメントDBの特徴を理解していくとユースケースに納得ができる場合が増え、考えをまとめてみたくなったので記事にしてみます。

ログ

KVSを利用したログのシステムは多くの事例があるため、イメージしやすいですね。

ElasticSearchを利用したログシステムは以前構築していたため、イメージしやすいです。検索においても条件の指定も可能で検索速度も早くかなり重宝しました。

なぜログが有用かというと、ログの内容を柔軟に変更できる点がスキーマレスとして有用なケースになっています。

アクセスログとか複数台のサーバーにあってそれぞれ確認したり、1日あたり200MBのサイズになったり必要な情報を探すだけで一仕事になるケースもあったのでElasticSearchに移行したことはよかったですね。あまり利用されていなかった印象はありましたが、便利だと実感しました。

Amazon Elasticsearch Serviceを使っていた時は容量やアクセス量が課題になった時に止まることがあったので、容量を気にしない構造はありがたいとおもいます。検索がどれくらいできるかためしてませんが、index次第でうまく使えるのかな。

フォーム

問い合わせフォームや質問フォームを構築する際に、項目が違う場合がよくあると思います。

こういうケースでRDBを利用すると、1対多のデータになります。回答についても1対多のデータになり、DBをみる際にはうまく検索しないと回答がわかりづらいです。

ドキュメントDBを利用することで、回答が１レコードにまとまるため回答とデータが紐づくことがわかりやすくなると思います。データ構造をRDBと同じリレーション構造にしてしまうとダメですが、そこはちゃんとアプリに合わせたデータ構造にすることで便利になりますね。

DBの構成を考えないだけで登録も取得も簡単になりそうで、便利だと実感してきました。

googleフォームとかフォーム作成ツールって便利だなー。と思っていましたが、案外RDBじゃないだけで簡単にみえてくるのがすごいですね。

動的なフォーム作る時は入力フォームの内容で結構面倒になるからあまり作ってきませんでした。radioとかselectの項目とか作るの考えると面倒ですね。

フォームの形も1レコードで作ろうと思えば作れそうですね。その分決まりごとを作っておかないと予期せぬデータが増えそうですが、設計上は簡単になりそうです。

チャット

フォームの内容とも似ていますが、メッセージに種類がいくつかあると思います。

テキスト、画像、動画、位置情報、スタンプ。

これがデータとして1レコードで作れそうですね。なんでも1レコードにいれてしまうのが良いのかわからない部分もありますが、メッセージというentityとして考えれば1レコードで考えるのは妥当になりそうです。

dynamoDBでチャットアプリのサンプルをいくつか見ましたが、どうやってlimitとsortをやっているのか気になっています。

indexにsort番号をつける感じですかね。

すでに全て世の中にある

書籍にも載っているユースケースばかりですが、自分で納得できることが重要だと思っています。人に説明することで勉強の理解度が深まることと似ていると思いますが、説明材料があることでRDBでいいじゃん。を説得しやすくなりますしね。

書いてある内容をそのまま鵜呑みにせず、なぜ有用なのかがしっくりくると使うモチベーションが上がると思っています。

実際DynamoDBを使ってみましたが、RDBの方がいままで利用していた分学習コストも低くやろうと考えたことは大体できると思うためRDBで良いじゃん。と結構周りから言われています。新しいことをやる必要って本当に詰まった時以外あまりないのも事実ですが、気になっていた技術なので触っている感じはあります。実務で活きると決まっているわけではないため、やりきるモチベーションは低くなってしまうわけです。

なにが作れるか見えてくるとモチベーションが違う。と思うわけです。

勉強ばかりで活かす場所を探しましょうかー。。。