« 2015年4月 | メイン | 2015年6月 »

2015年5月

2015/05/25

DB ディープダイブ part 6 : クエリプラン、中間結果、一時DBとストレージパフォーマンス

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はDB Deepdive part 6: Query Plans, Intermediate Results, tempdb and Storage Performanceで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

データベースのワークロード特性シリーズのパート6へようこそ。データベースは仮想化データセンタ内では最も多くのI/Oを消費するものの一つであると考えられています。データベースの操作とデータベースの設計はそれ自身が研究に値するものですが、データベースの設計の世界を少しかいま見てみるだけでも非常に面白いものだと考えています。データベースのエキスパートで、同僚でもある PernixData社の製品担当VPの Bala Narasimhan 氏のもとへ赴き、データベースの設計とそのI/Oの特徴について教えてもらいました。

このシリーズの過去の回 :

Part 1 - データベースの構造

Part 2 - データパイプライン

Part 3 - データベースチューニングのための補助機構

Part 4 - NoSQLプラットフォーム

Part 5 - クエリ実行プラン

以前の記事の中で、データベースのクエリオプティマイザを取り上げ、それがどのように動作しているかを紹介したしました。その際には TPC-H のようなクエリとSQLサーバのデータベースを用いて、クエリオプティマイザを利用する場合のクエリのストレージの要件について解説を行っています。

今日の記事ではストレージのパフォーマンスに影響のあるクエリ実行について切り込んでいきます。そのひとつは中間結果処理です。今日の内容ではPostgreSQLデータベース内のクエリオプティマイザを使用します。その理由はこれらの問題が特定のデータベース固有のものではないということをお見せしたいからです。言い換えると、ご紹介するものはデータベースが動作しているすべての環境で発生しているストレージのパフォーマンスの問題だということです。この話題を通して、これらのストレージパフォーマンスの問題はインフラストラクチャレベルで解決するのがもっとも良く、プロプライエタリのインフラにおける裏ワザやデータベース内部を書き直すべきではないということをお伝えしたいと考えています。

PostgreSQLのオプティマイザのツアーのあとは、もう一度SQLサーバへと戻り、SQLサーバでの処理の中間結果における恒常的な問題について取り上げます。これは一時DBと呼ばれます。ここではこれまでにどのような一時DBのパフォーマンスの問題を解消しようとする試みがあったかと、更に良い方法をご紹介します。

続きを読む »

2015/05/18

データベースワークロードの特徴とそのストレージアーキテクチャへの影響 part 5 - クエリ実行プラン

本ブログエントリーはPernixData社のシステムズエンジニアであるTodd Mace氏のブログ記事で、同社のテクノロジーエバンジェリストであるFrank Denneman氏がこの記事を自身のブログに転載したものを翻訳しています。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はDatabase workload characteristics and their impact on storage architecture design – part 5 - Query Execution Plansで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

データベースワークロードの特徴シリーズのパート5へようこそ。データベースは仮想化データセンタ内では最も多くのI/Oを消費するものの一つであると考えられています。データベースの操作とデータベースの設計はそれ自身が研究に値するものですが、データベースの設計の世界を少しかいま見てみるだけでも非常に面白いものだと考えています。データベースのエキスパートで、同僚でもある PernixData社の製品担当VPの Bala Narasimhan 氏のもとへ赴き、データベースの設計とそのI/Oの特徴について教えてもらいました。

このシリーズの過去の回 :

Part 1 - データベースの構造

Part 2 - データパイプライン

Part 3 - データベースチューニングのための補助機構

Part 4 - NoSQLプラットフォーム

データベースは企業にとってクリティカルなアプリケーションで、大抵はストレージの性能要件として高いものを要求します。このブログ記事ではデータベースツールを利用して、クエリレベルでデータベースがどのようにストレージパフォーマンスを要求するのか解説していきます。そして、PernixData FVPがデータベースのストレージパフォーマンス問題だけでなく、ストレージのパフォーマンスがボトルネックになってきた場合に発生するデータベースの管理性の問題までもをどのようにして解決するのかをご説明いたします。全編を通してデータベースのサンプルとしてSQLサーバを利用しますが、内容は幅広く応用可能です。

続きを読む »

2015/05/11

PernixData FVPの I/O プロファイリングの PowerCLI コマンド

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はPernixData FVP I/O Profiling PowerCLI commandsで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

