ロシア連邦で最初に開始されたプロジェクトであるHP Verticaは、1年半の実際の運用を経験しています

はじめに

HP Verticaの説明はすでにHabréやその他の情報源にありましたが、基本的にはすべての情報は理論に還元されました。 最近まで、Verticaは米国とヨーロッパの少しで実際の産業開発（私たちはVertikaと呼んでいますが、私は女性を指名することを提案します）で使用されましたが、 LifeStreet Mediaの男性はHabréでそれについて書きました。 Verticaですでに1年半が経過しているため、データウェアハウスには数十テラバイトのデータが含まれています。 データサーバーは1分間に数千のリクエストを処理し、その多くには数百億のレコードが含まれています。 データの読み込みは1日あたり約150 GBの量でリアルタイムで進行しています...一般的に、BigDataの下で本当に最新の新しいテクノロジーに乗るというギャップを埋め、スリルを共有する価値があると思いました。

誰に役立つか

ボリューム、コンテンツ、分析の複雑さの観点から、ビッグデータの保存と分析処理のタスクに直面している開発者、アーキテクト、インテグレーターにとって役立つと思います。 さらに、Verticaはようやく、Community Editionの完全な無料の完全バージョンを手に入れました。 3つのサーバーのクラスターを展開し、最大1 TBの生データをデータウェアハウスにアップロードできます。 Verticaでのソリューションの生産性と展開の容易さを考慮すると、1 TBのデータボリュームを持つ企業のデータウェアハウスを選択する場合、この提案を検討する価値があると思います。

私たちが選んだ方法に関する1つの段落で

簡単にホリバーの理由なし：
データウェアハウスサーバーを選択する際、価格設定、大量のデータを扱う高いパフォーマンスとスケーラビリティ、多くの異なるデータソースからリアルタイムでデータをロードする能力、プロジェクトを自分で簡単に開始できること、メンテナンスの最小コストの原則に興味がありました：結果として、これらすべての指標にとって、 Verticaは、IBM NetezzaとEMC GreenPlumを破って私たちを作りました。 後者は、すべての要件を完全に満たすことはできませんでした。 これにより、プロジェクトの開発と保守に追加のコストが発生する可能性がありますが、予算はそれほど多くありません。

建築家の観点から見たベリカの外観

アーキテクトは、Verticaのデータウェアハウスで最も重要な人物です。 まず、データウェアハウスの機能の成功と生産性はそれに依存します。 アーキテクトには2つの複雑なタスクがあります。Verticaクラスターの技術スタッフィングを正しく選択することと、データベースの物理モデルを正しく設計することです。

技術アーキテクチャの影響を受けるもの

私の重要度が低下するにつれて、私は個人的な気持ちを伝えます。

