データベース(RDBS)でMAX1000万件レコードまでのデータを入れたり、参照したりするシステムを考えています。MAX1000万件レコード、bigint型のカラムが10カラム、1日5000件ほどのINSERTを想定しています。


この程度であれば、ディスク容量の限界に気をつけていれば、さほど気にせずずっと動くものでしょうか。
サーバーはさくらのVPSの1000円くらいのプランでPostgresSQLサーバーを構築しようと思っています。

何か他に考慮しておくべき点や、他のデータベースに変えた方がいい、とか何かありましたらアドバイスをお願いします。

回答の条件
  • 1人5回まで
  • 13歳以上
  • 登録:2013/05/04 17:24:51
  • 終了:2013/05/06 16:06:41

ベストアンサー

id:a-kuma3 No.3

a-kuma3回答回数4463ベストアンサー獲得回数18412013/05/04 20:10:52

ポイント33pt

一応、システム屋さんです。
止まっちゃいけないシステムを扱うことが多いので、ちょっと気にし過ぎかもしれませんが、気になることは幾つもあります。

  • insert 以外 (update, delete, select) の呼量
  • テーブルの設計 (特に、インデックス)
  • 想定している同時接続数
  • DB をアクセスするアプリの機能
  • 使えるメモリ
  • CPU の性能

それぞれ、互いに絡んでくるので、質問で挙げられている程度の情報だと、それぞれの項目について個別にどうこう、ということが言いにくいです。

まず気になったのは呼量です。
データを入れっぱなし、ということは無いですよね。
インターネットに接続されているサーバを使うということは、検索前提だと思います。
インデックスをどう張るかで、性能は全然変わります。
やたらに張れば良いというわけではなく、意味も無く増やすと、インデックスもディスクを使いますし、更新系の操作の負荷を増やすことにつながります。
CPU の負荷が増えるということは、CPU の性能が大事になります。

多少、インデックスの張り方が悪くても、メモリをじゃぶじゃぶ使って、DB のバッファを増やしたり、アクセスするアプリのキャッシュ機能 (PHP だったら memcached のような) を使うことで、性能の改善はできます。
但し、利用できるメモリがあれば、です。

テーブルの構造が単純で、アプリもあまり凝ってなくて、単発の性能は問題が無くても、同時に何人使用する(という想定)か、というのも重要です。
Apache や MySQL の同時接続数を増やすしかありませんが、当然、メモリは必要になります。
多重度を増やして、大量の処理をさばくということになれば、CPU に要求される性能は高いものになり案素。

VPS を想定しているのであれば、物理的なホストのリソースを複数で分け合うわけですから、CPU タイムやメモリの使用量に対する制限が出てくることも想定されます。


後、ちょっと気になってるのは、

さほど気にせずずっと動くものでしょうか。

1000万レコードで、5000件/日の insert だと、単純に割り算をすると五年半くらいということになります。
「ずっと」というには、ぼくの感覚としてはちょっと短いかな、という気もしますが、通常のシステムであればハードのリプレースを行うくらいの期間なので、レンタルサーバなら借り換えてるよ、ということでしょうか。

id:redara

詳しい回答ありがとうございます。
考え方などとても参考になります。

長くてだいたい5年くらいの運用を考えていたのでMAX1000万レコードを想定しました。

2013/05/04 21:19:11

その他の回答(2件)

id:holoholobird No.1

holoholobird回答回数574ベストアンサー獲得回数1042013/05/04 18:02:36

ポイント34pt

どのように扱うかにもよりますが、重要なのはディスク容量ではなくメモリ容量だと思います。
さくらVPSの1000円プランだとおそらく2GB程度の容量しか使えないと思うので、データベースの構造にもよりますが、4GBのプランにしてはどうでしょうか。
後はSQL文を効果的に機能させるためにさまざまなソート用のカラムを作るなど、工夫をすれば十分に早いソートが可能だと思います。

私は2300万件、20カラムのデータを4GBのVPSサーバで動かしていますが、快適に使用できます。

id:redara

同規模の実績がありそうなので安心しました。

2013/05/04 21:15:42
id:dawakaki No.2

だわかき回答回数797ベストアンサー獲得回数1222013/05/04 19:09:55

ポイント33pt

トランザクションは「1日5000件ほどのINSERT」だけですか?
それであれば「さくらのVPSの1000円くらいのプラン」で十分です。

もしそのDBをネット公開するのであれば、同時接続数を制限しつつsnmpdで負荷監視を行って、徐々に接続数を増やしていくといいと思います。

id:redara

そこまでネットで公開するようなデータではないのですが、そのようなことが今後あれば参考にしたいと思います

2013/05/04 21:16:35
id:a-kuma3 No.3

a-kuma3回答回数4463ベストアンサー獲得回数18412013/05/04 20:10:52ここでベストアンサー

ポイント33pt

一応、システム屋さんです。
止まっちゃいけないシステムを扱うことが多いので、ちょっと気にし過ぎかもしれませんが、気になることは幾つもあります。

  • insert 以外 (update, delete, select) の呼量
  • テーブルの設計 (特に、インデックス)
  • 想定している同時接続数
  • DB をアクセスするアプリの機能
  • 使えるメモリ
  • CPU の性能

それぞれ、互いに絡んでくるので、質問で挙げられている程度の情報だと、それぞれの項目について個別にどうこう、ということが言いにくいです。

まず気になったのは呼量です。
データを入れっぱなし、ということは無いですよね。
インターネットに接続されているサーバを使うということは、検索前提だと思います。
インデックスをどう張るかで、性能は全然変わります。
やたらに張れば良いというわけではなく、意味も無く増やすと、インデックスもディスクを使いますし、更新系の操作の負荷を増やすことにつながります。
CPU の負荷が増えるということは、CPU の性能が大事になります。

多少、インデックスの張り方が悪くても、メモリをじゃぶじゃぶ使って、DB のバッファを増やしたり、アクセスするアプリのキャッシュ機能 (PHP だったら memcached のような) を使うことで、性能の改善はできます。
但し、利用できるメモリがあれば、です。

テーブルの構造が単純で、アプリもあまり凝ってなくて、単発の性能は問題が無くても、同時に何人使用する(という想定)か、というのも重要です。
Apache や MySQL の同時接続数を増やすしかありませんが、当然、メモリは必要になります。
多重度を増やして、大量の処理をさばくということになれば、CPU に要求される性能は高いものになり案素。

VPS を想定しているのであれば、物理的なホストのリソースを複数で分け合うわけですから、CPU タイムやメモリの使用量に対する制限が出てくることも想定されます。


後、ちょっと気になってるのは、

さほど気にせずずっと動くものでしょうか。

1000万レコードで、5000件/日の insert だと、単純に割り算をすると五年半くらいということになります。
「ずっと」というには、ぼくの感覚としてはちょっと短いかな、という気もしますが、通常のシステムであればハードのリプレースを行うくらいの期間なので、レンタルサーバなら借り換えてるよ、ということでしょうか。

id:redara

詳しい回答ありがとうございます。
考え方などとても参考になります。

長くてだいたい5年くらいの運用を考えていたのでMAX1000万レコードを想定しました。

2013/05/04 21:19:11

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません