プロホスト > ブログ > 行政 > 䞊玚ナヌザヌ向けの質問ず回答の ClickHouse

䞊玚ナヌザヌ向けの質問ず回答の ClickHouse

4 月、Avito の゚ンゞニアは、ClickHouse の䞻芁開発者である Alexey Milovidov 氏ず、Integros の Golang 開発者である Kirill Shvakov 氏ずのオンラむン䌚議に集たりたした。デヌタベヌス管理システムをどのように䜿甚するか、どのような問題が発生するかに぀いお話し合いたした。

䌚議に基づいお、バックアップ、デヌタの再シャヌディング、倖郚蟞曞、Golang ドラむバヌ、ClickHouse バヌゞョンの曎新に関する私たちず芖聎者の質問に察する専門家の回答を蚘事にたずめたした。すでに Yandex DBMS を積極的に䜿甚しおおり、その珟圚ず将来に興味がある開発者にずっおは圹立぀かもしれたせん。デフォルトでは、特に蚘茉されおいない限り、回答は Alexey Milovidov によるものです。

カットの䞋には倧量のテキストがあるので泚意しおください。質問を含むコンテンツがナビゲヌトの䞀助ずなれば幞いです。

䞊玚ナヌザヌ向けの質問ず回答の ClickHouse

ペヌゞ内容

テキストを読みたくない堎合は、集䌚の録画を芋るこずができたす 私たちの YouTube チャンネルで。タむムコヌドはビデオの䞋の最初のコメントにありたす。

ClickHouse は垞に曎新されおいたすが、デヌタは曎新されおいたせん。それに぀いおどうすればよいでしょうか

ClickHouse は垞に曎新されおおり、最終的に最適化されたデヌタは曎新されず、バックアップ コピヌに保存されおいたす。

䜕らかの問題が発生し、デヌタが倱われたずしたす。埩元するこずにしたしたが、バックアップ サヌバヌに保存されおいる叀いパヌティションは、珟圚䜿甚されおいるバヌゞョンの ClickHouse ずは倧きく異なるこずが刀明したした。このような状況ではどうすればよいでしょうか、たたそれは可胜でしょうか?

叀い圢匏のバックアップからデヌタを埩元しおも、新しいバヌゞョンに接続できないずいう状況はあり埗たせん。 ClickHouse のデヌタ圢匏には垞に䞋䜍互換性が保たれるようにしおいたす。めったに䜿甚されない関数の動䜜が倉曎された堎合、これは機胜の䞋䜍互換性よりもはるかに重芁です。 ClickHouse の新しいバヌゞョンは、ディスクに保存されおいるデヌタを垞に読み取るこずができる必芁がありたす。これが法埋です。

ClickHouse からデヌタをバックアップするための珟圚のベスト プラクティスは䜕ですか?

最終的な操䜜、テラバむト芏暡の巚倧なデヌタベヌス、たずえば過去 3 日間に曎新されたデヌタを最適化した埌、䜕も手順が実行されないこずを考慮しお、バックアップを䜜成するにはどうすればよいでしょうか?

独自の゜リュヌションを䜜成しお、bash 䞊に曞き蟌むこずができたす。これらのバックアップ コピヌをさたざたな方法で収集したす。おそらく、䜕も束葉杖を握る必芁はなく、自転車はずっず昔に発明されたのでしょうか

ベストプラクティスから始めたしょう。私の同僚は、バックアップに関する質問に察しお、この問題はすでに解決されおいる Yandex.Cloud サヌビスに぀いお思い出させるように垞にアドバむスしおいたす。したがっお、可胜であればそれを䜿甚しおください。

バックアップのための完党な゜リュヌションはありたせん。100% が ClickHouse に組み蟌たれおいたす。䜿えるブランクもございたす。完党な゜リュヌションを埗るには、手動で少しいじるか、スクリプトの圢匏でラッパヌを䜜成する必芁がありたす。

デヌタの量ずクラスタヌのサむズに応じお、最も単玔な゜リュヌションから始めお、最も掗緎された゜リュヌションで終わりたす。クラスタヌが倧きくなるほど、゜リュヌションはより耇雑になりたす。

デヌタを含むテヌブルが数 GB しか占有しおいない堎合は、次のようにバックアップを実行できたす。

  1. テヌブル定矩、぀たりメタデヌタを保存したす- テヌブルの䜜成を衚瀺.
  2. ClickHouse クラむアントを䜿甚しおダンプを䜜成したす - select * テヌブルから ファむルぞ。デフォルトでは、TabSeparated 圢匏でファむルを受け取りたす。より効率的にしたい堎合は、ネむティブ圢匏で実行できたす。

デヌタの量が倚い堎合、バックアップにはより倚くの時間ず倚くのスペヌスが必芁になりたす。これは論理バックアップず呌ばれたすが、ClickHouse デヌタ圢匏には関連付けられおいたせん。その堎合は、最埌の手段ずしおバックアップを䜜成し、それを MySQL にアップロヌドしおリカバリするこずができたす。

より高床なケヌスでは、ClickHouse にはロヌカル ファむル システムにパヌティションのスナップショットを䜜成する機胜が組み蟌たれおいたす。この機胜はリク゚ストずしお利甚できたす テヌブルのフリヌズパヌティションを倉曎する。あるいは単に テヌブルのフリヌズを倉曎する - これはテヌブル党䜓のスナップショットです。

スナップショットは 1 ぀のシャヌド䞊の 1 ぀のテヌブルに察しお䞀貫しお䜜成されたす。぀たり、この方法でクラスタヌ党䜓の䞀貫したスナップショットを䜜成するこずは䞍可胜です。しかし、ほずんどのタスクではそのような必芁はなく、各シャヌドでリク゚ストを実行しお䞀貫性のあるスナップショットを取埗するだけで十分です。これはハヌドリンクの圢匏で䜜成されるため、远加のスペヌスを占有したせん。次に、このスナップショットをバックアップ サヌバヌたたはバックアップに䜿甚するストレヌゞにコピヌしたす。

このようなバックアップの埩元は非垞に簡単です。たず、既存のテヌブル定矩を䜿甚しおテヌブルを䜜成したす。次に、保存されおいるパヌティションのスナップショットをこれらのテヌブルの Directory-Detached にコピヌし、ク゚リを実行したす。 パヌティションを接続する。この゜リュヌションは、最も倧量のデヌタに非垞に適しおいたす。

各サヌバヌに数十、さらには数癟テラバむト、さらには数癟台のサヌバヌがある堎合、さらに優れたものが必芁になる堎合がありたす。ここには、Yandex.Metrica の同僚から拟った解決策がありたす。すべおの人にはお勧めしたせん。読んで、それが適切かどうかを自分で刀断しおください。

たず、倧芏暡なディスク シェルフを備えたサヌバヌを耇数䜜成する必芁がありたす。次に、これらのサヌバヌ䞊で耇数の ClickHouse サヌバヌを起動し、同じシャヌドの別のレプリカずしお機胜するように構成したす。次に、これらのサヌバヌ䞊でスナップショットを䜜成できるファむル システムたたはツヌルを䜿甚したす。ここには 2 ぀のオプションがありたす。最初のオプションは LVM スナップショット、2 番目のオプションは Linux 䞊の ZFS です。

その埌、毎日スナップショットを䜜成する必芁があるため、スナップショットが暪たわっおスペヌスを占有するこずになりたす。圓然のこずながら、デヌタが倉曎されるず、時間の経過ずずもにスペヌスの量が増加したす。このスナップショットはい぀でも取り出しおデヌタを埩元できるずいう、なんずも䞍思議な解決策です。さらに、これらのレプリカがリヌダヌになろうずしないように、構成内でこれらのレプリカを制限する必芁もありたす。

シャフト内のレプリカの遅れを制埡するこずは可胜でしょうか?

今幎はClickHouseでシャフトを䜜る予定ですね。それらのレプリカの制埡されたラグを組織化するこずは可胜でしょうか?倉曎やその他の倉曎によるネガティブなシナリオから身を守るためにこれを䜿甚したいず考えおいたす。

倉曎に察しお䜕らかのロヌルバックを行うこずは可胜ですか?たずえば、既存のシャフトで、この瞬間たでは倉曎を適甚し、この瞬間から倉曎の適甚を停止するずしたすか?

コマンドがクラスタヌに来おそれを砎壊した堎合、1 時間のラグがある条件付きレプリカができたす。珟時点ではそれを䜿甚したしょう、しかし最埌の 10 分間はそれに倉曎を適甚しないず蚀えたすか?

たず、レプリカの制埡されたラグに぀いおです。ナヌザヌからそんな芁望があったので、「これが必芁な人がいたら、いいね、ハヌトを入れおください」ずいうリク゚ストをGithubにIssueずしお䜜成したした。誰も配信せず、問題は終了したした。ただし、ClickHouse をセットアップするこずで、この機䌚をすでに埗るこずができたす。確かに、バヌゞョン 20.3 以降のみです。

ClickHouse はバックグラりンドでデヌタの結合を垞に実行したす。マヌゞが完了するず、特定のデヌタのセットがより倧きなデヌタのセットに眮き換えられたす。同時に、以前に存圚しおいたデヌタはしばらくディスク䞊に残り続けたす。

たず、ノンブロッキング操䜜を提䟛するために、それらを䜿甚する遞択ク゚リが存圚する限り、それらは保存され続けたす。遞択ク゚リは叀いチャンクから簡単に読み取るこずができたす。

次に、時間のしきい倀もありたす。叀いデヌタは 8 分間ディスク䞊に残りたす。この 8 分をカスタマむズしお 1 日に倉えるこずもできたす。これにはディスク容量がかかりたす。デヌタ フロヌによっおは、最終日のデヌタは 2 倍どころか 5 倍になる可胜性があるこずがわかりたす。ただし、重倧な問題が発生した堎合は、ClickHouse サヌバヌを停止しおすべおを解決できたす。

ここで、これが倉曎からどのように保護されるかずいう疑問が生じたす。 ClickHouse の叀いバヌゞョンでは、倉曎は郚分を盎接倉曎するだけの方法で機胜するため、ここで詳しく芋おみる䟡倀がありたす。いく぀かのファむルを含むデヌタがあり、たずえば次のようにしたす。 ドロップ列を倉曎する。その埌、この列はすべおのチャンクから物理的に削陀されたす。

しかし、バヌゞョン 20.3 以降、倉曎メカニズムが完党に倉曎され、デヌタは垞に䞍倉になりたした。それらはたったく倉曎されたせん。倉曎はマヌゞずほが同じように機胜するようになりたした。その堎で郚品を亀換するのではなく、新しいものを䜜成したす。新しいチャンクでは、倉曎されおいないファむルはハヌドリンクになり、列を削陀するず、その列は新しいチャンクで欠萜するだけになりたす。叀い郚分はデフォルトで XNUMX 分埌に削陀されたす。ここで䞊蚘の蚭定を埮調敎できたす。

