none
処理速度改善 RRS feed

  • 全般的な情報交換

  • ご教授お願い致します。
     
      現在システムコンサルティングを行っている者ですが
      ユーザー様から既存のシステムで、過去データの取り扱いに
      困っているとのことです。
      例えば、過去の売上データ等を参照したい時に1分近く
      かかるので、しかし過去の参照が多いのでそのデータを保管
      していなくてはならい。それによりデータ量が多くなるため
      スペック的に遅くなる。
      それの改善を教えてくれとのことで、先日MicrosoftSQLserverの
      書籍を読んでいたら、過去のデータを分割して処理速度を
      改善出来る機能があると書いてありました。
      その本の例えでは、過去10年の売上データを1年単位に分割
      するようなことが書かれていました。
     
      よって、この辺の詳細な説明をお答え頂ければ幸いと存じます。
      詳細には、その操作方法も同時にお答え頂ければ幸いです。

      尚、ユーザー様が現在使用しているデータベースはMicroSoftSQLserverでは
      ありません。

      以上

    • 種類を変更済み 山本春海 2010年9月2日 5:10 適切なカテゴリではないため
    2010年9月2日 0:15

すべての返信

  • 詳細が知りたいのに SQL Server ではないと!?

    ぴったりしたレスがあるまでは↓のようなサイトに目を通されてはいかがでしょうか。

    SQL Server TechCenter
    http://technet.microsoft.com/ja-jp/sqlserver/default.aspx
    2010年9月2日 0:33
  • zeak01様

    はじめまして。
    早速ですが、内容を確認すると、「パーティション分割」の事をおっしゃっているのではないでしょうか?

    以下参考まで。
    http://itpro.nikkeibp.co.jp/article/COLUMN/20051201/225546/
    http://msdn.microsoft.com/ja-jp/library/cc411400.aspx

    参考になれば幸いです。


    MCITP(Database Developer/Database Administrator) MCPD(Web Developer/Windows Developer) MCTS(Distributed Applications)
    2010年9月2日 1:13
  • 以下のURLが参考になるかもしれません。 パーティションテーブル/インデックスを、例えば 日付で1カ月間隔で分割した場合、パーティション単位(1カ月間隔)にて検索することが可能となります。 Index Seek ではそれほどの効果はないと思いますが、Index Scan が行われているクエリでは効果があります。

    ただ、まずは、処理の遅いクエリを特定し、クエリの実行プランを確認した上で、インデックスを追加することでパフォーマンスが改善できないかを判断されたほうが良いと思います。

    パーティション テーブルとパーティション インデックスに対するクエリ処理の機能強化
    http://msdn.microsoft.com/ja-jp/library/ms345599.aspx

    2010年9月2日 1:32
  • 最も重要なのはここかと「尚、ユーザー様が現在使用しているデータベースはMicroSoftSQLserverではありません。」
    2010年9月2日 1:33
  • 佐祐理さんも仰っているように、RDBMS によってパフォーマンス改善方法が異なるため、RDBMS が何かはっきりしない状況では確実な回答を得難いように思えます。

    またこのフォーラムは SQLServer 専用のフォーラムですので

    > よって、この辺の詳細な説明をお答え頂ければ幸いと存じます。
    > 詳細には、その操作方法も同時にお答え頂ければ幸いです。

    と回答を求められても、このフォーラムですべき質問ではないように思えます。
    ユーザーが使用しているデータベースの掲示板等で質問された方がよさそうです。

    ただし RDBMS 全体で共通する考え方も存在しますので、参考になることがあるかも知れません。
    SQLServer ではないということなので、参考に以下の記事を挙げておきます。

    http://nippondanji.blogspot.com/2009/02/mysql10.html
    http://nippondanji.blogspot.com/2009/03/mysql7.html
    http://nippondanji.blogspot.com/2009/03/mysqlexplain.html

     


    ひらぽん http://d.hatena.ne.jp/hilapon/
    2010年9月2日 3:10
  • こんにちは、zeak01 さん。

    MSDN フォーラムのご利用ありがとうございます。フォーラム オペレーターの 山本です。

    ご存知かと思いますが、こちらは SQL Server に関連した問題のためのカテゴリとなります。

    すでにみなさんからレスポンスいただいているとおり、投稿いただいた内容を拝見した限りでは、適切なカテゴリをご案内することや、期待されているような回答を得ることが難しいようにお見受けいたします。

    誠に勝手ながらスレッドの種類を "全般的な情報交換" に変更させていただきました。ご理解のほどよろしくお願いいたします。

    SQL Server への移行を検討されているなどございましたら、是非こちらのフォーラムをご活用ください。
    よろしくお願いいたします。それでは。
    _________________________________________
    マイクロソフト株式会社 フォーラム オペレーター 山本 春海


     

    2010年9月2日 5:15
  •    言葉足らずで申し訳ございません。

     今後はデータベースをMicroSoftSQLserverに変更することになっています。

     よって、当データベースでの運用におきましてのご意見を

     頂けたらと思います。

     

     以上

    2010年9月2日 6:00
  • DBMS の変更ということだと
    パフォーマンス向上についてはもちろん
    新旧MS について広範囲な知識が必要だとおもいます。
    もちろん DB についてもです。

    ここで聞いた付け焼刃な知識だけでコンサルするわけではないですよね?
    詳細は、こういったフォーラムで説明する量ではないと思います。
    基礎を身につけてから、解らないことを質問されたほうが有意義だと思います。

    2010年9月2日 6:32
  • こんにちは。

    A-DBMS => B-DBMS にすると速くなる : ×

    データ量が少ない(速い) <==>データ量が多い(遅い) : ×

    RDBMS(遅い) <==> KEyValue 型(速い) : ×

    また、パーティショニングをしたから速いという事でもありません。

    現在の「1分は遅い」という理由・原因・到達目標をはっきりさせて、それらをSQL Server で如何にすれば解決できるか、というアプローチである必要があるのでは?

    極端な話、データベースの構造・構成が同じで、発行するクエリも同じであれば、改善できない可能性もあるわけです。しかし、パーティショニングし、かつ各パティションの物理ボリュームが別になる。ということであれば、外部的アプローチで速くなる可能性は高くなってきます。

    モデルと条件を明示するともっと具体的な意見が付くと思います。


    K.Oumi
    2010年9月2日 7:41
  • > 当データベースでの運用におきましてのご意見を頂けたらと思います。

    皆様が言われているとおり、パフォーマンスの改善は簡単な話ではありません。

    先の私の回答の中では MySQL の記事を取り上げましたが、MySQL だけでもざっと 17 以上の項目に渡りパフォーマンス改善の話があります。それは SQLServer でも変わりません。
    パフォーマンスを向上しようと思ったら、テーブル設計・インデックス・クエリ・ストアド・トランザクションから更にハードやネットワークまで考慮すべきことは多岐に渡ります。

    以前 SQLServer を使った案件で、パフォーマンスが大問題になった案件がありました。その時のチームの対処ですが、

    1.各テーブルのスキーマとインデックスを見直し。
    2.実行プランを確認しながらクエリを全面的に書き直す。
    3.プログラム内の埋め込みクエリを極力ストアドに変更した。
    4.ストアド内で一時テーブルが使えるところは使い回すようにした。
    5.毎日数万件規模で頻繁に更新が発生するため、毎晩深夜バッチを回してインデックスを貼り直すようにした。
    6.顧客から運用上ダーティーリード可との確認が取れたため、参照系クエリにおいては、トランザクションの分離レベルを Read Uncommitted に変更。
    7.その他諸々・・・ただしパーティーションは分割してない。

    これで更新30分→ 3秒、検索2分→ 1秒と、劇的に性能が向上したことがありました。ちなみにこの修正に8人月(4人×2ヶ月)かかりました。

    #そもそも DB の設計がおかしかったのですがね・・・(-ω-;


    ひらぽん http://d.hatena.ne.jp/hilapon/
    2010年9月2日 8:28