分析インフラストラクチャの進化（続き）

前の記事で、 Vertikaを選択した方法と理由について説明しました。 このパートでは、この珍しいデータベースの機能についてお話します。このデータベースは2年以上使用されています。 この記事を書くことは、特に一方では非常に技術的に詳細に伝える必要があるという事実のために、私が計画したよりも少し長くかかりました。 その結果、妥協の道を歩みました。詳細に触れることなく、Vertikaがどのように配置され、原則として機能するかを説明しようとします。

パート3. Vertica。 単に速い

単純に高速 -このvertikovskyのスローガンはゼロからは現れませんでした。 彼女は本当にとても速いです。 ソリューションを選択する際のテストで示された「ボックス化」設定でも高速です。 インフラストラクチャの移行の過程で、Vertikaをさらに高速化し、そこから最大限の生産性を得る方法を十分に研究しました。 しかし、まず最初に。

そもそも、Verticaには明らかなものはありません。 これは驚くかもしれませんが、Verticaでは、多くの一般的なSQLデータベースと比較して、次のものはありません。

• ストアドプロシージャと非決定的関数
• 厳密な制約-つまり、制約に違反するレコードを追加できます
• 列を削除する機能
• インデックス
• キャッシュ

インデックスの可用性がデータを保存する特別な方法によって補償される場合、残りの制限は、むしろ必要な必要性であり、パフォーマンスに対する支払いです。 あまり便利ではないこともありますが、深刻な問題ではありません。 それとは別に、キャッシュの不足について言います。 Vertikaは、分析に使用されるデータの量（これはテラバイト単位）はとにかくキャッシュに入れることができないと考えているので、そうすべきではありません。 データの要求はディスクに送られます。 記録または変更時にデータの中間ストレージに使用されるメモリの特別な領域があります。 しかし、原則として、すべてがディスク上にあります。 これは、データベースの最も遅い場所であるディスクサブシステムという強い見方と幾分矛盾しています。したがって、メモリへのデータの最大化に努めなければなりません。 それにもかかわらず。

ダウンロードのパフォーマンスについては詳しく説明しません。実際、ディスクの書き込み速度によって制限され、ボリュームを減らすためにデータがエンコードされるという事実に合わせて調整されます。 ユーザーの観点から見ると、SQLクエリのパフォーマンスははるかに興味深いものです。 Verticaは特殊な分析データベースであるため、単純なキークエリに対して高いパフォーマンスを期待する必要はありません。 分析に典型的なフィルターを使用した集約クエリで完全に開示されます。

物理データストレージを整理するいくつかの方法により、分析クエリの高性能が提供されます。

• 列指向のデータストレージ
• 特定の種類のクエリに最適化された列ストレージ
• さまざまなタスクに合わせて最適化された多くの物理テーブルビューを持つ機能
• クラスター線形スケーリング、MPP-大規模な並列処理、つまり、1つの要求をすべてのクラスターノードとすべてのプロセッサコアに同時に並列化できます。

これらの方法と、それらがパフォーマンスにどのように影響するかについて詳しく見ていきましょう。

列指向ストレージ

通常、分析問題で使用されるテーブルには、いくつかのイベント（事実）を特徴付ける数十および数百の列があります。 たとえば、販売統計、通話またはインターネット接続の統計、インプレッションとクリックの統計、市場資産の価格のダイナミクスなど。 通常、イベントの特性はディメンションと呼ばれ、集合的に多次元データキューブと呼ばれます。 ただし、人がすべての特性を一緒に分析することはありませんが、まず特定のデータスライスを検討し、次に比較的少数の測定値への投影を検討します。 （決定理論の専門家は、人が同時に7つ以上のパラメーターを分析できないことを長い間確立してきました）。 データベース言語に変換すると、スライスは述語またはwhere句であり、特定のディメンションのプロジェクションはgroup byによる集計です。 少し簡略化して、まだ結合があり、分析関数などがありますが、これらはすでに重要ではありません。 いずれにせよ、クエリ内のすべての列のうち、少数のみが使用されます。 したがって、ディスクからすべてのデータではなく一部のみを読み取る機能により、クエリが大幅に高速化されます。 物理的には、各列は変更されない1つ以上の比較的小さなファイルに保存されます（作成または削除されるだけです）。 したがって、列の読み取りは非常に高速な操作です。

