This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
StatusAuthorsCoachDRIsOwning StageCreated
proposed @mikolaj_wawrzyniak @jdrpereira @pskorupa @DylanGriffith @nhxnguyen workinggroup clickhouse 2023-02-23

ClickHouseまたはその代替品と対話するための抽象化レイヤーを検討します。

目次

要約

ClickHouseのインストールをオプトインしないGitLabインストールのために、ClickHouseまたはその代替品への読み取りアクセスを標準化するソリューションを提供してください。様々なオープンソースツールを分析し、内部でソリューションを構築するオプションと比較検討した結果。現在の推奨アプローチは、各データソースに接続するために専用のデータベースレベルドライバを使用することを提案しています。さらに、データベースの可用性の複雑さを単一のアプリケーションレイヤーに限定するために、リポジトリパターンの使用を提案しています。

動機

ClickHouseの実行にはかなりのリソースを必要とし、GitLabの小規模なインストールではパフォーマンスの向上による投資効果を得られない可能性があります。そのため、ClickHouseがすべてのインストールでグローバルに利用できるわけではなく、利用可能な異なるデータストアを交互に利用する必要があるというリスクが生じます。ワーキンググループの一部として既に提案された現在と将来のClickHouseユースケースのうち、10件中7件はClickHouseとは異なるデータストアを使用しています。このような状況を考慮すると、利用可能なデータストアとのインタラクションを標準化するツールやガイドラインを提供することで、ClickHouseを採用するユースケースをサポートすることが重要です。

提案されるソリューションは、基礎となるデータストアとのインタラクションのための統一されたインタフェースを提供するスタンドアローンのツールから、データストアとのインタラクションの周りに配置されるルールや制限を記述し、カプセル化の境界を描く実装ガイドラインに裏打ちされた各データストアを個別にサポートするライブラリのセットまで、さまざまな形を取ることができます。

目標

  • オプションで利用可能なデータストアがGitLabアプリケーションのコードベース全体に与える影響を単一の抽象化レイヤーに限定すること
  • データストア固有の機能をすべてサポート
  • メインGitLabアプリケーションのサテライトサービスの通信をサポート

非目標

  • 本提案では、データベースとの書き込み通信については直接考慮しません。
  • 本提案では、スキーマの変更やデータマイグレーションの課題については直接考慮していません。

上記の点は非目標であるにもかかわらず、最終的な解決策にいくつかの変更を課す可能性があることを認めます。

可能な解決策

前項で述べた高レベルの目標は、自社製のソリューションでも、オープンソースのツールを採用することでも達成できます。以下のセクションでは、この2つの方法について詳しく見ていきます。

MVCと反復の精神に基づき、Ruby用のActiveRecordのように、対応するデータストアと直接やりとりするドライバに依存するソリューションから始めることを提案します。このソリューションが、この終了基準で設定された目標を達成し、このドキュメントの_動機の_セクションで列挙されたイシューを軽減するのに役立つためには、そのようなドライバは、静的コード解析で強制される一連の開発ガイドラインによってサポートされる必要があります。

このような解決策は、オープンソースツールによって制限され、グループがClickHouseの機能を最大限に活用できなくなるリスクを懸念するワーキンググループの様々なメンバーからのフィードバックを受け、望ましいものとして選択されました。この文書で示されたワーキンググループの基準に沿って共同作業を行っているメンバーは、制限に関する懸念は包括的なプロトタイプのセットを構築することで軽減することができるということに同意していますが、そのために必要な時間と労力はこのワーキンググループの限界を超えています。また、ClickHouseの採用は探索的なステージにあり、グループはまだ自分たちの要求が何であるかを述べることができないかもしれないということも重要です。

提案されたドライバー

ClickHouseのドキュメントによると、RubyとGo用に以下のドライバがあります。

Ruby
  1. ClickHouse Rubyドライバ- Observabilityグループの研究の一環としてGitLabで使用されることになりました。
  2. Clickhouse::Activerecord
Go
  1. ClickHouse/clickhouse-go- 公式 SQL データベースクライアント。
  2. uptrace/go-clickhouse- 代替クライアント。
