Alexander ZaitsevがYandex ClickHouseへの移行に関する質問に答えます。 これは、 Highload ++ 2016レポートのトランスクリプトです 。
みなさんこんにちは！ カンファレンスのこの2日間で、2時間のmitapが2回ありましたが、今日ではClickHouseによるほぼ3時間のmitapでさえありました。 その後、ビクターとアレクセイは素晴らしい報告をしました。これ以上何も言えないようです。 これは実際にはそうではありません。
既に何かがある場合は、ClickHouseに移動する方法を説明します。 通常、何もなければ、すべてが非常に簡単です。 新しいシステムで構築してください。 しかし、何かがある場合、それははるかに複雑です。 あなたは今元気です。 ClickHouseは優れたシステムであることに気づきました。 ビクターとアレクセイがすべての質問に答えます。これが正しい決定であることをさらに保証することは間違いありません。
実際、あなたが移動するかどうかすべてが彼らが言うほど良いわけではありません。 ClickHouseは過去に扱ったすべてのものとはまったく異なるためです。
これはすべて完全に新しい非常に具体的な経験であり、すべてがうまく機能するためには多くの作業が必要です。 ログをアップロードするなど、いくつかの簡単なことがすぐに機能します。 また、それほど単純ではないものもすぐには機能しません。 最後に、私たちは成功したので、私は誰もが成功すると確信しています。 すべての障害を突破しました。
私たちは誰ですか？
広告ネットワークのLifeStreetで働いています。 かなり大規模なネットワークで、10年以上市場に出ています。さまざまなタイプの広告アイテムの最適化に取り組んでいます：キャンペーン、お知らせ、お知らせの一部、入札、外部システムとの統合など。
これは、年間数千万ドルを稼ぐ完全に活気のある会社であり、Yandexほどのデータはありませんが、どこか半分になります。 1日に100億イベントのみ。 このビジネスはすべて大規模な分析システムに保存されます。内部ユーザーと外部ユーザーの両方、および機械学習アルゴリズム、最適化などで使用されます。 2010年にVerticaで構築された非常に優れた、十分に調整されたインフラストラクチャは、米国でVerticaを使用し始めた最初の会社の1つです。 これについては2013年の最後のHighLoadで2回話しました。 当時、私は分析システムを構築するための他のオプションについて話しました。 そのとき、ClickHouseは存在しませんでした。 私はそこにVerticaが見つけられなかったものとは異なってより良く見えました。 その後、それ以上のものはありませんでした。
しかし、私たちは見続けました-私たちはすべてVerticaが好きでしたが、いくつかのものがあり、遅かれ早かれそれを放棄したかったです。 昨年、Snowflakeのようなものがありました。Snowflakeは完全にAmazonの会社です。 これは非常に拡張性が高く、オンデマンドでサーバーを引き上げます。つまり、夜間にサーバーの電源をオフにし、日中はサーバーの電源を入れて料金を支払う必要はありません。 データはすべてAmazon S3などに保存されます。 元Verticaプログラマーによって開発されたため、非常に優れています。彼らは悪いことをしません。
これまでのところ順調に進んでいますが、Verticaを残したいと考えています。
帽子のウサギのように、1つの素晴らしい瞬間が表示されます。 誰もが彼を見て急いでいます-それは何ですか。 彼は速いので、非常に速く走る、と彼らは真実を語った。 それは著しく拡大し、彼らは一ヶ月後に家族全員でウサギを一匹植えました。 これは本当にクールなことです。皆さんから本当に感謝しています。
CTOから次の内容のメールが送信されます。
サーシャ、ClickHouseにも同様の使用例があり、広告ネットワークであり、クリックなどをカウントします。 彼らはシステムをリリースし、すべてが紙の上で完璧に見えます。 実際に必要なもの。 使用できれば、すべてが完全に適合します。非常にクールです。 ご覧ください。
すぐに言われた
2016年の夏から秋にかけてのClickHouseとは何ですか？
最初に、彼はちょうど現れました-完全に新しいもの。 これは通常、どの製品にとっても悪いことです。多くのバグがある可能性が高いです。 これはYandexの内部プロジェクトです。 これは、理解できず、見込みがある最初の外部製品です。
オープンソースでリリースされました。 それで何？
当時、独立したインストールはありませんでしたが、今では実稼働インストールがあるとさえ言っています-実際、誰がどのような結果でロードするかはわかりません。 これが本当に必要なものであることを見て理解する良いケーススタディはありません。 サポートはありません。Alekseyが唯一のサポートですが、彼は一人です。 ロードマップはありません。製品がどのように開発されるかは明確ではありません。 会社は計画を公開していません。これはすべて内部的なもの、つまりオープンソースのような製品ですが、すべての計画は内部的なものです。 発表されたとおり、ClickHouseには3人の開発者しかいませんでしたが、Yandex.Metricaアシスタントの開発者も数人いました。
すでに文書化されている多くの既知の制限があることが、文書からすぐに明らかになりました。 そして、何個の未知のものが理解不能であったか、しかし、それらもそうであったことは明らかでした。
常に成功しているわけではないため、オープンソースでリリースしたことをやっただけの他のプロジェクトの話を少し押しつぶしました。 たとえば、FacebookはCassandraをオープンソースで非常に未加工の状態でリリースし、最終的には使用しなくなりましたが、Cassandraは幸運でしたが、他の人が開発しています。
Peter Zaitsevのレポートを読んでいるのなら、彼はおそらくPerconaサーバーに含まれているTokuDBとTokuMXについて話したでしょう。 それはボストンのそのようなトクテック企業でした。 彼女は、MySQL用の完全に素晴らしい分析エンジンを作成しました。これは、多くのタスクでInnoDBよりもはるかに優れた、ブロックでデータを保存および取得しました。 同社は素晴らしいが、すべてが非常に貧弱に売れた。結局、倒産したが、結果が失われないように、すべてオープンソースでリリースされた。
そのようなリストで、私たちはLifeStreetのディレクターに来ます。そして、彼はこの領域とお金に責任があります。 「ポール、Verticaが必要であり、分析構造をこれに変更します 。 これはロシアで開発されました 。 」 彼は何と言ったと思いますか？ 彼は礼儀正しい人ですが、彼は次のように言いました。 「これを私のために働き、お金をもたらすものに置き換えたいですか？」
幸いなことに、彼は決定を下しませんが、そう言いました。
次に、データベースの開発方法、SQL、およびこれらすべてのことを知っている開発者に行きました。 彼らはClickHouseを見始めました。 彼らは、ClickHouseにはほとんど何もないことに気付きました。
- トランザクションもconstもありません。
- 主キーがありますが、これは実際には主キーではありません。これは物理的なソート順と言えます。
- 一貫性はありません。つまり、一貫性は保証されません。
- 削除と更新はありません。
- NULLはありません。Nullをまったく書き込めないシステムです。
- ミリ秒なし、つまり秒単位の正確な時間、ミリ秒が必要です-Int64などの独自の方法で、または別のフィールドに保存してください。
- 自動型変換はありません。つまり、Int8からInt16でさえ明示的にキャストする必要があります。
- 通常のSQLはありません。これは前のリスト全体から明らかです。
- 任意のパーティショニングはありません;月ごとにしかパーティショニングできません。つまり、日ごと、週ごと、または任意のキーごとにパーティショニングすることはできません。
- クラスター管理ツールはありません。つまり、Yandex自体がおそらく持っていますが、彼はそれをあまりにもパックできなかったので、オープンソースで見ることができなかったか、したくありませんでした。
開発者はこのリストを見たときに何と言ったと思いますか？
彼は言った： 「そして彼らはそれをデータベースと呼んでいますか？」 「彼ら」-それはYandexです。 それでも、システムには重大な制限があるという理解にもかかわらず、試してみることにしました。
それは非常に近いサブジェクトエリアとタスクであるため、まず最初に試すことにしました。 そして、密接な仕事なので、ソリューションは私たちにとってうまくいく可能性が高く、さらに、ロシアのYandexの権限は非常に高いです。 Yandexで働いたり仕事をしたりする十分な数の人々を知っています-彼らはすべて非常に高い専門家です。 このトピックに対するコミュニティの関心がすぐに活発になります。 彼はそれが本当に面白くて、これが空のフレーズにならないことを示しました。 私たちにとって非常に興味深いものになりました。 面白いことだから、本当にやってみたかった。 そして、それは無料です。
私たちは試してみました-すぐに小さなパイロットプロジェクトを作成し、それが本当にうまくいくことに気付きました。 Yandexは真実を語っています。 これは速いです。
これは私たちの記憶の中の最初のデータベースです-近年、私たちが確認し、多くのことを確認しました-これはVerticaほど悪くはありませんでした。 Yandexではより良く、テストではほぼ同じで、どこか少し良く、どこか少し悪くなりました。 これは非常に強力な結果です。
多くの機能-これも理解しました。 これは非常に優れたドキュメントです。つまり、オープンソースでリリースされたばかりのプロジェクトのドキュメントとしてです。 私の意見では、それは理想であり、今でもあります。もちろん、そこにはいくつかのことがありますが、まず、いつでもそれらを尋ねることができます。 Googleグループに関する完全に活気のあるフォーラムで、アレックスは自分の入場により、作業時間のほぼ半分を費やしています。 これらの答えは常に非常に詳細であり、彼は問題の本質を理解しようとしているため、Yandexでの態度は深刻すぎると確信しています。
まあ、私はすでにアレクセイについて話しました：質問への答え、個人的なメール、そして私たちが個人的にYandexに来たという点まで来ました-私はアレクセイと話をして彼を見て見ました。 私たちは見て、「それが可能である」ことに気づきました。
だから私たちは行きました
私が言ったように、主な問題は、既存のシステムをClickHouseに転送する必要があることでした。 これらはデータスキームであり、ロードスクリプトです。これは、内部および外部のすべてのお客様にこのデータを返すために使用されたOLAPサービスであり、管理手順もあります。
基本的な再配置の問題があります。 別の場所に移動する場合-通常は何かですが、あなたには適していません。 あなたはイギリスに移動し、反対側を旅しなければなりません。 アメリカに移動しましたが、プラグはそこに収まりません。 あなたが慣れている特定の習慣があります。 彼らはあなたのために働き、あなたは動き、彼らはあなたのために働きをやめます。 この移動の問題は、移動するものが何であれ、非常に近いシステムであっても常に存在します。 そして、ClickHouseには複雑さがあります-それが主なものでした。 MySQL、Oracle、Verticaなどのデータベースで確立されたプラクティスで慣れ親しんでいるもの-ClickHouseでのアプローチとその適用可能性について話すと、額が機能しなかったが額ができなかった。
最も重要なことは、もちろん、スキームです。 すべてはデータスキームに依存します。 そして、分析問題で使用される回路は、キューブに埋め込まれた星または星に展開されたキューブです。 そのようなcなジオメトリ。
このプレートは中央にあります-通常「ファクト」と呼ばれ、側面のプレートは「測定値」または「寸法」と呼ばれます。 さらに、メトリックなどの合成概念があります。これは、事実を集計する関数です。
この図は、必ずしもここに描かれているように見えるとは限りません。常に2つの極値があるからです。 すべての測定値を含むすべてをファクトテーブルに入れることができます。これはディスク上で非常に高価になり、多くのスペースが必要になり、リストを取得するのに費用がかかります。 10億のレコードがあり、そこにあるすべての国のリストを取得したい場合、列がどの程度効果的に保存されていても-確かに国のリストを個別に保持していなければ-すべてを読む必要があり、高価になります。 そして、あなたは何も変えることはできません。 通常、ファクトテーブルは変更されません。
もう1つの極端な例は、測定テーブルにすべてのものがある場合です（そして、ClickHouseはいわば大きな豚を置いています-非常に悪い結合を持っているという事実により、後で説明しますが、結合は非常に限られています）。 繰り返しになりますが、更新はありません。ただし、測定値を更新または追加するのに十分な頻度で最初に測定する必要があります。
ここでもう少し立ち止まります
測定は、3つの条件タイプに分けることができます。 1つ目は静的な参考書で 、決して変わらない、よくない、ごくまれです。 たとえば、国のリスト、時間の階層、地理の階層など。 彼らはほとんど変わらない。 また、通常、会社には独自のCRMとRPがあり 、顧客のリスト、広告会社のリスト、広告の特性などの可変ディレクトリがあります 。 それらは変化しますが、頻繁ではありません。 LTPデータベースが正常である場合、何かが一度変更されています。 そして、これらの変更は分析データベースに表示する必要があります。 さらに、ネットワークからの任意の属性を使用する一連のデータがあります -たとえば、頻繁に非常に迅速に変更されるidアプリケーションまたは電話モデル、静的ディレクトリを作成すること、またはわずかに変更することさえほとんど不可能である新しいものが表示されます。 あなたはあなたのトラフィックから何が来ているのか決してわかりません。
結局のところ、ClickHouseには辞書のようなすばらしいものがあります。 ビクターはそれらについて少し言いましたが、私はそれらについてもっと言います。 Cassandraから類似物を取得する場合、辞書を使用すると、キーに何かを関連付けることができます。これは列ファミリーです。つまり、キーごとの値を持つ列が多数あります。 これらの辞書はすべて、たとえばファイルやMySQLデータベースなど、さまざまなソースから取得できます。 これらはXMLで記述されており、ここでは1つの辞書を1つのファイルに記述することができるため、バージョンの管理とこの全体の管理が少し簡単になります。
これらは更新されますが、いくつかのニュアンスがありますが、これについては後で説明します。
そして、関数を介してそれらにアクセスします-ClickHouse内に配線された辞書へのアクセスを示したため、Victorによって示されたものを介しませんが、一般的なタイプの辞書へのアクセスは、一般的なタイプの関数からもアクセスできます。
辞書には特定の制限があります。 制限の1つは、ClickHouseには実際に多くの制限があることです。Ulnt64タイプです。他のタイプはありません。 また、ClickHouse型の明示的なキャストの実装セットが存在しないため、別のテーブルに異なる型の列がある場合、型にキャストする必要があり、あまり便利ではありません。
私たちにとって十分に重要な2番目の制限は、誰かのためではないかもしれません-これは、すべての列の値を取得する直接的な方法がないためです。 そこにあるものを辞書から理解することはできません。 そのような方法はありません。ソースのみを見ることができますが、ClickHouseから直接質問することはできません。
一定のサイズ制限があります 。 そこには3種類の辞書があり、最も効果的で最速の辞書であり、サイズは50万行で、もう1つの魔法の数字です。 制限の少ない他のタイプもありますが、動作は遅くなります。 ディクショナリをオンデマンドで更新したり、ソースを変更したりすることはできません。いくつかの微妙な違いがあります。 何とかこれに従わなければなりません。 クラスターの各ノードでは、すべてが独立しています。 クラスター内に100個のノードがあり、辞書を更新する必要がある場合、各ノードに移動して更新する必要があります。 また、場合によっては、クエリの実行が遅くなる場合があります。
そんなことを思いつきました。 今、ノウハウ、Yandexが今それを使用しているかどうかはわかりません。 このノウハウを思いつきました-テーブルを作成し、辞書ごとにキーのみを保存する別のテーブルを添付します。
それは何を与える
これにより、たとえば一方で辞書からすべてのエントリを取得することが可能になり、他方ではそのようなクエリを最適化することが可能になります。 非常に大きなテーブルがあり、たとえばこの種の条件でこのようなクエリを作成する場合、この関数はすべての行で呼び出されます。非常に大きなテーブルに対しては速すぎない可能性があります。 ただし、別のキープレートを使用して、リクエストを書き換えることができます。 最初に非常に単純なクエリで個別のキーのセットを引き出してから、非常に効率的な選択が機能します。
これらはもちろん単純化されたクエリです。 現実には、まだ他の条件がいくつかありますが、その考えはおそらく理解できるでしょう。
データが変化しているため、辞書の更新も重要です。 デフォルトのタイマー方式は、デフォルトで5分です。 なぜこれが悪いのですか？ あなたが多くの辞書と多くのサーバーを持っている場合、例えば接続があり、例えばMySQLがたくさんあり、彼らはそれを困惑させることができるという事実によって。
一部またはレプリカをインストールするか、何らかの方法でそれを解決する必要がありますが、MyISAMにソーステーブルがあることが幸運である場合、ClickHouse自体は辞書が変更されたことを理解します。 MyISAMテーブルの内容はその説明にあるので、showテーブルを見ると、最後の変更の日付があり、ClickHouseはそれを見て変更を取得できます。
もう1つの優れた方法は、タッチ設定を作成することです。 つまり、サーバーに移動すると、辞書記述ファイル用のTouch構成ファイルを作成すると、ClickHouseは辞書が変更されたと判断し、それを取得します。 ただし、クラスター内のすべてのサーバーを通過する必要があります。
そして最後に、私たちが思いついた最後の方法-私たちは思いつきましたが、試しませんでした。 これは、たとえば、共有ファイルをどこかに作成し、ファイルから辞書を取得します。 共有ファイルは、すべてのノードを通過するよりも変更が簡単です。
一般に、Viktorが指摘したように、結合の80％が削除されたため、私たちにとって、それは本当の銀の弾丸であり、銀の店全体でさえあり、スタースキーマ（立方体の星）を何らかの方法で機能させることができます。
しかし、テーブルはまだ時々必要です
まず、これはキー用です。 第二に、これらは辞書に収まらないWebトラフィックの属性です。 第三に、複合キーを使用している場合、何らかの理由でハッシュを作成できない場合、複雑なキーで結合すると、辞書は失敗します。
日付の範囲で結合を行う必要がある場合、日付の範囲が値であるテーブルがあります。 この値を今日または昨日などに取得する必要があります。 このような特定のユースケースは、常に異なる方法で解決できますが、これは辞書では機能しません。
テーブルが表示されると、 「テーブルの更新方法」という質問が表示されます。 ClickHouseによると、これを行う必要はありませんが、更新する必要がある場合は全体を書き換えます。 まあ、本当にしたいなら、できます。
これにはReplacingMergeTreeのようなものがあります。 原則としてレコードを更新することができますが、まず、非常に最終的に-更新したら、そこにレコードを追加し、この新しいレコードが最新になったら、それがわからないときに。 最適化を呼び出すと、運が良ければすぐに実際に最新のものになります。または、finalを入れて、現在のレコードを引き出します。 Yandexによると、これは低速で非効率的ですが、小さなテーブルには違いはありません。
個々のフィールドを更新するのは不便です。つまり、レコード全体に便利です。 個別の選択によって値を引き出してから書き戻す必要があるため、個別のフィールドは不便です。
また、各テーブルのClickHouseには、それぞれの日付であるパーティションキーが必要になるという問題もあります。 日付が不要な場合でも、追加する必要があります。 そして時々、この日に役立つものを載せたいという欲求があります。 そして、そこに何か便利なものを置くと、ReplacingMergeTreeを使用すると、さまざまなパーティションが崩壊しないため、これは機能しません。
そして、あなたがそれを削除する必要があるなら、それはさらに悪いです。 テーブルを削除できない場合、ゼロですべてが上書きされている場合にのみ-しかし、事実からCollapsingMergeTreeのようなものがあり、最後の会議で詳細に説明されました。 これは、異なる記号で何かを追加してから、正しい記号でエントリを追加する場合の、このような銀行の「反転」に類似しています。 彼女は再び、最終的には、つまりいつかは正しくなるでしょう。 適切な方法で、メトリックのみ、つまりお金のみまたは数字のみを修正できます。 通常、データは修正されませんが、集計の結果が修正されます。 データはいつか修正されるかもしれませんが、必ずしもそうではありません。
先に進む前に次に言うことは、セグメンテーションとシャーディングに関連する問題です。 これには各企業の要件が異なります。 たとえば、Yandexを使用すると、シャーディングがアカウントまたはクライアントに基づいていることがすぐにわかります。また、そこには多くのユーザーがいるため、異なるサーバーに非常に分散している可能性があります。 私が覚えている限り、彼らはこのために2レベルのシステムを作り、すべてが非常に便利です。
私たちの会社にはそれがなく、「広告ネットワーク」を持っている私たちのような会社-彼らは多く、おそらく顧客を持っていない-他のいくつかの分析のニーズがあります。 明確にねじを外すことは不可能であり、それをうまく行うために他の方法を考える必要がありますが、ロードとリクエストの両方のパフォーマンスはシャーディングに依存するため、それについて考える必要があります。
ClickHouseには、Replicated Spreadsheetsなどの優れた機能があります。 1匹のウサギを取り、それを2つの異なるサーバーに配置すると、2匹のウサギが得られます。 または、3台のサーバーで-3匹のウサギを取得します。 1台のサーバーが落ち、2台目のサーバーが残りました。
分散テーブルなどがあります。 ウサギを取り出して（実際にはそうではない）小片に切るとき、別のサーバーに小片を配置します。 ウサギ全体を取得するには、すべてのサーバーにアクセスする必要がありますが、各サーバーには小さなピースがあり、結果は同じですが、高速に処理できます。
これらのアプローチは組み合わせる必要があります。つまり、ウサギがいて、各ピースが複数のサーバー上にあります。 負けてすぐに振り返ることができます。
以前の知識をすべて一般化すると、ClickHouseからそのようなFarmVilleファームを取得できます。このファームでは、ファクトが多数の多数のシャードに配置され、一部のシャードが複製されます。
シャード自体は少なくとも1回、できれば2回複製されます。 ディメンションテーブルはすべてのノードにレプリケートされます。これは、すべてのノードでデータをフィルター処理してすべてに移動する必要があるためです。 また、一部のテーブルは、ファクトと調和して保存できます-たとえば、それらのシャードに。 これらは、データを持っているためにトラフィックから来ている人です。たとえデータの隣に保存されていても、場所を保持し、不必要ではありません。
そして、すべてがデザイン側にある場合、何も共有しないダウンロードを作成できます。 コンセプトは作成され、何も使用しませんが、余分なものはどこにも送信しません。 そして、これが起こるように、Distributedをロードしないようにしてください-ウサギを自分で切り分けて、必要な破片に入れてください。 また、Distributedは選択専用です。
さらに、レプリケーションが不要な場合でも、レプリケートされたテーブルを使用することをお勧めします。
この場合、ZooKeeperは動作し、ブロックのチェックサムを考慮するためです。 途中で何かが壊れ、トランザクションがなく、何を書いたか、何を書いていないかがわからない場合、ZooKeeper（同じことを書いた場合）はまだブロックを比較して書き留めます彼の観点から申し込んだ。 これは、ある種の一貫性の誤った感覚を与えます。 また、一時/中間テーブルも常に役立ちます。
多数の小さなデータを中間テーブルに書き込んでから、それらを結合して大きなテーブルに書き込むことができます。 または、一時テーブルへの書き込み、操作、辞書の追加、結合、データの処理、メインテーブルへの書き込みを行います。 これがすべて正しく行われていれば、ダウンロードは非常に高速です。 Verticaよりも高速に処理しました。間違いなく、それほど高速ではありませんでした。
何かをClickHouseに変換しようとしている人に生じるもう1つの痛い点は、集計です。
これは何ですか
ニンジンのパックがある場合は、ニンジンを1枚取り、10という数字を書いて、これが新しいニンジンであると言うことができます。 しかし、彼女はそれらと同じではありません-彼女はただのニンジンではなく、彼女の性格を失います。 Yandexは、詳細を失い、すべてをより適切に、常に維持するため、集約はまったく必要ないと考えています。
しかし、これを考慮すると、Yandexの全員がこの意見に固執しているわけではありません。ClickHouseには、ClickHouse自体と集約するツールがあります。AggregatedとSummingMergeTree。実際に、すでに挿入したものを集約し、集約および圧縮されたデータを保存します。
最も楽しいのは、このパスをたどると、このAggregatedおよびSummingMergeTreeを事実としてMVとして作成できることです。 そして、あなたは一種の事実を入れて、あなたの側では、魔法のように、集合体が現れます。 彼にはあらゆる種類の問題や困難がある可能性がありますが、ここでは説明しませんが、それでもこれは有効な解決策であり、誰かを助けるかもしれません。
次に、データにアクセスしました。 他のデータベースにはない興味深い詳細が数多くあります。 これらは、配列とそれらを操作するための高次関数、または配列が文字列に展開されるARRAY JOINです。 選択式のやや珍しい表記。 任意の場所で、式または列のエイリアスを配置できます。必ずしも使用する必要はありません。同じ選択行で後で使用できます。 便利な場合もありますが、特にどこかで既に使用されている名前を使用する場合は、キャッチするのが非常に難しいエラーが発生する場合があります。
結合に関連する興味深い詳細、完全に非SQL、完全に非標準。 ClickHouseは主キーを保証しないためです。この問題に対処するために、彼らはANY vs ALL JOINのようなものを思いつきました。
これは何ですか
一方、ALL JOINはJOIN条件に一致するすべてを返し、ANYは1つのレコード（最初に取得したレコード）を返します。したがって、参加するテーブルに一意でないエントリがある場合、それを恐れることはありません-最大で1つを受け取ります。
分散されたものに関連する興味深い特異性があります：PREWHERE vs WHERE。 1つはシャードで実行され、もう1つはシャードの後に実行されます。
GLOBAL IN、GLOBAL JOINは私たちが気に入ったものです。また、近似計算はサンプリングモデルまたは確率モデルであり、Victorが述べましたが、多くの場合、非常に大きなデータ配列があり、精度が必要な場合、これを使用できます。
しかし、これはすべて良いです。
今、痛み。このSQLの方言にないものは、時にはSQLでさえ名前を付けるのが非常に難しいが、本当にしたい。
これは自動キャストであり、これを何度も繰り返します。テーブルのエイリアスの名前を変更するのは、その構文がJOIN向けであるため、理解できる理由です。 JOINテーブルを1回作成できます。つまり、JOINテーブルを1回選択すると、2回は機能しなくなります。したがって、再指定は必要ありません。
2つのJOINを作成するには、副選択を行い、もう一度選択する必要があります。後で説明します。そして、JOINは使用のみをサポートします-これは、列の名前が両側で同じであり、型が同じであることを意味します。タイプが異なる場合は、サブ選択を再度行うか、タイプをキャストするか、名前を変更する必要があります。
SQLにはgroup by / order by 1,2,3のような有用なものはありません... ClickHouseを使いやすく、素早く作業できるアナリストが、スライシングとダイシングを行うディメンションを変更して変更する場合、それを呼び出します。選択するディメンションを変更する場合、グループ化するために実行する必要があります。そこで、彼はまた、order byに名前を変更します。他のデータベースでは、1、2、3で注文を書いたときにこれは非常に便利です...そこにある列を分析する必要はありません。
nullや合体はありません。これは非常に便利な機能であり、それがなければ人々がどのように生活するのかわかりません。
それでもなお、私たちの何人かが怪我をしたために、これはJDBCとHTTPインターフェースを介した一時テーブルがなく、セッションがないためです。 Yandexは何らかの形でこれを何らかの形で修正することを約束しますが、今のところは、定数テーブルを使用し、それらが時間通りに削除されることを確認する必要があります。
したがって、さまざまな松葉杖を思いつきます。つまり、型を明示的に変換し、結合をラップします。ここで、3つまたは4つの2つのテーブルを結合しない場合、この構造は大きくなります。また、各副選択では、メモリを浪費しています-大量の小さなテーブルを大きなテーブルにアタッチする必要がある場合、必要なメモリ量を理解するために、各結合の条件が流れ、メモリを消費して費やした後のこの大きなテーブルあまり便利ではありません。したがって、辞書！
高次のarrayFilter関数を使用してnullをゼロに置き換えた場合、合体を書き換える優れた方法は次のとおりです。これは私のお気に入りの例です。ここで開発者がすぐに驚いたのは、0からではなく1から始まる番号が配列されていることです。
そして次のこと-私はそれが痛みであるかどうかわからないが、管理
ClickHouseの管理は次のようになります。
これは、「熟練した手」または「自分でやる」セットです。つまり、あなたはすべてを持っています-あなたは何でも集めることができます。
すべてが非常に柔軟で非常に手作業です。そして、主な問題の1つは、すべてのノードで実行する必要があるDDL操作（変更後のテーブルなど）です。各ノードに移動して、テーブルの作成またはテーブルの変更を行います。ノードを忘れた場合、何らかのリクエストでこれが落ちる可能性があります。
ZooKeeperがあります。彼はテーブルについての彼自身の考えを持っています。実際、レプリケートされたテーブルの名前はClickHouseにあり、それらの名前はZooKeeperにあります。テーブルの名前を変更すると、ClickHouseでのみ名前が変更され、ZooKeeperでは名前が変更されません。そして、これは非常に興味深い発見につながる可能性があります。たとえば、テーブルの名前を変更し、同じ場所に別の構造を使用して新しいテーブルを作成し、データをコピーする場合、ZooKeeperでは名前がまだ古いため、これは額では機能しません。
前のレポートは「Yandex-非常に高速で便利です」というタイトルでしたが、私たちの意見では、非常に高速ですが、便利ではありません。しかし、それでも、本当に必要な場合はClickHouseに移行できます。そして何よりもまず、機能と制限を理解する必要があります。つまり、私たちがどこに向かっているのかを理解する必要があります。
Yandex Way（私たちの名前）を推測することは非常に重要です-これは、システムを構築する際にYandexが検討したユースケースです。これは、どのように機能し、Yandexの道路を理解するかのメトリックです。あなたはそれに沿って進むか、あなたの道をつなぎ、あなたがあなたのやり方をしていることを理解することができます。
たとえば、ClickHouseの使用を開始したときに最初に遭遇したのは、マイナスキーがサポートされていなかったためです。つまり、テーブルは-1であり、エラーが発生します。このバグをすばやく修正しました。つまり、Yandexにはネガティブキーはありませんでしたが、誰かが登場しました。
そして、Yandexには、おそらくリグレッションがないように、必要なものでカバーされた単体テストがあり、必要なのは誰も保証せず、チェックする必要があることは明らかです。
フォーラムでアレクセイとビクターの方法を試してみて、尋ねることをheしないでください。私たちの方法を説明しました。
あなたは私がYandexを誓うと思うかもしれません。しかし、決してそうではありません。彼らに本当に感謝し、彼らは素晴らしいプロジェクトを行い、いくつかのことはうまくいかないことを感じました。彼らは私たちとRDBMSで動き出そうとしている企業のために働きません。一部の人は、一方では仕事をし、他方では、コミュニティからのフィードバックを本当に望んでいたので、製品を開発する方法を理解するためにこの方法でそれを受け取りました。
道の終わりには、エメラルドの街が皆を待っています。とても早く、とても良いです。ClickHouseは本当にうまく機能します。
私にはすべてがあります。
レポート：Yandex ClickHouseへの移行。