1. MPPサーバーとして、Verticaはまずネットワークアーキテクチャに厳しい要件を持っています。 クラスター内に3台のサーバーがあり、ベースが3 TBの場合、サーバーとユーザー間のデータ交換は、ネットワークコストで特に顕著ではありません。 6つのサーバーと30テラバイトのデータのデータベースがある場合、ピーク負荷時にネットワークがクラ​​スター全体の操作の最も弱いポイントになる可能性があります。 また、100台のサーバーと1ペタバイト以上のデータベースがあるとしますか？ 怖い :)
2. クラスタサーバーのローカルディスクに適切にアセンブルされたアレイは、パフォーマンス、ストレージボリューム、および鉄のコストのバランスの取れたバランスを保証します。 安価な低速ディスクでRAIDをRAIDしますが、大容量ですか？ 安くて陽気なが、ゆっくり。 高速ディスクにすべてを集めましたが、ボリュームはより少ないですか？ 高価で高速ですが、データベースに十分なスペースがないため、サーバーをクラスターに接続する必要があります。 VerticaのFlexテクノロジに関するドキュメントを読み、クラスターサーバーに高速ディスクと低速ディスクを掛け、フィルターおよび返されたデータとしてのクエリへの参加によってテーブル列（投影）のストレージを分散しますか？ よくやった、仕事に最適なクラスターを得た。 ローカルの高速ディスクをサーバーに追加し、そこでVertica一時スペースを取り出すと、すべてが見栄えがよくなります。
3. 秘密は公開されています。メモリが大量にあることはなく、大量のRAMを搭載したサーバーをすぐに購入する方が、後で既存のサーバーに配信するよりも安価です。 数十億のデータレコードに対する分析クエリには大量のメモリが必要であり、誰も物理学をキャンセルしなかったことを思い出してください。 1人のアナリストの1セッションで最大20ギガバイトのメモリを簡単に消費できます。 アナリストを数え、ELTが果たす重い要求を数え、パニックに陥らず、テラバイトのメモリを購入しようと考えないでください。 Verticaは、リソース使用率の負荷をリソースプールと正常にバランスさせることができます。 推定負荷を考慮して、クラスター内のサーバー数で割った推定データストレージ量に基づいて、クラスターサーバーのRAMサイズの黄金平均を選択し、リソースプールの区切りを使用してピーク負荷から安全に保護できます。
4. Sybase IQの後のVerticaでいつも驚かされるのは、CPU負荷が低いことです。 大量のクエリの実行中にIQを実行すると、すべてのプロセッサがフルタイムで動作し、同じ条件下でVerticaを使用すると、Sybaseを背景に休暇でリラックスしているように見えます。 さらに、両方のサーバーは列指向であり、データベースに格納されるとすべてのデータが圧縮されます。 奇跡、そしてそれだけですが、Verticaが最も重要な場所ではないという事実は残っていますが、2つのコアで十分であるという事実のガイドとしてこれを受け取らないことを望みます。 奇跡はありません。他の場所ではクエリの実行がコアを占有するため、重いクエリは複数のスレッド間で実行を並列化し、多くのコアを占有します。 したがって、予想される負荷に焦点を合わせて、クラスターサーバーコアの数を選択します。

物理データベースモデルの影響を受けるもの

重要度のレベルを下げることは困難です。すべてが重要であるため、リストには番号が付けられていません。