特定の列エンコード方法

Verticaの列コーディングは、2つの目的に使用されます。

• ディスク上のデータのサイズを縮小し、それによって読み取り/書き込みを高速化します
• データをディスクに配置して、フィルタリング、結合、グループ化、ソート、およびその他の標準操作を行うのに便利です。

覚えているように、Verticaにはインデックスはありません。 代わりに、ディスク上のデータ自体が「スタック」されているため、すぐに見つかります。 スタイリング方法は投影と呼ばれます。 これは、すべての列が投影に含まれるわけではないというヒントですが、後でこれに戻ります。 クイック検索は、order（order by）とRLE（run length encoding、つまり、行の値の繰り返し数をエンコードする）を組み合わせることにより実現されます。 RLEが順序でどのように機能するかは、例で示すのが最も簡単です。 フィールドevent_date、amount、および別の100フィールドを持つテーブルがあると想像してください。 1年には365日あり、毎日10億のエントリがあります。 典型的なリクエストが期間（日、週など）のお金を計算する場合、event_dateでソートされたevent_dateのRLEエンコードを使用します。 テーブルをevent_dateでソートした場合、event_date列には1,000,000,000個の同一の値のブロックがあります。 RLEコーディングとは、ディスク上の物理的に、毎日のevent_dateカラムの日付と繰り返し回数（この場合は10億）のみがあることを意味します。 このような記録は年間365あります。 ディスクから立ち上げてディスクを見つけるのはほんの一瞬です。 event_dateレコードには、残りの列を持つブロックへのポインターのようなものが含まれています。 つまり、 “select sum(amount) from t where event_date='2012-07-01'”を実行するには、単にevent_date列を読み取り、次に目的の日付に関連する1つまたは複数の量のブロックを読み取ります。 とても速いです。 RLEには複数の順序付けられた列が存在する可能性があることは明らかです。 また、このようなコーディング方法は、一意の値が多くない列に最適であることも明らかです。 測定の典型的なもの。

一般に、これはインデックスに多少似ています。 ただし、動作は少し異なります。 まだaccount_type（2つの値）列と、たとえばdepartment（5つの値）列があるとします。 また、多くの場合、検索を行う必要があります。 インデックスの場合、ケースごとに別々のインデックスを作成する必要があります。 また、Vertikaでは、1つの投影法で十分であり、3つの列すべてを任意の組み合わせで検索できます。 たとえば、次の順序の場合：account_type、department、event_dateによる順序。 RLEエンコーディングを使用したすべての列。 このように、event_dateの検索は「壊れる」ように思われます。 account_type、department、event_dateのインデックスを使用すると、そうなります。 ただし、Vertikaの場合、event_dateの要求は前の例よりもわずかに遅いだけ実行されます... 1つのevent_dateブロックの代わりに、10個（2 account_type * 5部門）を読み取り、それぞれで「your」event_dateを見つけ、対応するブロックを読み取る必要があります量。 RLEによるevent_dateブロックのサイズが小さいことを考えると、この違いはほとんど見えません。

アイデアが明確であることを願っています。 インデックスの代わりに、ディスク上のいくつかの列がソートされ、巧妙に接続されます。 通常、これは写真または表で示されますが、残念ながらここにはありません。

RLEエンコーディングは、検索に加えて、グループによる並べ替えを高速化するためにも使用されます。これは、データが既に並べ替えが不要な場合があるためです。 検索の場合と同様に、group byが投影の最初の位置にない場合、加速（いわゆるパイプライン化されたgroup by）も発生します。

Vertikaは列をエンコードする多くの方法をサポートしますが、残りはよりコンパクトなデータ配置に使用されます。これはもちろんパフォーマンスにも影響しますが、そもそもそうではありません。

コーディングに加えて、Verticaは従来のデータのパーティション分割、およびそれに応じてパーティションの削除またはパーティションのプルーニングもサポートします。これにより、場合によってはディスクから読み取られるデータの量をさらに減らすことができます。

さまざまなタスクに合わせて最適化された多くの物理テーブルビューを持つ機能