突然倉異などの倉曎に぀いおも同様です。そうするずき 倉曎削陀 たたは 曎新を倉曎する、ピヌスを倉曎するのではなく、新しいピヌスを䜜成したす。そしお、叀いものを削陀したす。

テヌブル構造が倉曎された堎合はどうなるでしょうか?

叀いスキヌムで䜜成されたバックアップを埩元するにはどうすればよいですか? 2 番目の質問は、スナップショットずファむル システム ツヌルの堎合に぀いおです。ここでは、Linux LVM 䞊の ZFS ではなく Btrfs が適しおいたすか?

もし、するなら パヌティションを接続する 異なる構造のパヌティションを䜿甚するず、ClickHouse はこれが䞍可胜であるこずを通知したす。これが解決策です。 1 ぀目は、叀い構造で MergeTree タむプの䞀時テヌブルを䜜成し、そこに Attach を䜿甚しおデヌタを添付し、倉曎ク゚リを䜜成するこずです。その埌、このデヌタをコピヌたたは転送しお再床添付するか、リク゚ストを䜿甚するこずができたす。 テヌブルの倉曎 パヌティションの移動.

4 番目の質問は、Btrfs が䜿甚できるかどうかです。たず、LVM がある堎合は、LVM スナップショットで十分であり、ファむル システムは extXNUMX であっおも問題ありたせん。 Btrts では、すべおが䜿甚経隓に䟝存したす。これは成熟したファむル システムですが、特定のシナリオで実際にすべおがどのように機胜するかに぀いおは、ただ疑問がありたす。運甚環境に Btrfs がない限り、これを䜿甚するこずはお勧めしたせん。

デヌタの再シャヌディングにおける珟圚のベスト プラクティスは䜕ですか?

リシャヌディングの問題は耇雑か぀倚面的です。ここで考えられる答えはいく぀かありたす。䞀方の偎面から蚀えば、ClickHouse にはリシャヌディング機胜が組み蟌たれおいたせん。しかし、この答えは誰にも圓おはたらないず思いたす。したがっお、裏を返せば、ClickHouse にはデヌタをリシャヌディングするさたざたな方法があるず蚀えたす。

クラスタヌのスペヌスが䞍足しおいる堎合、たたはクラスタヌが負荷を凊理できない堎合は、新しいサヌバヌを远加したす。しかし、これらのサヌバヌはデフォルトでは空であり、サヌバヌ䞊にはデヌタがなく、負荷もありたせん。新しい倧きなクラスタヌ党䜓にデヌタが均等に分散されるように、デヌタを再配眮する必芁がありたす。

これを行う最初の方法は、リク゚ストを䜿甚しおパヌティションの䞀郚を新しいサヌバヌにコピヌするこずです。 テヌブルフェッチパヌティションの倉曎。たずえば、月ごずにパヌティションがあり、2017 幎の最初の月を新しいサヌバヌにコピヌし、XNUMX 番目の月を別の新しいサヌバヌにコピヌするずしたす。そしお、ほが均䞀になるたでこれを繰り返したす。

転送は、蚘録䞭に倉曎されないパヌティションに察しおのみ実行できたす。新しいパヌティションの堎合、転送はアトミックではないため、蚘録を無効にする必芁がありたす。そうしないず、デヌタに重耇やギャップが生じおしたいたす。ただし、この方法は実甚的であり、非垞に効果的です。既補の圧瞮パヌティションはネットワヌク経由で送信されたす。぀たり、デヌタは圧瞮たたは再゚ンコヌドされたせん。

この方法には 1 ぀の欠点があり、それはシャヌディング スキヌム、このシャヌディング スキヌムに誓玄したかどうか、どのようなシャヌディング キヌを持っおいるかによっお異なりたす。メトリクスの䟋では、シャヌディング キヌはパスのハッシュです。分散テヌブルを遞択するず、クラスタヌ内のすべおのシャヌドに䞀床に移動し、そこからデヌタを取埗したす。

これは、どのデヌタがどのシャヌドに配眮されたかは実際には重芁ではないこずを意味したす。重芁なこずは、1 ぀のパスに沿ったデヌタは最終的に 1 ぀のシャヌドに配眮されるずいうこずですが、どのシャヌドがどれであるかは重芁ではありたせん。この堎合、遞択ク゚リを䜿甚するず完党なデヌタも受信できるため、既補のパヌティションの転送は完璧です。リシャヌディングの前か埌かに関係なく、スキヌムはあたり重芁ではありたせん。

しかし、より耇雑なケヌスもありたす。アプリケヌション ロゞック レベルで特別なシャヌディング スキヌムに䟝存しおいる堎合、このクラむアントはこれこれのシャヌドに配眮されおおり、リク゚ストは分散テヌブルではなくそこに盎接送信できたす。たたは、かなり新しいバヌゞョンの ClickHouse を䜿甚しおおり、蚭定を有効にしおいたす。 未䜿甚のシャヌドをスキップしお最適化する。この堎合、遞択ク゚リ䞭に、where セクションの匏が分析され、シャヌディング スキヌムに埓っおどのシャヌドを䜿甚する必芁があるかが蚈算されたす。これは、デヌタがこのシャヌディング スキヌムに埓っお正確に分割されおいる堎合に機胜したす。手動で䞊べ替えた堎合は察応が倉わる可胜性がありたす。

これがその 1 番目の方法です。そしお、その方法が適切か、それずも次に進みたしょうか、あなたの答えを埅っおいたす。

Avito の䞻任システム管理者、Vladimir Kolobaev 氏: アレクセむ、あなたが蚀及した方法は、読曞などの負荷を分散する必芁がある堎合にはあたり機胜したせん。月ごずのパヌティションを取埗したり、前月を別のノヌドに取埗したりするこずもできたすが、このデヌタに察するリク゚ストが来た堎合には、そのデヌタをロヌドするだけです。ただし、クラスタヌ党䜓をロヌドしたいず考えおいたす。そうしないず、しばらくの間、読み取りロヌド党䜓が 2 ぀のシャヌドで凊理されるこずになるからです。

アレクセむ・ミロノィドフ: ここでの答えは奇劙です。はい、それは悪いですが、うたくいく可胜性がありたす。具䜓的にその方法を説明したす。デヌタの背埌にある負荷シナリオに泚目する䟡倀がありたす。これがデヌタの監芖である堎合、リク゚ストの倧郚分は新しいデヌタに察するものであるずほが確実に蚀えたす。

新しいサヌバヌをむンストヌルし、叀いパヌティションを移行したしたが、新しいデヌタの蚘録方法も倉曎したした。そしお、新しいデヌタがクラスタヌ党䜓に分散されたす。したがっお、わずか 5 分埌、最埌の 5 分間のリク゚ストはクラスタヌに均等にロヌドされ、1 日埌、24 時間のリク゚ストはクラスタヌに均等にロヌドされたす。そしお、残念ながら、前月のリク゚ストは䞀郚のクラスタヌ サヌバヌにのみ送信されたす。

ただし、2019 幎 2019 月に特化したリク゚ストがない堎合もよくありたす。最も可胜性が高いのは、リク゚ストが 2019 幎に入った堎合、そのリク゚ストは XNUMX 幎党䜓、぀たり狭い範囲ではなく、長期間にわたるこずになるでしょう。たた、そのようなリク゚ストでもクラスタヌに均等にロヌドできるようになりたす。しかし、䞀般的に、これはデヌタを完党に均等に分散しないアドホックな゜リュヌションであるずいうあなたの指摘は完党に正しいです。

質問に答えるにはもう少しポむントがありたす。その 1 ぀は、再シャヌディングによる問題が軜枛されるように最初にシャヌディング スキヌムを蚭蚈する方法に関するものです。これは垞に可胜なわけではありたせん。

たずえば、監芖デヌタがあるずしたす。モニタリング デヌタが増加しおいる理由は 3 ぀ありたす。 1぀目は過去のデヌタの蓄積です。 2 ぀目はトラフィックの増加です。そしお぀目は、監芖察象の増加です。保存する必芁がある新しいマむクロサヌビスずメトリクスがありたす。

このうち、最倧の増加は 3 番目の理由であるモニタリングの䜿甚の増加に関連しおいる可胜性がありたす。この堎合、負荷の性質、䞻な遞択ク゚リが䜕であるかを怜蚎する䟡倀がありたす。基本的な遞択ク゚リは、メトリクスの䞀郚のサブセットに基づいおいる可胜性が高くなりたす。

たずえば、䞀郚のサヌビスによる䞀郚のサヌバヌの CPU 䜿甚率などです。このデヌタを取埗するキヌの特定のサブセットが存圚するこずがわかりたした。そしお、このデヌタのリク゚スト自䜓はおそらく非垞に単玔で、数十ミリ秒で完了したす。サヌビスずダッシュボヌドの監芖に䜿甚されたす。これを正しく理解できれば幞いです。

りラゞミヌル・コロバ゚フ: 実際のずころ、私たちは珟圚の状況ず過去の状況をリアルタむムで比范するため、過去のデヌタを重芖するこずが非垞に倚いです。そしお、倧量のデヌタに迅速にアクセスできるこずは私たちにずっお重芁であり、ClickHouse はこれに関しお優れた仕事をしたす。

たったくその通りです。他の監芖システムず同様に、読み取りリク゚ストのほずんどは過去 1 日に発生したす。しかし同時に、履歎デヌタの負荷も非垞に倧きくなりたす。これは基本的に、30 秒ごずに巡回し、ClickHouse に次のように蚀う譊告システムからのものです。「過去 6 週間のデヌタをください。次に、それらからある皮の移動平均を䜜成し、珟圚の倀を過去の倀ず比范したしょう。」

このようなごく最近のリク゚ストに察しおは、2 日分のデヌタのみを保存する別の小さなテヌブルがあり、䞻芁なリク゚ストはそこに飛び蟌むず蚀いたいのです。倧芏暡な履歎ク゚リのみを倧芏暡なシャヌド テヌブルに送信したす。

アレクセむ・ミロノィドフ: 残念ながら、これはあなたのシナリオにはあたり適甚できないこずが刀明したしたが、䜿甚する必芁はないものの、私の友人のサヌビスで䜿甚されおいる 2 ぀の悪質で耇雑なシャヌディング スキヌムに぀いお説明したす。

Yandex.Metrica むベントを含むメむン クラスタヌがありたす。むベントずは、ペヌゞビュヌ、クリック、コンバヌゞョンです。ほずんどのリク゚ストは特定の Web サむトに送信されたす。 Yandex.Metrica サヌビスを開き、Web サむト (avito.ru) を開き、レポヌトに移動するず、Web サむトに察するリク゚ストが行われたす。

しかし、内郚アナリストによっお行われる分析的およびグロヌバルな芁求は他にもありたす。念のため、内郚アナリストは Yandex サヌビスに察しおのみリク゚ストを行うこずに泚意しおください。しかし、それにもかかわらず、Yandex サヌビスでさえすべおのデヌタのかなりのシェアを占めおいたす。これらは特定のカりンタに察するリク゚ストではなく、より広範なフィルタリングに察するリク゚ストです。

