👩🏾‍💻 🍬 😉 TPC-Hベンチマークを使用したHPE VerticaおよびExasol分析データベースのパフォーマンスベンチマーク 😤 🏨 🏅

この記事では、データウェアハウス（DWH）と分析の構築に使用できるデータベースの比較のトピックを続けたいと思います。前に、 Oracle In-Memory OptionおよびIn-Memory RDBMS Exasolのテスト結果について説明しました。この記事では、Verticaに焦点を当てます。説明したすべてのテストで、1つのノードで少量のソースデータ（2 GB）とデータベース構成でtpc-hベンチマークを使用しました。これらの制限により、さまざまなバリエーションと設定でベンチマークを何度も繰り返すことができました。特定のプロジェクトの分析DBMSを選択するには、読者に、ケース（データ、クエリ、機器、およびその他の機能）のテストを実施することをお勧めします。

Vertica DBMSに関する簡単な情報

Verticaは、リレーショナル分析の列指向MPPデータベースです。 Habréには、このDBMSの主な機能を説明する記事が十分にあります（記事の最後にはそれらの一部へのリンクがあります）。したがって、それらについては説明しません。

Facebook は、内部分析タスクにVerticaを使用しています。 2年前には、数百のサーバーと数十ペタバイトのデータのクラスターがありました...このプロジェクトに関連する情報は見つかりませんでした。おそらく、誰かが信頼できるリンクをコメントで共有するでしょう。
Verticaは、 Michael Stonebreaker （元はC-Storeと呼ばれていました）が率いるチームによって開発されました。 Michaelのこれまでの素晴らしい経験（Ingres、Postgres、Informix、およびその他のDBMS）を考慮して、分析タスク専用にゼロから作成されました。アプローチを比較するために、VerticaのライバルGreenplum（現在はDellが所有）を思い出すことができます。これは、変更されたPostgreSQLデータベースに基づいたMPP DBMSです。
2016年、Hewlett-Packard Enterprise（HPE）は、Micro FocusのソフトウェアビジネスをVerticaに売却しました。これがVerticaの開発にどのように影響するかはまだ明らかではありませんが、この取引が優れた製品を台無しにしないことを本当に願っています。
Exasolとの比較のコンテキストでは、Verticaはメモリ内データベースではなく、さらにVerticaにはバッファプールがないことに注意することが重要です。つまり、データベースは主にRAMのサイズを大幅に超えるデータの処理を目的としており、バッファキャッシュのサポートを拒否することで、サーバーのリソースのかなりの部分を節約できます。同時に、Verticaはファイルシステムの機能、特にキャッシングを効果的に活用します。

TPC-Hベンチマーク

以前の2つの記事を読んでいない人のために、 tpc-hベンチマークについて簡単に説明します。分析システムとデータウェアハウスのパフォーマンスを比較するように設計されています。このベンチマークは、DBMSとサーバーハードウェアの多くのメーカーで使用されています。 tpc-hページには多くの結果があります。公開するには、136ページで仕様のすべての要件を満たす必要があります。私はテストを公式に公表するつもりはなかったので、すべての規則を厳密に守っていませんでした。ランキングには単一のテストDBMS Verticaがないことに注意してください。

TPC-Hでは、指定されたスケールファクターパラメーターを使用して8つのテーブルのデータを生成できます。これにより、ギガバイト単位のデータのおおよその量が決まります。結果を公開するすべてのテストについて、2 GBに制限しました。

ベンチマークには、さまざまな複雑さの22のSQLクエリが含まれます。 qgenユーティリティによって生成されたクエリは、特定のDBMSの特定の機能に調整する必要がありますが、 Exasolのように、VerticaはANSI SQL-99標準をサポートし、これら2つのDBMSのクエリはすべてまったく同じでした。テストでは、2種類の負荷が生成されました。

8人の仮想ユーザーが1周に3回並行して22リクエストすべてを実行
2人の仮想ユーザーがサークル内で同時に12回、22のリクエストすべてを実行します

その結果、どちらの場合も、528個のSQLクエリの実行時間が推定されました。

テストサイト

次の機能を備えたラップトップ：

Intel Core i5-4210 CPU 1.70GHz-4仮想プロセッサー; DDR3 16 Gb; SSDディスク。

OS：

MS Windows 8.1 x64

VMware Workstation 12 Player

仮想OS：Ubuntu 14.04.4 x64（メモリ：8 Gb;プロセッサー：4）

DBMS：