• Sybase IQの背景に対して、Verticaは驚くほど大きなテーブルでもJOINと効果的に機能しますが、列指向のDBMSは元々、過剰な接続を取り除き、データスキームを簡素化することを目的としていました。 可能な限り、データの非正規化を使用してください。 これにより、データの保存コストは増加しませんが、クエリの実行が高速化され、クエリの作成が簡素化され、クエリから不要なテーブルが削除されます。 ここでの欠点は、テーブル内の非正規化されたデータがライセンス内の場所を占めることです。 しかし、論理的に考えると、商品の名前と価格のファクトテーブルへの出力は、レコードごとに平均30バイトかかります。つまり、ファクトの10億レコードが30 GBのライセンスになります。 神は、バイトをどれだけ節約できるかを知っています。
• 以前は、データスキーマを設計するとき、パーティションテーブルは最も重要なことではないと考えていました。これは、Verticaの古いバージョンの場合です。 しかし、Verticaの新しいバージョンを見ると、そのように考えるのをやめました。 パーティション化により、テーブルデータを論理コンテナに分割し、Verticaを使用してデータの保存とアクセスを簡単に行うことができます。 Vertica開発者の評決は厳しいものです。パーティションのキーが多くあるべきではなく、少なすぎるべきではありません。 最初のケースでは、パーティションコンテナのクラウドを修正することにより、要求を実行するときにVerticaがシャットダウンします。 2番目のケースでは、Verticaはディスク上の数百ギガバイトサイズのコンテナのマージと読み取りに多くの時間を費やします。 また、パーティションを計画するときは、Verticaがパーティションキーによってコンテナを他のテーブルに迅速かつ効率的に削除できるだけでなく、これを使用する必要があることを覚えておく価値があります。 これらすべての結論は簡単です。たとえば、都市や顧客などの論理的な標識に従ってコンテナを作成しないでください。 自問してください：都市またはクライアントに関するすべての情報を事実から削除するか、アーカイブテーブルに転送する理由がありますか？ ただし、過去の期間、日、週、または月の情報を削除または転送することは、ファクトテーブルをパーティション分割するためのキーを日付ごとに考慮する十分な理由です。 会社の将来とデータウェアハウスの長い幸せな生活を信じ、データを永久に保存する必要がないことに同意しない人のために、Verticaには素晴らしいMERGE_PARTITIONS関数があります。 指定した間隔のパーティションキーを1つのコンテナに接続し、テーブル内のパーティションキーの数を適切な制限内に保つことができます。 私は測定について期待しています、そしてそれは明らかです：パーティションは絶対に必要ではありません。
• Vertica、Hadoop、CassandraのいずれのMPPサーバーでも、クラスターサーバー間でデータを均等に分散できます。 車を愛する人なら誰でも、運転中にバランスが悪いことがすぐに視覚的に感じられることを確認します。 ここではMPPも例外ではありません。データストレージのセグメンテーションとして都市によるセグメンテーションを指定した場合、クラスターの1つのサーバーには1500万番目のモスクワがあり、もう1つのサーバーには4万番目のウリュピンスクがあります。 どのサーバーがリクエストを処理するかはすでに明らかであると思いますが、クラスターサーバーの残りの部分は単にアイドル状態になり、「モスクワ」サーバーが処理を完了するのを待ちます。 セグメンテーションが明示的に示されていない場合、Verticaはデフォルトですべてのテーブルフィールドのハッシュによって単純にセグメント化します。 これにより、クラスターサーバー間でデータが均等に分散されますが、場合によっては手動で行うことができます。 これらのグループ化フィールドのレコードが常にほぼ均一に分散されている場合、これは特定のフィールドのデータグループ化要求で頻繁に使用する場合に意味があります。 たとえば、各都市には毎日ほぼ同じ数の販売ファクトがあります。 もちろん、モスクワでは1日に数万件のレコードが記録され、ウリュピンスクでは1ダースの売り上げが記録されます。 ロシアには多くの都市があり、年に数日もあるため、販売日と都市のハッシュでファクトテーブルのセグメンテーションを決定する場合、同じモスクワのレコードはクラスターサーバー間で日ごとに均等に収まり、ウリュピンスクはそのようなテーブルのデータの分散の統計誤差になります、クラスターサーバー間でのレイアウト。 このセグメンテーションの順序で何が得られますか？ 日と都市によるグループ化を使用したクエリは、すべてのフィールドによるセグメンテーションよりも最適に機能します。 各サーバーが都市と曜日ごとにデータを集計し、最終結果をサーバーイニシエーターに転送するだけで十分で、セッションの結果が返されます。 そうしないと、各サーバーがデータを取得し、保有しているデータを部分的に集約し、さらに集約するためにイニシエーターに転送します。 そのようなゲームがろうそくに値するのはいつですか？ 私の意見は、何千もの都市に大きな販売期間があるデータの要求がある場合のみです。 つまり、この例では、明らかにこのようなセグメンテーションを行う価値はなく、salesテーブルのデータの通常の均一なセグメンテーションを行うだけで十分です。 しかし彼らが言うように、彼はただ見せるための例であり、そうではありません。 測定のセグメンテーションにより、すべてがシンプルになります。適切な数のレコードを使用した測定では、サーバー上のすべてのコピーのミラーストレージを作成し、残りはノード間でデータを分散することも簡単です。 ここで、測定値をミラーリングするとき、ファクトテーブルを測定値に接続するときのクラスター内の各サーバーのコストは、メモリ内の測定レコードのコピーを取得して接続を開始するだけであることに注意してください。 それ以外の場合は、各サーバーから測定値を取得してから接続する必要があります。 ここで、ミラーのネットワーク費用は原則に従って少なくなっています-全員から受け取った人よりも、全員から受け取った人の方が少ないです。
• マーケターとのVerticaの強みの1つは、Verticaにはインデックスがないことです。 そうです、インデックスはありませんが、データストレージ用の並べ替えおよびエンコード形式があります。 実際、テーブルまたはそのプロジェクションがさまざまなクエリを実行する準備がどれだけ効率的であるか、およびクエリ実行プランを作成するときにクエリオプティマイザーが最も好むプロジェクションはこれらに直接依存します。 正直なところ、プロジェクション内のフィールドをより良くコーディングおよびソートする方法のすべてのニュアンスの説明は、Voodooの主題に関する大きな論文を集めています。 したがって、推奨事項の単純な設計ルールに限定します。
  1. 列の値を保存する方法を選択すると、Verticaは自動的にそのデータ型に焦点を合わせます。 アルゴリズムによってBIGINTが場合によってはファクト値であると予測することは不可能ですが、ディメンション識別子によっては、テーブルを記述するときにクエリでのフィルタリングと集計に使用されるフィールドの一部のENCODING指示を無視しないことは価値があります。は事実ではなく、次元の価値です。 この列オプションの正しい説明があれば、Verticaでのデータの保存と検索が簡単になり、より効率的なクエリを作成するときにオプティマイザーを考慮する必要があります。 また、グループ化についても忘れないでください。リクエストで常に返されて一緒に処理されるフィールドがある場合、それらのストレージを1か所にまとめて、レコードの読み取りと収集のコストを削減する正当な理由があります。
  2. テーブルまたはプロジェクションに並べ替えを割り当てる場合、すべての場合において、並べ替えが増えず、プロジェクションを作成しても安全ではないことに注意してください。 したがって、テーブルでは、最も頻繁に実行されるクエリの観点からソートを選択し、残りのケースではすでに予測を行います。
  3. フィールドと並べ替え順序を選択するときは、次のルールに焦点を当てます：並べ替えの開始時に、最も頻繁に検索される列を等値クエリで配置し、一意の列を識別するのに最も適しています。次に、並べ替えの途中で、接続または検索で使用されるフィールドを配置すると便利ですリスト演算子IN。 最後に行うことは、比較演算が進むフィールドを配置することです。 並べ替えの観点から、我慢の長い販売テーブルの場合、次のフィールドの順序を配置することが最も有益です：地域、クライアント、Sales_Date。 この並べ替え順序は、日付期間の指定されたセクションに地域および/またはクライアントによるフィルターがあるすべてのクエリをカバーします。 これらのクエリがORDER BYでソートフィールドを使用する場合、Verticaはクエリの実行をさらに簡単にします。
  4. エンコードとソート、およびセグメンテーションが最適であるかどうかをまだ完全に確信することはできないため、騎士の動きをいつでも行うことができます。 つまり、明示的にセグメンテーションと並べ替えを指定せずにVerticaにプロトタイプテーブルを展開し、一定量のデータを入力し、このテーブルにより一般的なクエリを書き込み、データベースデザイナーを介してVertica adminToolsユーティリティを実行します。 デザイナーはクエリを分析し、自分の観点から最適なエンコードとデータの並べ替えを使用して、テーブルに必要な投影を作成します。 次に、このテーブルでクエリを実行し、クエリプランを確認し、提案された投影法の効果を評価し、作成された投影法で提案された並べ替え、セグメンテーション、フィールドコーディングに焦点を当ててワークシートを作成します。 必要に応じて、テーブル自体の並べ替えでカバーされず、デザイナーのVerticaによって提案されたクエリの追加のプロジェクションをすぐに作成します。

