DB設計：お知らせや、通知のDBは、NoSQLと、RDBどちらを使うことが多いですか？

Question

DB設計で悩んでます。

要件によって変わるのは前提でお聞きしたいです。
お知らせや、通知などは、「ユーザー数☓お知らせ数」で、レコードがどんどん増えていくので、MysqlなどRDBで管理するべきかどうか悩んでいます。
RDBで管理すれば、あとで集計などは楽そうですが、容量がどんどん増えるので、DB全体を圧迫していきそうに感じてます。

このテラテイルもそうですが、こういうお知らせは、どこに保存するのが良いですか？
ぜひ皆様のお考えを知りたいです。
どうぞよろしくお願いします。

Answer 1

個人的にはRDBです。
RDBに保存されているユーザーとリレーションを設定したいので。

RDBで管理すれば、あとで集計などは楽そうですが、容量がどんどん増えるので、DB全体を圧迫していきそうに感じてます。

古くなったら消すとか、既読したら別のテーブルに移すなど手はありますが、実際そこまでするのは本当に大規模じゃないとなかなかないと思われます。

Comments

[kurosaki]

ありがとうございます！参考にさせていただきます！

[kyoya0819]

> 古くなったら消すとか、既読したら別のテーブルに移すなど手はありますが、実際そこまでするのは本当に大規模じゃないとなかなかないと思われます。

詳しくはわからないですが、もしかしたらメルカリの取引評価がこれを採用している「かも」です。

Answer 2

お知らせ毎，ユーザー毎などで管理をするならRDBですが，
insertするならinfo1,info2...などでスケールアウトしやすいnosqlの方が実装は楽でしょう．

ただ，容量がどんどん増えるとおっしゃっているので，規模感は分からないですけど相当量ならコスパはnosqlでしょうね．
持っている情報だけですと，横に増えると考えて
小規模 -> RDB
中，大規模 ->nosql

Comments

[kurosaki]

ありがとうございます！参考にさせていただきます！

[sazi]

>「小規模 -> nosql」　「中，大規模 ->RDB」
一般的に言われるものと逆なのですが、「持っている情報」とはどのようなものですか？

[hentaiman]

同じ事疑問に思ったけど、全DBデータをNoSQLにするかRDBにするかという意味で質問を捉えたんじゃないかと。まあそうだとしても個人的にはNGですけど。

[mote]

やべ、結論逆だった…
前半でNOSQLのスケールアウトとか言ってて結論逆になってて申し訳ない。

Answer 3

お知らせや、通知などは、「ユーザー数☓お知らせ数」

全体へのお知らせとか通知は、そんなことにはならないし、そのようにデータを生成するのも無駄です。

お知らせと通知先の組み合わせで考えるならリレーショナルを考慮する必要があるのでRDBの方が当然管理はしやすいと思います。

Comments

[kurosaki]

ありがとうございます！参考にさせていただきます！

[sazi]

大量に蓄積していくだけのデータならNoSQLが向いていますが、質問に挙げられた項目についてはそうは思えませんので。