クライアント・アーキテクチャ案

コードベースをうまく整理し、特定のデータベースエンジンとの結合を制限するためには、データのクエリを含むインタラクションを単一のアプリケーションレイヤーにカプセル化することが重要です。

基礎となるデータベースエンジンをカプセル化したままにしておくことで、推奨されるソリューションは、他のツールを後から導入する機会を保ちつつ、グループにそのユースケースを探求し理解する時間を与える、良い双方向のドアの決定となります。

最も低い抽象化レイヤでは、ClickHouseドライバと直接やり取りするクラス群が存在すると予想され、Railsによって実装されたMVCパターンに従うクラスは_モデルに_分類されるべきです。

モデルレベルの抽象化は既存のパターンとガイドラインにうまく組み入れることができますが、残念ながら自己管理インスタンス用のClickHouseデータベースエンジンのオプションの可用性という課題を解決することはできません。ビジネスロジックの要求に応えるために最適なデータベースを選択する責任を持つ専用のエンティティを設計する必要があります。すでに述べた既存の抽象化ガイドラインの中から、Finders 与えられた要件に最も近いと思わ Findersれるのは、データベース固有のインタラクションを独自の公開APIの後ろにカプセル化し、データベースベンダーの詳細をその上のすべてのレイヤーから隠すというFinders 事実のため Findersです。

しかし、これらはActiveRecord ORM フレームワークと密接に結合しており、さらに複雑なクエリを構成するために使われるかもしれないActiveRecord::Relation オブジェクトを返すために既存の GitLab 規約に縛られています。このカップリングによって、Finders はClickHouseのオプションの可用性に対応できません。なぜなら、返されるデータは2つの異なるデータベースから来る可能性があり、互いに互換性がないかもしれないからです。

Array 上記のことを考慮すると、Finders と同じような抽象度の新しいエンティティをコードベースに追加することを検討する価値があるかもしれません。

必要なレベルの分離はリポジトリ・パターンを使うことで実現できます。リポジトリ・パターンはビジネス/ドメイン・ロジックをデータ・アクセスから分離するように設計されています。さらに、リポジトリ・パターンは基礎となるデータベース上で実行されるオペレーションを制限しないので、データベースの機能をフルに活用することができます。

リポジトリパターンを実装するには、以下のものを作成する必要があります：

  1. 例えば、MyAwesomeFeature::Repository::Strategies::ClickHouseStrategy やMyAwesomeFeature::Repository::Strategies::PostgreSQLStrategy などです。ストラテジーは、基礎となるデータベースとの通信、つまりクエリの作成を行います。
  2. リポジトリは、あらかじめ定義された基準（データベースの可用性など）で選択された利用可能なストラテジーを使って、データベースとやりとりするための高レベルインターフェースを公開する役割を担っています。単一のリポジトリが使用するストラテジーは、同じ公開インターフェースを共有しなければなりません。
  3. Plain Old Ruby Object(PORO) Modelリポジトリを使ってアプリケーション層が実装するビジネスロジックのデータを表します。データベースには依存しません。

リポジトリパターンに基づいたソリューションは、Observabilityグループによってすでに実装されていることに注目すべきです（@ahegyi、@splattael、@brodockに感謝）。ErrorTracking::ErrorRepository 、エラートラッキング機能のPostgreSQLからClickHouseへのマイグレーションをサポートするために使用されており（API経由でインテグレーション）、データベースの選択基準として機能フラグのトグルを使用しています。

ErrorRepository は2つの戦略を使用しています：

  1. OpenApiStrategy APIプロキシエンティティを使用してClickHouseと対話する場合
  2. ActiveRecordStrategy ActiveRecord フレームワークを使用して PostgreSQL とやりとりします。

これらのストラテジーはそれぞれ、以下のPOROモデルを使って上の抽象化レイヤーにデータを返します：

  1. Gitlab::ErrorTracking::Error
  2. Gitlab::ErrorTracking::DetailedError

