Q&A
件数とパフォーマンス、可用性あたりがトレードオフになると思いますが、????文章だとデータはユーザーあたり1日1件になりますが、合っているでしょうか。
前提・実現したいこと
サーバ、アプリ開発等初学者の高校生です。
AWSの無料枠を使って、バイタルデータを折れ線グラフ化させるアプリを開発しようと考えています。
以下のようなバイタルデータをs3へ送信しています。
S3へjsonファイルがアップロードされるといずれかのDBへとデータの挿入を行う
という形を想定しています。
毎日送られるデータを用いてグラフを更新していきたい場合どういった構成をとればよいでしょうか。RDS,DynamoDBの差はある程度理解していますが自身の用途に当てはめて考えると決めあぐねてしまいます。
追記
学習用途に作成しているものなので、想定しているデータ、ユーザの規模ともに極めて小さいです。
送信されたjsonファイル
{"Name": "***", "Day": "2020-09-11", "Time": "15:08:40", "MaxBloodPressure[mmHg]": 101, "MinBloodPressure[mmHg]": 62, "AveBloodpressure[mmHg]": 82, "HeartRate[bpm]": 65, "BodyTemperature[degree Celsius]": 36.22}
回答3件
0
正直なところそんなに複雑なクエリを投げるようなものでもなさそうなので、どちらでもいいと思います。
学習のためであるならば両方やってみて比べてみるのもいいでしょう。
RDSは一般にそこそこ高額なので、リレーショナルである必要のなく、かつ少量のデータを置いておきたい場合は、ケチるためにDynamoDBを使うことはありますが、無料枠の範疇なのでそこは考慮外ですね。
今回作るものがもし頻繁にデータが追加されて容量がどんどん増えていくもので、かつそこまで複雑なクエリが必要でないものであればDynamoDBは一つの選択肢でしょう。
とはいえ、DynamoDB（を含むNoSQL）を適切に使いこなすのは結構難しいので基本的にはRDS（というか、RDBMS）を使うことを前提にしてNoSQLを適用する可能性を検討する、という優先順位で考えて十分な場合が多いです。
投稿2020/09/12 09:05
総合スコア7588
習得コストに関しては考えていませんでした。年内に何とか形にしたいと思っているので、やはりRDSを優先的に扱うべきなのかと。ただ、その構成ですとデータ送信の自動化をしている先駆者があまり見つけられずうだうだと勉強だけが続いてしまいそうです...
回答ありがとうございます。
習得コストの話ではなく、設計の難易度の話なんですけどね…。
いくらでも方法はありますが、S3へのPUTをトリガーに何かしらの処理を挟むとよさそうですね。
バッチ処理とかでもいいとかならどうとでもなりますし。
それらについての手法の差異はあるでしょうが、今回の範疇だと大差ないので勉強のためならやはり両方やってみることをおすすめします。
ちなみに、jsonであればdynamoDBに突っ込む方法はすぐに出てくると思います。
表現があいまいでした、申し訳ないです...。
S3へのPUTをトリガーにlambdaでRDSへ...と考えたのですが、一般的にこの構成はアンチパターンなのですね。今回は多数のアクセスは想定していないですがやはり避けるべきなのかなあと。
他の皆様にもいろいろとご指摘いただきましたので勉強しつつ複数の手法に手を出してみます。
json→dynamoDBですが確かに方法発見しました!さらに悩んでしまいそうですが頑張ります！
LambdaとRDSの組み合わせがなぜアンチパターンと言われていたかについては下記をご参照ください。
https://www.keisuke69.net/entry/2017/06/21/121501
今はアップデートのおかげでアンチパターンを回避して使う方法もありますし、用途によってはさして問題ないケースもあるので、「なぜアンチパターンだったのか」をきちんと理解してください。
要件と前提に書いてないのでここはわかりませんが、反映をリアルタイムに行いたいのであればデータ送信の時点でRDSなりDynamoDBなりに入るようにすればいいような気もします。
AWS内部からの送信であれば何らかの処理で直接入れてもいいですが、AWS外部から送信しているのならAPIを経由するといいでしょう。
特にリアルタイム性が求められないなら、定期的にバッチ処理でインポートする、でも十分です。
今は学習の段階だと思いますが、RDBMSとNoSQLの特性を理解して適切に選択ができるといいですね。
知識、語彙ともに不十分なので提示いただいた参照先を十分に理解するには時間がかかりますが...最大の問題はlambdaがRDSに張るコネクションは、RDSが許容できるコネクション数を上回ってしまう可能性があるよ、ということでしょうか。
リアルタイム性についてはあまり考慮をしていませんでした。計測自体が1日1回程度を想定しているため、定期的な送信でもよいかと考えました。いろいろとご指摘いただいて要件定義の甘さを痛感しています。
概ねその理解でよいです。
特性については参考サイトの記事に詳しく書いてありますが、Lambdaに対するリクエストごとにRDSへのコネクションが張られてしまう可能性があるので、必要以上に接続数を要求してしまうケースがあるということです。
これについては最近リリースされたRDS Proxyを使うことによって回避が可能です。
その要件ならS3へのPUTごとに送る必要もあまりなくて、バッチ処理でまとめてインポートでも良さそうな気がしますね。
バッチサーバを作ってその上でcron実行でもいいですが、FargateでScheduled Tasksでの実行だとサーバが不要です。
用途によってはLambdaでもいいですが、時間のかかる処理の場合はあまり向きません。
無料枠の範疇であればとりあえず立てたサーバの上で定期実行するのが一番シンプルですが、本来はバッチ実行する環境とアプリケーションを動かす環境は分けたほうが好ましいです。
先の参照先については調べしらべ深く理解しておこうと思います。
proxyは知っていましたが、fargateというサービスの存在は初耳でした。どちらも有用なサービスですが今のところ無料での利用はできないようですね。今後有料での利用をする場合には参考にさせていただきます。
aws初学者としてはサービスをフル活用してみたいところですが、バッチ処理も選択肢の一つとして考えます。
本来は環境を分ける、というのは多数のユーザーを意識した時のサーバ負荷やセキュリティ、メンテナンスの効率等を考えての構成なのでしょうか。後学のためご回答いただきたいです。
fargateはECSで選択できるコンテナ実行基盤のことです。
正直なところ無料枠だけではクラウドの恩恵は十分には受けられませんが、初学の段階で基礎を学ぶのであればまずは無料枠の範囲でよいとは思います。
書くのを忘れてましたがGlueもアリですね。
ごく単純な理由として、どちらかでエラーが発生してサーバのリソースを食いつぶしたりサーバダウンしたりしたら、本来は独立している両者の処理がともにダウンしてしまうからです。
無料枠の範囲ではサーバを複数立てる構成はほぼ実現不可能だと思いますが、運用上は一つのサーバの役割は少ないほうが好ましいです。
また、ELBを使ってスケールする環境を作りたい場合、新しくサーバを立ててすぐに同じように動いてくれるWEBサーバとして使えるようにならないといけません。
例えばバッチをWEBサーバ上で定期実行してるような環境をそのまま複製したりすると、複製したサーバの台数分バッチが多重実行されることになりますよね。
フレームワークの機能（RailsのRakeタスクやLaravelのartisanなど）でバッチを作成していてサーバ上のcronで定期実行している、なんて環境はよくありますが、何も考えずにそれを行うとスケール可能な環境に作り変えたい時のハードルが増えます。
多くのフレームワークはモノリシックにシステムを作成することを前提に作られていますが、デフォルトではクラウドインフラ上でスケールさせられる構成に適した作りにはなっておらず工夫が必要です。
そこまで考慮しないでとりあえず動くものをまずは作りたい、というときはあまり細かいことは考えなくてもいいんですけどね。
fargateの理解、活用にはもう少し勉強が必要そうですので自身への課題として考えることとします...。
こうやって多くの技術者が触れているサービスに関わるというのは非常に楽しいので、将来的には有料でも何か作ってみたいと思います。
glueというのも初耳で先ほど少し調べてみました。性質としては高度な機能を持たされたDBのようなものと考えました。サーバーレスですが、先日おっしゃっていたバッチ処理に関しても利用の可能性を感じます。そして無料の利用枠がある点もありがたいです。ただ、DBとの性質の違いがあまり理解できていないこと、web上に参照できる資料があまりないことから、即座に利用するには不安が残るところもあります。
アプリケーションの環境とバッチ実行の環境を分ける理由、非常にわかりやすく納得の行くものでした。確かに独立の環境で動かすほうがリスクを分散させるという意味で有効ですね。ですが本件に関してはやはりそこまで考慮することは必ずしも、と感じますので現行立てているサーバ上で定期的なバッチ処理を行うという形で考えてみることにします。
選択肢を大いに広げていただけたこと大変感謝します。やはり普段から利用している方に聞かないとわからないことは多いですね。もっといろいろな環境で学んでみたいと思いました。
> glueというのも初耳で先ほど少し調べてみました。性質としては高度な機能を持たされたDBのようなものと考えました
いいえ、その理解は正しくないです。
GlueというのはいわゆるETLを提供するAWSのマネージドサービスで、あるデータソースからあるデータソースへのデータの移行やその途中での変換を行うことができます。
色々言っちゃいましたけどまだ初学の段階ということなので、とりあえずまずは動くものを作ってみるといいと思います。
ここで書いたようなことはおいおい思い出してくれればよいかなと…。
Glue自体がDBとしての機能も持つものと思っていましたが、そういうことだったんですね。aws公式の概要は私には少し難しかったようです。
これまでに頂いた助言は適宜参考にし、不格好なりにも何とか形づくっていきたいと思います。
非常に助かりました。また助言を求めつつ頑張って作ってみます。
0
うか。RDS,DynamoDBの差はある程度理解していますが自身の用途に当てはめて考えると決めあぐねてしまいます。
SQLを使うかどうかで判断すれば良いと思いますが、実際のところどの程度の理解でしょうか？RDBMSとNoSQLの違いは把握されているんでしょうか？
もし違いについて曖昧な知識であれば一旦RDBとNoSQLの違いを調べた方がいいですね。
投稿2020/09/12 07:56
総合スコア6426
処理にかかる時間の違いがある？程度に非常に曖昧な理解でしたので、簡単に調べなおしました。
NoSQLは膨大なデータを扱う際によく使われるとのことで、本システムには過分であると判断しました。
ご指摘ありがとうございます。
いや、一番大きな違いはSQLを使えるかどうかです。SQLがあるからこそRDBは世界に広まりまったようなもんでしょう。
一旦プログラム開発は置いといて先にSQLの勉強してみたらどうでしょうか？１～２カ月も勉強すれば十分です。
知る前と知った後でプログラム開発の速度はもちろんの事、DB設計やプログラムの構成が劇的に（読み易く・速く）変わると思いますよ。
それから改めてRDSかDynamoDBを選定しても遅くないです。というかここで聞く間でもなく即座に自身で判断出来るようになると思います。
SQLに対する認識が、ただのDBを操作するための簡単な言語のようなもの、と考えていましたが甘かったようですね。
都合上開発の手は止められないのですが、本腰を入れて後学のためにもSQLに対する知見を広めてみたいと思います。一応、自身の判断の正誤を見るためにも一度RDSで仮の構成もしてみることにしました。
認識不足を補うお言葉ありがとうございました。
0
ベストアンサー
毎日送られるデータを用いてグラフを更新していきたい場合どういった構成をとればよいでしょうか
データの規模がわかっていませんが、RDB で必要十分に思います。
RDBの強力な整合性に対して、結果整合とする代わりにパフォーマンスを向上させた Dynamo
という違いがあると認識していて、レコード数や Read/Write の回数等がかなりの量にならない限り RDB を選択すべきに思います。
（もちろん細かいメリットデメリットはあるとは思いますが
S3へjsonファイルがアップロードされるといずれかのDBへとデータの挿入を行う
という形を想定しています
質問と関係はないですが、自分であれば、S3を中継する必要は感じないので、DBに直接保存する構成にすると思いました。
投稿2020/09/12 07:48
編集2020/09/15 12:26総合スコア1531
回答ありがとうございます。
ご指摘後改めて調べたところ、RDS利用が適切かと感じました。
s3を中継したのは自分が視覚的に理解しやすかったためですが、技術的に可能であればおっしゃられた通りの構成にも挑戦してみようと思います。
RDSは名前の通りリレーショナルデータベースを扱ったもので、DynamoDBはNoSQLのマネージドサービスなのでそもそもモノが違います。
RDSの整合性の部分を削った…というのはあまり適切ではないかと。
https://www.acrovision.jp/service/aws/?p=1749
https://blog.serverworks.co.jp/tech/2017/04/12/what_is_different_dynamodb_and_rds/
とはいえ、大抵のケースではRDBMSを選択しておくのが無難（最適かはケースバイケース）というのには同意します。
適切でない理由がよくわかりませんでしたが（モノが違うのは当然理解しています）、意図としては
概して RDB と DynamoDB（NoSQL というと Redis 等も含むので） では
整合性 <-> パフォーマンス /スケーラビリティ
のトレードオフのとり方が基本的な、かつ一番大きな違いの軸としてあると認識しているので、
要件的にパフォーマンス面で差が出ない以上、単に整合性を犠牲にする面があるというのを伝わりやすいように言ったつもりです
「そもそもモノが違う」ので「削った」とするのは正確ではない、という意図です。
> 最低でも何百万、総数数億レコード以上のデータとか言う話でない限りトレードオフにならず、
RDSの整合性等の部分を削ったものが Dynamo だと思っています。
説明として大きく間違っていると思います。
データ構造を正規化することができ、その恩恵を大きく受けることができるのが RDB、正規化しにくいデータ構造や、もしくは非正規化データを取り扱うことで大きな恩恵を受けることができる場合に採用されるのが DynamoDB です。
性質の違いの例を別に上げたところで、原文の真偽を決定することはできない気がしました。
その説明も正しいですが、結果整合性を採用することでパフォーマンスにメリットを出している、という事実も正しいと認識しています。
また、回答段階では1日1レコードという条件がなく、複数ユーザーの時系列で保存するような状況で
> 最低でも何百万、総数数億レコード以上
が必要になる可能性もあったため、今回の要件でトレードオフになりえる最大の特徴になると考えました。そのため、その言及を回答でしたのみです。
また、正規化データかどうかは、そもそも今回の要件ではデータ形式決まっているように見えるので、トレードオフにならないかと思います。
要件を前提としていて、 RDB と Dynamo の一般的な性質の違いすべてを正しく説明する意図ははじめからありません。
> 結果整合性を採用することでパフォーマンスにメリットを出している、という事実も正しいと認識しています。
もしこれが概論として間違っているのであれば、詳しく教えていただきたいです
（大きく間違っていると断じられているので
回答の表現が気に入らない方がいるようなので、意図するところは同じですが表現を修正しました。
よくよく見たら言及しているのは「RDB」とDynamoDBの比較で「RDS」とDynamoDBの比較ではないんですね。
自分が読んでて違和感を感じてしまっていたのは多分そのせいでしょう。
仰るようにRDBMS一般の話であれば大抵のケースでは無難な選択です。
ただし「RDS」を対象とした場合、コストパフォーマンスの話がつきまといます。
RDSは高いんです…。EC2+RDS（＋色々）の構成で組んだ時、大抵のケースで最も料金が高くなるのはRDSです。
少量の、しかもRDBを使うほどリレーショナルである必要もないデータに対してRDSを使うのはtoo muchなケースはあります。
（少量のデータを想定していることは後で追記されたことではありましたが、一方無料枠であることは当初から記載済みでもありました）
今回の場合無料枠の範疇なのでそのへんは考慮する必要はありませんけれど。
ただ、「RDBで必要十分だからDynamoDBよりもRDBを選択すべき」と断言するのはやはりちょっと違和感があり、本来はデータ構造と要件に応じてもう少し精査すべきところであるとは思います。
自分の回答に「どちらでもいいと思う」と書いたのはそのへんを意図してのことです。
個人的な意見を言うと、今回出されているデータだけを見るなら別にDynamoDBでも何ら問題はないのではとも思いますが、最終的にこのデータをどう使うかとか他のデータとどう絡むか次第ですね。
もっとも学習用途とのことなのでどっちもやってみればいいというのは自分の回答の通りです。
質問に対する回答とは大きく外れてしまいましたが…。
RDS と読み替えても良いです。
無料枠と書いてあるので、料金に関して判断のトレードオフにはしていません。
そもそも、RDSとDynamoDBであれば一般的な採用率や学習情報の量などに雲泥の差があるので断定しています。
上記コメントの主張がわからないのですが、RDSとDynamoDB どちらにすればよいか？という質問に対して明確に答えることが、回答の第一意義なので、伝わりやすさ等加味して簡潔に理由を加えて示せば十分と思っています。
最終的にどちらでも良い、好きな方使えば良いと言うのは自分も同意見ですが、あくまで質問に答えるということをしています。
ドキュメントにも書いてあるような余計なことをつらつら書くことは、質問者のニーズという点で考えると、おせっかいな面が出てくると思い、あくまでしない主義です。
> 結果整合性を採用することでパフォーマンスにメリットを出している、という事実も正しいと認識しています。
実際のパフォーマンスの差異は、データ構造の持ち方によって発生します。
DynamoDB はデータ構造の設計として、アプリケーションのユースケースを適切に表すことが推奨されますが、まさにそれがパフォーマンスに対しての差異として現れます。
アプリケーションのユースケース毎にデータを持つことで、限定的なクエリで高速にレスポンスを返すのが DynamoDB の特徴です。ユースケース毎にデータを持つという事は、多くの場合、非正規化データを持つことになります。
一方、RDB では、正規化された table をクエリでつなぎ合わせて、柔軟にデータを作り出すことが可能です。クエリによるデータの抽出は、当然ですがそれなりに重く、処理毎に実行されるので、あらかじめユースケースごとに作成されたデータを返す DynamoDB と比べると、パフォーマンスに劣ります。
と、ここまで書いておいてなんですが、RDB で非正規化データを取り扱うことも、逆に DynamoDB で正規化データを取り扱うことも可能です。RDB であえて正規化せずパフォーマンス優先なデータ構造をとることもあるし、DynamoDB で正規化したデータ構造に対して複雑なクエリを実現することも(極稀に)あります。
ただ、それらは各 DB のコンセプトから外れるため推奨されず、DB の良さを封じてしまうことになります。RDB で非正規化データを扱うことはメンテナンス性能や柔軟なデータの抽出に影響を及ぼし、DynamoDB で正規化データに拘ることは、は深刻なパフォーマンス劣化につながります。
結果整合性は主にスケールアウトの文脈で語られる内容なので、パフォーマンスに対しての文脈では違和感があります。パフォーマンスを比較軸として採用するのであれば、推奨されるデータ構造のあり方で語られるべきだと思います。
> 実際のパフォーマンスの差異は、データ構造の持ち方によって発生します。
それは当然というか当たり前というか、逆にRDSとDynamoDBで明確な違いはないように思います。
どちらもより正規化すればパフォーマンスは基準より悪くなりますし、より非正規化すれば良くなる傾向は変わらないかと思います。（つまり基準パフォーマンスに対する両者の本質的な違いではない
もちろんスキーマレスかどうかやクエリの発行方法等によって実装のやりやすさ等は変わりますが。
> 結果整合性は主にスケールアウトの文脈で語られる内容
スケールアウトせずとも、複数AZに書き込むので、ほぼ同時に複数トランザクションした場合、書き込み完了していないAZのデータを読むと古い結果が返ると思いました。（つまり整合性を犠牲にしている。が、当然最新であることを保証しないのでパフォーマンスする
更に、やはりACID をどこまで保証するかが、RDS と DynamoDB の一番大きな違いだと思います。
（もっといえば一般的な NoSQL のバリエーションの分類についても
> 結果整合性を採用することでパフォーマンスにメリットを出している、という事実も正しいと認識しています。
つまりこれは正しい認識で良いですよね？論点がずれている気がします。
> どちらもより正規化すればパフォーマンスは基準より悪くなりますし、より非正規化すれば良くなる傾向は変わらないかと思います。
先のコメントにも書きましたが、「データ構造を正規化することができ、その恩恵を大きく受けることができるのが RDB、正規化しにくいデータ構造や、もしくは非正規化データを取り扱うことで大きな恩恵を受けることができる場合に採用されるのが DynamoDB」です。つまり、DB 設計のコンセプトが違うことが大きな差異です。
当然、DB の設計コンセプトなので、コンセプトに従った使用方法が推奨されます。
(コンセプトから外れた使い方をすると、使用メリットを大きく減じることになります)
> 結果整合性を採用することでパフォーマンスにメリットを出している、という事実も正しいと認識しています。
この表現にこだわる理由が分かりません。
パフォーマンスの文脈であれば、明らかに、推奨されるデータ構造の違いが差異だと思いますよ。
> データ構造を正規化することができ、その恩恵を大きく受けることができるのが RDB、正規化しにくいデータ構造や、もしくは非正規化データを取り扱うことで大きな恩恵を受けることができる場合に採用されるのが DynamoDB
その説明 `も` 正しいとしています。が、
> 結果整合性を採用することでパフォーマンスにメリットを出している、という事実も正しいと認識しています。
です。
> もしこれが概論として間違っているのであれば、詳しく教えていただきたいです
>（大きく間違っていると断じられているので
これの回答だと思ったので、ずれた持論を展開されるのであれば特にこれ以上返答する内容はありませんmm
（単に上記について間違っているかどうか知りたかっただけなので
> パフォーマンスの文脈であれば、明らかに、推奨されるデータ構造の違いが差異だと思いますよ。
この言明については先のコメント内容から明確に間違いだと思います。
あなたの回答
tips
プレビュー