Vertica Analytic Database v7.2.2-1（単一ノード）

Verticaの物理データモデル

Verticaで使用されるディスク容量とクエリパフォーマンスは、投影列の並べ替え順序と圧縮アルゴリズムに大きく依存します。これに基づいて、いくつかの段階でテストを実行しました。最初の段階では、この方法でスーパープロジェクションのみが作成されました。

CREATE TABLE ORDERS ( O_ORDERKEY INT NOT NULL, O_CUSTKEY INT NOT NULL, O_ORDERSTATUS CHAR(1) NOT NULL, O_TOTALPRICE NUMERIC(15,2) NOT NULL, O_ORDERDATE DATE NOT NULL, O_ORDERPRIORITY CHAR(15) NOT NULL, O_CLERK CHAR(15) NOT NULL, O_SHIPPRIORITY INT NOT NULL, O_COMMENT VARCHAR(79) NOT NULL) PARTITION BY (date_part('year', ORDERS.O_ORDERDATE));

2つの最大のテーブルORDERSとLINEITEMは、年ごとにパーティション分割されました。ベンチマークは1つのノードで実行されたため、セグメンテーション（シャーディング）はありませんでした。後続の段階では、データベースデザイナーを使用して物理構造が最適化されました。詳細は以下をご覧ください。

Verticaへのデータのアップロード

テキストファイルからデータを読み込むには、次のスクリプトを使用しました。

 COPY tpch.lineitem FROM LOCAL 'D:\lineitem.tbl' exceptions 'D:\l_error.log';

すべてのファイルのダウンロード時間は5分でした。 21秒（Exasol 3分37秒）。この方法では、データは最初に1行ずつ RAMからWOSコンテナーにロードされ（デフォルトのwosdataプールパラメーター： maxmemorysize = 25％ ）、その後ROSコンテナーで行ごとに自動的にディスクにロードされます。また、ETL Pentaho DIツール（別名ケトル）を使用して、ファイルおよびOracleからのダウンロードをテストしました。Verticaの特別なプラグインを使用しても、はるかに遅くなります。

試験結果

*前のテストでは、Exasolでのクエリの実行は、結果のキャッシュにより大幅に短縮されました（一部のパラメーター値が生成されるため、テストの一部のリクエストは変更されません）。 Verticaにはそのようなキャッシュはありません。オッズを均等にするため、Exasolでは無効にしました。

 alter session set QUERY_CACHE = 'OFF';

Verticaのテストシーケンス

ステージ1.最初の起動

最初のテスト実行は、 統計を収集せずにデータをスーパープロジェクションにロードした後に実行されました。リードタイムは2セッションで581秒、8セッションで680秒でした。繰り返し実行すると、時間は最小限に短縮されました（上記の表を参照）。

次の表は、最初のダウンロード後のExasolおよびVerticaでのデータの編成に関する情報を提供します。

Verticaのディスクおよびメモリ内の占有スペースに関する情報の要求：

 SELECT ANCHOR_TABLE_NAME, PROJECTION_NAME, USED_BYTES/1024/1024 as USED_Mb, ROS_USED_BYTES/1024/1024 as ROS_Mb, WOS_USED_BYTES/1024/1024 as WOS_Mb FROM PROJECTION_STORAGE WHERE ANCHOR_TABLE_SCHEMA='tpch' order by 1,3 desc;

この表は、予測が最適な方法で作成されなかったという事実にもかかわらず、Verticaがデータを少しだけ圧縮することを示しています。テストプロセスでは、ロードされたデータに基づいてDBデザイナーを使用し、クエリを除外して構造を最適化することも試みました。圧縮率は6です。

ステージ2.統計収集

テーブルから統計を収集した後、実行時間が予想外に約30％増加しました。統計とクエリ実行計画の分析により、ほとんどのリクエストで実行時間がわずかに減少したか、変化しなかったことが示されましたが、いくつかのリクエストでは大幅に増加しました。これらのクエリでは、 ORDERSおよびLINEITEMを含む多くのテーブルが結合され、実行時間が長くなるほどコストが低くなりました。

ステージ3. DB Designerを使用した構造の最適化

包括的な設計は、21番目のtpc-hベンチマークリクエストに基づいたクエリパフォーマンス（より大きなフットプリント）オプションで作成されました（実行前にビューが作成されるため、1はスキップされます）。結果は次の数値になります。