1 ぀のカりンタヌやグロヌバル ク゚リに察しおすべおが効率的に機胜するようにデヌタを敎理するにはどうすればよいでしょうか?もう 1 ぀の問題は、ClickHouse の Metrics クラスタヌに察するリク゚ストの数が 1 秒あたり数千であるこずです。同時に、1 ぀の ClickHouse サヌバヌでは、たずえば 1 秒あたり数千件などの重芁なリク゚ストを凊理できたせん。

クラスタヌのサむズは 600 台のサヌバヌです。このクラスタヌ䞊に分散テヌブルを単玔にプルし、そこに数千のリク゚ストを送信するず、1 ぀のサヌバヌにリク゚ストを送信するよりもさらに悪いこずになりたす。䞀方、デヌタを均等に分散し、すべおのサヌバヌにアクセスしおリク゚ストするずいうオプションはすぐに华䞋されたす。

正反察の遞択肢がありたす。デヌタをサむト間でシャヌディングし、1 ぀のサむトに察するリク゚ストが 1 ぀のシャヌドに送信されるず想像しおください。これで、クラスタヌは 1 秒あたり 1 䞇件のリク゚ストを凊理できるようになりたすが、1 ぀のシャヌドでは 1 ぀のリク゚ストの動䜜が遅すぎたす。スルヌプットの点で拡匵できなくなりたす。これがサむトavito.ruの堎合は特にそうです。 Avito が RuNet で最もアクセス数の倚いサむトの 1 ぀であるず蚀っおも、その秘密は明かしたせん。それを 1 ぀のシャヌドで凊理するのは狂気の沙汰でしょう。

したがっお、シャヌディング スキヌムはより巧劙な方法で蚭蚈されおいたす。クラスタヌ党䜓は、レむダヌず呌ばれるいく぀かのクラスタヌに分割されたす。各クラスタヌには、十数から数十のシャヌドが含たれおいたす。このようなクラスタヌは合蚈 39 個ありたす。

これはどのようにスケヌルされるのでしょうか?クラスタヌの数は倉化せず、数幎前は 39 でしたが、今もそのたたです。ただし、デヌタが蓄積されるに぀れお、それぞれのシャヌドの数が埐々に増加したす。党䜓的なシャヌディング スキヌムは次のようになりたす。これらのクラスタヌは Web サむトに分割されおおり、どの Web サむトがどのクラスタヌにあるかを理解するために、MySQL の別のメタベヌスが䜿甚されたす。 1 ぀のサむト - 1 ぀のクラスタヌ䞊。そしおその内郚では、蚪問者 ID に埓っおシャヌディングが発生したす。

蚘録する際は、蚪問者 ID の陀算の䜙りで陀算したす。ただし、新しいシャヌドを远加するず、シャヌディング スキヌムが倉曎され、分割は続行されたすが、陀算の䜙りは別の数倀で行われたす。これは、1 人の蚪問者がすでに耇数のサヌバヌに存圚しおいるこずを意味し、これを信頌するこずはできたせん。これは、デヌタの圧瞮率を高めるためだけに行われたす。そしお、リク゚ストを行うずきは、クラスタヌを調べお数十のサヌバヌにアクセスする分散テヌブルに移動したす。これはずおも愚かな蚈画です。

しかし、私たちがこの蚈画を攟棄したず蚀わなければ、私の話は䞍完党になりたす。新しいスキヌムでは、すべおを倉曎し、clickhouse-copier を䜿甚しおすべおのデヌタをコピヌしたした。

新しいスキヌムでは、すべおのサむトが倧芏暡ず小芏暡の 120 ぀のカテゎリに分類されたす。しきい倀がどのように遞択されたかはわかりたせんが、その結果、倧芏暡なサむトが 360 ぀のクラスタヌに蚘録され、それぞれ 120 ぀のレプリカを持぀ 120 個のシャヌド、぀たり XNUMX 台のサヌバヌが存圚したす。たた、シャヌディング スキヌムは、あらゆるリク゚ストが䞀床にすべおのシャヌドに送信されるように蚭蚈されおいたす。 Yandex.Metrica で avito.ru のレポヌト ペヌゞを開くず、リク゚ストは XNUMX 台のサヌバヌに送信されたす。 RuNet には倧芏暡なサむトがほずんどありたせん。そしお、リク゚ストは XNUMX 秒あたり XNUMX 件ではなく、XNUMX 件未満です。これらすべおは分散テヌブルによっお静かに凊理され、それぞれが XNUMX 台のサヌバヌで凊理されたす。

2 番目のクラスタヌは小芏暡サむト甚です。これはサむト ID に基づくシャヌディング スキヌムであり、各リク゚ストは 1 ぀のシャヌドにのみ送信されたす。

ClickHouse には、クリックハりス コピヌ ナヌティリティがありたす。圌女に぀いお教えおいただけたすか

この゜リュヌションはより煩雑で、生産性も倚少劣るずすぐに蚀いたす。利点は、指定したパタヌンに埓っおデヌタを完党に汚すこずです。ただし、このナヌティリティの欠点は、リシャヌドがたったく行われないこずです。あるクラスタヌ スキヌマから別のクラスタヌ スキヌマにデヌタをコピヌしたす。

これは、これが機胜するには 2 ぀のクラスタヌが必芁であるこずを意味したす。これらは同じサヌバヌ䞊に配眮できたすが、それでもデヌタは段階的に移動されず、コピヌされたす。

たずえば、以前は 4 台のサヌバヌがありたしたが、珟圚は 8 台になっおいたす。すべおのサヌバヌ䞊に新しい分散テヌブル、新しいロヌカル テヌブルを䜜成し、クリックハりス コピヌ機を起動しお、そこから読み取り、新しいシャヌディング スキヌムを受け入れ、そこにデヌタを転送する必芁がある䜜業スキヌムを指定したす。たた、叀いサヌバヌでは、叀いデヌタを残しおおく必芁があり、同じ叀いデヌタの半分がその䞊に到着するため、珟圚のサヌバヌの 1.5 倍のスペヌスが必芁になりたす。デヌタを再シャヌディングする必芁があり、スペヌスがあるず事前に考えられおいる堎合は、この方法が適しおいたす。

クリックハりスコピヌ機は内郚でどのように動䜜したすか?すべおの䜜業を、1 ぀のシャヌド䞊の 1 ぀のテヌブルの 1 ぀のパヌティションを凊理する䞀連のタスクに分割したす。これらすべおのタスクは䞊行しお実行でき、clickhouse-copier は耇数のむンスタンスの異なるマシン䞊で実行できたすが、1 ぀のパヌティションに察しお行うこずは挿入遞択にすぎたせん。デヌタは読み取られ、解凍され、再分割され、その埌再び圧瞮され、どこかに曞き蟌たれ、再゜ヌトされたす。これはより難しい決断です。

リシャヌディングず呌ばれるパむロット的なものがありたした。圌女はどうですか

2017 幎に、リシャヌディングず呌ばれるパむロット的なものがありたした。 ClickHouseにもオプションがありたす。私が理解しおいるように、それは離陞したせんでした。なぜこれが起こったのか教えおもらえたすかそれは非垞に関連性があるようです。

党䜓的な問題は、デヌタを適切な堎所に再シャヌディングする必芁がある堎合、これをアトミックに行うために非垞に耇雑な同期が必芁になるこずです。この同期がどのように機胜するかを調べ始めたずころ、根本的な問題があるこずが明らかになりたした。そしお、これらの基本的な問題は理論的なものであるだけでなく、非垞に簡単に説明できるものの圢ですぐに実際に珟れ始めたした-䜕も機胜したせん。

䜎速ディスクに移動する前に、すべおのデヌタを結合するこずはできたすか?

マヌゞのコンテキストにおける䜎速ディスクぞの移動オプションを䜿甚した TTL に぀いおの質問です。 cron 経由以倖に、䜎速ディスクに移動する前にすべおの郚分を 1 ぀にマヌゞする方法はありたすか?

質問に察する答えは、転送する前に、すべおの郚分を䜕らかの方法で自動的に 1 ぀に接着するこずは可胜である、ずいうこずです。「いいえ」です。これは必芁ないず思いたす。すべおの郚分を 1 ぀にマヌゞする必芁はありたせんが、䜎速ディスクに自動的に転送されるこずを期埅しおください。

転送ルヌルには 2 ぀の基準がありたす。 1枚目は詰めた状態です。珟圚のストレヌゞ局の空き領域が䞀定の割合未満の堎合、チャンクを 1 ぀遞択し、それを䜎速のストレヌゞに移動したす。ずいうか、遅いのではなく、蚭定どおりに次の速床になりたす。

2 番目の基準はサむズです。倧きな郚品を動かすこずです。高速ディスクの空き容量に応じおしきい倀を調敎でき、デヌタは自動的に転送されたす。

事前に互換性を確認する方法がない堎合、ClickHouse の新しいバヌゞョンに移行するにはどうすればよいですか?

この話題は定期的に議論されたす ClickHouse電報チャット内 さたざたなバヌゞョンを考慮しお、それでも。バヌゞョン 19.11 から 19.16 ぞのアップグレヌド、たずえば 19.16 から 20.3 ぞのアップグレヌドはどの皋床安党ですか。サンドボックスで互換性を事前に確認できない状態で新しいバヌゞョンに移行する最善の方法は䜕ですか?

ここにはいく぀かの「黄金の」ルヌルがありたす。初め - 倉曎履歎を読む。内容は倧きくなりたすが、䞋䜍互換性のない倉曎に぀いおは別の段萜に分かれおいたす。これらの点を危険信号ずしお扱わないでください。これらは通垞、䜿甚しない可胜性が高いいく぀かの゚ッゞ機胜に関係する軜埮な非互換性です。

次に、サンドボックスで互換性を確認する方法がなく、運甚環境ですぐに曎新したい堎合は、これを行う必芁はないずいう掚奚事項がありたす。たずサンドボックスを䜜成しおテストしたす。テスト環境がない堎合は、倧芏暡な䌚瀟ではない可胜性が高く、デヌタの䞀郚をラップトップにコピヌしお、すべおが正しく動䜜するこずを確認できたす。マシン䞊でロヌカルに耇数のレプリカを䜜成するこずもできたす。たたは、近くのどこかにある新しいバヌゞョンを入手しお、そこにデヌタの䞀郚をアップロヌドするこずもできたす。぀たり、即垭のテスト環境を䜜成したす。

もう 1 ぀のルヌルは、本番環境でのバグの発芋ずその埌のクむック修正のため、バヌゞョンのリリヌス埌 1 週間は曎新しないこずです。混乱しないように、ClickHouse のバヌゞョンの番号を理解したしょう。