キャッシュ汚染を解消する」という記事の中で、管理者が一時的に仮想マシンのRead、Writeのいずれか、もしくは双方をキャッシュしないようにするPowerCLIコマンドがあるということをお伝えしました。

Read操作が発生した際、FVPはデータがホストから提供されるのか、それともストレージから提供されるのかを判断します。もしもキャッシュミスが生じたら(2)、データはストレージからの取得となります(3)。データのパフォーマンスを改善するためには、データはローカルの高速化リソースにコピーされてからアプリケーションに渡される必要があります(4)。これはフォールスライト(false write)と呼ばれる手順です。

Fig222

これらのコマンドを利用することで、FVPは頻繁にアクセスされるデータを高速化リソース上に残したまま、ストレージに対して直接Writeを発行することができます。FVPはキャッシュミスによってストレージから取得されるバックアップジョブやアンチウィルススキャンのためのデータをキャッシュ上のホットデータを上書きすることなく無視することができるのです。

Fig223

仮想マシン上のFVPの高速化を一時的に止めるためには、WindowsのPowerShellセッションを開き、FVP管理サーバへ接続します。Windows PowerShellプロンプトから以下のFVPコマンドレットを実行します :

Suspend-PrnxReadDataPopulation: このコマンドレットは特定の仮想マシンに対して、FVPがフォールスライトを行わないようにする際に利用します。

Suspend-PrnxWriteDataPopulation:このコマンドレットは特定の仮想マシンに対して、FVPがトゥルーライト(True Write)を行わないようにする際に利用します。トゥルーライトは仮想マシンがWrite-Backモードになっている際に発生します。

Suspend-PrnxReadWriteDataPopulation:このコマンドレットは特定の仮想マシンに対して、FVPがフォールスライトおよびトゥルーライトを行わないようにする際に利用します。

例えばSQL01という名前の仮想マシンのフォールスライトを停止するには以下のコマンドを利用します : 

Suspend-PrnxReadDataPopulation –Name "SQL01"

一つのコマンドで複数の仮想マシンに対しての停止も行えます :

"SQL01","SQL02","SQL03" | ForEach-Object {SuspendPrnxReadDataPopulation –Name $_}

$_ という変数にSuspend-PrnxReadDataPopulationに対して、データをパイプさせて利用されています。最初にこのコマンドが呼び出された時にはコマンドレットは SQL01という名前に対して実行され、二回目にはコマンドレットはSQL02に対して実行されます。以降同じです。

バックアップジョブが終了すれば、それに対応する再開のコマンドレットを呼び出します。

  • Resume-PrnxReadDataPopulation
  • Resume-PrnxWriteDataPopulation
  • Resume-PrnxReadWriteDataPopulation

例えば :

Resume-PrnxReadDataPopulation –Name "SQL01"

仮想マシンのフォールスライトやトゥルーライトが停止されていても、FVPはすべての操作を継続して実行可能です。例えば、Suspend- PrnxReadDataPopulationが有効になっていても、データがキャッシュされていれば、すべてのReadのI/Oは高速化リソースから提供されます。

ほとんどすべてのバックアップソリューションはPre-およびPost-コマンドを設定することができるようになっています。これらのコマンドを利用して、アプリケーションから頻繁にアクセスされるデータを残しながら、フラッシュデバイス上にバックアップによって発生する不必要な消耗や劣化を発生させないことができるようになっています。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)

2015/05/04

パート5 - キャッシュの汚染の解消

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はPart 5 - Solving Cache pollutionで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

従来型共有ストレージでの仮想化データセンターの拡張性についての問題」シリーズではなぜ、相互接続された(ストレージの)各コンポーネントがうまく強調せず、一環したパフォーマンスを提供することが難しいのかの詳細をお話しています。根本的な問題としてはグローバルなコントロールプレーンが存在しないということがあげられます。消費者(仮想マシン)とその分散の具合、そして優先順位に基づいたリソースの配分を決定づけるための共通言語が存在しないということです。

すべてのものを織り込めるユニバーサルな言語の登場を待つ代わりに、業界はソフトウェアのコントロールプレーンのトレンドに湧いています。インテリジェンスをアーキテクチャの境界部分へと動かし、そしてリソースはコモディティ化されていきます。ストレージリロースを直接コンピューティングレイヤーに入れることは素晴らしいコントロール性を実現するだけでなく、リソースの消費と分散についての優れた洞察を行えるようにもします。このモデルが業界をキャッシュの汚染問題などの解決が難しい問題を解決に導いてくれます。

続きを読む »