第2回　あのシステムもビッグデータ分析や機械学習に活用中！超高速データベース「Vertica」とは？［前編②］

前回紹介した列指向/分散型データベースの課題を、Verticaはどのように解決しているのでしょうか。今回はVerticaの強みについて、具体的に見ていきましょう。

Verticaの強み①─⁠─真のMPPアーキテクチャ

Verticaがほかの分散型データベース製品と大きく異なるのは、「⁠マスタノード」（⁠リーダーノード）が存在しない点です。Hadoopも含め多くの同型の他製品は、処理を受け付けるメインの独立したノードが存在します。同時処理するアクセス数が多くなると、配下で処理をするノードのリソースに余裕があっても、このマスタノードがボトルネックになってしまうケースがあります（図1⁠）⁠。

それに対して、Verticaではマスタノードのおもな役割であるSQLリクエストの受け付けをどのノードでも担うことができます。図2の例では、SQLを受け付けたノード2がリーダーノードとして機能し、ノード1、ノード3へ処理を指示しています。Verticaでは、このリーダーの役割を行うノードをイニシエータと呼び、その他のノードをエグゼキュータと呼びます。イニシエータは固定する必要がなく、どのノードでもイニシエータになります。

これによって、マスタノードが一般的に抱える問題であるアクセス集中のボトルネックを解消できることから、Verticaのアーキテクチャは真のMPPであると言えるでしょう。Verticaは相対的に「同時処理に強い」と評価されますが、その理由の一つがこの点にあります。

なお、可用性の観点でも、マスタノードが単一障害点（SPOF）にならないという点は重要なポイントです。

ネイティブロードバランサ

Verticaでは、特定ノードへのアクセス集中を抑えるためのロードバランス機能が提供されています。高価なロードバランサを用意しなくても、クライアントドライバとして用意されているJDBC、ODBC、ADO.NETでロードバランスの設定を行えば容易にアクセス分散を実現できます（図3⁠）⁠。

ただし、現状で設定できるバランシングモードはラウンドロビンもしくはランダムな分散だけです。簡易的ではありますが、実用に耐える最低限の機能は持ち合わせているため、多くのユーザーはこの機能を活用しています。

なお、接続先のノードに障害が発生した場合に備え、接続時フェイルオーバーの機能も実装されています。ここでは同時処理の強みの話から少しそれるため詳細は省きますが、下記の「Vertica技術サイト」で詳しく紹介しています。

http://vertica-tech.ashisuto.co.jp/WDP_web_failover

Verticaの強み②─⁠─ワークロード管理機能

Verticaには、クエリの同時処理を上手にさばくアーキテクチャに加え、優れたワークロード管理機能が備わっています。

ワークロード管理の機能によって、コンピュータリソースのワークバランスを設定できます。従来のデータベースではポピュラーな機能と言えますが、列指向型データベースではまだ実装できていないものも多くあります。その点、Verticaにはリソースマネージャと呼ばれる機能があり、ワークバランスを非常にきめ細かく柔軟に設定できます。

たとえば、定型レポート（ショートクエリ：それほど時間のかからない軽めのSQL）と自由検索処理（ロングクエリ：時間のかかる重いSQL⁠）⁠、さらにニア・リアルタイムでロード処理を行う、といった処理を同一システムで行っているケースをイメージしてみてください。このようなシステムでよくある課題は、ショートクエリがロングクエリやロード処理と同時実行されたことで大幅に性能劣化してしまうというケースです。どのような処理が実行されていても、ショートクエリには影響が出ないようにしたい、というニーズはよく聞く話です。

ワークロード管理は、まさにそのようなニーズに応えます。たとえば図4では、ショートクエリを実行する「一般ユーザー」にCPUリソースをより多く割り当てるような設定を行っています。他製品ではメモリの制御しかできないものなどがありますが、Verticaのワークロード管理機能は、CPU、メモリ、同時実行可能数なども細かく設定できるところが強みです。

Verticaの強み③─⁠─プロジェクション

Verticaにはプロジェクションという独自技術があります（図5⁠）⁠。Verticaでは、通常のRDBMSと同様に、テーブルを作成してそのテーブル名や列名を指定してSQLで処理します。しかし、テーブル内のデータは、必ず1つ以上のプロジェクションに格納されます（SQLを作成する際、プロジェクションを意識する必要はありません⁠）⁠。

プロジェクションの最適化

では、プロジェクションにはどのような価値があるのでしょうか。

Verticaでは、初期データをロードしたあとのお約束として「テーブル（実体はプロジェクション）の最適化」を行います。この作業は、Database Designer（DBD）というユーティリティやManagement ConsoleというGUIツールなどVerticaの標準ツールから実行できます。テーブル最適化を実行すると、Verticaがそのテーブルの特性（列ごとのカーディナリティなど）を調査したうえで、より効率的なテーブル構成に再構成します（図6、7⁠）⁠。おもに次のような点が再構成のポイントになります。

テーブル内の列順序を変更
先頭の列から順にデータをソート
複数のノードでデータを均等に分散するためにどの列を基準にするべきかの分析と実行