バヌゞョン20.3.4がありたす。数字の 20 は補造幎 - 2020 を瀺したす。䞭身の芳点からは、これは重芁ではないため、泚意を払いたせん。次ぞ - 20.3。䜕らかの新機胜を備えたリリヌスをリリヌスするたびに、3 番目の数倀 (この堎合は 20.4) を増やしたす。 ClickHouse に䜕らかの機胜を远加したい堎合は、この数を増やす必芁がありたす。぀たり、バヌゞョン 20.3.4 では、ClickHouse の動䜜がさらに向䞊したす。 4 桁目は 4 です。ここで XNUMX は、新しい機胜は远加されたせんでしたが、いく぀かのバグが修正されたパッチ リリヌスの数です。そしお XNUMX はそれを XNUMX 回行ったこずを意味したす。

これが䜕かひどいこずだずは思わないでください。通垞、ナヌザヌは最新バヌゞョンをむンストヌルでき、幎間皌働時間に問題なく動䜜したす。しかし、䞭囜人の同志によっお远加されたビットマップを凊理するための関数で、間違った匕数を枡すずサヌバヌがクラッシュしたず想像しおください。私たちにはこれを解決する責任がありたす。新しいパッチ バヌゞョンがリリヌスされ、ClickHouse はより安定したす。

ClickHouse を運甚環境で実行しおいお、远加機胜を備えた ClickHouse の新しいバヌゞョンがリリヌスされた堎合 (たずえば、20.4.1 が最初のバヌゞョンです)、初日に急いで運甚環境に導入しないでください。そもそもなぜそれが必芁なのでしょうか ClickHouse をただ䜿甚しおいない堎合は、むンストヌルできたす。ほずんどの堎合、すべお問題なく動䜜したす。ただし、ClickHouse がすでに安定しお動䜜しおいる堎合は、パッチずアップデヌトに泚目しお、どのような問題が修正されおいるかを確認しおください。

キリル・シュノァコフ テスト環境に぀いお少し補足したいず思いたす。誰もがテスト環境を非垞に恐れおおり、非垞に倧芏暡な ClickHouse クラスタヌがある堎合、テスト環境は少なくずも 10 分の 1 より小さくなければならないず䜕らかの理由で信じおいたす。党然そんなこずないですよ。

私自身の䟋から蚀えたす。私にはプロゞェクトがあり、ClickHouse がありたす。私たちのテスト環境は圌専甚です。これは Hetzner にある 20 ナヌロの小さな仮想マシンで、ここにはすべおがデプロむされおいたす。これを行うために、Ansible では完党な自動化が行われおいるため、原則ずしお、ハヌドりェア サヌバヌに配眮するか、単に仮想マシンにデプロむするかなど、どこに配眮しおも違いはありたせん。

䜕ができるでしょうか ClickHouse のドキュメントで、自宅に小さなクラスタヌをデプロむする方法の䟋を提䟛するずよいでしょう。Docker や LXC で、おそらく Ansible プレむブックを䜜成したす。これは、人によっおデプロむメントが異なるためです。これにより倧幅に簡玠化されたす。 5 分でクラスタヌを取埗しおデプロむできるず、䜕かを理解するのがはるかに簡単になりたす。テストしおいない補品バヌゞョンに移行するのは終わりのない道であるため、これは非垞に䟿利です。うたくいくこずもあれば、うたくいかないこずもありたす。したがっお、成功を期埅するのは悪いこずです。

Maxim Kotyakov 氏、シニア バック゚ンド ゚ンゞニア Avito 氏: 倧䌁業が盎面する䞀連の課題のうち、テスト環境に぀いお少し補足したす。圓瀟には本栌的な ClickHouse アクセプタンス クラスタヌがあり、デヌタ スキヌムず蚭定に関しおは、運甚環境の正確なコピヌです。このクラスタヌは、最小限のリ゜ヌスを備えたかなり荒廃したコンテナヌにデプロむされたす。本番デヌタの䞀定の割合をそこに曞き蟌みたす。幞いなこずに、Kafka でストリヌムを耇補するこずが可胜です。そこにあるものはすべお同期され、スケヌルされたす。容量ずフロヌの䞡方の点で、理論的には、他のすべおの条件が等しい堎合、メトリクスの点で本番ず同様に動䜜するはずです。爆発の可胜性があるものはすべお、最初にこのスタンドに転がされ、準備が敎うたで数日間そこに攟眮されたす。しかし圓然のこずながら、この゜リュヌションは高䟡で難しく、サポヌト コストがれロではありたせん。

アレクセむ・ミロノィドフ: Yandex.Metrica の友人たちのテスト環境がどのようなものかを説明したす。 600 ぀のクラスタヌには 360 台のサヌバヌがあり、別のクラスタヌには XNUMX のサヌバヌがあり、さらに XNUMX 番目ずいく぀かのクラスタヌがありたす。そのうちの XNUMX ぀のテスト環境は、それぞれに XNUMX ぀のレプリカを持぀単玔な XNUMX ぀のシャヌドです。なぜ XNUMX ぀のシャヌドがあるのでしょうか?あなたが䞀人ではありたせんように。そしおレプリカもあるはずです。支払える最䜎限の金額だけです。

このテスト環境では、ク゚リが機胜しおいるかどうか、たた重倧な問題がないかどうかを確認できたす。しかし、すべおが機胜しおいるにもかかわらず、負荷に小さな倉化がある堎合、たったく異なる性質の問題が発生するこずがよくありたす。

䟋を挙げおみたしょう。 ClickHouse の新しいバヌゞョンをむンストヌルするこずにしたした。これはテスト環境に投皿されおおり、自動テストは Yandex.Metrica 自䜓で完了しおおり、叀いバヌゞョンず新しいバヌゞョンのデヌタを比范し、パむプラむン党䜓を実行したす。そしおもちろん、CI のグリヌン テストも行いたす。そうでなければ、このバヌゞョンを提案するこずさえなかったでしょう。

すべお順調。いよいよ本番に向けお動き始めたす。グラフの負荷が数倍に増加したずいうメッセヌゞが衚瀺されたす。バヌゞョンをロヌルバックしおいたす。グラフを芋るず、負荷は実際にロヌルアりト䞭に数回増加し、ロヌルアりト時に枛少しおいるこずがわかりたす。その埌、バヌゞョンのロヌルバックを開始したした。そしお負荷は同じように増加し、同じように枛少したした。結論は次のずおりです。レむアりトのせいで負荷が増加したしたが、驚くべきこずではありたせん。

その埌、同僚に新しいバヌゞョンをむンストヌルするよう説埗するのは困難でした。私は蚀いたす「倧䞈倫、出発しおください。頑匵っおください、すべおうたくいきたす。グラフの負荷が増加したしたが、すべお問題ありたせん。頑匵れ。"䞀般的に、これを実行しただけで、バヌゞョンは実皌働甚にリリヌスされたした。しかし、ほがすべおのレむアりトで同様の問題が発生したす。

Kill ク゚リはク゚リを匷制終了するこずになっおいたすが、そうではありたせん。なぜ

ある皮のアナリストであるナヌザヌが私のずころに来お、私の ClickHouse クラスタヌを配眮するリク゚ストを䜜成したした。リク゚ストが送信されたレプリカたたはシャヌドに応じお、䞀郚のノヌドたたはクラスタヌ党䜓。このサヌバヌ䞊のすべおの CPU リ゜ヌスがシェルフ内にあり、すべおが赀色になっおいるこずがわかりたす。同時に、ClickHouse 自䜓がリク゚ストに応答したす。そしお私はこう曞きたす、「プロセスリストを芋せおください、どのようなリク゚ストがこの狂気を匕き起こしたのかを教えおください。」

このリク゚ストを芋぀けお、それに kill を曞き蟌みたす。そしお、䜕も起こっおいないこずがわかりたす。私のサヌバヌは棚の䞭にあり、ClickHouse がいく぀かのコマンドを䞎え、サヌバヌが生きおいるこずを瀺し、すべおが順調です。しかし、すべおのナヌザヌリク゚ストで劣化があり、劣化はClickHouseのレコヌドから始たり、killク゚リは機胜したせん。なぜ kill ク゚リはク゚リを匷制終了するものだず思っおいたしたが、そうではありたせん。

さお、かなり奇劙な答えが埗られたす。重芁なのは、kill ク゚リではク゚リが kill されないずいうこずです。

Kill query では、「I want this query to be kill」ずいう小さなボックスにチェックを入れたす。そしお、リク゚スト自䜓は、各ブロックを凊理するずきにこのフラグを確認したす。蚭定されおいる堎合、リク゚ストは動䜜を停止したす。誰もリク゚ストを殺さないこずが刀明したした、圌自身がすべおをチェックしお停止する必芁がありたす。そしお、これは、リク゚ストがデヌタのブロックを凊理しおいる状態にあるすべおのケヌスで機胜するはずです。次のデヌタブロックを凊理し、フラグをチェックしお停止したす。

これは、リク゚ストが䞀郚の操䜜でブロックされおいる堎合には機胜したせん。確かに、おそらくこれはあなたのケヌスではありたせん。なぜなら、あなたによるず、倧量のサヌバヌリ゜ヌスを䜿甚するからです。倖郚゜ヌトやその他の詳现では、これが機胜しない可胜性がありたす。しかし、䞀般的にこれは起こるべきではなく、バグです。そしお、私がお勧めできる唯䞀のこずは、ClickHouseを曎新するこずです。

読み取り負荷時の応答時間を蚈算するにはどうすればよいですか?

アむテムの集合䜓 (さたざたなカりンタヌ) を栌玍するテヌブルがありたす。行数は玄1億行です。 1 個のアむテムに XNUMX 個の RPS を泚ぐ堎合、予枬可胜な応答時間を圓おにするこずは可胜ですか?

文脈から刀断するず、曞き蟌みには問題がないため、読み取り負荷に぀いお話しおいるこずがわかりたす。1,000 行、10 䞇行、堎合によっおは数癟䞇行を挿入するこずもできたす。

読曞リク゚ストは非垞に異なりたす。遞択 1 では、ClickHouse は 8192 秒あたり玄数䞇件のリク゚ストを実行できるため、64 ぀のキヌに察するリク゚ストでもすでにある皋床のリ゜ヌスが必芁になりたす。たた、このようなポむント ク゚リは、読み取りごずにむンデックスによっおデヌタ ブロックを読み取る必芁があるため、䞀郚のキヌず倀のデヌタベヌスよりも困難になりたす。私たちのむンデックスは各レコヌドではなく、各範囲に察応したす。぀たり、範囲党䜓を読み取る必芁がありたす。デフォルトでは 1 行です。たた、圧瞮されたデヌタ ブロックを XNUMX KB から XNUMX MB に解凍する必芁がありたす。通垞、このような察象を絞ったク゚リは完了するたでに数ミリ秒かかりたす。しかし、これが最も簡単なオプションです。

簡単な算術を詊しおみたしょう。数ミリ秒を 1000 で乗算するず、数秒になりたす。 XNUMX 秒あたり XNUMX のリク゚ストに察応するのは䞍可胜であるかのように芋えたすが、実際には、耇数のプロセッサ コアがあるため、それは可胜です。そのため、原則ずしお、ClickHouse は XNUMX RPS を保持できる堎合がありたすが、短いリク゚スト、特に察象を絞ったリク゚ストの堎合は可胜です。

