本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はDatabase workload characteristics and their impact on storage architecture design – part 2 – Data pipelinesで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
データベースのワークロード特性シリーズのパート2へようこそ! データベースは仮想インフラストラクチャの中でもっともI/Oを消費するもののうちの一つだと考えられています。データベース操作とデータベース設計はそれ自身が研究ともなり得るものです。しかし、データベース設計の世界の表面から少し潜ってみるということはとても面白いことだと思いました。PernixDataの製品ディレクタであり、データベースの専門家である同僚のBara Narasimhan氏のもとへ赴き、データベース設計とそのI/Oの特徴について教えてもらいました。
質問 2: 以前Podcastでデータパイプラインについて言及していましたが、これはどういうものなのでしょうか?
あるとき、事業者はデータを解析し、よりよい決断をしたいと思うようになるでしょう。例えば、流通業の商品管理は売れている場所のデータを解析し、どの店舗でどのような商品が売れていて、なぜそうなのかを知りたいと思うはずです。これを実現するためにはデータに対してレポートと解析を実行する必要があります。しかし、以前お話したとおり、これらのレポートと解析は通常スループットが必要とされ、アドホックになってしまいます。もしこれらのレポートと解析を低レイテンシーの売り場でのトランザクションを提供している同じOLTPデータベース上で実行したとすると、OLTPデータベースのパフォーマンスに影響を及ぼします。OLTPデータベースは顧客に相対する、インタラクティブな操作を通常実行しているため、パフォーマンスへの影響はビジネスの収益にも影響をおよぼすことになってしまいます。
通常、企業が行っているのはOLTPデータベースからデータを取り出し(Extract)、データを新しい形へ変換(Transform)して別のデータベースに取り込む(Load)ことです。通常はデータウェアハウスです。これはETLとして知られている手順です。ETLを実施するために顧客はOLTPデータベースとデータウェアハウスの間にInformatica(ETL)(3)もしくはHadoop(4)などのソリューションを利用します。顧客は単にOLTPデータベースをすべて舐める(読み取り中心、大きなブロックサイズ、スループットが必要とされるクエリ)だけの時もあればデータウェアハウス自身の内でETLを実行する時もあります。データを他の形へ変換する場合にはデータの読み込みと編集、そしてデータを新しいテーブルに書き出すことが必要となります。夜にデータウェアハウスのにかかる負荷について聴いたことがある人もいるのではないでしょうか? この負荷がその処理の正体です!
以前にお伝えしたとおり、OLTPデータベースはスキーマの正規化が行われていますが、データウェアハウスは正規化されていない状態のスキーマでStarスキーマなどが利用されています。結果として夜間に単純に直接OLTPデータベースからデータウェアハウスへデータを読み込むことはできません。代わりにOLTPデータベースからデータを取り出し、変換して、正規化されたスキーマからStartスキーマへ変更し、データウェアハウスに読み込ませる必要があるのです。これがデータパイプラインです。これを説明した画像が以下です:
付け加えると、データウェアハウスに継続して流れこんでくる、直近の最新のデータなどの小さなデータ読み込みもあります。最新のデータをデータウェアハウス内で利用することで利用しているレポートや実行している解析が時代遅れでなく、最新のものであると確認でき、ひいては最も正確な決断を下せるようになります。
上で述べたようにETLの手順とデータウェアハウスはスループットが必要とされます。サーバサイドフラッシュやメモリはここで大きな役割を担います。というのもETL手順やデータウェアハウスはこれらのサーバサイドのリソースのスループット性能を活用できるようになるからです。
PernixData FVPを利用
FVPをデータパイプラインで利用することの特徴と主な利点は:
- OLTPデータベースはサーバサイドフラッシュやメモリの特徴である低レイテンシーを活用できるようになる。これは1秒毎に実行できるトランザクションの数を増やし、高いレベルでの同時並行性を実現しながら、一方でFVPのWrite-Backレプリケーション機能によってデータの喪失からの保護も提供します。
- Write-Backモードによってデータウェアハウスへの小規模なデータの読み込みは驚くほどに高速化します。というのも、新しい行はサーバサイドのフラッシュやメモリに届けばすぐにテーブルに追加されます。
- レポートや解析は結合や連結、ソートなどを実行します。これらの操作は膨大な料のデータへの迅速なアクセスを必要とし、巨大な一時的な結果を生成します。高いReadとWriteのスループットが求められますが、これをデータベースが隣で動作しているサーバの中で処理できることはパフォーマンスに著しく貢献できます。繰り返しになりますが、Write-Backの大勝利です。
- 解析はアドホックであり、データベース管理者のチューニングを頼りにすることもできません。ベーステーブルをFVP経由でフラッシュ上に持つことでアドホックなクエリに対しても著しくパフォーマンスに貢献します。
- 解析のワークロードは一時テーブルをデータベース内に作り、活用する傾向にあります。サーバーサイドリソースの利用はこの一時的なテーブルへの読み取りとそこへの書き込みアクセスのパフォーマンスを改善します。
- 上記に加え、運用面でも大きなメリットが有ります。データパイプラインのすべてを仮想化できるようになるのです。(OLTPデータベース、ETL、データウェアハウス、データマート、等)というのも、高いパフォーマンス、一貫したパフォーマンスをサーバサイドリソースとFVPから提供できるからです。これら両方を提供できることはどちらのワークロードにとって最高のことです。vSphere HA, DRS、vMotionなどの仮想化プラットフォームの運用上のメリットを活用しながら、同時に全データパイプラインをパフォーマンスに一切苦しむことなく標準化ができるのです。
本シリーズのパート3をお待ちください。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
