開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

  • 会員限定
  • 2015/02/24

NTTデータがPostgreSQLを極限まで使い切ったその先に見たものとは?(後編)

NTTデータオープンソースDAY2015

PostgreSQLを大規模なミッションクリティカルなシステムの中で使うには、どのようなノウハウが求められるのか。オープンソースの利用に積極的なNTTデータがその事例を、1月26日に開催されたイベント「NTTデータオープンソースDAY 2015」で紹介しています。講演内容をダイジェストにしました。

Publickey 新野淳一

Publickey 新野淳一

ITジャーナリスト/Publickeyブロガー。大学でUNIXを学び、株式会社アスキーに入社。データベースのテクニカルサポート、月刊アスキーNT編集部 副編集長などを経て1998年退社、フリーランスライターに。2000年、株式会社アットマーク・アイティ設立に参画、オンラインメディア部門の役員として2007年にIPOを実現、2008年に退社。再びフリーランスとして独立し、2009年にブログメディアPublickeyを開始。現在に至る。

本記事は「NTTデータがPostgreSQLを極限まで使い切ったその先に見たものとは?(前編)」の続きです。

実行計画をチェックするためにPostgreSQLを騙す。

 3つ目は実行計画のチェックです。PostgreSQLのSQL文はコストベースで実行されますので、統計情報を見て、テーブルをスキャンする方法、結合する方法などを選択するのですが、その選択が実行性能にとって重要です。そこで実行計画をチェックしました。

photo

 ただし、本番環境でしかもサービス開始後のリアルな計画を開発環境で再現してチェックしなければ意味がありません。

 本来であれば本番環境と似たサンプルデータを用意して実行計画を作らせたかったのですが、なかなかデータを用意できなかったので、統計情報を操作してPostgreSQLをだます形でそれを実現しました。

 ただし統計情報はテーブルの中身によって更新されるため、一回騙す仕組みだけでなく騙し続ける仕組みも必要でした。そこで統計情報カスタマイズ機能を作りました。

photo

 さらに、騙し続ける仕組みとして統計情報固定化機能も作りました。本来の統計情報を使わずに、つねに騙す方へ固定化できます。

 これで9割くらいはSQL文の問題が解決できるようになりました。しかしまだ最小限で最大限の効果が求められました。そこで、HINT句を使ってSQLチューニングをしました。

photo

 そして5つ目の最後の手段としてSQL文の書き換えも行いました。

 この5つの関門を設定したことで、大量のSQL文の性能を守ることができました。

photo

【次ページ】 >オープンソースの良さでトラブルを解決

データベース ジャンルのトピックス

データベース ジャンルのIT導入支援情報

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!