単玔なリク゚ストの数に応じお ClickHouse クラスタヌを拡匵する必芁がある堎合は、レプリカの数を増やし、ランダムなレプリカにリク゚ストを送信するずいう最も単玔な方法をお勧めしたす。 1 ぀のレプリカが 1 秒あたり 500 のリク゚ストを保持する堎合、これは完党に珟実的ですが、3 ぀のレプリカは 15,000 件のリク゚ストを凊理するこずになりたす。

もちろん、ポむント読み取りの最倧数に合わせお ClickHouse を構成できる堎合もありたす。そのためには䜕が必芁なのでしょうか 64 ぀目は、むンデックスの粒床を䞋げるこずです。この堎合、むンデックス内の゚ントリ数がサヌバヌごずに数癟䞇たたは数千䞇になるこずを前提ずしお、XNUMX ぀に枛らす必芁はありたせん。テヌブルに XNUMX 億行がある堎合、粒床は XNUMX に蚭定できたす。

圧瞮されたブロックのサむズを小さくするこずができたす。これには蚭定がありたす 最小圧瞮ブロック サむズ, 最倧圧瞮ブロック サむズ。それらを削枛し、デヌタを補充するず、タヌゲットを絞ったク゚リが高速化されたす。ただし、ClickHouse はキヌず倀のデヌタベヌスではありたせん。倚数の小さなリク゚ストは負荷のアンチパタヌンです。

キリル・シュノァコフ 普通口座がある堎合のアドバむスをさせおいただきたす。これは、ClickHouse がある皮のカりンタヌを保存する堎合のかなり暙準的な状況です。私にはナヌザヌがいお、圌はどこの囜出身で、第䞉の分野の出身であり、䜕かを段階的に増やす必芁がありたす。 MySQL の堎合、䞀意のキヌを䜜成し (MySQL では重耇キヌ、PostgreSQL では競合)、プラス蚘号を远加したす。これはもっずうたくいきたす。

デヌタがあたりない堎合、ClickHouse を䜿甚する意味はあたりありたせん。通垞のデヌタベヌスがあり、これをうたく実行したす。

より倚くのデヌタをキャッシュに入れるには、ClickHouse で䜕を調敎できたすか?

状況を想像しおみたしょう - サヌバヌには 256 GB の RAM があり、ClickHouse は日垞的に玄 60  80 GB、ピヌク時には最倧 130 GB を䜿甚したす。より倚くのデヌタがキャッシュに保存されるように、䜕を有効にしお調敎できるか、それに応じお、ディスクぞのトリップが枛ったのでしょうか

通垞、オペレヌティング システムのペヌゞ キャッシュがこれに適切に察応したす。䞊郚を開いお、「キャッシュ枈み」たたは「空き」を確認するず、キャッシュされおいる量も衚瀺され、すべおの空きメモリがキャッシュに䜿甚されおいるこずがわかりたす。このデヌタを読み取るずきは、ディスクからではなく RAM から読み取られたす。同時に、圧瞮されたデヌタがキャッシュされるため、キャッシュが有効に掻甚されおいるずも蚀えたす。

ただし、いく぀かの単玔なク゚リをさらに高速化したい堎合は、ClickHouse 内の解凍されたデヌタのキャッシュを有効にするこずができたす。いわゆる 非圧瞮キャッシュ。 config.xml 構成ファむルで、非圧瞮キャッシュ サむズを必芁な倀に蚭定したす。残りはペヌゞ キャッシュに眮かれるため、空き RAM の半分以䞋にするこずをお勧めしたす。

さらに、芁求レベルの蚭定は 2 ぀ありたす。最初の蚭定 - 非圧瞮キャッシュを䜿甚する - その䜿甚を含みたす。すべおのデヌタを読み取っおキャッシュをフラッシュできる重いリク゚ストを陀く、すべおのリク゚ストに察しおこれを有効にするこずをお勧めしたす。 2 番目の蚭定は、キャッシュを䜿甚する最倧行数のようなものです。倧芏暡なク゚リがキャッシュをバむパスするように自動的に制限されたす。

RAM 内のストレヌゞ甚に storage_configuration を構成するにはどうすればよいですか?

新しい ClickHouse ドキュメントで、関連するセクションを読みたした。 デヌタストレヌゞ付き。説明には高速 SSD を䜿甚した䟋が含たれおいたす。

同じこずをボリュヌムホットメモリでどのように構成できるのか疑問に思いたす。そしおもう䞀぀質問です。 select はこのデヌタ構成でどのように機胜するのか、セット党䜓を読み取るのか、それずもディスク䞊の 1 ぀だけを読み取るのか、このデヌタはメモリ内で圧瞮されおいるのか、などです。そしお、prewhere セクションはそのようなデヌタ組織ずどのように連携するのでしょうか?

この蚭定はデヌタ チャンクのストレヌゞに圱響し、その圢匏はたったく倉曎されたせん。
詳しく芋おみたしょう。

RAM ぞのデヌタ ストレヌゞを構成できたす。ディスクに察しお構成されおいるのはそのパスだけです。ファむル システム内のパスにマりントされる tmpfs パヌティションを䜜成したす。このパスを最もホットなパヌティションのデヌタを保存するパスずしお指定するず、デヌタの䞀郚が到着し、そこに曞き蟌たれ始めたす。すべお問題ありたせん。

ただし、信頌性が䜎いため、これを行うこずはお勧めしたせん。ただし、異なるデヌタセンタヌに少なくずも 3 ぀のレプリカがある堎合は、可胜です。䜕かあった堎合でもデヌタは埩元されたす。サヌバヌが突然オフになり、再びオンになったず想像しおみたしょう。パヌティションが再床マりントされたしたが、そこには䜕もありたせんでした。 ClickHouse サヌバヌが起動するず、これらの芁玠が存圚しないこずがわかりたすが、ZooKeeper メタデヌタによれば、それらは存圚するはずです。圌は、どのレプリカがそれらを持っおいるかを調べ、それらを芁求し、ダりンロヌドしたす。このようにしおデヌタが埩元されたす。

この意味で、デヌタを RAM に保存するこずは、デヌタをディスクに保存するこずず基本的に倉わりたせん。デヌタがディスクに曞き蟌たれるずき、デヌタは最初にペヌゞ キャッシュに保存され、埌で物理的に曞き蟌たれるからです。これは、ファむル システムのマりント オプションによっお異なりたす。ただし、念のために蚀っおおきたすが、ClickHouse は挿入時に fsync を行いたせん。

この堎合、RAM 内のデヌタはディスク䞊のデヌタずたったく同じ圢匏で保存されたす。遞択ク゚リも同様に、読み蟌む必芁があるピヌスを遞択し、そのピヌスの䞭から必芁なデヌタ範囲を遞択しお読み蟌みたす。デヌタが RAM 䞊にあるかディスク䞊にあるかに関係なく、prewhere はたったく同じように機胜したす。

Low Cardinality は䞀意の倀の数たで有効ですか?

䜎カヌディナリティは巧劙に蚭蚈されおいたす。デヌタ ディクショナリをコンパむルしたすが、それらはロヌカルです。第䞀に、䜜品ごずに蟞曞が異なるこず、第二に、同じ䜜品の䞭でも範囲ごずに蟞曞が異なるこずです。䞀意の倀の数がしきい倀 (おそらく 100 侇) に達するず、その蟞曞は単に棚䞊げされ、新しい蟞曞が䜜成されたす。

答えは䞀般的に、ロヌカル範囲ごずに、たずえば毎日ごずに、最倧 100 䞇個の䞀意の倀があれば、カヌディナリティが䜎いこずが効果的です。その埌は単玔なフォヌルバックが行われ、1 ぀だけではなく、倚くの異なる蟞曞が䜿甚されたす。通垞の文字列列ずほが同じように動䜜したすが、効率は若干劣るかもしれたせんが、重倧なパフォヌマンスの䜎䞋はありたせん。

50 億行のテヌブルを党文怜玢するためのベスト プラクティスは䜕ですか?

さたざたな答えがありたす。 1 ぀目は、ClickHouse は党文怜玢゚ンゞンではないずいうこずです。これには特別なシステムがありたす。たずえば、 Elasticsearch О スフィンクス。しかし、Elasticsearch から ClickHouse に切り替えようずしおいる人を芋かけるこずが増えおいたす。

なぜこのようなこずが起こるのでしょうか?圌らは、Elasticsearch がむンデックスの構築を始めずしお、䞀郚のボリュヌムの負荷に察凊できなくなるずいう事実によっおこれを説明しおいたす。むンデックスは非垞に煩雑になるため、単玔にデヌタを ClickHouse に転送するず、容量の点で数倍効率的に保存されるこずがわかりたす。同時に、怜玢ク゚リは、圢態孊を考慮しおデヌタ党䜓から䜕らかのフレヌズを怜玢する必芁があるようなものではなく、たったく異なるものであるこずがよくありたした。たずえば、過去数時間のログ内でバむトの䞀郚を芋぀けたす。

この堎合、ClickHouse でむンデックスを䜜成したす。その最初のフィヌルドは日付ず時刻になりたす。たた、最倧のデヌタカットオフは日付範囲に基づきたす。遞択した日付範囲内では、原則ずしお、like を䜿甚したブルヌト フォヌス手法を䜿甚した堎合でも、党文怜玢を実行するこずがすでに可胜です。 ClickHouse の like 挔算子は、芋぀けられる䞭で最も効率的な like 挔算子です。もっず良いものを芋぀けたら、教えおください。

ただし、やはりフルスキャンず同じです。たた、フル スキャンは CPU だけでなくディスクでも遅くなる可胜性がありたす。突然 1 日あたり 1 テラバむトのデヌタが発生し、日䞭に単語を怜玢するず、そのテラバむトをスキャンする必芁がありたす。そしおそれはおそらく通垞のハヌドドラむブ䞊にあり、最終的には SSH 経由でこのサヌバヌにアクセスできないような方法でロヌドされるこずになりたす。

この堎合、もう 1 ぀小さなトリックを提䟛する準備ができおいたす。これは実隓的なもので、うたくいくかもしれないし、うたくいかないかもしれたせん。 ClickHouse には、トリグラム ブルヌム フィルタヌの圢匏で党文むンデックスがありたす。 Arenadata の同僚はすでにこれらのむンデックスを詊しおおり、倚くの堎合、意図したずおりに機胜したす。

これらを正しく䜿甚するには、トリグラム ブルヌム フィルタヌずは䜕か、そのサむズを遞択する方法など、フィルタヌがどのように機胜するかを正確に理解する必芁がありたす。これらは、デヌタ内でめったに芋぀からない、たれなフレヌズや郚分文字列に察するク゚リに圹立぀ず蚀えたす。この堎合、サブ範囲はむンデックスによっお遞択され、読み取られるデヌタは少なくなりたす。

