本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はDatabase workload characteristics and their impact on storage architecture design – part 1で閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
PernixData FVPはデータベースの高速化によく利用されています。データベースは殆どの場合ブラックボックスなソリューションです。もちろん、明日保証がない程にリソースを消費するということは周知の事実ですが、ストレージ技術の観点からデータベースのリソース消費についての一般的な知見を述べることはできないでしょうか?私は製品ディレクタのBala Narasimhan氏にデータベース操作をより良く理解するためのいくつかの質問を投げかけ、FVPがどのようにビジネスで必要とされるパフォーマンスを提供するのに役立っているかを教えてもらいました。
なぜ私がBala氏に聴いたかというと、彼はデータベースのテクノロジーについて豊富な経験を持っているからです。HPでカーネルメモリ管理のソフトウェアを書いたあと、彼はOracleへと移り、SGA、PGAメモリを担当していました。10Gにおける自動メモリ管理は彼が成し得たもっとも誇るべき成果の一つです。その後、彼はオープンソースのデータベースであるPostgresを、スケールアウトでき、データウェアハウスや解析に利用できる行リレーショナル・データベースに書き換えようとするスタートアップへと移ります。最近Bala氏は仮想化データベースのパフォーマンスのボトルネックを解消する(リンク先は英語)というWebセミナーを録画しました。Bala氏のTwitterアカウントはこちらです。データベースに関連するトピックスは広範囲に渡るため、より理解しやすくするために、この記事は小さな記事のシリーズに分割しています。
質問 1: よく見られる様々なデータベースのユースケースは何ですか?
ユースケースは星の数ほどありますが、OLTP、レポーティング、OLAPそして解析が一般的なものです。レポーティング、OLAP(Online Analytical Processing)と解析はデータウェアハウスカテゴリ内に入ります。OLTP(Online Transaction Processing)データベースは通常データウェアハウスのための入力ソースとしての単一アプリケーションとして利用されます。つまり、データウェアハウスはレポーティングと解析に最適化されたOLTPデータベース上に構成されるもの、ということもできます。
データベースのためのアーキテクチャを設定しようとする際には何を解決しようとしているのか?ワークロードはどのような技術要件を抱えているのか? レイテンシが必要なのか? 検索なのか? もしくは多くのデータを可能な限り早く読み込みたいのか? アプリケーションがレイテンシ重視なのか、スループットの確保が重要なのか?など自問してみなくては行けません。したのテーブルは左から右へと平均ブロックサイズが大きくなります。補足 : ブロックサイズが大きくなると大抵の場合、レイテンシ重視のブロックサイズではなく、スループットが大きなワークロードに対応しなくてはなりません。左から右へ行くへしたがってデータベースの設計は正規化状態から非正規化状態になっていきます。
| OLTP | Reporting | OLAP | Analytics |
データベースのスキーマの設計
OLTPは正規化されたスキーマの素晴らしい事例です。データベースのスキーマはテーブル、ビュー、保存されたプロシージャなどのオブジェクトの論理的なグループを作るコンテナーオブジェクトのことです。正規化されたスキーマを利用する場合、テーブルを小さなテーブルに分割することから始めます。例えば、すべての顧客のアクティビティのログをすべて格納している銀行のデータベースを考えてみましょう。それぞれの顧客に対して複数の行がこのテーブルに含まれていることになります。ここで、もし顧客が住所を更新したとしたら、データベースの一貫性を保つためにデータベースの複数の行を更新する必要があります。これはデータベースのパフォーマンスとデータベースの同時並行性に影響を与えます。このようにすることを避け、複数のテーブルで顧客の詳細情報だけが格納された1つのテーブルが含まれた複数のテーブルを持つデータベースのスキーマを作ることもできます。こうすることで、このテーブルの行を1箇所更新するだけで顧客が住所を変更できるようになり、すべてのデータベースへの挿入動作について、同時並行性とパフォーマンスを改善し、削除や更新は1つのテーブルしか利用しないようにすることができます。小さな更新は高速なレスポンスを必要としますが、小さなブロックのため、非常にレイテンシ重視です。
OLTPデータベースは正規化される傾向になりますが、データウェアハウスは非正規化状態で、更にデーブル数が少なくなってきます。例えば1234番のアカウントをもつのは誰かということをデータベースにクエリすることを考えましょう。この場合、アカウントテーブルと顧客テーブルの2つのテーブルを結合する必要があります。この例では2つの方法での結合が有りますが、データウェアハウスではもっと多くの結合の方法があります(というのも、複数のテーブルを一度に結合することもできるからです)、この場合一般的にはスループットが重視されます。
ビジネス・プロセス
データベースを見ていく際に面白いわけかたとして、ビジネスプロセスごとに見ていく方法があります。これについてはデータベースの可用性、同時並行性、レスポンスの要件を掘り下げていきます。大抵のOLTPデータベースは処理を実施する前に置かれます。顧客に相対する処理に利用され、ドラマのように銃弾が飛び交う部分です。とても早いレスポンスが求められます。読み込み、挿入、更新を可能な限り早くしたいですし、そのために上記の理由で高度に正規化されていきます。OLTPデータベースのパフォーマンスが遅くなったり、利用できなくなると殆どの場合、売上を創りだしている処理に影響が出ます。データウェアハウスは通常は顧客と相対する操作は行いません。データウェアハウスに格納されているデータは通常複数のルートから提供されたもので、日々の業務の中へとビジネス上の知見を提供します。 ビジネスにおいての品質の向上とコストの改善について理解したい場合を例に取りましょう。大抵の場合そうですが、データウェアハウスが1つしかない場合を考えます。ビジネスの中でほとんの場合は巨大なデータウェアハウスとそこから取り出された｢データマート｣が利用されます。データベースの乱立は企業にとって実際にある問題で、それらのデータベースを管理し、それぞれに必要なストレージパフォーマンスを提供するのは非常に難しいことなのです。
さぁ、4つのデータベースのタイプそれぞれの要件を理解し、そこからのアーキテクチャ設計への影響を見て行きましょう:
OLTP
OLTPのワークロードはReadとWriteが程よく混在したものです。レイテンシが重要視され、高いレベルでの同時並行性が要求されます。同時並行性についてお話する際の良い例がATMマシンです。それぞれの顧客がATMマシンで小規模なを実行する接続を行っています、しかし、大抵の銀行は数多くの顧客が同時に利用できるようにATMマシンを多数稼働させています。顧客がお金を引き出したいと考えているなら、データベースの顧客のレコードを読み込みむという手順が必要です。顧客がお金を引き落とせるかどうかの確認と、記録(書き込み)のトランザクションが発生します。データベース管理者用語にSQLでSELECT宣言が来たら、次はUPDATE宣言が来るぞ、という物があります。適切なOLTPデータベースは低遅延で同時にかなりの数のユーザーに対応することが出きるべきです。また、それは必然的に対話的なレベルとなります。というのもレイテンシはユーザーエクスペリエンスに影響を与えるからです。ATMマシンや銀行の窓口で顧客を長時間にわたって待たせることはできません。可用性の観点から、データベースがダウンするようなこともあってはなりません、接続は切れてはいけませんし、あらゆる時間に稼働し動作し続ける必要があります(週7日24時間)。
| OLTP | レポーティング | OLAP | 解析 | |
| 可用性 | +++ | |||
| 同時並行性 | +++ | |||
| レイテンシの重要度 | +++ | |||
| スループットの必要性 | + | |||
| アドホック | + | |||
| I/O操作 | R/W混在 |
レポーティング
レポーティングのデータベースは主にReadが重視される操作を利用し、何にもましてスループットを要求します。OLTPほど同時並行性や可用性は重視されません。特徴的なワークロードは繰り返されるデータの読み取りです。レポーティングは通常、ユーザーがビジネスのパフォーマンスを理解したい際に行われます。例えば今週どれだけの顧客が口座を開き、どれだけの顧客が口座を閉じたのか、個人向け銀行口座のチームが新規顧客の獲得ノルマを達成したのか?などです。レポーティングは予測可能なリクエストと考えられます。ユーザーはどんなデータを見たいのか理解しており、指令のとおりに知りたい数字を定型化してレポートすればよいのです。これはつまり、レポートが何度も繰り返されるため、データベース管理者はデータベースとスキーマをクエリが予測可能で効率的な状態で処理できるように設計、最適化できるということを意味します。データベースはこのレポートに最適化して設計できます。大抵のレポーティングのデータベースのスキーマの設計はスタースキーマとスノーフレークスキーマを含んだものです。
この類のデータベースはバックオフィスの処理を行うものなので、可用性や同時並行性は厳しい要件ではありません。レポートが必要なタイミングだけ、データベースが利用できればよいのです。スループットの改善は非常に効果が高いです。
| OLTP | レポーティング | OLAP | 解析 | |
| 可用性 | +++ | + | ||
| 同時並行性 | +++ | + | ||
| レイテンシの重要度 | +++ | + | ||
| スループットの必要性 | + | +++ | ||
| アドホック | + | + | ||
| I/O操作 | R/W混在 | Read中心 |
OLAP
OLAPはOLTPの解析部分ということもできます。OLTPが元々のデータの基である場合、OLAPはデータを統合します。大抵の場合は複数のOLTPデータベースを元にしています。データベースの世界で、OLAPはよく複数次元のViewを提供します。つまり様々なソースからのデータを元にデータをドリルダウンして、異なる属性のデータを結合して解析いくような場合です。ワークロードは、レポートでデータを様々にスライスしたり、カットしたりするクエリに応じて自然とアドホックなものになります。ワークロードはほとんどが読み取り中心で複数のデータベースの結合を含め、非常に複雑なクエリを走らせることになります。当然スループットの必要性も高いです。OLAPのクエリの例は夏の期間中にゴールドクレジットカードの顧客が追加で契約した保険サービスの総計などになります。
| OLTP | レポーティング | OLAP | 解析 | |
| 可用性 | +++ | + | + | |
| 同時並行性 | +++ | + | + | |
| レイテンシの重要度 | +++ | + | ++ | |
| スループットの必要性 | + | +++ | +++ | |
| アドホック | + | + | ++ | |
| I/O操作 | R/W混在 | Read中心 | Read中心 |
解析
解析のワークロードは当たり前に完全にアドホックです。レポーティングは現在わかっている数字を表示するだけですが、解析ではなぜその数字がそうであるのかの知見を提供します。レポーティングは個人向け口座チームがどれだけの新規顧客口座を開設したかを表示しますが、解析では個人向け口座チームがなぜ前期にノルマを達成できなかったのかという理由を提供することを目的としています。解析は複数のデータベースにクエリを投げることもあり、また、複数のステップでクエリを投げる場合もあります。殆どの場合、解析のクエリは一時的に大きな中間結果を書き込むこともあります。この一時的な結果を利用してデータをスライスしたりカットしたりすることがあるからです。これはつまり、データは可能な限り早く保存される必要があるということと、そのデータが次のクエリのために再度読み込まれるため、データの読み取りのパフォーマンスも同様に重要であるということです。出力が次のクエリの入力となり、これが何度も行われる可能性があり、読み取りと書き込みのパフォーマンスの両方が必要とされ、そうでない場合にはクエリのスピードが著しく落ちてしまいます。
別の問題はソートの手順です、例えばソートする必要があるデータがあるにもかかわらず、データセットが大きすぎてソートの最中にすべてのデータをメモリ上に持つことができない場合、ディスクにデータが溢れてしまいます。
当たり前に解析クエリは完全にアドホックなので、最初から効率のよいスキーマを設計することが難しいです。これが解析をパフォーマンスの観点から特に難しくしているポイントです。
| OLTP | レポーティング | OLAP | 解析 | |
| 可用性 | +++ | + | + | + |
| 同時並行性 | +++ | + | + | + |
| レイテンシの重要度 | +++ | + | ++ | +++ |
| スループットの必要性 | + | +++ | +++ | +++ |
| アドホック | + | + | ++ | +++ |
| I/O操作 | R/W混在 | Read中心 | Read中心 | R/W混在 |
DBワークロードのためのストレージアーキテクチャの設計と検証
それぞれの特性を持つデータベースのストレージパフォーマンス要件をより良く理解することで、ニーズに合わせた環境を設計できるようになります。これらの要件を理解することでインフラでの検証をよりワークロードを想定したものにすることができます。
｢平均的なDBのワークロード｣をIOMeterで走らせるのではなく、どんなタイプのデータベースを利用するのかによって、ワークロードにとってのレイテンシやスループットの重要性を理解して望むことができるようになります。本シリーズの次の記事ではパフォーマンスについて、データベースのチューニングを行うべきか、ストレージアーキテクチャで解決すべきかの判断について掘り下げていきます。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
