RailsでWebアプリを作っています。最大で1990年～2010年まで20年間 * 4四半期/1年 = 80 個のテーブルを作るとします。
一回の処理でそれぞれ20個、40個、80個のテーブルからデータを参照して表示する場合、
一度に参照するテーブルの数が増えるに従ってどれくらい速度が低下するものなのでしょうか。
また、一度に参照するテーブルの数は何個以内に抑えるのが望ましいのでしょうか。
データベースを扱うのは初めてで設計の目安など分からないので、どなたか教えて頂けないでしょうか。よろしくお願いします。
No.1
49
10
100pt
こんばんは。
まずテーブル設計がRailsの流儀と異なりますので、アプリを作った際に苦労すると思われます。Railsではmodel:table=1:1です。これが基本です。
今のテーブル設計だとするとテーブルを発行するＳＱＬが運用中に発生する事になります（データを追加しないなら話は別です）。で、それに対応するモデルをそのたびに作るか、当初よりモデルを通常のモデルとは異なる形で工夫するか・・・等々難易度が高くなりそうな気がします。なによりRailsの強みが消えてしまう可能性が高そうです。
※既存のテーブル設計がそうなっているとか、データ量が膨大なためSQLの実行速度が出ないため等の理由がある場合は別です。
新規で作る物であると仮定すると私なら以下のような形で設計します。
「1990年〜2010年まで20年間 * 4四半期/1年 = 80 個のテーブル」
ではなく上記の物を一つのモデル、テーブルで作る。
で、モデルのnamed_scope等を使って期間を区切る等で対応します。
データ数が膨大で速度が出ない場合はテーブル分割する、もしくはRDBを捨ててkey:value型のデータストアを使う等考えます。
単純に「一度の処理で参照するデータベースのテーブル数が増えると速度が低下するのでしょうか？」という質問内容に関して言うと、「速度低下します」という答えになります。ただそれが無視できる範囲の物なのか？トータルで見て遅いのか？負荷がかかったときに遅くなるのか？データ量により重くなる等ケース・バイ・ケースですので、そこは個別に対応していくしかないというのが正直なところです。※キャッシュを使うという手もあります。
No.1
4910
ここでベストアンサー
100pt
こんばんは。
まずテーブル設計がRailsの流儀と異なりますので、アプリを作った際に苦労すると思われます。Railsではmodel:table=1:1です。これが基本です。
今のテーブル設計だとするとテーブルを発行するＳＱＬが運用中に発生する事になります（データを追加しないなら話は別です）。で、それに対応するモデルをそのたびに作るか、当初よりモデルを通常のモデルとは異なる形で工夫するか・・・等々難易度が高くなりそうな気がします。なによりRailsの強みが消えてしまう可能性が高そうです。
※既存のテーブル設計がそうなっているとか、データ量が膨大なためSQLの実行速度が出ないため等の理由がある場合は別です。
新規で作る物であると仮定すると私なら以下のような形で設計します。
「1990年〜2010年まで20年間 * 4四半期/1年 = 80 個のテーブル」
ではなく上記の物を一つのモデル、テーブルで作る。
で、モデルのnamed_scope等を使って期間を区切る等で対応します。
データ数が膨大で速度が出ない場合はテーブル分割する、もしくはRDBを捨ててkey:value型のデータストアを使う等考えます。
単純に「一度の処理で参照するデータベースのテーブル数が増えると速度が低下するのでしょうか？」という質問内容に関して言うと、「速度低下します」という答えになります。ただそれが無視できる範囲の物なのか？トータルで見て遅いのか？負荷がかかったときに遅くなるのか？データ量により重くなる等ケース・バイ・ケースですので、そこは個別に対応していくしかないというのが正直なところです。※キャッシュを使うという手もあります。
cusposさん、いつも回答有難うございます。モデルやテーブルを大量生成するのは現実的ではないのですね。
今回作っているのは上場企業の財務諸表を登録するデータベースでして、上場企業数 4000弱 * 4四半期 * 10～30年 = 16万～48万 件ほどのレコードが
理論上1つのテーブルに収まる可能性があります。カラムの数は最高で100くらいだと思うのですが、この場合データ量は何件ほどから速度が低下するのでしょうか？
まだ実運用でどれくらい負荷がかかるか等全く分からず回答しにくいとは思うのですが、もしよければ教えて頂けないでしょうか。よろしくお願いします。
No.2
2915301
100pt
落ちる可能性が高いですが、体感できるほどかどうかはデータ量や、
どのように集計したいのかが判らないので何とも・・・。
速度は気になる所ですが、取り扱い安さから考えると、
時系列データは縦一列に並べる感じで１つにしてしまうほうが楽です。
（SQL書いてみれば判りますが一度に10テーブルでも気が滅入りますよ。）
レコード数の多さが気になっておられるのかもしれませんが、
データベースに取ってみれば10万でも100万でも問題になりません。
（ただし、インデックスを設定しておかなければなりません。
カラムの内容も、どのような集計を行う予定なのかも判らないので、
どのカラムにどのようにインデックスをつけるべきかは・・・。）
データ比較等もお考えだと思いますが、SQL１つで１つのテーブルを使い、
複数の集計を同時にこなす事も可能ですし、
1990年と2000年、2008年の同四半期のデータを横並びに出力するなども可能です。
（SQLで集計だけ行ってRuby側で整形して出力という手でももちろんＯＫ。）
kn1967さん、本日は回答有難うございます。レコード数は100万でもいけてしまうのですね。
上場企業の四半期の財務諸表の各項目のデータが収まる予定ですので、証券コードと決算年度に（決算年度に沿って時系列的に登録されるとは限らないですが）
インデックスを設定するのが良いでしょうか？インデックスについてはこれから調べないといけませんが…。
ご指摘の通り、データ比較等も行いたいと考えています。SQLもほぼ書いたことがないので、こちらも勉強が必要ですね。
No.3
4910
100pt
こんばんは。
速度はデータ量だけによりません。indexの張り方、SQLの作り方、入っているデータの形により何とも言えないというのが正直なところです。このあたりのノウハウはRailsというより、DB依存の内容です。
ただ既にデータが手元にありそうな雰囲気ですので、これをインポートして、ベンチマークを取ってみるといいと思います。
とりあえずはデータつっこんでみて、SQLのみ発行してどれくらいで返ってくるか確認（http://www.daito.ac.jp/~ikeuchi/webdb/mysql_5.htmlなんか参考になるでしょうか）、最終的にはab等で負荷テストをかけてみるのがいいかと思います。
※CRUD系の動作を想定していたので、前述のような回答になりましたが、create、editの動作は少なそうですね。・・・だとすると、SQLが速度面のボトルネックになるようだったら、テーブル分けちゃうのも悪くない手かもしれません。あとデータの性質から言うとトランザクションもいらないのかな？DBがMySQLだとするとMyIsamで作って適切にindex張ってあげれば、SQLのスピードは問題無さそうな気もします。
回答有難うございます。手元にデータはなくて、必要な時にデータベースに登録する感じです。
レコード件数が増えてきたらまた負荷対策も考えてみようと思います。
No.4
44914
22pt
＞RailsでWebアプリを作っています
＞一回の処理でそれぞれ20個、40個、80個のテーブルからデータを参照して表示する場合、
表示形式（View）に対応した中間テーブルを作って、一度そちらにデータを入れて
それを読み込むようにしたほうが無難。
Railsは実際のところ遅いですからね。
sirotugu40さん、コメント有難うございます。
中間テーブルというのは今日初めて聞きました。調べてみようと思います。
kn1967
2009/10/24 21:36:25
1
1
2
1
17
14
cuspos
tyn
cusposさん、いつも回答有難うございます。モデルやテーブルを大量生成するのは現実的ではないのですね。
今回作っているのは上場企業の財務諸表を登録するデータベースでして、上場企業数 4000弱 * 4四半期 * 10～30年 = 16万～48万 件ほどのレコードが
理論上1つのテーブルに収まる可能性があります。カラムの数は最高で100くらいだと思うのですが、この場合データ量は何件ほどから速度が低下するのでしょうか？
まだ実運用でどれくらい負荷がかかるか等全く分からず回答しにくいとは思うのですが、もしよければ教えて頂けないでしょうか。よろしくお願いします。