最近、ClickHouse には党文怜玢のためのさらに高床な機胜が远加されたした。これは、たず、8 ぀のパスで䞀床に倚数の郚分文字列を怜玢したす。これには、倧文字ず小文字を区別するオプション、倧文字ず小文字を区別しないオプション、UTF-XNUMX たたは ASCII のみをサポヌトするオプションが含たれたす。必芁な最も効果的なものを遞択しおください。

1 パスで耇数の正芏衚珟を怜玢する機胜も登堎したした。 X を 1 ぀の郚分文字列のように曞いたり、X を別の郚分文字列のように曞く必芁はありたせん。すぐに曞くこずができ、すべおが可胜な限り効率的に行われたす。

3 番目に、正芏衚珟の近䌌怜玢ず郚分文字列の近䌌怜玢が行われるようになりたした。誰かが単語のスペルを間違えた堎合、最倧䞀臎する単語が怜玢されたす。

倚数のナヌザヌの ClickHouse ぞのアクセスを敎理する最善の方法は䜕ですか?

倚数の消費者やアナリストのアクセスを敎理する最適な方法を教えおください。キュヌを圢成し、最倧同時ク゚リの優先順䜍を付ける方法ず、どのようなツヌルを䜿甚するか?

クラスタヌが十分に倧きい堎合は、さらに 2 台のサヌバヌを構築するのが良い解決策です。これがアナリストの゚ントリ ポむントになりたす。぀たり、アナリストにクラスタヌ内の特定のシャヌドぞのアクセスを蚱可せず、デヌタのない空のサヌバヌを 2 ぀䜜成し、それらのサヌバヌにアクセス暩を構成するだけです。この堎合、分散リク゚ストのナヌザヌ蚭定はリモヌト サヌバヌに転送されたす。぀たり、これら 2 ぀のサヌバヌ䞊ですべおを構成し、その蚭定はクラスタヌ党䜓に圱響したす。

原則ずしお、これらのサヌバヌにはデヌタはありたせんが、リク゚ストを実行するにはサヌバヌ䞊の RAM の量が非垞に重芁です。倖郚集玄たたは倖郚䞊べ替えが有効になっおいる堎合、ディスクは䞀時デヌタにも䜿甚できたす。

考えられるすべおの制限に関連する蚭定を確認するこずが重芁です。ここで、アナリストずしお Yandex.Metrica クラスタヌにアクセスし、リク゚ストを尋ねるずしたす。 ヒット数からカりントを遞択, その埌、すぐにリク゚ストを実行できないずいう䟋倖が䞎えられたす。スキャンできる最倧行数は 1,000 億行で、クラスタヌ䞊の 1 ぀のテヌブルには合蚈 50 兆行がありたす。これが最初の制限です。

行制限を削陀しおク゚リを再床実行するずしたす。次に、次の䟋倖が衚瀺されたす - 蚭定が有効になっおいたす 日付によるむンデックスを匷制する。日付範囲を指定しないずク゚リを完了できたせん。アナリストに頌っお手動で指定する必芁はありたせん。兞型的なケヌスは、むベントの日付が週の間に曞かれる日付範囲です。そしお、単に間違った堎所に括匧を指定しただけで、and の代わりに or - or URL が䞀臎するこずが刀明したした。制限がない堎合、URL 列がクロヌルされ、倧量のリ゜ヌスが無駄になるだけです。

さらに、ClickHouse には 2 ぀の優先順䜍蚭定がありたす。残念ながら、それらは非垞に原始的です。 1぀は単に呌ばれたす 優先順䜍。優先床 ≠ 0 で、䜕らかの優先床を持぀リク゚ストが実行されおいるが、優先床の倀がそれより小さい、぀たり優先床が高いリク゚ストが実行されおいる堎合、優先床の倀がそれより倧きい、぀たり優先床が䜎いリク゚ストが実行されたす。は単に䞀時停止されおいるだけで、この間はたったく機胜したせん。

これは非垞に倧たかな蚭定であり、クラスタヌに䞀定の負荷がかかる堎合には適しおいたせん。ただし、重芁な短くおバヌスト的なリク゚ストがあり、クラスタヌがほずんどアむドル状態である堎合には、この蚭定が適しおいたす。

次の優先順䜍の蚭定が呌び出されたす。 OSスレッドの優先順䜍。 Linux スケゞュヌラのすべおのリク゚スト実行スレッドに nice 倀を蚭定するだけです。たあたあの動䜜ですが、それでも動䜜したす。 nice の最小倀を蚭定し (倀が最倧であるため、優先床が最も䜎くなりたす)、優先床の高いリク゚ストに -19 を蚭定するず、CPU が消費する優先床の䜎いリク゚ストは、優先床の高いリク゚ストの玄 XNUMX 分の XNUMX になりたす。

最倧リク゚スト実行時間 (たずえば 5 分) を構成する必芁もありたす。最も優れおいるのは、ク゚リ実行の最䜎速床です。この蚭定は長い間存圚しおおり、ClickHouse の速床が䜎䞋しないこずを保蚌するだけでなく、匷制的に蚭定する必芁がありたす。

想像しおみおください。䞀郚のク゚リの凊理が 1 秒あたり 100 䞇行未満である堎合、それは実行できたせん。これは私たちの良い名前、良いデヌタベヌスに恥をかかせるこずになりたす。これだけは犁止したしょう。実際には 2 ぀の蚭定がありたす。䞀人は呌ばれたす 最小実行速床 - 1 秒あたりの行数で、最小実行速床をチェックする前の秒はタむムアりトず呌ばれたす (デフォルトでは 15 秒)。぀たり、15 秒は可胜ですが、それが遅い堎合は、䟋倖をスロヌしおリク゚ストを䞭止したす。

クォヌタを蚭定する必芁もありたす。 ClickHouse には、リ゜ヌス消費をカりントするクォヌタ機胜が組み蟌たれおいたす。ただし、残念ながら、CPU やディスクなどのハヌドりェア リ゜ヌスではなく、論理リ゜ヌス、぀たり凊理されたリク゚ストの数、読み取られた行数、バむト数が察象ずなりたす。たた、たずえば、5 分以内に最倧 100 件のリク゚スト、1 時間あたり最倧 1000 件のリク゚ストを構成できたす。

どうしおそれが重芁ですか䞀郚の分析ク゚リは ClickHouse クラむアントから盎接手動で実行されるためです。そしおすべおがうたくいくでしょう。しかし、瀟内に高床なアナリストがいる堎合は、圌らがスクリプトを䜜成するため、そのスクリプトに゚ラヌが発生する可胜性がありたす。この゚ラヌにより、リク゚ストは無限ルヌプで実行されたす。これは私たちが身を守る必芁があるものです。

1 ぀のク゚リの結果を 10 人のクラむアントに提䟛するこずは可胜ですか?

非垞に倧きなリク゚ストを同時に送信したいナヌザヌが䜕人かいたす。リク゚ストは倧きく、原則ずしお迅速に実行されたすが、そのようなリク゚ストが同時に倚数あるため、非垞に苊痛になりたす。 10回連続で届いた同じリク゚ストを1回だけ実行し、10人のクラむアントに結果を䞎えるこずは可胜でしょうか?

問題は、キャッシュの結果や䞭間デヌタのキャッシュがないこずです。オペレヌティング システムにはペヌゞ キャッシュがあり、ディスクからデヌタを再床読み取るこずはできたせんが、残念なこずに、デヌタは匕き続き解凍、逆シリアル化、および再凊理されたす。

䞭間デヌタをキャッシュするか、同様のク゚リをある皮のキュヌに䞊べお結果キャッシュを远加するこずで、これをなんずか回避したいず考えおいたす。珟圚、リク゚スト キャッシュを远加する開発䞭のプル リク゚ストが 1 ぀ありたすが、これは in セクションず join セクションのサブク゚リのみを察象ずしおいたす。぀たり、゜リュヌションは䞍完党です。

しかし、私たちもそのような状況に盎面しおいたす。特に暙準的な䟋は、ペヌゞ分割されたク゚リです。報告曞があり、数ペヌゞあり、制限 10 の芁求がありたす。それから同じこずですが、制限 10,10 です。それからたた次のペヌゞ。そしお問題は、なぜ毎回これだけのこずを数えるのかずいうこずです。しかし、今のずころ解決策はなく、回避する方法もありたせん。

ClickHouse の隣にサむドカヌずしお配眮される代替゜リュヌションがありたす - クリックハりスプロキシ.

キリル・シュノァコフ ClickHouse プロキシには、組み蟌みのレヌト リミッタヌず組み蟌みの結果キャッシュがありたす。同様の問題が解決されおいたため、そこで倚くの蚭定が行われたした。プロキシを䜿甚するず、リク゚ストをキュヌに入れるこずでリク゚ストを制限したり、リク゚スト キャッシュの存続期間を構成したりできたす。リク゚ストが本圓に同じである堎合、プロキシはリク゚ストを䜕床も送信したすが、ClickHouse に送信されるのは 1 回だけです。

Nginx には無料版でもキャッシュがあり、これも機胜したす。 Nginx には、リク゚ストが同時に到着した堎合、リク゚ストが完了するたで他のリク゚ストの速床が䜎䞋するずいう蚭定もありたす。ただし、ClickHouse Proxy ではセットアップがはるかに適切に行われたす。 ClickHouse 専甚に、特にこれらの芁求に合わせお䜜成されたため、より適しおいたす。たあ、取り付けは簡​​単です。

非同期操䜜やマテリアラむズド ビュヌに぀いおはどうですか?

再生゚ンゞンの操䜜が非同期であるずいう問題がありたす。最初にデヌタが曞き蟌たれ、その埌デヌタが厩壊したす。いく぀かの集合䜓を含む実䜓化されたタブレットがサむンの䞋に存圚する堎合、重耇がそれに曞き蟌たれたす。たた、耇雑なロゞックがない堎合、デヌタは耇補されたす。それに぀いお䜕ができるでしょうか

明らかな解決策はありたす。それは、非同期折りたたみ操䜜䞭に特定のクラスの matview にトリガヌを実装するこずです。特効薬や同様の機胜を実装する蚈画はありたすか?

重耇排陀がどのように機胜するかを理解するこずは䟡倀がありたす。これからお話しするこずは質問ずは関係ありたせんが、念のため芚えおおいおください。

レプリケヌトされたテヌブルに挿入する堎合、挿入されたブロック党䜓の重耇排陀が行われたす。同じ行の同じ数を含む同じブロックを同じ順序で再挿入するず、デヌタは重耇排陀されたす。挿入するず「OK」ず衚瀺されたすが、実際には1パケット分のデヌタが曞き蟌たれるだけであり、重耇するこずはありたせん。

これは確実性を埗るために必芁です。挿入䞭に「OK」が衚瀺された堎合、デヌタは挿入されおいたす。 ClickHouse から゚ラヌを受け取った堎合は、挿入されなかったこずを意味するため、挿入を繰り返す必芁がありたす。ただし、挿入䞭に接続が切断された堎合は、デヌタが挿入されたかどうかがわかりたせん。唯䞀のオプションは、挿入を再床繰り返すこずです。デヌタが実際に挿入され、それを再挿入した堎合、ブロック重耇排陀が行われたす。これは重耇を避けるために必芁です。

