ここから本文です

RDBMSで1000万件以上のレコードがあった場合の速度的な問題の解決方法は?

luk********さん

2011/5/2320:00:26

RDBMSで1000万件以上のレコードがあった場合の速度的な問題の解決方法は?

RDBMSはSELECT文を使うと必ず全ての行にアクセスすると思います。
1000万件のレコードの場合どのように速度面を考慮すればいいでしょうか?
そこまで含めてデータベースソフトに丸投げでいいですか?
どのような対策が講じられているのか教えて下さい。

また、今回は1000万件としましたが、1000万件では速度的な問題がほとんど発生しないかもしれません。
どの程度のレコード数で速度的な問題が発生するかも併せて教えて下さい。

閲覧数:
39,706
回答数:
2

違反報告

ベストアンサーに選ばれた回答

chu********さん

編集あり2011/5/2422:39:31

>RDBMSで1000万件以上のレコードがあった場合の速度的な問題の解決方法は?
>RDBMSはSELECT文を使うと必ず全ての行にアクセスすると思います。

「必ずすべての行にアクセスする」とは、どういう意味でしょうか?

主要なテーブルの母体データ件数が数千万件に達するといったシステムでも、そのすべてのデータを操作対象とするような業務は、全体から見ればほんの一部です。また、特定の行だけが操作対象なのに、全件を無駄にサーチさせるといったことはおきないように、インデクスの定義、SQLの作成基準の制定&チェックなどを行います。

多くの業務では、1回の処理で操作対象になるのは、1件~数件程度です。適切なインデクス定義、インデクスを活用し、データを絞り込める検索条件などのSQLの記述を行えば、インデクスを縦に辿ることができ、母体データ件数が多量であっても、極端に性能劣化することはありません。

インデクスの段数は、「1ページで管理できるキー数」と「母体データ件数」の対数の関係になり、概算できます。
母体データ件数=1000万件、キー長=8、インデクスを管理するページ長=4kとすると、ざっくりした概算では、インデクスは、4段程度になります。つまり、「=」条件、範囲条件などで絞り込みができる場合は、行データへのI/Oを含めて5回程度のI/Oで目的のデータを得られます。
絞り込んだ検索中心の業務を行っている場合は、上位インデクスは、DBのI/Oバッファ(キャッシュ)に乗っている場合が多く、実I/Oはさらに少なくなる可能性が高いです。

多量データを管理するシステムでは、パーティショニングなどで、負荷分散を行うといったこともよく行われます。
RDBMSによっては、SQLを内部的に分割し、「パーティション毎にクエリを発行する」という子クエリを作り、並列処理させるといった機能を実装しているものもあります。

多量の参照業務は、ホットスタンバイの待機系、あるいは参照専用ノードなどで、行うといったことも行われます。

多量データの操作でもっとも問題になるのは、他の回答者さんの回答にもあるように、「多量データのランダムアクセス」です。また、「多量データのソート」も、システム全体への負荷、性能を出す上で大きな問題になります。

主に利用されるキー値の順に、なるべく近傍に行データを格納するという、クラスタ化といった機能を実装しているRDBMSがいくつかあります。この方式では、クラスタ化したキー順アクセスで、高性能を出すことが可能です。

ランダムアクセスがリアルタイム処理でなくバッチ処理であれば、ランダムアクセスするキーをソートして、キー順処理にするといった対処を行う場合もあります。

データを絞り込みしていない状態で、ソートを伴う操作を行うのは、性能的には致命的です。インデクスは、検索での絞り込みだけでなく、「作業メモリ、作業ファイルを使った実ソートの抑止」にも活用できます。

大規模&高性能を要求されるようなシステムでは、「作業メモリ、作業ファイルを使った実ソートが発生するSQLの記述を禁止」といった規制をするといったことも行われます。実際にどのように実現するかというと、DBA、アプリ開発部署、顧客などと調整を行い、「本当に必要なインデクス」、業務を実現する上で、「本当に必要な検索条件」などの操作などを分析、性能を確保するために、一部の業務での「検索条件の項目の洗い直し」などを調整します。

また、規模の大きなシステムでは、DBミドルを作成し、プログラマが性能を出すことを無視したSQLを作ってしまわないようにするといった方法を採用することも少なくありません。

全件操作するようなSQLでは、クラスタ化インデクスを除いては、インデクスを使うより、母体データだけを検索した方が性能を出せる場合もあり、RDBMSのオプティマイザも、そういった実行計画を選択する場合もあります。
多量データの順検索などで威力を発揮する、一括先読みなどの仕組みを実装しているRDBMSも少なくありません。

これ以外に、例えば1000万件の内、アクセス頻度が極めて低いデータについては、別方式で管理するといったことも行われます。

HDDなどのハードのキャッシュ、I/O性能の向上などに期待し、導入するといったことも行われます。

数千万件以上といった多量データを処理する場、メモリに関するパラメタチューニングだけでは、到底対処できないケースがあります。
そのため、これまで述べた負荷分散、インデクスの適切な定義、SQLの記述方法の規制、DBミドルの作成、アクセスされることが極めて稀なデータは別方式で管理など、そのシステムにあった対処方法を組み合わせることでシステムを構築していきます。

ベストアンサー以外の回答

1〜1件/1件中

プロフィール画像

カテゴリマスター

nor********さん

2011/5/2322:17:24

> RDBMSはSELECT文を使うと必ず全ての行にアクセスすると思います。
場合によります。INDEX検索を用いて極少数の行のアクセスですむ場合も少なくありません。

> 1000万件のレコードの場合どのように速度面を考慮すればいいでしょうか?
大量のバッチ処理などの場合はクラスタ化INDEXの利用とか、一回のI/Oサイズを大きくする、どうしてもソート処理が発生するならセッション単位にソート用のメモリ領域を一時的に大きくするなど工夫が必要でしょう。

RDBMSが不向きなのは大量のランダムデータの書き込みが発生する場合でしょう。このような場合は仕組み上DISKへの秒あたりの書き込み可能回数がボトルネックになりやすくなります。
現在、民生用3.5inch DISKだと平均シークタイムで3.5msec、回転数で15000rpmが最高ですから、秒あたりの書き込み回数は200~ぐらいのオーダーです。
DISK20本に分散しても一秒間に4,000行しか対応できないことになります。
まあ、DISK側でもエレベーターシーキングなどを行い性能の向上を図っていますが、限界もあります。
数十万件/秒のリクエストがあると限界に達するのではないかと思います(参照のみにとどまるならばかなり話が違ってきますが)。

RDBMSで対応しようとするならば、今後メモリバッファのさらなる拡大、大容量のSSDの中間キャッシュ利用、容量的に冗長であっても本数を確保し、ストライピングなどでアクセスの分散を図ることが必要だと思います。

あわせて知りたい

みんなで作る知恵袋 悩みや疑問、なんでも気軽にきいちゃおう!

Q&Aをキーワードで検索:

Yahoo! JAPANは、回答に記載された内容の信ぴょう性、正確性を保証しておりません。
お客様自身の責任と判断で、ご利用ください。
本文はここまでです このページの先頭へ

「追加する」ボタンを押してください。

閉じる

※知恵コレクションに追加された質問は選択されたID/ニックネームのMy知恵袋で確認できます。

不適切な投稿でないことを報告しました。

閉じる