Q&A
> 1人1000レコードｘ1000人＝100万レコードも生成されてしまうのがネックに感じています。
それの何が問題なのですか？
（逆に、「何が何でもレコードを減らしたい」事情はどのようなものでしょうか）
実現したいこと
1ユーザ1000以上のレコードをもつ必要があるサービスを構築中です。
例えば、Twitterのフォロー/アンフォローのようなテーブル構築をしたいです。
【案①】
| id | user_id | follow_user_id |
|---|---|---|
| 1 | 5987 | 3654 |
| 2 | 5987 | 4342 |
| 3 | 5987 | 2232 |
| : | : | : |
このようにするのが一般的だということは理解できます。
https://katakata-gym.com/blog/7lMlLHQCHBEfSseaEHuP
や
https://hit.hateblo.jp/entry/2016/05/09/131806
の記事を見ても、このように構築されています。
この構成だと更新や削除は簡単に行えますが、私はこれはしたくありません。
なぜなら、レコード数が膨大になるからです。
↑のようなDB構成にした場合、例えば、1000人をフォローしたら1000レコードが生成されてしまいます。
1人1000レコードｘ1000人＝100万レコードも生成されてしまうのがネックに感じています。
【案②】
そうではなく、
| id | user_id | follow_user_id |
|---|---|---|
| 1 | 5987 | 3654,4342,2232, ... |
| : | : | : |
というように、1ユーザ1レコードとして、1つのカラムの中にコンマ区切りで追記していく方法を思いついています。
こうした場合、1人1レコードｘ1000人＝1000レコードしか生成されない点を評価しています。
※なるべくレコード数を減らしたいという観点。
この案でもいいのですが、もっといい方法があるかもしれないと思い、質問させていただきました。
背景が長くなってしまいましたが、質問内容としては、
Q. Twitterのフォロワーのように、1人のユーザが1000や2000個の情報を持つ必要がある場合、1人当たりのレコード数をなるべく減らすことに重点を置いた場合、【案②】以外のやり方でいい方法はありませんでしょうか？
以上、よろしくお願いいたします。
構造は比較的単純だけど巨大でトランザクションも必要なデータだと、kafkaのようなソフトを使うのかなぁと漠然と思っていました。しかし、これだけ具体性のない話だけで質問しちゃうようなレベルだと、考えるだけ時間の無駄かもしれません。
まずは案１をRDBMSで作るのが正解だと思いますよ。むしろ他はなしよりのなしだと思います。あなたの自由ではありますが…
レコードに分けた場合には効率的に検索・追加・削除できるアルゴリズムが採用されるので、まとめるものとは比較にならないほど高速になります。
> ※なるべくレコード数を減らしたいという観点。
高速性を犠牲にしてまでレコード数を減らすだけの意味があるのでしょうか？DBサイズの差は微々たる物だと思います。
＞＞「何が何でもレコードを減らしたい」事情はどのようなものでしょうか
＞＞高速性を犠牲にしてまでレコード数を減らすだけの意味があるのでしょうか？
レコード数が多くなるにつれて処理性能が落ちてくると聞いたので、それならなるべくレコード数を減らすようにしたいと思った次第です。
＞＞まずは案１をRDBMSで作るのが正解だと思いますよ。
＞＞まとめるものとは比較にならないほど高速になります。
回答くださった皆様のご意見をうかがう所、それがベスト...というかそれしかあり得ないのですね。理解いたしました。そもそもデータベースはそういう大量レコードになることを想定されているものだとは知りませんでした。
> レコード数が多くなるにつれて処理性能が落ちてくると聞いたので、
意味をちゃんと考えましょう。
同じプログラムで同じテーブル構造の場合、件数の多い方が遅くなるのは当然です。
違うプログラムで違うテーブル構造の場合、件数と速度の関係はなんとも言えません。違うプログラムなので。
DBMSが内部でうまくやってくれていることを、自分のプログラムで同じ事をコーディングすると遅くなるのが普通でしょう。
回答5件
6
ベストアンサー
回答
1人1000レコードｘ1000人＝100万レコードも生成されてしまうのがネックに感じています。
何となく不安になる気持ちは分からなくは無いですが、一般的なRDBMSでは（適切に設計すれば）100万レコードくらいは処理時間的にも容量的にもネックにはなり得ません。
RDBMSというものはそのようなケースを効率的に処理するためのシステムなので、これを何となくネックになりそうのレベルで回避するべきものではありません。
（Twitter等の超大型システムで使うレベルのレコード数だとRDBMSだけだと厳しいので色んな工夫がされています）
とは言っても気になるでしょうから、
まずは、100万レコードでも1000万レコードでも作ってみて、実際に試してみるのが良いかと思いますよ。
PHP＋MySQLの場合であれば以下のような形で試してみて下さい。
- user_idにINDEXを設定する
- 100万レコードのデータを作る（PHPでダミーデータをINSERTするか、エクセルなどでCSVを作って
phpMyAdmin CSV インポートあたりで検索してインポートする） - 実際に想定するSQL(例えば、ユーザーID1のフォローユーザー一覧から100IDを取得するSQL をphpMyAdminから実行してみて実行時間を確認する
SQL
1 SELCT `follow_user_id` FROM `テーブル名` WHERE `user_id` = 1 LIMIT 100;
環境にもよりますが、数ミリ～数十ミリ秒とかそういう単位の時間で処理することが出来ます。
初学者にはお勧めはしませんが別の方法
初学者には全くお勧めできませんが、
JSON型 https://dev.mysql.com/doc/refman/8.0/ja/json.html
のフィールドにJSONでデータを投入することで総レコード数がユーザー分になります。
ただ、この場合はフォローユーザー一覧は何も考えなくても高速に取得出来ますが、
その逆のフォロワー一覧を取得するのはかなり苦手になります。
それを解消しようとした場合はフォローとフォロワーを別フィールドにしてそれぞれJSON型にするなど、設計も管理も難易度が高くなります。
まずは基礎の正規化を学習して、JSON型のメリットデメリットを理解出来るようになってからの使用を強くお勧めします。
更に他の方法
RDBMS以外のデータベースを使用するのも一つの手ですが、これも初学者が学習するにはRDBMSに比べるとかなりハードルが高くなるのでお勧めできません。
単純に教材数、特に初学者向けの教材の量はRDBMSに比べると極端に少なくなります。
投稿2023/01/08 19:08
総合スコア18611
回答へのコメント
詳細にたくさんの案をお教えくださりありがとうございます。
「RDBMSというものはそのようなケースを効率的に処理するためのシステムなので、これを何となくネックになりそうのレベルで回避するべきものではありません。」とのことで腑に落ちたところがありました。
データベースはそもそもそういう大量レコードになることを想定されていることを理解しました。
ちゃんと正規化されているのであれば特に問題ないのですね、丁寧にお教えくださり誠にありがとうございました。
皆様のご意見を頂戴したうえで検討しまして、今回は皆様の言う通り、1ユーザ複数レコードという本来のデータベースの使い方で進めようと思います。ありがとうございました。
解決したようで良かったです。
> 皆様のご意見を頂戴したうえで検討しまして、今回は皆様の言う通り、1ユーザ複数レコードという本来のデータベースの使い方で進めようと思います。
はい、それが良いと思います。
その上で問題が出たら`MySQL explain 実行計画 チューニング`あたりで検索してチューニングを試みれば殆どのケースで解決すると思います。
2
100万レコード程度なら気にしなくてよいと思いますが、100億とか1兆だとまた話が違ってくるので、他の案も出しておきます。
・テーブル水平分割 (例えば user_id 奇数と偶数で分ければレコード数は 2分の1になる。末尾1桁で分ければ10分の1)。ロジックが煩雑になるので分割そのものは Redshift や BigQuery 等の製品にまかせるのもアリ。
・複数サーバで分散処理。Twitter などはタイムライン表示するだけでも数百～数千(想像ですが) のサーバにリクエストを投げ、それを集約した結果を表示しているはず
・時系列を考える。タイムライン表示であれば最初の1～2ページは正しいものを表示させるが、それ以降のページは数秒遅れてもいいかも、など
・サービスとして上限を設ける。Twitterも最大フォロワー数や1日ごとの上限を設けている (有償ユーザは上限緩和)
・ユースケースにより遅延が発生してよいところは ACID を崩す。フォロワー追加時は案1のテーブルにINSERT。Webアプリは基本的に案2のテーブルを見る。毎分、案1のテーブルを読み、案2のテーブルを更新するバッチを動かすなど。例えばAがBをフォローした際、Bがそれをリアルタイムで検知できないくても多分問題はない。一方AはBをフォローした直後からBのコメントがAのタイムラインに出てほしいかもしれない、などと場面場面で遅延が許容されるかを検討する
・インメモリDB。全部メモリ上に乗っけて高速化
あとついでに言うと、100万レコードなら大丈夫と思っていてもいざ全部作って性能試験したら全然ダメで全面的に作り直しとか、サービスがバズって1000万レコード超えちゃったとか、レコード数は100万以下だけど同時利用ユーザが想定の100倍になりDBが持たないというケースも当然ありうるので、最初の段階でいろいろ心配しておくことは大変よいことだと思います。
投稿2023/01/09 11:59
総合スコア1751
2
1人1000レコードｘ1000人＝100万レコードも生成されてしまうのがネックに感じています。
わたしはOracle Databaseで1テーブルで最大42億件のデータを扱ったDWHを使ったことがあります。100万件のデータなんて微々たるものです。一度きちんと正規化されたDBである程度使ってみては？
投稿2023/01/09 06:38
総合スコア16280
回答へのコメント
1テーブルで最大42億件のデータはすごいですね、数百万件でも多いと思ってしまった私にとっては想像もつかない量でした。ちゃんと正規化されていれば万単位のレコードなんて大したことないんですね、ご経験をお教えくださりありがとうございました。
2
1人当たりのレコード数をなるべく減らすことに重点を置いた場合、【案②】以外のやり方でいい方法はありませんでしょうか？
そちらに突き進みたいのであれば、RDBMS以外の、NoSQLを選んだほうがいいでしょう。
「1つのカラムの中にコンマ区切りで追記していく」ようなことをするのは、RDBMSのリレーショナル性を無にするに等しい行為です。
投稿2023/01/08 14:10
総合スコア142194
回答へのコメント
そもそもRDBMSは大量レコードを扱うことを想定されていることは新しい気付きになりました。お教えくださりありがとうございした。