さらに、ErrorRepository は、サポートされるデータストアの種類という点で、リポジトリパターンが提供する驚くべき柔軟性の好例です。ライブラリや外部サービスAPIといった異なるソリューションを、単一の統一されたインターフェースの下にインテグレーションすることができます。この例は、将来的にリポジトリパターンがClickHouseやPostgreSQLのニーズを超えて拡張される可能性を示しています。

以下のマージリクエストは、ActiveRecordモデル、サービス、ファインダーに基づいた現在のGitLabアーキテクチャをリポジトリパターンにマイグレーションするためにobservabilityグループが行った変更を文書化したものです。

クライアントアーキテクチャを強制するための可能な方法

クライアント側のアーキテクチャを提案するだけでは、それが一般的な慣習として完全に確立されるには十分ではありません。リポジトリパターン実装の自動検証を導入する方法は複数あります：

  1. Database::PreventCrossJoinsと同様の方法でActiveRecord クエリサブスクライバを利用し、_Strategiesの_外部で実行されたClickHouseへのクエリを検出します。
  2. CodeReuse rubocop ルールを拡張し、_Strategies_の外部で ClickHouse ドライバを使用するすべてのフラグを立てます。
  3. _リポジトリ_外部で行われるClickHouseインスタンス(例:CurrentSettings.click_house_enabled?)の存在をチェックするユーティリティメソッドへの呼び出しを検出するrubocopルールを作成。

この開発ステージでは、作成者はリストアップされたすべてのオプションが実行可能で有望であると考えています。したがって、どのオプションを使用するかについての決定は、ClickHouseのための最初のリポジトリパターンの実装が現れるまで延期されるでしょう。

オープンソースツールの概要

このセクションでは、作成者は、記載された目標を達成するための代替アプローチとして検討されたが、推奨アプローチとして選択されなかった既存のサードパーティのオープンソースソリューションの概要を提供します。

評価基準

1.ライセンス(MUST HAVE)
  1. ソリューションは、受け入れ可能なライセンスの下でオープンソースでなければなりません。
2.異なるデータストアのサポート(MUST HAVE)
  1. 提案されている抽象化レイヤーがClickHouseとPostgreSQLの両方をサポートできるかどうか（必須）に焦点を当てています。
  2. 2つ以上の必須ストレージがサポートされているかどうかも考慮する必要があります。
  3. ソリューションは PostgreSQL の必要最小限のバージョンをサポートしなければなりません。
3.プロトコルの互換性

すべての抽象化レイヤーは、ツールへの直接アクセスと比較して、制限されたAPIという代償を伴います。この出口基準は、共通の抽象化のためにツールのAPIを制限するトレードオフの程度を理解させようとしています。

  1. PostgreSQLとClickHouseでどのような読み取りオペレーションが可能かを列挙してください (selects,joins,group by,order by,union など)。
  2. 提案されている抽象化レイヤでどのようなオペレーションが可能か、そのようなオペレーションを行うにはどの程度複雑か、ネイティブにオペレーションを実行する場合と比較して性能上の懸念はないか、などを列挙してください。
  3. 必要なオペレーションが抽象化レイヤでサポートされていない場合でも、データソースへの直接アクセスは可能ですか？例えば、ActiveRecord では、生の SQL 文字列を#execute
4.オペレーション
  1. デプロイプロセス：どの程度複雑か？提案されたツールは、スタックに追加されるライブラリツールですか、それともGitLabシステムに沿って独立してデプロイされる追加サービスが必要ですか。ツールがサポートするデプロイタイプ（Kubernetes/VM、SaaS/セルフマネージド、サポートするOS、クラウドプロバイダー）。オフラインインストールをサポートしていますか。
  2. オペレーションに必要なハードウェアリソースは？
  3. 安定したパフォーマンスを保証するために、複雑なモニタリングやオペレーションが必要ですか？
  4. 成熟した保守プロセスとそのドキュメント：アップグレード、バックアップとリストア、スケーリング
  5. 高可用性のサポート。ツールは、HAクラスタを構築し、自己管理のためにフェイルオーバーを実行する方法を文書化していますか？ツールはゼロダウンタイムのアップグレードをサポートしていますか？
  6. FIPSおよびFedRAMPコンプライアンス
  7. レプリケーションプロセスと、新しいツールがGeoLabにどのように適合するか。