たた、マテリアラむズド ビュヌがどのように機胜するかも重芁です。デヌタがメむンテヌブルに挿入されるずきに重耇排陀された堎合、デヌタはマテリアラむズドビュヌにも入りたせん。

さお、質問に぀いおです。個々の行を重耇しお蚘録しおいるため、状況はさらに耇雑になりたす。぀たり、耇補されるのはパック党䜓ではなく、特定の行であり、それらはバックグラりンドで折りたたたれたす。実際、デヌタはメむンテヌブルで折りたたたれたすが、折りたたたれおいないデヌタはマテリアラむズドビュヌに移動し、マヌゞ䞭にマテリアラむズドビュヌには䜕も起こりたせん。マテリアラむズド ビュヌは挿入トリガヌにすぎないからです。他の操䜜䞭は、それ以䞊䜕も起こりたせん。

そしお、私はここであなたを幞せにするこずはできたせん。この堎合に必芁なのは、具䜓的な解決策を探すこずだけです。たずえば、マテリアラむズド ビュヌで再生するこずは可胜ですか。たた、重耇排陀方法も同様に機胜する可胜性がありたす。しかし残念ながら、垞にそうずは限りたせん。集玄しおいる堎合は機胜したせん。

キリル・シュノァコフ 昔は束葉杖の工事もありたした。広告のむンプレッションが存圚するずいう問題があり、リアルタむムで衚瀺できるデヌタがいく぀かありたすが、これらは単なるむンプレッションです。これらが重耇するこずはめったにありたせんが、重耇した堎合はいずれにしおも埌で折りたたむこずになりたす。そしお、クリックやこのストヌリヌ党䜓など、再珟できないものもありたした。しかし、すぐにでも芋せたいずも思いたした。

マテリアラむズド ビュヌはどのように䜜成されたしたか?盎接曞き蟌たれたビュヌもありたした。生デヌタに曞き蟌たれたり、ビュヌに曞き蟌たれたりしたした。そこでは、ある時点でデヌタがあたり正しくなくなったり、重耇したりするこずがありたす。テヌブルの 2 番目の郚分では、マテリアラむズド ビュヌずたったく同じように芋えたす。぀たり、構造が完党に同䞀です。時々、デヌタを再蚈算し、重耇のないデヌタをカりントし、それらのテヌブルに曞き蟌みたす。

API を䜿甚したした。これは ClickHouse では手動では機胜したせん。そしお、API は次のようになりたす。テヌブルに最埌に远加した日付を取埗するず、正しいデヌタがすでに蚈算されおいるこずが保蚌され、あるテヌブルず別のテヌブルにリク゚ストが䜜成されたす。リク゚ストは䞀方から䞀定の時間を遞択し、もう䞀方からはただ蚈算されおいない時間を取埗したす。それは機胜したすが、ClickHouse だけでは機胜したせん。

アナリスト甚、ナヌザヌ甚など、䜕らかの API がある堎合、原則ずしお、これはオプションです。あなたは垞に数えおいたす、垞に数えおいたす。これは、1 日に 1 回たたは別の時間に実行できたす。必芁のない、重芁ではない範囲を自分で遞択したす。

ClickHouseにはたくさんのログがありたす。サヌバヌで起こっおいるこずをすべお䞀目で確認するにはどうすればよいですか?

ClickHouse には非垞に倚数のさたざたなログがあり、その数は増え続けおいたす。新しいバヌゞョンでは、䞀郚の機胜はデフォルトで有効になっおいたすが、叀いバヌゞョンでは、曎新時に有効にする必芁がありたす。しかし、その数はたすたす増えおいたす。最終的には、サヌバヌで珟圚䜕が起こっおいるかを、おそらく䜕らかの抂芁ダッシュボヌドで確認したいず考えおいたす。

これらのログを完成品ずしお衚瀺する既補のダッシュボヌドの機胜をサポヌトしおいる ClickHouse チヌムたたは友人のチヌムはありたすか?結局のずころ、ClickHouse でログを芋るだけでも十分です。しかし、それがすでにダッシュボヌドの圢で準備されおいれば、非垞にクヌルになるでしょう。私はそれからキックを受けるでしょう。

ダッシュボヌドはありたすが、暙準化されおいたせん。圓瀟では、玄 60 チヌムが ClickHouse を䜿甚しおいたすが、最も䞍思議なのは、その倚くが自分甚に䜜成したダッシュボヌドず、少し異なるダッシュボヌドを持っおいるこずです。䞀郚のチヌムは、内郚の Yandex.Cloud むンストヌルを䜿甚しおいたす。必芁なものがすべおではありたせんが、既補のレポヌトがいく぀かありたす。他の人は独自のものを持っおいたす。

Metrica の同僚は Grafana に独自のダッシュボヌドを持っおおり、私も圌らのクラスタヌ甚に独自のダッシュボヌドを持っおいたす。セリフキャッシュのキャッシュヒットなどを調べおいたす。そしおさらに難しいのは、䜿甚するツヌルが異なるこずです。私は Graphite-web ずいう非垞に叀いツヌルを䜿甚しおダッシュボヌドを䜜成したした。圌は完党に醜いです。私は今でもこの方法で䜿っおいたすが、おそらく Grafana の方が䟿利で矎しいでしょう。

ダッシュボヌドの基本的なものは同じです。これらはクラスタヌのシステム メトリックです: CPU、メモリ、ディスク、ネットワヌク。その他 - 同時リク゚スト数、同時マヌゞ数、1 秒あたりのリク゚スト数、MergeTree テヌブル パヌティションの最倧チャンク数、レプリケヌション ラグ、レプリケヌション キュヌ サむズ、1 秒あたりの挿入行数、1 秒あたりの挿入ブロック数。ログからではなくメトリクスから取埗できるのはこれだけです。

りラゞミヌル・コロバ゚フ: アレクセむ、少し蚂正したいず思いたす。グラファナがいる。 Grafana には ClickHouse ずいうデヌタ゜ヌスがありたす。぀たり、Grafana から ClickHouse に盎接リク゚ストを行うこずができたす。 ClickHouse にはログを含むテヌブルがあり、それは誰にずっおも同じです。その結果、Grafana でこのログ テヌブルにアクセスしお、サヌバヌが行うリク゚ストを確認したいず考えおいたす。こんなダッシュボヌドがあれば最高ですね。

自分で自転車に乗りたした。しかし、質問がありたす。すべおが暙準化されおいお、Grafana が誰もが䜿甚しおいるのであれば、なぜ Yandex にはそのような公匏ダッシュボヌドがないのでしょうか?

キリル・シュノァコフ 実際、ClickHouse に送られるデヌタ゜ヌスは Altinity をサポヌトするようになりたした。そしお、どこを掘り、誰をプッシュするかのベクトルを䞎えたいだけです。 Yandex はただ ClickHouse を䜜っおおり、それにた぀わる話は知らないので、圌らに尋ねるこずができたす。 Altinity は珟圚 ClickHouse を掚進しおいる䞻芁䌁業です。圌らは圌を芋捚おるこずはなく、圌をサポヌトしたす。原則ずしお、ダッシュボヌドを Grafana Web サむトにアップロヌドするには、登録しおアップロヌドするだけで枈み、特別な問題はありたせん。

アレクセむ・ミロノィドフ: 過去 1 幎間にわたり、ClickHouse には倚くのク゚リ プロファむリング機胜が远加されたした。リ゜ヌス䜿甚量に関する各リク゚ストのメトリクスがありたす。そしお぀い最近、ミリ秒ごずにク゚リがどこに費やしおいるかを確認するために、さらに䞋䜍レベルのク゚リ プロファむラヌを远加したした。しかし、この機胜を䜿甚するには、コン゜ヌル クラむアントを開いおリク゚ストを入力する必芁がありたすが、それをい぀も忘れおしたいたす。どこかに保存したのですが、正確な堎所を忘れおしたいたす。

「ここに重いク゚リがあり、ク゚リ クラスごずにグルヌプ化されおいたす」ずいうツヌルがあればいいのにず思いたす。䞀぀抌しおみるず、だから重いのだず蚀われたした。珟圚そのような解決策はありたせん。そしお、本圓に䞍思議なのは、人々が私に「教えおください、Grafana 甚の既補のダッシュボヌドはありたすか?」ず尋ねたずき、私がこう蚀うのです。「Grafana の Web サむトにアクセスするず、「ダッシュボヌド」コミュニティがあり、ダッシュボヌドがありたす。 Dimka からは、Kostyan からのダッシュボヌドがありたす。自分で䜿ったこずがないので、䜕なのか分かりたせん。」

サヌバヌが OOM にクラッシュしないようにマヌゞに圱響を䞎えるにはどうすればよいですか?

テヌブルがありたす。テヌブルにはパヌティションが 1 ぀だけあり、それは ReplacingMergeTree です。 4幎間デヌタを曞き蟌み続けおいたす。それに倉曎を加え、䞀郚のデヌタを削陀する必芁がありたした。

これを実行したずころ、このリク゚ストの凊理䞭にクラスタヌ内のすべおのサヌバヌ䞊のすべおのメモリが消費され、クラスタヌ内のすべおのサヌバヌが OOM 状態になりたした。その埌、党員が䞀緒に立ち䞊がっお、同じ操䜜、このデヌタ ブロックのマヌゞを開始し、再び OOM に陥りたした。それから圌らは再び起き䞊がりたしたが、たた倒れたした。そしおこの事は止たらなかった。

その埌、これは実際にはバグであり、圌らが修正したこずが刀明したした。ずおも玠敵ですね、ありがずうございたす。しかし残留物が残った。さお、テヌブル内で䜕らかのマヌゞを行うこずを考えるず、疑問が生じたす。なぜこれらのマヌゞに䜕らかの圱響を䞎えるこずができないのでしょうか?たずえば、必芁な RAM の量によっお、たたは原則ずしお、この特定のテヌブルを凊理する量によっお制限したす。

「Metrics」ずいうテヌブルがあるので、2 ぀のスレッドで凊理しおください。 10 個たたは 5 個のマヌゞを䞊行しお䜜成する必芁はなく、2 回に分けお実行したす。メモリは2個分はあるず思いたすが、10個凊理するには足りないかもしれたせん。なぜ恐怖が残るのでしょうかなぜなら、テヌブルは成長し続けおおり、い぀か、原理的にはバグによるものではなく、デヌタが倧量に倉曎されるため、テヌブル䞊の十分なメモリが䞍足するずいう状況に盎面するこずになるからです。サヌバ。そしお、マヌゞ時にサヌバヌが OOM にクラッシュしたす。しかも倉異は解陀できるのですが、メルゞがもういたせん。

ご存知のずおり、マヌゞ時に RAM の量は 1 ぀の狭い範囲のデヌタにのみ䜿甚されるため、サヌバヌは OOM に陥りたせん。したがっお、デヌタ量に関係なく、すべおがうたくいきたす。

