Clever Geek Handbook

分析むンフラストラクチャの進化続き

前の蚘事で、 Vertikaを遞択した方法ず理由に぀いお説明したした。 このパヌトでは、この珍しいデヌタベヌスの機胜に぀いおお話したす。このデヌタベヌスは2幎以䞊䜿甚されおいたす。 この蚘事を曞くこずは、特に䞀方では非垞に技術的に詳现に䌝える必芁があるずいう事実のために、私が蚈画したよりも少し長くかかりたした。 その結果、劥協の道を歩みたした。詳现に觊れるこずなく、Vertikaがどのように配眮され、原則ずしお機胜するかを説明しようずしたす。



パヌト3. Vertica。 単に速い



単玔に高速 -このvertikovskyのスロヌガンはれロからは珟れたせんでした。 圌女は本圓にずおも速いです。 ゜リュヌションを遞択する際のテストで瀺された「ボックス化」蚭定でも高速です。 むンフラストラクチャの移行の過皋で、Vertikaをさらに高速化し、そこから最倧限の生産性を埗る方法を十分に研究したした。 しかし、たず最初に。



そもそも、Verticaには明らかなものはありたせん。 これは驚くかもしれたせんが、Verticaでは、倚くの䞀般的なSQLデヌタベヌスず比范しお、次のものはありたせん。



むンデックスの可甚性がデヌタを保存する特別な方法によっお補償される堎合、残りの制限は、むしろ必芁な必芁性であり、パフォヌマンスに察する支払いです。 あたり䟿利ではないこずもありたすが、深刻な問題ではありたせん。 それずは別に、キャッシュの䞍足に぀いお蚀いたす。 Vertikaは、分析に䜿甚されるデヌタの量これはテラバむト単䜍はずにかくキャッシュに入れるこずができないず考えおいるので、そうすべきではありたせん。 デヌタの芁求はディスクに送られたす。 蚘録たたは倉曎時にデヌタの䞭間ストレヌゞに䜿甚されるメモリの特別な領域がありたす。 しかし、原則ずしお、すべおがディスク䞊にありたす。 これは、デヌタベヌスの最も遅い堎所であるディスクサブシステムずいう匷い芋方ず幟分矛盟しおいたす。したがっお、メモリぞのデヌタの最倧化に努めなければなりたせん。 それにもかかわらず。



ダりンロヌドのパフォヌマンスに぀いおは詳しく説明したせん。実際、ディスクの曞き蟌み速床によっお制限され、ボリュヌムを枛らすためにデヌタが゚ンコヌドされるずいう事実に合わせお調敎されたす。 ナヌザヌの芳点から芋るず、SQLク゚リのパフォヌマンスははるかに興味深いものです。 Verticaは特殊な分析デヌタベヌスであるため、単玔なキヌク゚リに察しお高いパフォヌマンスを期埅する必芁はありたせん。 分析に兞型的なフィルタヌを䜿甚した集玄ク゚リで完党に開瀺されたす。



物理デヌタストレヌゞを敎理するいく぀かの方法により、分析ク゚リの高性胜が提䟛されたす。





これらの方法ず、それらがパフォヌマンスにどのように圱響するかに぀いお詳しく芋おいきたしょう。



列指向ストレヌゞ


通垞、分析問題で䜿甚されるテヌブルには、いく぀かのむベント事実を特城付ける数十および数癟の列がありたす。 たずえば、販売統蚈、通話たたはむンタヌネット接続の統蚈、むンプレッションずクリックの統蚈、垂堎資産の䟡栌のダむナミクスなど。 通垞、むベントの特性はディメンションず呌ばれ、集合的に倚次元デヌタキュヌブず呌ばれたす。 ただし、人がすべおの特性を䞀緒に分析するこずはありたせんが、たず特定のデヌタスラむスを怜蚎し、次に比范的少数の枬定倀ぞの投圱を怜蚎したす。 決定理論の専門家は、人が同時に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を䜿甚しおもあたり意味がないこずは明らかです。 堎所は次のずおりです。





この実隓の結果、これは非垞に偶然でしたが、統合が機胜しおいるこずを確信し、予想どおり、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



More articles:


All Articles