ETL / ELT開発者の観点から見たVerticaの外観

ETLロジック開発者は簡単かつ安心して生活できます。Verticaにはすべての標準データアクセスドライバー（ODBC、JDBC、.NET、Python）があります。 COPYコマンドのフラットファイルをバッチダウンロードするための印象的なネイティブプロプライエタリツールのセットもあります。 独自のパーサー、フィルター、バリデーターで拡張できます。 COPY LOCALを使用して、クラスターサーバー自体から、および稼働中のマシンからローカルにファイルをダウンロードできます。 Vertica JDBCドライバーは、JDBC Prepared Statementを介したバッチ挿入をサポートし、値の貼り付けパケットをCOPYバッチ挿入に自動的に変換します。 これにより、レコードを高速に挿入できます。 軟膏の唯一の機能は、バッチダウンロードの拡張機能がCでしか書けないことです。これは開発をすぐに複雑にします。 最新のうわさから判断すると、Verticaは自信を持ってJavaの世界（明らかにHadoopに近い）との統合に向かって動いているので、近い将来、こうしたものをJavaに記述してプラグインできる可能性が非常に高いです。 大量のデータの並列ロードの生産性と効率の問題に触れると、Verticaのアーキテクチャはそれらを完全に引き継ぎます。 ETL開発者は、リアルタイムのロードとロードバランシングのニュアンスに関する特別な知識を必要としません。

