Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

データベースアプリケーションのパフォーマンスにおける7つの大罪

原文: Seven deadly sins of database application performance

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2011/07/11 14:00

 多くのデータベースアプリケーションでは、どこかの時点で必ずパフォーマンスが検討課題になります。(原文:Seven deadly sins of database application performance、2011/02/11投稿)

 本稿はデータベースソフトウェア「SQL Anywhere」およびデータベース全般に関する英語ドキュメントを翻訳する形で提供しています。図など、部分的に英語のままになっていますが、製品のSQL Anywhere自体は完全に日本語化されていますのでご安心ください。

 パフォーマンス分析は一筋縄ではいかないことが多いのですが、それは可変要素が非常に多く、ハードウェアの特性、ワークロード、物理的データベース設計、およびアプリケーション設計など、あらゆる要素を検討する必要があり、またこれらの要素の間にトレードオフや副作用が存在するからです。これが正解、と言えるものが見つからないのが普通です。

 少し前、SQL AnywhereのコンサルタントであるBreck Carterが、「How to Make SQL Anywhere Slow(SQL Anywhereを遅くする方法)」という記事を書きました。これは今までに読んだ記事のなかでも最大のお気に入りの1つです。Breckはこの記事の中で、パフォーマンスの低下につながる38の異なるデータベース設計、アプリケーション設計、およびサーバ構成設定を列挙しています。この記事を受けて、今後しばらくは「データベースアプリケーションのパフォーマンスにおける7つの大罪」という少々生意気なタイトルの下に、特に説明する値打ちがあると思われる7つの具体的な問題について詳しく書いていこうと思います。

 「データベースアプリケーションのパフォーマンスにおける7つの大罪」とは次のとおりです。

  1. お粗末な物理データベース設計(スキーマ設計問題、テーブルの列の順序、インデクシング、データページサイズ)
  2. ロックの競合(ホットロー問題または上位のANSI分離レベルでの実行による)
  3. 反復的なネスト構造の実行(ネストされたクエリ、ユーザー定義関数、クライアントサイド結合など多数)
  4. 単一クエリでの処理量が必要以上に多い(アクセス/取得するデータ量が膨大、またはクエリが複雑すぎて最適化が難しいなど)
  5. 効率の悪いクライアント/サーバインタラクション(フェッチ設定、ワイド挿入またはワイドフェッチ、プリペアードステートメントの使用、同一サーバからの同じ情報の再フェッチなどが要因として考えられる)
  6. SELECT文の最適化目標の選択ミス
  7. トランザクションモデルの選択ミス(特に自動COMMITの使用)

 次回の記事では、アプリケーションのパフォーマンスにマイナス影響を与える物理データベース設計のトピックを取り上げます。



  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • Glenn Paulley(Glenn Paulley)

    カナダ オンタリオ州 ウォータールー R&DセンターにてSQL Anywhere 開発における Director of Engineering としてクエリ・オプティマイザなどの開発をリードしている。 ・IvanAnywhere

バックナンバー

連載:Glenn Paulley氏 データベース関連ブログ 翻訳記事

もっと読む

All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5