りラゞミヌル・コロバ゚フ: 倧䞈倫。ここで、バグが修正された埌、自分甚に新しいバヌゞョンをダりンロヌドし、倚くのパヌティションがある別の小さなテヌブルで同様の操䜜を実行したした。たた、マヌゞ䞭にサヌバヌ䞊で玄 100 GB の RAM が消費されたした。 150 個が占有され、100 個が食べられ、50 GB のりィンドりが残っおいたため、OOM には陥りたせんでした。

実際に 100 GB の RAM を消費した堎合に OOM に陥るのを防ぐには、珟圚䜕が必芁ですか?マヌゞ䞊の RAM が突然足りなくなった堎合はどうすればよいでしょうか?

アレクセむ・ミロノィドフ: マヌゞ専甚のRAMの消費量が制限されおいないずいう問題がある。 2 番目の問題は、䜕らかのマヌゞが割り圓おられおいる堎合、それがレプリケヌション ログに蚘録されるため、それを実行する必芁があるこずです。レプリケヌション ログは、レプリカを䞀貫した状態にするために必芁なアクションです。このレプリケヌション ログをロヌルバックする手動操䜜を行わない堎合は、䜕らかの方法でマヌゞを実行する必芁がありたす。

もちろん、「䞇が䞀に備えお」OOM から保護するために RAM 制限を蚭けおおくこずは䞍必芁ではありたせん。これではマヌゞの完了には圹立ちたせん。マヌゞは再び開始され、䜕らかのしきい倀に達し、䟋倖がスロヌされ、その埌再び開始されたす。これでは䜕も良いこずはありたせん。しかし、原則ずしお、この制限を導入するこずは有益です。

ClickHouse 甚の Golang ドラむバヌはどのように開発されたすか?

Kirill Shvakov によっお䜜成された Golang ドラむバヌは、珟圚 ClickHouse チヌムによっお正匏にサポヌトされおいたす。圌 ClickHouse リポゞトリ内、圌は今倧きくお本物です。

ちょっずしたメモ。無限の秩序の通垞の圢匏を収めた玠晎らしい、愛されおいるリポゞトリがありたす - これが Vertica です。たた、Vertica 開発者によっおサポヌトされおいる独自の公匏 Python ドラむバヌもありたす。たた、ストレヌゞのバヌゞョンずドラむバヌのバヌゞョンが倧幅に異なり、ある時点でドラむバヌが動䜜しなくなるこずが䜕床かありたした。そしお2点目。この公匏ドラむバヌのサポヌトは、「ニップル」システムによっお実行されおいるように思えたす。問題を曞き蟌むず、氞久にハングアップしたす。

質問が2぀ありたす。珟圚、Kirill の Golang ドラむバヌは、Golang から ClickHouse ず通信するためのほがデフォルトの方法です。 http むンタヌフェヌスが奜きで今でも http むンタヌフェヌス経由で通信しおいる人は別ですが。このドラむバヌの開発はどのように進められるのでしょうかリポゞトリ自䜓の重倧な倉曎ず同期されたすか?たた、問題を怜蚎する手順は䜕ですか?

キリル・シュノァコフ 1 ぀目は、すべおが官僚的にどのように組織されおいるかずいうこずです。この点に぀いおは議論されおいないので、お答えするこずはありたせん。

この問題に関する質問に答えるには、ドラむバヌのちょっずした履歎が必芁です。私は倧量のデヌタを扱う䌚瀟で働いおいたした。それは、どこかに保存する必芁がある膚倧な数のむベントを含む広告スピナヌでした。そしおある時点でClickHouseが登堎したした。デヌタを入力したずころ、最初はすべお問題ありたせんでしたが、その埌 ClickHouse がクラッシュしたした。その瞬間、私たちはそれが必芁ないず刀断したした。

1 幎埌、私たちは ClickHouse を䜿甚するずいう考えに戻り、䜕らかの方法でそこにデヌタを曞き蟌む必芁がありたした。導入メッセヌゞは次のずおりでした。ハヌドりェアは非垞に匱く、リ゜ヌスはほずんどありたせん。しかし、私たちは垞にこの方法で䜜業しおきたため、ネむティブ プロトコルに泚目したした。

私たちは Go で䜜業しおいたので、Go ドラむバヌが必芁であるこずは明らかでした。私はほがフルタむムでそれを行いたした - それは私の仕事でした。私たちはそれをある時点たで持っおきたしたが、原理的には私たち以倖の誰かがそれを䜿甚するこずを誰も想定しおいたせんでした。その埌、CloudFlare もたったく同じ問題を抱えおいたしたが、圌らは同じタスクを抱えおいたため、しばらくの間は非垞にスムヌズに連携できたした。さらに、これを ClickHouse 自身ずドラむバヌの䞡方で実行したした。

ClickHouse ず仕事に関する私の掻動が少し倉わったため、ある時点でそれをやめたした。したがっお、問題は解決されおいたせん。定期的に、自分で䜕かを必芁ずする人がリポゞトリにコミットしたす。その埌、プル リク゚ストを確認し、堎合によっおは自分で線集するこずもありたすが、これはめったに起こりたせん。

ドラむバヌに戻りたいです。数幎前、このすべおが始たったずき、ClickHouse も異なっおおり、異なる機胜を備えおいたした。これで、ドラむバヌが適切に動䜜するようにドラむバヌを再䜜成する方法がわかりたした。そうなるず、蓄積された束葉杖のせいで、バヌゞョン 2 はいずれにしおも互換性がなくなりたす。

この問題をどう敎理しおよいかわかりたせん。私自身にはあたり時間がありたせん。もしドラむバヌを終えた人がいたら、私は圌らを助け、䜕をすべきかを教えるこずができたす。しかし、プロゞェクトの開発におけるYandexの積極的な参加に぀いおはただ議論されおいたせん。

アレクセむ・ミロノィドフ: 実際、これらのドラむバヌに関する官僚制床はただありたせん。唯䞀のこずは、ドラむバヌが公匏組織に提出されおいるずいうこずです。぀たり、このドラむバヌは Go の公匏のデフォルト ゜リュヌションずしお認識されおいたす。他にもいく぀かのドラむバヌがありたすが、それらは個別に提䟛されたす。

これらのドラむバヌを瀟内で開発するこずはありたせん。問題は、この特定のドラむバヌのためではなく、地域のすべおのドラむバヌの育成のために個人を雇甚できるかどうか、それずも倖郚から誰かを芋぀けるこずができるかずいうこずです。

Lazy_load 蚭定を有効にしお再起動するず、倖郚蟞曞がロヌドされたせん。䜕をするか

Lazy_load 蚭定が有効になっおおり、サヌバヌが再起動された埌、蟞曞は自動的にロヌドされたせん。ナヌザヌがこの蟞曞にアクセスした埌にのみ発生したす。そしお、初めおアクセスするず゚ラヌが発生したす。 ClickHouse を䜿甚しお䜕らかの方法で蟞曞を自動的にロヌドするこずは可胜ですか、それずもナヌザヌが゚ラヌを受信しないように蟞曞の準備状況を垞に自分で制埡する必芁がありたすか?

おそらく、ClickHouse のバヌゞョンが叀いため、蟞曞が自動的に読み蟌たれたせんでした。こんなこずもあり埗るでしょうか

たず、ク゚リを䜿甚しお蟞曞を匷制的にロヌドできたす。 システムリロヌド蟞曞。次に、゚ラヌに関しおですが、蟞曞がすでにロヌドされおいる堎合、ク゚リはロヌドされたデヌタに基づいお機胜したす。蟞曞がただロヌドされおいない堎合は、リク゚スト䞭に盎接ロヌドされたす。

これは重い蟞曞にはあたり䟿利ではありたせん。たずえば、MySQL から 100 䞇行を取埗する必芁がありたす。誰かが単玔な遞択を行いたすが、この遞択は同じ 100 䞇行を埅機したす。ここには 2 ぀の解決策がありたす。 1 ぀目は、lazy_load をオフにするこずです。次に、サヌバヌが起動したら、サヌバヌに負荷をかける前に、次のこずを行いたす。 システムリロヌド蟞曞 たたは、蟞曞を䜿甚するク゚リを実行するだけです。するず蟞曞が読み蟌たれたす。 ClickHouse は蟞曞を自動的にロヌドしないため、lazy_load 蚭定を有効にしお蟞曞の可甚性を制埡する必芁がありたす。

最埌の質問に察する答えは、バヌゞョンが叀いか、デバッグが必芁かのどちらかです。

少なくずも 1 ぀の蟞曞が゚ラヌでクラッシュした堎合、システムのリロヌド蟞曞がどれも読み蟌たないずいう事実をどうすればよいでしょうか?

システムのリロヌド蟞曞に぀いおは別の質問がありたす。 2 ぀の蟞曞がありたす。1 ぀はロヌドされおおらず、2 ぀目はロヌドされおいたす。この堎合、システム リロヌド蟞曞は蟞曞をロヌドしないため、システム リロヌド蟞曞を䜿甚しお名前によっお特定の蟞曞をポむントバむポむントでロヌドする必芁がありたす。これもClickHouseのバヌゞョンに関係するのでしょうか

あなたを幞せにしたいです。この行動は倉わり぀぀ありたした。これは、ClickHouse を曎新するず、それも倉曎されるこずを意味したす。珟圚の自分の行動に満足しおいない堎合 システムリロヌド蟞曞、アップデヌトしお、良い方向に倉わるこずを祈りたしょう。

ClickHouse 構成で詳现を構成するが、゚ラヌが発生した堎合には衚瀺しない方法はありたすか?

次の質問は、蟞曞に関する゚ラヌ、぀たり詳现に぀いおです。蟞曞の ClickHouse 構成で接続の詳现を指定したした。゚ラヌがある堎合は、応答ずしおこれらの詳现ずパスワヌドを受け取りたす。

ODBC ドラむバヌ蚭定に詳现を远加するこずで、この゚ラヌを解決したした。 ClickHouse 構成で詳现を構成し、゚ラヌが発生した堎合にこれらの詳现を衚瀺しない方法はありたすか?

ここでの実際の解決策は、odbc.ini でこれらの資栌情報を指定し、ClickHouse 自䜓では ODBC デヌタ ゜ヌス名のみを指定するこずです。他のディクショナリ ゜ヌスではこれは起こりたせん。MySQL のディクショナリでも、その他のディクショナリでも、゚ラヌ メッセヌゞを受け取ったずきにパスワヌドが衚瀺されるはずはありたせん。 ODBC に぀いおも調べたす。存圚する堎合は削陀するだけです。

ボヌナス: 集䌚からの Zoom の背景

画像をクリックするず、熱心な読者のために集䌚のボヌナス背景が開きたす。私たちは Avito テクノロゞヌのマスコットたちず䞀緒に火を消し、システム管理者宀や昔ながらのコンピュヌタヌクラブの同僚ず話し合い、萜曞きを背景に橋の䞋で毎日ミヌティングを行っおいたす。

䞊玚ナヌザヌ向けの質問ず回答の ClickHouse

出所 habr.com

コメントを远加したす