ELTロジック開発者の観点から見ると、Verticaには2つの苦情があります。ストアドプロシージャ言語はサポートされておらず、式またはC言語のプリミティブ以外の独自の関数を記述する方法はありません。 最後のVerticaチームは、Javaの関数のサポートという形ですぐに修正することを約束していますが、ストアドプロシージャについては何も約束していません。 そのため、ETLツールを使用してELTロジックを保存および実行する必要があります。 残りについては、Verticaは最も要求の厳しいスクリプト開発者さえも完全に満たします：ANSI SQL標準の完全なサポート、他のデータサーバーから馴染みのある多くの機能、データタイプとその削減の簡単な作業、中間結果を保存するためのローカルおよびグローバルセッション一時テーブルのサポート、オペレーターの存在MERGE、大規模なデータ配列に対する高速UPDATEおよびDELETEのサポート、時間間隔（TIME EVENT）、時間接続（TIME JOIN）などをサポートすることによりOLAP機能を拡張 。 このすべてにより、ステージング領域からウィンドウ表示領域へのデータの変換と入力に関する複雑なクエリを簡単に記述し、集計とKPIを計算し、ウェアハウス内のデータを計算する他の作業を実行できます。 実践からわかるように、Oracle、MSSQL、またはSybase IQ DBMSを知っている開発者は、複雑なクエリのレベルでVerticaの共通言語をすばやく見つけます。 Oracle開発者にとって、ストアドプロシージャとカーソルの言語の欠如は、おそらくデータ計算ロジックの開発アプローチのパラダイムを変更する追加の動機となります。 おそらくこれが、Vertica開発者がストアドプロシージャのサポートの問題から遠ざかっている理由の1つであると思われます。IMHOは、カーソルがパフォーマンスを損なうことを恐れているかもしれません（もちろん、冗談ですが、真実です）。

BI開発者の観点から見たVerticaの外観

BIソリューションの開発者の観点から見ると、Verticaには、たとえば、MSSQLのSybase IQのテーブル関数やストアドプロシージャなど、パラメータ化されたビューの類似物の可能性が明らかに欠けています。 BIの複雑なクエリを開発する場合、多くの場合、指定されたパラメータによるデータのフィルタリングがサブクエリ内のどこかで使用されます。 さらに、すでにサブクエリの結果を超えて、データが集計されます。 パラメータ付きの保存されたクエリなど、Verticaでクエリを作成できないため、BI開発者は、異なるユニバース、抽出、およびBIツールにある他のものの間で複雑なクエリをコピーする必要があります。 それ以外の場合、ELT開発者の場合のように、Verticaはあらゆる複雑な分析クエリの全範囲を完全にカバーします。 つまり、SQLクエリに制限はなく、OLAP関数と拡張機能、WITH、TIME SERIES、TIME JOIN、EVENT SERIESのサポート、地理データの操作、IPアドレス指定、URLなどがあります。 Verticaリポジトリメタデータ自体はBIで顕著に表示され、すべての主要なBI製品でVerticaに問題はありません。 ここで、VerticaとBIの相互作用に興味のある人は、Vertica + Tableauのような素晴らしい組み合わせに注意を払う価値があります。 これら2つの製品を組み合わせることで、強力な分析をリアルタイムで直接提供します。 Tableauは当社で高く評価されました。 BI開発者にとっての主要な問題、つまりアドホックリクエストのパフォーマンスと機能制限は、Verticaには存在しないため、BIソリューションの開発の速度と品質にプラスの影響を与えると考えています。

管理者の観点から見たVerticaの外観

Verticaの管理は、条件付きでnullと見なすことができます。 これは、Verticaが管理を必要としないという意味ではありません。 必要に応じて、Verticaの管理がときどき必要になることが理解されています。 さらに、専任の常勤常任管理者ユニットの代わりに、リモートサーバーの管理またはアーキテクト、ETLまたはBI開発者による管理が非常に可能です。 サーバー管理自体は、いくつかのカテゴリに分類できます。