このようにテーブルを最適化することで、データの並び順が整理され、データがソートされることによって非常に高いデータ圧縮が行われます。また、ソートされたことによってSQLのWHERE句で指定されたデータを効率良く探し出せるようになり、パフォーマンスが劇的に向上します。

なお、アプリケーションから頻繁に処理されるSQLをテーブル最適化の際にVerticaに読み込ませると、 SQLの特性（WHERE句でよく使用される列など）も踏まえて最適化が行われます。アプリケーションの特性まで考慮したテーブル構造にしてくれるのです。

テーブルやアプリケーションの特性をユーザー（管理者）が考え、ソートするべき列やデータ分散のための列を明示的に指定しなければいけないデータベースもありますが、VerticaではそれをVerticaに委ねることができるため、設計コストの負担がありません（ユーザー自身によって明示的に列順序などを指定することも可能です⁠）⁠。

なお、テーブル最適化作業は、ワークロードに大きな変更がない限りは、初期データロード後に一度だけ実行すれば問題ありません。また、テーブルを最適化したあとにロードしたデータも、自動的に並び替えが行われます。

特定のクエリに特化したプロジェクション

テーブル最適化によって、テーブルが汎用的に高速処理しやすい構成になります（⁠「⁠最適化されたプロジェクション」と言います⁠）⁠。しかし図7の例の場合、「⁠エリア」列、「⁠店舗」列をWHERE句に指定したSQLと比較して、「⁠日付」列のみを指定した処理は、あまりデータソートがされていないので大きな効果は得られません（処理が相対的に遅くなる可能性があります⁠）⁠。

このように、最適化プロジェクションはそのテーブルが「汎用的に」効率化されている状態であるため、個別のSQLで見ると構成を変更すればより高速化できる可能性があります。

このような個別SQLを高速化するための手段として、Verticaには「クエリスペシフィックプロジェクション」が用意されています（図8⁠）⁠。簡単に言えば、個別SQLのために、そのSQLに最適化した別のプロジェクションを作るというしくみです。クエリスペシフィックプロジェクションは、最適化プロジェクションとは別にいくつでも作成できます。SQLが発行されると、Verticaは各テーブルに作成されているプロジェクションで最も効率的なプロジェクションを自動的に使用します。SQLで指定するのはあくまでもテーブル名で、アプリケーション側に手を加える必要はありません。

多くのユーザーからは、最適化プロジェクションだけで期待する性能を出すことができた、という声をいただいています。しかし、その中でどうしてもさらに性能改善したいSQLがいくつかある場合、Verticaではクエリスペシフィックプロジェクションを作成して対処する方法が用意されています。スケールアウトによる全体の処理性能向上も1つの方法ですが、個別SQLへの対応が用意されていることは、Verticaの大きな魅力です。

なお、クエリスペシフィックプロジェクションの作成もとても簡単です。高速化したいSQLをツール（DBD）に渡して実行すれば、Verticaが自動的に作成してくれます。作成例やその効果をYouTubeにアップしていますので、ぜひご覧ください。

https://www.youtube.com/watch?v=_H2qDvPCCqo

ちなみに、クエリスペシフィックプロジェクションのほかに、クエリの集計処理を実施した状態でプロジェクションを作成しておく「ライブアグリゲートプロジェクション」も提供されています。上手に使いこなせば大幅な性能向上が実現できます。

テーブル最適化による効果

ほかのデータベースからVerticaに移行した事例では、それまで30分を要していた4億件のデータ集計処理がVerticaでは2秒に短縮でき、実に900倍の性能向上を実現しています。これはクエリスペシフィックプロジェクションを使わずにテーブルを最適化しただけで得られた効果です。

さらには、Verticaは自動的にチューニングをするため、メンテナンス作業といった運用コストを削減することにも成功しています。

プロジェクションの注意事項

プロジェクションは内部的に別オブジェクトとして物理的に作成されるため、次の事項については注意が必要です。

データロード、更新系処理の性能劣化（プロジェクションの数だけデータの書き込み処理が増えます）
データ領域に十分な空きがあるか（プロジェクションの数だけデータ領域を消費します）

分析性能とトレードオフになるこれらのポイントを理解したうえで、活用を検討してください。

さっそく試してみよう！

今回は、情報分析系データベースとしてのVerticaの強みを中心に説明してきました。すでに同ジャンルの製品をお使いの方も、特にプロジェクションについては使ってみたいと思っていただけたのではないでしょうか。

誌面の都合で書ききれないVerticaの良さはまだたくさんあります。また、利用上の注意事項も当然あります。ぜひ後述の「Vertica技術情報サイト」にアクセスし、さらに深い情報を参照してみてください。また、Verticaには、3ノード構成、1TBまでの範囲であれば機能制限なしで利用できる評価版「Vertica Community Edition」があります。このダウンロード方法から、Verticaのインストール、テストデータのロード、プロジェクションの最適化方法などを網羅した「はじめてのVertica」を、http://vertica-tech.ashisuto.co.jp/WDP_webからダウンロードできます。オンプレミス環境、AWS環境のどちらにも対応しています。ぜひ、お試しください。