5.開発者の経験
  1. ソリューションは、採用を容易にし、学習曲線を減らすために、十分に構造化され、明確で、徹底的に文書化されたAPIを持っている必要があります。
6.成熟度
  1. そのソリューションはいつまで存在しますか？よく使われていますか？安定したコミュニティがありますか？ライセンスが許せば、ツールのフォークもかなりの選択肢です。
7.技術的適合性
  1. GitLabで使っているプログラミング言語で書かれていますか？そうすれば、バグ修正や新機能で貢献しやすくなります。
8.相互運用性（必須）
  1. Ruby on Railsで書かれたGitLabアプリケーションと、Goで書かれたコンテナレジストリのようなサテライトサービスの両方をサポートできるソリューションであること。

オープンソースのソリューション

1.キューブ開発

評価

  1. ライセンス Apache 2.0 + MIT ↪So_2705
  2. 異なるデータストアのサポート ✅ 有
  3. プロトコルの互換性 OLAP理論の概念を使用してデータを集約します。これは、利用メトリクスの集計のようなユースケースでは有用かもしれませんが、他のユースケースでは有用ではありません。SQLクエリと独自のクエリ形式の両方のAPIを持っています。
  4. オペレーションの手間 Dockerやk8sを使ってデプロイする独立したサービス。Redisをキャッシュとデータ構造ストアとして使用します。
  5. 開発者の経験 良いドキュメント
  6. 成熟度 ヘッドレス BI ツール自体はかなり新しいアイデアですが、Cube.js はこの分野におけるオープンソースの代表的なソリューションのようです。アナリティクスセクションでは、製品アナリティクススタックの内部で使用しています。
  7. 技術的なフィット感 RESTおよびGraphQL APIを使用。独自のクエリ形式とデータスキーマ形式がありますが、十分に文書化されています。YAMLまたはJavaScriptでデータ定義。

コメント

このソリューションはすでに~"group::product analytics "によってClickHouseの読み取りインターフェイスとして使われています：

  1. cube.dev用ClickHouseドライバはコミュニティソースであり、現在のところメンテナーがいません。小規模でシンプルなリポジトリであり、ClickHouseの新しいメジャーバージョンが登場し、いくつかの変更が加えられるまでは少なくとも動作するはずです。
  2. Cube.devはGitLabの技術スタックの一部であるType ScriptとJavaScriptで書かれており、それらに精通した開発者もいます。しかし、Cube.devは主にバックエンドの開発者が使うことを想定しており、バックエンドの開発者はこれらの技術の経験がそれほどありません。
  3. 単純な SQL 作業のための抽象化レイヤで、JSON に基づいてバックエンドに応じた正しいクエリを構築します。
  4. データストア固有の機能 (ウィンドウ・ファネル ClickHouse など) が他のエンジンに変換されないため、同じデータを表現するために追加のキューブ・スキーマを構築する必要があります。
  5. これまでのところ、ローカルの開発環境と AWS VPS の両方で、数百万行のインポート負荷テストにおけるパフォーマンスはイシューではありません。
  6. ほとんどのエンジンに対してpostgres SQLのようなインターフェイスを公開しますが、残念ながらClickHouseに対しては公開しないので、ワーキンググループのユースケースのためにはJSON APIの方がより現実的かもしれません。
  7. Cube.dev は、ClickHouse のようなオプションのコンポーネントを処理する実行時に、条件付きで使用できるスキーマをその場で自動生成できます。

この会話の録音もあります。

2.クリックハウスFDW

評価