したがって、9つの追加のプロジェクションが作成されましたが、構造（列のシーケンスとさまざまな圧縮アルゴリズム）の最適化により、ディスク上のデータの合計量はほとんど変化しませんでした。ただし、新しい構造により、問題のあるクエリがさらに遅くなり、それに応じて全体の実行時間が遅くなりました。

ステージ4.手動最適化

他のデータモデル（主にスタースキーマ）でのVerticaでの以前の経験を考慮して、データベースからのより良い結果を期待したため、ボトルネックをより深く調べることにしました。これを行うには、次の手順を実行しました。

統計およびクエリ実行プランの分析-システムテーブルv_monitor：query_requests、query_plan_profiles、execution_engine_profiles、query_events。
ANALYZE_WORKLOAD（）関数の結果に関するデータベース推奨事項の分析。
いくつかの追加の投影の作成。
一般プールの設定を変更します。

これはすべて重要な結果をもたらしませんでした。

次に、問題のあるリクエストが書き直され、すべてのリクエストの実行時間の約30％がかかりました。

リクエスト元：

 select nation, o_year, sum(amount) as sum_profit from ( select n_name as nation, extract(year from o_orderdate) as o_year, l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity as amount from part, supplier, lineitem, partsupp, orders, nation where s_suppkey = l_suppkey and ps_suppkey = l_suppkey and ps_partkey = l_partkey and p_partkey = l_partkey and o_orderkey = l_orderkey and s_nationkey = n_nationkey and p_name like '%thistle%' ) as profit group by nation, o_year order by nation, o_year desc;

オプティマイザーヒントを使用してリクエストコードを書き直しました：

 select /*+SYNTACTIC_JOIN */ n_name as nation, extract(year from o_orderdate) as o_year, sum(l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity) as amount from lineitem join orders on o_orderkey = l_orderkey join partsupp on ps_suppkey = l_suppkey and ps_partkey = l_partkey join part on p_partkey = l_partkey and p_name like '%thistle%' join supplier on s_suppkey = l_suppkey join nation on s_nationkey = n_nationkey group by n_name, extract(year from o_orderdate) order by 1, 2 desc;

その結果、リクエストは約4倍に加速されました。

その結果、DB Designerによって作成された構造と1つのクエリ修正を使用した2セッションでの最小テスト実行時間は531秒でした（最適化なしの最初の実行は581秒続きました）。

リクエストを書き換えたり、モデルを変更したり、他の完全に「正直な」メソッドではないことで最大限に活用するという目標がなかったので、私はこれでやめました。

結論

このテストは、特定のタスク/プロジェクトに最適なツールと実装オプションを常に選択する必要があるというルールを再度確認します。私の与えられた制限のあるtpc-hベンチマークは、次の理由でVertica DBMSにとって「不便」です。

すべてのデータはRAMに配置され、VerticaはインメモリDBではありません。
正規化されたtpc-hモデルとオプティマイザーのエラー。アドホッククエリのパフォーマンスが最優先事項である場合、Verticaのプレゼンテーションストレージレイヤーには非正規化モデル（スタースキーマなど）が適しています。 Exasolデータベースは正規化されたモデルにも対応しています。これは、私の意見では、DWHレイヤーの数を減らすことができるため、大きな利点です。

Verticaは過剰な機能でオーバーロードされておらず、開発と管理が比較的簡単ですが、Exasolはこの点でさらにシンプルで、ほとんどすべてを実行します。どちらが優れているか、柔軟性かシンプルかは、特定のタスクに依存します。

VerticaとExasolのライセンス価格は同程度であり、無料の限定バージョンが利用可能です。分析DBMSを選択するプロセスでは、両方の製品を検討することをお勧めします。

Verticaに関する役立つリンク

アーキテクチャと主要機能の概要。
とりわけ、彼はロシア語での実際の経験、おそらくAlexey Konstantinov ascrusを共有しています。彼のおかげで、Habréとブログで彼の出版物をすべてお勧めします。
alexzaitsevの紹介記事と実際の経験。
Nikolai Golov azathotによる Verticaでのストレージの方法論の選択。アンカーモデリング（6 NF）は、Verticaにとって興味深い予想外の選択肢です。ニコライは、 Higload ++やHPE会議など、さまざまなイベントで彼の実務経験を頻繁に共有しています。
多くの例を含む公式のオンラインドキュメント。
Verticaには欠けているが、多くの人が探しているものに関する短い記事。

分析データベースのリーダーの1つはTeradataです。

TPC-Hベンチマークを使用したHPE VerticaおよびExasol分析データベースのパフォーマンスベンチマーク