前のセクションを読んだ後、テーブルまたはプロジェクションの1つの物理的表現だけで常にうまくいくとは限らないという点で、合理的な疑念が忍び寄るかもしれません。 最も洗練されたRLE / order-byでさえすべての場合に役立つわけではないので。 したがって、Verticaは1つのテーブルに対して複数のプロジェクションをサポートしています。 少なくとも1つの投影にはすべての列を含める必要があり（スーパー投影）、残りの投影には一部のみを含めることができます。 これにより、さまざまなタイプのクエリに対して特定の小さなプロジェクションを構築できます。 このアプローチは、マテリアライズドビューに少し似ています。 しかし、MVは「横向き」のローションであり、投影法はデータを保存するための主要かつ唯一の方法です。 Vertikovskyのエンジニアは、投影法の使用をユーザーに完全に見えなくすることに成功しました。 それら自体は最新の状態に保たれ、クエリオプティマイザーは、私が知る限り、各要求に最適な投影法を正確に選択します。

基本原則を理解したので、特定のタスクの投影設計を独自に開発するのは非常に簡単です。 しかし、初心者または怠け者には、Vertikaに付属する特別なユーティリティVert Designerがあります。これは、一連のテーブルとテストクエリの最適な設計を生成するのに役立ちます。

すべての設計変更は、作業中のデータベースで行うことができます。 既存のスーパープロジェクションを使用して、新しいスーパープロジェクションが作成されます。 もちろん、これはパフォーマンスを低下させますが、（列の数による）小さな予測では、それほど時間はかかりません。

線形スケーリング。 MPP

垂直スケールの量はほぼ線形です：

• ドライブ
• コア
• サーバー

サーバー全体のスケーリングは、クラスターのサーバー（ノード）全体の投影の均一な「スミアリング」（セグメンテーション）によって保証されます。 セグメンテーションの方法は、開発者が設定します。通常、これは1つ以上の列からのハッシュ関数です。明示的な条件もあります。 要求に応じて、各サーバーは、そのためのすべてのカーネルを含む操作を実行し、結果は要求を開始したサーバーで結合されます。 それが実際に機能することを除いて、超自然的なことはありません。 すべてのテーブルがセグメント化に意味があるわけではありません。 ほとんど常に結合でのみ使用される小さなディメンションテーブルは、通常、セグメント化されず、完全なコピーが各ノードに保存されます。 同じテーブルに対して、一部のプロジェクションはセグメント化できますが、他のプロジェクションはセグメント化できません。 これにより、特定のタスクに合わせて物理設計を非常に柔軟にカスタマイズし、最適なパフォーマンスを実現できます。

パフォーマンスに加えて、クラスターではフォールトトレランスを構成できます。 この場合、各データブロックはクラスターの異なるノードの2つ以上のインスタンスに格納されます。 複製レベルはK安全レベルと呼ばれます。 標準レベル1では、クラスターは1つの（保証された）ノードからフロア（N / 1）ノードへの損失が最良の場合に発生します。 ただし、一部（すべてではない）の種類の要求に対して1つ以上のノードがドロップされたクラスターのパフォーマンスは、大幅に（桁違いに）低下する可能性があることがわかりました。 Vertikovetsはこれがバグであることを確認しており（Vertica 6で既に修正済み）、この問題に陥らないようにリクエストを変更することができました。 ちなみに、鉄は頻繁に壊れるので、「ラメ」クラスターで繰り返し生活しなければなりませんでした。

Vertikaは透過的なクラスター拡張をサポートし、プロセスは完全に制御可能です。 新しいものを追加した後、すべての投影を手動または自動で再調整する必要があります。 本番システムでは、時間外に手動で行うことをお勧めします。リバランスによりディスクが大量にロードされるためです。 バージョン5以降、ディスク上のデータは、バランスを取り直すのに便利な方法で格納されます（エラスティッククラスター）。 再コーディングせずにブロックを移動するだけで十分です。 パフォーマンスがはるかに高速で低コストです。

もう少し練習。 さまざまなタスクのために、異なるハードウェア上でVertikaにいくつかの異なるデータベースインスタンスを作成する必要がありました（データのバックアップとクローン作成に関するあまり成功しなかった記事を参照 ）。 これは、すべてのスケーラビリティを備えたクラスターが、比較的短い単純なクエリを比較的ゆっくり実行するという事実のために発生しました。 ネットワーク遅延と、異なるノードからの結果を結合するための追加の「パス」の必要性が影響を与える可能性があります。 クエリが実際に大量のデータを必要とする場合、大量にソートする場合など、クラスターの能力が明らかになります。