• 役割とユーザーを管理します。 標準プロセスは、ロールごとの分布のユーザーデータベース内の説明と、データベースオブジェクトへのロールアクセスの説明です。 作業は頻繁ではなく、ユーザーとロールが追加されると行われます。
• クラスター負荷管理。 Verticaサーバーアーキテクチャのプレゼンテーションを必要とする、より複雑なプロセス。 Verticaサーバーリソースをリソースプール全体に最適に分散するには、さまざまなプロセスおよびユーザーグループのクラスターの現在の負荷を分析する必要があります。 リソースプールを使用すると、要求の実行を分類し、必要に応じてリソース使用の異なる説明を選択し、ホット予約メモリサイズ、消費されるメモリの最大量、競合する接続の数、リソースの受信の優先度、クエリ実行の最大許容時間、および制限を指定できますCPU使用率。 リソースプールの有能な開発とそれらの間の異なるユーザーの分散により、ピーク負荷の場合でもバランスの取れたクラスター運用が保証されます。 これにより、リアルタイムの運用レポートと長い分析クエリの下で、カテゴリのタスク間で実行を効果的に分散できます。 通常、このような作業は既に確立された負荷と、ピーク時のサーバー負荷がいつどのように発生するかを考えて、実稼働サーバーで既に行われています。 負荷条件が変わらない限り、リソースプールを変更しても意味がありません。
• クラスタサーバーを管理します。 新しいサーバーをクラスターに追加するプロセス、クラスターからサーバーを交換または削除するプロセスは、複雑ではなく、ユーティリティを介して行われますが、そのような作業中にクラスターのパフォーマンスが部分的に低下しないように、サーバーアーキテクチャと作業計画を明確に理解する必要がありますデータウェアハウスの他の費用のかかる作業と一致しました。 たとえば、現時点でこのようなタスクの1つは、テーブルからテーブルへの大量のデータのオーバーロード、または外部ソースからのロードです。 たとえば、実際には、クラスター内の3つのサーバーにさらに3つのサーバーを追加し、それらの間でデータの再調整を行うと、パフォーマンスがわずかに低下しますが、その結果、ユーザーは気付きませんでした。
• クラスターの回復。 クラスターサーバーの1つがクラッシュした場合、Vertica管理者は、サーバーが物理的に機能してネットワーク上の他のサーバーを確認した場合、このサーバーを再起動できます。 サーバーをクラスターから切断すると、クラスター内の別のサーバーが停止したサーバーの作業を強制的に引き継ぐため、データウェアハウスのパフォーマンスが部分的に低下します。 管理者には、障害の発生したサーバーの起動または交換、サーバー上のデータの自動回復のさらなる作業、および作業へのその包含を可能にするユーティリティがあり、Verticaが引き継ぎます。 サーバーのハードウェアが信頼できる場合、この作業は頻繁ではありません-私たちの実践では、Verticaはクラスターサーバーの1つを2回だけ停止しました。 RAMを操作しているときに障害が発生したという事実による最初の時間、RAIDコントローラーが失敗したときの2回目。 どちらの場合も、サーバーで技術的な作業が行われている間、クラスターは動作を停止しませんでした。 ユーザーとデータダウンローダーは、データウェアハウスを操作する通常モードで作業を続けました。
• サーバーのバージョンをアップグレードします。 これは、Verticaサーバーの1つに配布キットをダウンロードし、10分以内にVerticaサーバーを一時的に停止し、アップグレードインストールを開始し、Verticaサーバーを再起動することによって行われます。 Linuxにファイルをアップロードしてプログラムを実行できる管理者は、このジョブを処理できます。
• クエリの最適化。 特定のクエリの動作が遅すぎる場合は、テーブルが別のプロジェクションを実行するときが来ている可能性があります。 これを行うために、管理者はVertica adminToolsユーティリティからデータベースデザイナーを呼び出し、問題のあるクエリを実行できます。 出力では、デザイナーはこれらのクエリの迅速なライフのために正確に欠けているものを分析し、テーブルへの投影の形で既製のレシピを提供します。 これらのレシピに従うかどうかはあなた次第です。 Verticaの開発者は、アメリカとヨーロッパの顧客が推奨されるプロジェクションを作成することをためらわず、すべてが問題ないことを主張しています。 私はデザイナーが何をするかを個人的に再確認しています。 基本的に、苦情はありませんが、提案された予測の一部が不要であり、リクエストを高速化するための利点をもたらすよりもサーバーのディスク上のスペースをより多く使用する場合があります。 これは主に、リクエストが数秒で完了する必要がなく、ユーザーまたはプロセスからの苦情なしにリクエストが実行されるまで、セッションが数十秒待機する場合に適用されます。