PostgreSQL 用 ClickHouse Foreign Data Wrapper です。PostgreSQLに格納されているかのようにClickHouseテーブルをクエリできます。Postgresがスケールしなくなった時に、ClickHouseをドロップインで簡単に導入するための有効なオプションになるでしょう。

  1. ライセンス Apache 2.0 ✅。
  2. PostgreSQLインスタンスを通してClickHouseを呼び出すことで、異なるデータストアをサポートします。✅
  3. プロトコルの互換性 SELECT、INSERT文を一見してサポート。結合については不明。定義上、生のSQLを使用可能。
  4. オペレーション
    1. PostgreSQLの拡張。2つのDB間のマッピングが必要。
    2. 実行がClickHouseからの応答を待つためにCPUサイクルを浪費する場合、PostgreSQLの性能に悪影響を与える可能性があります。
    3. PostgreSQLとClickHouseのデプロイ間の接続を公開し管理する必要があります。
  5. 開発者の経験 未定
  6. 成熟度 数年前から存在し、ClickHouseのドキュメントにも記載されていますが、広く使われているようには見えません。
  7. 生の SQL 文にフィットします。

コメント

3.クリックハウス::アクティブレコード

評価

  1. ライセンス MIT License ✅ ．
  2. アプリケーション層でActiveRecord用のClickhouseアダプタを提供し、PostgreSQLに沿ったクエリができるようにします。✅
  3. プロトコルの互換性 ジョインについてはわかりません。
  4. オペレーション作業 Ruby on Rails ライブラリツール - ActiveRecord アダプタ形式の ORM インタフェース。
  5. 開発者の体験 Railsに慣れている開発者にとっては作業が簡単。
  6. 成熟度 数年前から存在していますが、レポのアクティビティは乏しいです（ただし、それ自体は悪いことではありません）。
  7. Railsライブラリに適した技術。

コメント

4.Metriql

評価

データソースにDBTを使用するヘッドレスBIソリューション。データからメトリクスを定義し、集計で変換するという点ではCube.devに似ています。作成者はこのFAQエントリで、MetriqlとCube.jsのような他のBIツールとの違いを説明しています。

  1. ライセンス Apache 2.0 ✅。
  2. 異なるデータストアをサポート データソースからの読み込みに DBT を使用するため、CH と PostgreSQL が可能です。
  3. プロトコルの互換性 OLAP理論の概念を使ってデータを集約します。REST APIを通じて即席のSQLクエリが可能です。
  4. オペレーションの手間 デプロイには別のサービスが必要で、DBTが必要です。
  5. 開発者の経験 セットアップと使用には DBT の知識が必要です。かなりシンプルな REST API がここにドキュメントされています。
  6. 成熟度 最初のリリースは2021年5月ですが、レポのアクティビティはほとんどありません（それ自体は悪いことではありません）。
  7. 技術的なフィット感 REST APIまたはJDBCアダプタを介してBIツールと接続。SQLまたはMQL（SQLのフレーバー/サブセット）を使用したクエリが可能。

コメント

5.却下された注目すべきサードパーティ・ソリューション

AirflowやMeltanoのようなETLのみのソリューションや、TableauやApache Supersetのような可視化ツールは、通常明らかに我々の基準から外れているため、見込みリストから除外しました。

pg2ch論理レプリケーションを使用したPostgreSQLからClickHouseへのミラーリング。レポはアーカイブされています。論理レプリケーションは私たちの規模では十分な性能を発揮しないかもしれません - 私たちは性能の懸念からPostgreSQL DBでは使用していません。

LookerBIツール。クローズドソース。

Hasuraデータベースソース用のGraphQLインターフェース。ClickHouseのサポートはまだありません。

dbt サーバdbt 用 HTTP API。MariaDB ビジネスソースライセンス(BSL) ❌.

オープンな質問

  1. この提案の主な焦点は読み込みインターフェイスですが、書き込みインターフェイスに焦点を当てた補完的な取り組みの結果次第では、オプションの可用性に関する同様の懸念が書き込みインターフェイスにも当てはまるかもしれません。もしインジェストパイプラインが書き込みインターフェイスのオプションの可用性の課題を解決しないのであれば、この文書で提案されているリポジトリパターンの実装に書き込みインターフェイスを含めることが重要かもしれません。
  2. ClickHouseのスキーマ変更とデータマイグレーションに関する懸念は、既存のどのワーキンググループの基準でもカバーされていません。この課題を全体として解決することは、この文書の範囲外ですが、スキーマ変更をサポートするために、提案されているリポジトリパターンに基づく実装に何らかの変更が必要かもしれないという認識を高めることは賢明です。