垂直延長

Vertikaは、Hadupとの統合を提供した最初のRDBMSメーカーの1つです。 したがって、VerticaとHadupeを頼りに同じタスクを試すのは自然でした。 ある意味で、 「大規模データ分析へのアプローチの比較」の足跡をたどりました。 実験では、さまざまな次元でユニークビジターをカウントする実際のタスクを使用しました。 Vertikovアダプターは非常に高速ではないため、アダプターとHDFSでの最初のデータ保存の両方をテストしました。

このタスクの実装をいくつか試しました。 テストシナリオ-ユニークビジターの数を、国やその他のディメンションごとにカウントします。 テストデータの量は約3億件のレコードで、そのうち6〜7千万件が一意です。 VertikaとKhadupの両方がほぼ線形にスケールし、単一サーバーの実験の結果で十分であるため、意図的にクラスターを使用しませんでした。 実際には、1台のサーバー上のKhadupを使用してもあまり意味がないことは明らかです。 場所は次のとおりです。

• Google Big Query-最速のクエリには数分かかりました。 グーグルが彼らのサービスに多額のお金を望んでいたので、私は拒否しなければならなかった（それはリクエストごとに数百ドルになった）。 ここでは、md5ビジター識別子を使用しました。 それ以外の場合、8バイト整数。 つまり、GBQはさらに高速になる可能性があります。 別の問題はデータの読み込みです。
• Verticaは、良好なハードウェア上の独立したサーバー（クラスターではない）であり、このタスクにのみ使用されました。 要求が完了するまで約15分かかります。 そのようなニーズがある場合、タスクはかなり並列化できます。 スピードが私たちに合っていました。
• 1スレッドプレーンJava。 2時間 1回の実行とHashMap。
• Hadoop（クラスターではない）。 豚のリクエスト。 額に約8〜10時間。 データストレージをローカルに使用し、すべてのコアをロードする-2時間（つまり、シングルスレッドのJavaアプリケーションに相当）。 おそらく、クラスターへの拡張により、線形または線形に近い増加が得られます。 しかし、Vertikaとの違いはまだ非常に大きいです。

この実験の結果、これは非常に偶然でしたが、統合が機能していることを確信し、予想どおり、Hadoopはかなり低速でした。 クエリをPig / Hiveに直接記述する利点はかなり疑わしく、SQLで同じタスクを表現できる場合はまったくありません。 おそらく、本格的なMapReduceが必要なタスクがまだあるでしょう。

Hadoopは、Verticaの機能を拡張する唯一の方法ではありません。 Verticalを使用すると、集計関数および分析関数を含むC ++でUDFを記述でき、最新バージョンではR言語との統合を提供します。 SQLの点で複雑です。 このために、ODBCまたは独自のRESTサービスを使用しました。 現在、この統合はさらに簡素化されています。

おわりに

現在、Vertikaは1年半以上にわたって生産に携わっています。 単一サーバーシステムとクラスターシステムの両方があります。 Vertikaは非常に信頼性の高いデータベースであることが判明しました。データベースの障害によりデータの損失や障害が発生したことはありません。 最初のバージョンの1つにエラーがあり、一部のクエリの結果が誤っていましたが、すぐに修正されました。 特に不完全なクラスタでパフォーマンスの問題がありましたが、それらも解決されました。 現在、1日に約10億のファクト（およびサーバーの1つに50億のファクト）をアップロードします。これらのファクトは、さまざまな集計で数億件のレコードに集計されます。 Vertikaは1日に約1万人のユーザーリクエストを実行し、ランタイムシステム、監視、およびその他の内部ロボットからのリクエストの約2倍を実行します。 通常、数日または数週間の統計のスライスを要求するほとんどのユーザークエリは、5〜10秒実行し、実行時間（かなり単純）1.5〜2秒です。 これはOLTPデータベースではなく、分析であるため、このような応答時間は非常に満足のいくものです。 ただし、現在、より強力なクラスターに移行しているため、クエリの実行時間が平均で3倍短縮されます。

しかし、時間が止まることはありません。多層データウェアハウスやインメモリOLAPのようなものが必要だと考えています。 しかし、それについては次の記事で詳しく説明します。

PS 7月11日、モスクワでの会議でVerticaに関する質問に回答できます： habrahabr.ru/events/836