リーダーシップの観点からVerticaはどのように見えますか

まず、私たちの経営陣が頭痛の種にならなかったものを、その理由の説明とともにリストします。

1. 分析のために新しいデータソースを迅速に追加する必要があります。新しいスキームとテーブルが追加され、それらにデータローダーが作成され、作業が透過的で理解しやすくなります。
2. : , , . .
3. , BI: Vertica ANSI SQL .
4. : .
5. ライセンスをアップグレードするためのリソースが必要です。新しいサーバーを購入し、それらをクラスターに接続してパフォーマンスまたはデータストレージエリアを増やす場合、これはダウンロードに許可される初期データ量のライセンスに影響しません。また、ライセンスは、クエリの実行を高速化するための追加の構造（投影）の作成には影響しません。したがって、ライセンスのアップグレードは、ソースデータの量がライセンスの購入を計画しているボリュームに達し、スペースを解放するために古いアーカイブデータを削除する方法がない場合にのみ必要です。まだこの点に到達していませんが、アーカイブされた古いデータを保存する問題はこれまで以上に重要です。データは、会社の食欲が増したため、計画よりもはるかに多くなりました。

私たちの経営陣が常に好んだこと：

1. タスクをすばやく設定し、同じくらい速く結果を取得します。
2. いつでも、あらゆる条件下で、あらゆる期間の分析レポートを迅速に受け取ります。
3. 当社で進行中のプロセスの状態をリアルタイムで確認できます。
4. Verticaに関する苦情や、Verticaが原因で何らかの理由でタスクが完了しなかったという指摘を聞いてはいけません。

私たちの経営陣がいつも好きではなかったこと：

1. 価格品質と速度については、悲しいかな、あなたは支払う必要があります。Verticaは無料ではなく、最も安価なソリューションではないため、経営陣は、お金を使う道徳的な意欲を必要とし、同時にそれから得られるものを実現する必要があります。

インテグレーターの観点から見たVerticaの外観

私個人の意見では、Verticaは、スタートアップを養うインテグレーターや、エスコートを養うインテグレーターに適しています。現在、主要なインテグレーターのほとんどは、古典的なDBMSを使用したプロジェクトのサポートのおかげで収入を得ており、クライアント間でデータウェアハウジングを開発するための迅速かつ効果的なスタートアップを展開したいと考えています。それらの主な問題は、VerticaがLinuxプラットフォームでのみ動作することです。MSに密着しているすべてのクライアントがLinuxにサーバーを展開することを望んでいるわけではなく、これらのサーバーの適切な管理設定なしでは実行できないことを認識しています。ただし、ここでは、インテグレーターは希望するサポートを得るチャンスがあります。

要約する

Verticaについての私、同僚、会社に対する一般的な気持ちは、1年半の実践的な操作で非常に良かったです。誰も失望の理由はありませんでした（彼らはテーブルをノックしました-パパ）。ほとんどの場合、このサーバーに直面して、インテグレーターは喜んでそのプロジェクトを取り上げ、一部のユーザーはVerticaに完全に焦点を当て、他の同様の製品との作業を中断しました（shh ...それは秘密です）。企業のマネージャーや建築家の多くが訪れて、私たちが持っているものを見て評価しました。データウェアハウスを選択する際に、多くの専門家がリモートで私たちに相談しました。その中には、結果としてVerticaを選択したものもあり、すでにスタートアップを開発しています。企業があったVerticaは道徳的および政治的な理由でまったく気に入らなかったため、他のデータウェアハウスサーバーを選択することにしました。いずれにせよ、Verticaの製品は有望であり、HPが失敗することはないことを誰もが認識しており、Verticaを購入し、内部吸収なしで会社の構造全体をそのままにしました。

一般的に、「ビッグ」サーバーの短いツアーは終了しました。ご清聴ありがとうございました。
敬具DWHの建築家Konstantinov Aleksey

PS