Q&A
ありがとうございます！
NoSQLの方がしっかりと目的とビジョンを持って設計・導入しないとデメリットが大きくなるのかな、と捉えました。
「よく分からなければRDS」←すごく心に響きました笑
でもNoSQLを触らずにいても仰られた言葉の意味を理解できないと思いましたので、まずは使ってみようと思います。
（勝手に引用した記事に言及させてしまい、申し訳ありませんでした。。。）
個人開発・スタートアップで採用すべき最強のアーキテクチャを考えた
上記記事で
RDS vs DynamoDB
結論から言うと問答無用でDynamoDBを選択することを推奨します。
正確にいうとDynamoDBでは表現しきれないデータ構造や複雑すぎるアクセスパターンの場合はRDSにせざるをえないのですが、初期のフェーズではDynamoDBで作って無理が出てきたらRDSとの併用を考えるという形が良いと思います。
との記載がありました。
この記事への人気コメントとして、
この理由でNoSQL採用すると後で死なない？NoSQLをRDBの代わりとして使わないほうがいいよ
これ、スタートアップではものすごい技術的負債になるので、普通に RDS にしたほうがいいよ。 “初期のフェーズではDynamoDBで作って無理が出てきたらRDSとの併用を考える”
という反応がありました。
もちろんどのようなデータがどんな要件で使われるかで適する構造は変わると思いますが、一般論として、どのような要件であればRDSが適していて、どのような要件ならNoSQLが適しているのでしょうか？
また、コメントではなぜこの文脈においてNoSQLに否定的な見解が支持を集めているのでしょうか？
これから作るシステムでNoSQL採用を少し検討していたタイミングでしたので、経験のある方の率直な感触を伺えたらと思いました。
回答2件
0
RDBMSの重要な特性として、ACIDと言われるものがあります。
- A…Atomicity（不可分性）1つのトランザクションが「完全に実行される」か「全く実行されない」かのどちらかになる
- C…Consistency（一貫性）データベースレベルで、データに制約条件をかけて、それは必ず守られる
- I…Isolation（独立性）トランザクションの途中経過は、他のトランザクションからは見えない
- D…Durability（永続性）トランザクションの結果が確定すれば、そのデータが失われることはない
NoSQLは、これらの特徴を持たない、あるいは独自の形で実装しています。たとえば、DynamoDBでは自由な構造のデータを作成できますので、明らかにCと合致しません。
NoSQLを使う場合、その製品が担保していないデータ整合性は、別な方法で担保する必要が出てきます。
なお、Amazon自身がDynamoDBに合うかどうかのチェックリストを公開しています。
投稿2020/10/30 08:38
総合スコア145184
0
ベストアンサー
SQL使いたければRDBMS（以降RDS）
RDSで困らなければRDS
よく分からなければRDS
勝手に引用された記事に対して意見言うのは悪い気がしますが、
初期のフェーズではDynamoDBで作って無理が出てきたらRDSとの併用を考えるという形が良いと思います。
かなり控えめに言ってありえないです
そんなシステムの面倒見てくれって言われたら相場より高くします。
これから作るシステムでNoSQL採用を少し検討していたタイミングでしたので、経験のある方の率直な感触を伺えたらと思いました。
それはそれで良いんじゃないでしょうか。何事も経験です。両方使ってそれぞれの特徴を知るのが良いでしょう。
投稿2020/10/30 05:25
総合スコア6421
mysqlやpostgres等のRDBMS利用したシステム構築・設計の経験が無ければそちらを優先して作る事をおすすめします。
それをNoSQLに置き換えて作るとしたらどうするかで考えた方が良いです。
※特徴が違うので置き換えるという考え方も不適切ですが
なるほどです。
以前RubyOnRails x PostgresでWEBアプリを作った時に、データが増えてきたらクエリ実行がレスポンスのボトルネックになってしまい、redisを導入してクエリ結果をキャッシュした時がありました。
レスポンスがかなり早かったので、もしかしたらもっとredisにデータを持たせても良いのかな、と感じました。
その際にredis documentsの日本語訳（http://redis.shibu.jp/tutorial/index.html）を見たのですが、ケーススタディに衝撃を受けました。
SET uid:1000:username antirez
SET uid:1000:password p1pp0
SET username:antirez:uid 1000
uidとusernameとpasswordを別のkeyで保存している！
postgresなら一発なのに、欲しいデータを取るためにプログラム側で担う事がとても多いなと感じました。
ソートも検索も別テーブルの連携も事前に予定していないと厳しそうだなと。
でもユースケースでtwitterライクなアプリを作れるなら、もしかしたら一般的にこうしたアプローチが初手で採用される世の中なのかな、、、と感じ、先のQiita記事と併せて不安になり質問させていただいた次第です。
誰にも気軽に聞けず不安でしたが、お答えを伺えて少し安心しました！ありがとうございました。
質問とは関係無いけど回答したついでに、
そういう時はredisを検討する前にSQLチューニング、DBチューニングをするものです。
> postgresなら一発なのに、欲しいデータを取るためにプログラム側で担う事がとても多いなと感じました。
利用箇所が適していないだけか、他に適した手段があるのでは？と思います。
> でtwitterライクなアプリを作れるなら、もしかしたら一般的にこうしたアプローチが初手
twitterでこそNoSQLが最初の選択に来るなんてありえないです。
という事で、質問者の今の習熟度ならSQL・DBのチューニングを学習するのが一番良いんじゃないかと思います。次点でネットワーク。
ついでのご回答、誠にありがたいです・・・
キャッシュよりSQL・DBチューニングの方が先立つべしとの事ですね。
ありがとうございます！精進いたします。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2020/10/31 01:35