SentryバックエンドのクラウドネイティブミドルウェアはClickHouse PaaSを実践し、Snubaイベント分析エンジンを強化します。

SentryバックエンドのクラウドネイティブミドルウェアはClickHouse PaaSを実践し、Snubaイベント分析エンジンを強化します。

ClickHouse PaaS クラウドネイティブ マルチテナント プラットフォーム (Altinity.Cloud)

公式サイト: https://altinity.cloud

PaaS アーキテクチャの概要

クラウドネイティブのオーケストレーション機能を備え、マルチクラウド環境の展開、自動化された運用と保守、柔軟なスケーリング、自己修復をサポートし、テナント分離、権限管理、操作監査などのエンタープライズレベルの機能を提供する、高性能で低コストの分散ミドルウェア サービスを設計するのは非常に困難です。

ユーザーに提供されるSaaSモデル

Sentry Snuba イベント ビッグ データ分析エンジン アーキテクチャの概要

Snuba は、ClickHouse 上で豊富なデータ モデル、高速な取り込みコンシューマー、クエリ オプティマイザーを提供するサービスです。 Sentry イベントに関するデータを検索および提供する集約エンジン。

データは Clickhouse テーブルとマテリアライズド ビューに完全に保存され、入力ストリーム (現在は Kafka トピックのみ) を介して取り込まれ、ポイントインタイム クエリまたはストリーミング クエリ (サブスクリプション) を介してクエリできます。

ドキュメント: https://getsentry.github.io/snuba/architecture/overview.html

Kubernetes クリックハウス オペレーター

Kubernetes オペレーターとは何ですか?

Kubernetes Operator は、Kubernetes アプリケーションをパッケージ化、デプロイ、管理する方法です。 Kubernetes API (アプリケーション プログラミング インターフェイス) と kubectl ツールを使用して、Kubernetes 上で Kubernetes アプリケーションをデプロイおよび管理します。

  • https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/operator/

ClickHouse の Altinity 演算子

Altinity: 主要なオープンソース ClickHouse Operator プロバイダー。

  • アルティニティ: https://altinity.com/
  • GitHub: https://github.com/Altinity/clickhouse-operator
  • ユーチューブ: https://www.youtube.com/@Altinity

もちろん、このようなマルチテナントの分離された ClickHouse ミドルウェア PaaS クラウド プラットフォームは、企業やクラウド ベンダーによってオープンソース化されることはほとんどありません。

ラドンDB クリックハウス

  • https://github.com/radondb/radondb-clickhouse-operator
  • https://github.com/radondb/radondb-clickhouse-kubernetes

altinity-clickhouse-operator をベースにクラウドベンダー (QingCloud) によってカスタマイズされています。実稼働クラスターの迅速な展開のためにいくつかの最適化が行われました。

Helm + Operator で ClickHouse クラスターをクラウドに素早くデプロイ

クラウドネイティブ実験環境

  • VKE K8S クラスター、Vultr 管理クラスター (v1.23.14)
  • Kubesphere v3.3.1 クラスターのビジュアル管理、フルスタック Kubernetes コンテナ クラウド PaaS ソリューション。
  • Longhorn 1.14、Kubernetes 向けのクラウドネイティブ分散ブロック ストレージ。

clickhouse-operator をデプロイする

ここでは、RadonDB のカスタマイズされたオペレーターを使用します。

  1. values.operator.yaml は次の 2 つのパラメータをカスタマイズします。 
 # オペレーターはクラスター内のすべての名前空間のクリックハウス展開を監視します
すべての名前空間を監視する: true
 # オペレータメトリックの監視を有効にする
PrometheusMonitorを有効にする: true
  1. helm デプロイ演算子: 
 cd vip - k8s - paas / 10 -クラウド-ネイティブ- clickhouse

 # kubeシステムにデプロイ
helm をインストール clickhouse -演算子 。 /クリックハウス-演算子- f値​​.operator .yaml - n kube -システム

kubectl - n kube -システム取得 po | grep clickhouse -演算子
# clickhouse -オペレーター- 6457 c6dcdd - szgpd 1 / 1実行中0 3分33秒

kubectl - n kube -システム取得 svc | grep clickhouse -演算子
# クリックハウス-演算子-メトリック ClusterIP 10.110 .129 .244 <なし> 8888 / TCP 4 m18s

 kubectl api -リソース| grep クリックハウス
# clickhouseinstallations chi clickhouse .radondb .com / v1 true ClickHouseInstallation
 # clickhouseinstallationtemplates chit clickhouse .radondb .com / v1 true ClickHouseInstallationTemplate
 # clickhouseoperatorconfigurations チョップコンフclickhouse .radondb .com / v1 true ClickHouseOperatorConfiguration

clickhouse-clusterをデプロイする

ここでは、RadonDB によってカスタマイズされた clickhouse-cluster helm チャートを使用します。 2 つのシャード + 2 つのレプリカ + 3 つの zk ノードのクラスターをすばやくデプロイします。

  1. values.cluster.yaml のカスタマイズ: 
クリックハウス:
 クラスター名: snuba - clickhouse -ノード
 破片数: 2
 レプリカ数: 2
 ...
飼育員:
 インストール: true
 レプリカ: 3
  1. helm デプロイ clickhouse-cluster: 
 kubectl で ns クラウドを作成-クリックハウス
helm インストール clickhouse ./clickhouse-cluster-f値​​.cluster .yaml - nクラウド- clickhouse

 kubectl get po - n クラウド- clickhouse
 # chi - clickhouse - snuba - ck - nodes - 0 - 0 - 0 3 / 3実行中5 ( 6分13 秒前) 16分
# chi - clickhouse - snuba - ck - nodes - 0 - 1 - 0 3 / 3実行中1 ( 5分 33 秒前) 6分 23 秒
# chi - clickhouse - snuba - ck - nodes - 1 - 0 - 0 3 / 3実行中1 ( 4分 58 秒前) 5分 44 秒
# chi - clickhouse - snuba - ck - nodes - 1 - 1 - 0 3 / 3実行中1 ( 4分 28 秒前) 5分 10 秒
# zk -クリックハウス- 0 1 / 1実行中0 17 m
 # zk -クリックハウス- 1 1 / 1実行中0 17 m
 # zk -クリックハウス- 2 1 / 1実行中0 17 m

オペレータを使用してクリックハウスシャードクラスターを急速に拡張する

  1. 次のコマンドを使用して、shardsCount を 3 に変更します。 

 kubectl 編集 chi/clickhouse -n クラウドクリックハウス

  1. ポッドを表示: 

 kubectl get po -n クラウドクリックハウス

# 名前 準備完了 ステータス 再起動 年齢
#chi-clickhouse-snuba-ck-nodes-0-0-0 3/3 実行中 5 (24 分前) 34 分
#chi-clickhouse-snuba-ck-nodes-0-1-0 3/3 実行中 1 (23 分前) 24 分
#chi-clickhouse-snuba-ck-nodes-1-0-0 3/3 実行中 1 (22 分前) 23 分
#chi-clickhouse-snuba-ck-nodes-1-1-0 3/3 実行中 1 (22 分前) 23 分
# chi-clickhouse-snuba-ck-nodes-2-0-0 3/3 実行中 1 (108 秒前) 2 分 33 秒
#chi-clickhouse-snuba-ck-nodes-2-1-0 3/3 実行中 1 (72 秒前) 119 秒
#zk-clickhouse-0 1/1 ランニング 0 35分
#zk-clickhouse-1 1/1 ランニング 0 35分
#zk-clickhouse-2 1/1 ランニング 0 35分

chi-clickhouse-snuba-ck-nodes-2-0-0 と chi-clickhouse-snuba-ck-nodes-2-1-0 が見つかりました。シャードとレプリカはオペレーターによって自動的に作成されます。

試してみる

ReplicatedMergeTree+Distributed+Zookeeperはマルチシャードマルチコピークラスタを構築します

ClickHouseに接続

Pod に入り、ネイティブのコマンドライン クライアント clickhouse-client を使用して接続します。 

 kubectl exec - it chi - clickhouse - snuba - ck - nodes - 0 - 0 - 0 - n cloud - clickhouse -- bash
 kubectl exec - it chi - clickhouse - snuba - ck -ノード- 0 - 1 - 0 - n クラウド- clickhouse -- bash
 kubectl exec - it chi - clickhouse - snuba - ck - nodes - 1 - 0 - 0 - n cloud - clickhouse -- bash
 kubectl exec - it chi - clickhouse - snuba - ck - nodes - 1 - 1 - 0 - n cloud - clickhouse -- bash
 kubectl exec - it chi - clickhouse - snuba - ck - nodes - 2 - 0 - 0 - n cloud - clickhouse -- bash
 kubectl exec - it chi - clickhouse - snuba - ck - nodes - 2 - 1 - 0 - n cloud - clickhouse -- bash

ターミナルからこれら 6 つのポッドに直接入ります。次にテストします: 

 clickhouse -クライアント--multiline -u ユーザー名 -h ip --password パスワード
# クリックハウス-クライアント- m

分散データベースの作成

  1. system.clusters を表示
システム.clustersから*を選択します。

2. testという名前のデータベースを作成する

クラスター'snuba-ck-nodes'にデータベース テストを作成します。
 # 削除: クラスター'snuba-ck-nodes'上のデータベース テストを削除します。
  1. 各ノードを確認すると、テスト データベースがすでに存在していることがわかります。 
データベースを表示します。

ローカルテーブルを作成する (ReplicatedMergeTree)

  1. テーブル作成ステートメントは次のとおりです。

次の 2 つのパラメータを受け入れる ReplicatedMergeTree テーブル エンジンを使用して、クラスター内の各ノードのテスト データベースにローカル テーブル t_local を作成します。

  • zoo_path — Zookeeper 内のテーブルのパス。テーブルの同じシャードの異なるレプリカに対して同じパスが定義されています。

'/clickhouse/tables/{shard}/test/t_local'

  • replica_name — Zookeeper 内のテーブルのレプリカ名
クラスター'snuba-ck-nodes'にCREATE TABLE test .t_localを作成します。
 （
 イベント日付日時、
 カウンターID UInt32 、
 ユーザーID UInt32
 ）
 ENGINE = ReplicatedMergeTree ( '/clickhouse/tables/{shard}/test/t_local' 、 '{replica}' )
 PARTITION BY toYYYYMM (イベント日付)
 ORDER BY (カウンターID 、イベント日付、 intHash32 (ユーザーID ) )
サンプルBY intHash32 ( UserID ) ;
  1. マクロプレースホルダー:

テーブル作成ステートメントのパラメータに含まれるマクロ置換プレースホルダ ({replica} など)。設定ファイルのマクロセクションの値に置き換えられます。

クラスター内のクリックハウス シャードとレプリカ ノードの configmap を表示します。 

 kubectl get configmap - n クラウド- clickhouse | grep クリックハウス

名前 データ 年齢
chi -クリックハウス-共通- configd 6 20時間
chi -クリックハウス-共通-ユーザー6 20時間
chi -クリックハウス-デプロイ- confd - snuba - ck -ノード- 0 - 0 2 20 h
 chi -クリックハウス-デプロイ- confd - snuba - ck -ノード- 0 - 1 2 20 h
 chi -クリックハウス-デプロイ- confd - snuba - ck -ノード- 1 - 0 2 20 h
 chi -クリックハウス-デプロイ- confd - snuba - ck -ノード- 1 - 1 2 20時間
chi -クリックハウス-デプロイ- confd - snuba - ck -ノード- 2 - 0 2 19 h
 chi -クリックハウス-デプロイ- confd - snuba - ck -ノード- 2 - 1 2 19 h

ノード構成値を表示します。 

 kubectl describe configmap chi - clickhouse - deploy - confd - snuba - ck - nodes - 0 - 0 - n cloud - clickhouse

対応する分散テーブルを作成する（分散） 

クラスター'snuba-ck-nodes'にCREATE TABLE test .t_dist を作成します。
 （
 イベント日付日時、
 カウンターID UInt32 、
 ユーザーID UInt32
 ）
 ENGINE = Distributed ( 'snuba-ck-nodes' 、 test 、 t_local 、 rand ( ) ) ;

 # クラスター'snuba-ck-nodes'上のテーブルtest .t_distを削除します。

分散エンジンで使用される 4 つのパラメーターは次のとおりです。

  • cluster - サービス構成内のクラスターの名前 (snuba-ck-nodes)
  • database - リモートデータベースの名前 (テスト)
  • テーブル - リモートテーブル名 (t_local)
  • sharding_key - (オプション) シャーディング キー (CounterID/rand())

次のような関連テーブルを表示します。 

使用テスト;
テーブルを表示します。
 # t_dist
 # ローカル

分散テーブルを通じて複数のデータを挿入します。 

 ＃ 入れる
test .t_distに値( '2022-12-16 00:00:00' , 1 , 1 ) , ( '2023-01-01 00:00:00' , 2 , 2 ) , ( '2023-02-01 00:00:00' , 3 , 3 )を挿入します。

任意のノードからデータをクエリします。 

 test .t_distから*を選択します。

Snuba Engine 向け ClickHouse PaaS

Sentry Helm Charts の分解と分析

Kubernetes Operator に移行する前に、sentry-charts に付属する clickhouse および zookeeper チャートを分解して分析してみましょう。

非公式セントリーヘルムチャート:

  • https://github.com/sentry-kubernetes/charts

彼の Chart.yaml は次のとおりです。 

 APIバージョン: v2
アプリバージョン: 22.11.0
依存関係:
 -条件:ソースマップ.enabled
 名前: memcached
 リポジトリ: https://charts.bitnami.com/bitnami
 バージョン: 6.1.5
 -条件: redis .enabled
 名前:レディス
 リポジトリ: https://charts.bitnami.com/bitnami
 バージョン: 16.12.1
 -条件: kafka.enabled
 名前:カフカ
 リポジトリ: https://charts.bitnami.com/bitnami
 バージョン: 16.3.2
 -条件: clickhouse .enabled
 名前:クリックハウス
 リポジトリ: https://sentry-kubernetes.github.io/charts
 バージョン: 3.2.0
 -条件: zookeeper .enabled
 名前:動物園の飼育員
 リポジトリ: https://charts.bitnami.com/bitnami
 バージョン: 9.0.0
 -エイリアス: rabbitmq
 条件: rabbitmq.enabled
 名前: rabbitmq
 リポジトリ: https://charts.bitnami.com/bitnami
 バージョン: 8.32.2
 -条件: postgresql .enabled
 名前: postgresql
 リポジトリ: https://charts.bitnami.com/bitnami
 バージョン: 10.16.2
 -条件: nginx.enabled
 名前: nginx
 リポジトリ: https://charts.bitnami.com/bitnami
 バージョン: 12.0.4
説明: Kubernetes 用の Helm チャート
メンテナー:
 -名前: Sentry - Kubernetes
名前:セントリー
タイプ:アプリケーション
バージョン: 17.9.0

この sentry-charts は、デプロイメントのためにすべてのミドルウェア helm チャートを結合して依存するため、sentry マイクロサービスおよびミドルウェア クラスターの拡張には適していません。より高度なアプローチとしては、各ミドルウェアにカスタマイズされた Kubernetes Operator (clickhouse-operator など) と独立した K8S クラスターを用意し、外部にサービスを提供するミドルウェア PaaS プラットフォームを形成することです。

ここでは、ミドルウェア チャートを独立した名前空間または個別のクラスター操作に分割します。設計対象:

  • ZooKeeper 名前空間: cloud-zookeeper-paas
  • ClickHouse 名前空間: cloud-clickhouse-paas

ZooKeeper Helm Chart を個別にデプロイする

ここでの zookeeper チャートは bitnami/zookeeper を使用しており、そのウェアハウス アドレスは次のとおりです。

  • https://github.com/bitnami/charts/tree/master/bitnami/zookeeper
  • https://github.com/bitnami/containers/tree/main/bitnami/zookeeper
  • ZooKeeper Operator については別の記事で説明します。
  1. 名前空間を作成します。 
 kubectl作成ns クラウド- zookeeper - paas
  1. values.yaml をカスタマイズするだけです: 
 # Prometheus モニタリングに必要なサービスを公開する
メトリクス:
 コンテナポート: 9141
 有効: true
 ....
 ....
サービス：
 注釈: { }
 クラスターIP : ""
 ベースクライアントポートを無効にする: false
 外部トラフィックポリシー:クラスター
 追加ポート: [ ]
 ヘッドレス:
 注釈: { }
 publishNotReadyAddresses : true
 ロードバランサIP : ""
 ロードバランサーソース範囲: [ ]
 ノードポート:
 クライアント： ""
 TLS : ""
 ポート:
 クライアント: 2181
 選挙: 3888
 フォロワー数: 2888
 3181まで
 セッションアフィニティ:なし
 タイプ: ClusterIP

注: 外部ロード バランサーをサポートするクラウド プロバイダーのサービスを使用する場合は、サービスにロード バランサーを提供するために、サービス タイプを「LoadBalancer」に設定する必要があります。外部ロードバランサからのトラフィックはバックエンド Pod に直接リダイレクトされますが、これがどのように機能するかはクラウド プロバイダーによって異なります。

  1. helm デプロイメント: 
 helm で zookeeper をインストールします。/zookeeper -f値​​.yaml -nクラウド- zookeeper - paas

クラスター内では、zookeeper.cloud-zookeeper-paas.svc.cluster.local:2181 を使用して外部サービスを提供できます。

  1. zkCli は ZooKeeper に接続します: 
 POD_NAME をエクスポートします。 $ ( kubectl get pods --namespace cloud-zookeeper-paas -l "app.kubernetes.io/name=zookeeper,app.kubernetes.io/instance=zookeeper,app.kubernetes.io/compnotallow=zookeeper" -o jsnotallow="{.items[0].metadata.name}")

 kubectl - n クラウド- zookeeper - paas exec - it $POD_NAME -- zkCli.sh

 ＃ テスト
[ zk : localhost : 2181 (接続済み) 0 ] ls /
 [動物園の飼育員]
 [ zk : localhost : 2181 (接続済み) 1 ] ls / zookeeper
 [設定、クォータ]
 [ zk : localhost : 2181 (接続済み) 2 ]終了

# 外部アクセス
# kubectl ポート転送--namespace cloud-zookeeper-paas svc/zookeeper 2181: & zkCli.sh 127.0.0.1:2181
  1. zoo.cfg を表示
 kubectl - n cloud - zookeeper - paas exec - it $POD_NAME -- cat /opt/bitnami/zookeeper/conf/zoo.cfg 
 # 各ティックのミリ秒数
ティックタイム= 2000
 # 初期値であるティック数
# 同期フェーズは
初期制限= 10
 #通過できるティック数
# リクエストを送信し、確認応答を受け取る
同期制限= 5
 # スナップショットが保存されるディレクトリ。
 # / tmpをストレージとして使用しないでください。ここでの/ tmpは単なる
# 例のため。
 dataDir =/ビットナミ/動物園の飼育員/データ
# クライアントが接続するポート
クライアントポート= 2181
 # クライアント接続の最大数。
 # より多くのクライアントを処理する必要がある場合は、これを増やします
最大クライアント接続数= 60
 #
 # 必ずメンテナンスセクションをお読みください
# 自動消去をオンにする前に管理者ガイドを参照してください。
 #
 # https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
 #
 # dataDirに保持するスナップショットの数
自動パージ.snapRetainCount = 3
 #パージタスク間隔（時間単位）
 # 自動パージ機能を無効にするには「0」に設定します
自動パージ.パージ間隔= 0

 ## メトリクスプロバイダー
#
 # https://prometheus.ioメトリクスエクスポーター
metricsProvider .className = org .apache .zookeeper .metrics .prometheus .PrometheusMetricsProvider
 #metricsProvider .httpHost = 0.0 .0 .0
メトリックプロバイダー.httpPort = 9141
メトリックプロバイダー.exportJvmInfo = true
事前割り当てサイズ= 65536
スナップカウント= 100000
最大接続数= 0
許可しない= false
クォーラムListenOnAllIPs = false
 4 lw .commands .whitelist = srvr 、 mntr 、 ruok
最大セッション数= 40000
管理者サーバーポート= 8080
 admin.enableServer = true
サーバー.1 = zookeeper - 0 .zookeeper - headless .cloud - zookeeper - paas .svc .cluster .local : 2888 : 3888 ; 2181
サーバー.2 = zookeeper - 1 .zookeeper - headless .cloud - zookeeper - paas .svc .cluster .local : 2888 : 3888 ; 2181
サーバー.3 = zookeeper - 2 .zookeeper - headless .cloud - zookeeper - paas .svc .cluster .local : 2888 : 3888 ; 2181

ClickHouse Helm Chartを独立してデプロイする

ここでのクリックハウス チャートは、sentry-kubernetes/charts によって管理されているバージョンを使用します。

  • Sentry Snuba は現在、ClickHouse 21.x 以降には対応していません。ここでのミラーバージョンは yandex/clickhouse-server:20.8.19.4 です。
  • https://github.com/sentry-kubernetes/charts/tree/develop/clickhouse
  • ClickHouse Operator + ClickHouse Keeper については、以降の記事で説明します。

組み込みの clickhouse-charts にはいくつか問題があります。 「type:LoadBalancer」または「type:NodePort」の構成を許可するには、サービス部分を変更するだけです。

注: 外部ロード バランサーをサポートするクラウド プロバイダーのサービスを使用する場合は、サービスにロード バランサーを提供するために、サービス タイプを「LoadBalancer」に設定する必要があります。外部ロードバランサからのトラフィックはバックエンド Pod に直接リダイレクトされますが、これがどのように機能するかはクラウド プロバイダーによって異なります。

  1. 名前空間を作成します。 
 kubectl作成ns クラウド-クリックハウス- paas
  1. values.yaml をカスタマイズするだけです:

上記の zoo.cfg 内の 3 つの zookeeper インスタンスのアドレスに注意してください。 

サーバー.1 = zookeeper - 0 .zookeeper - headless .cloud - zookeeper - paas .svc .cluster .local : 2888 : 3888 ; 2181
サーバー.2 = zookeeper - 1 .zookeeper - headless .cloud - zookeeper - paas .svc .cluster .local : 2888 : 3888 ; 2181
サーバー.3 = zookeeper - 2 .zookeeper - headless .cloud - zookeeper - paas .svc .cluster .local : 2888 : 3888 ; 2181 
 # zookeeper_servers を変更する
クリックハウス:
 設定マップ:
 動物園管理サーバ:
 設定:
 -ホストテンプレート: 'zookeeper-0.zookeeper-headless.cloud-zookeeper-paas.svc.cluster.local'
 インデックス:クリックハウス
 ポート: "2181"
 -ホストテンプレート: 'zookeeper-1.zookeeper-headless.cloud-zookeeper-paas.svc.cluster.local'
 インデックス:クリックハウス
 ポート: "2181"
 -ホストテンプレート: 'zookeeper-2.zookeeper-headless.cloud-zookeeper-paas.svc.cluster.local'
 インデックス:クリックハウス
 ポート: "2181"
 有効: true
 操作タイムアウト: "10000"
 セッションタイムアウト: "30000"

 # Prometheus モニタリングに必要なサービスを公開する
メトリクス:
 有効: true

もちろん、ここでは Headless Service を使用する必要はありません。これは同じクラスターの異なる名前空間間の内部アクセスであるため、ClusterIP タイプの Service を入力するだけで済みます。 

 # zookeeper_servers を変更する
クリックハウス:
 設定マップ:
 動物園管理サーバ:
 設定:
 -ホストテンプレート: 'zookeeper.cloud-zookeeper-paas.svc.cluster.local'
 インデックス:クリックハウス
 ポート: "2181"
 有効: true
 操作タイムアウト: "10000"
 セッションタイムアウト: "30000"

 # Prometheus モニタリングに必要なサービスを公開する
メトリクス:
 有効: true
  1. helm デプロイメント: 
 helm で clickhouse をインストールします。 /クリックハウス- f値.yaml - nクラウド-クリックハウス- paas
  1. ClickHouseに接続
 kubectl - n クラウド- clickhouse - paas exec - it clickhouse - 0 --clickhouse-client --multiline --host="clickhouse-1.clickhouse-headless.cloud-clickhouse-paas"
  1. クラスターを検証する
データベースを表示します。
システム.clustersから*を選択します。
システム.zookeeperから*を選択します( path = '/clickhouse' )。

現在のClickHouseクラスタのConfigMap

kubectl get configmap -n cloud-clickhouse-paas | grep クリックハウス

クリックハウス-設定1 28時間
クリックハウス-メトリカ1 28時間
クリックハウス-ユーザー1 28時間

クリックハウス設定(config.xml) 

 <ヤンデックス>
 <パス> / var / lib / clickhouse /</パス>
 <tmp_path> / var / lib / clickhouse / tmp / </tmp_path>
 <user_files_path> / var / lib / clickhouse / user_files / </user_files_path>
 <format_schema_path> / var / lib / clickhouse / format_schemas / </format_schema_path>

 <include_from> /etc/clickhouse-server/metrica.d/metrica.xml </include_from>

 <users_config> users.xml </users_config>

 <表示名>クリックハウス</表示名>
 <listen_host> 0.0 .0 .0 </listen_host>
 <http_ポート> 8123 </http_ポート>
 <tcp_port> 9000 </tcp_port>
 <インターサーバーhttp_ポート> 9009 </インターサーバーhttp_ポート>
 <最大接続数> 4096 </最大接続数>
 <キープアライブタイムアウト> 3 </キープアライブタイムアウト>
 <最大同時クエリ> 100 </最大同時クエリ>
 <非圧縮キャッシュサイズ> 8589934592 </非圧縮キャッシュサイズ>
 <マークキャッシュサイズ> 5368709120 </マークキャッシュサイズ>
 <タイムゾーン> UTC </タイムゾーン>
 < umask > 022 </ umask >
 <mlock_executable>が偽</mlock_executable>
 < remote_servers incl = "clickhouse_remote_servers" optinotallow = "true" />
 < zookeeper incl = "zookeeper-servers" optinotallow = "true" />
 < macros incl = "マクロ" optinotallow = "true" />
 <組み込み辞書の再読み込み間隔> 3600 </組み込み辞書の再読み込み間隔>
 <最大セッションタイムアウト> 3600 </最大セッションタイムアウト>
 <default_session_timeout> 60 </default_session_timeout>
 <内部 DNS キャッシュを無効にする> 1 </内部 DNS キャッシュを無効にする>

 <クエリログ>
 <データベース>システム</データベース>
 <テーブル> query_log </テーブル>
 <partition_by> toYYYYMM (イベント日付) </partition_by>
 <フラッシュ間隔ミリ秒> 7500 </フラッシュ間隔ミリ秒>
 </クエリログ>

 <クエリスレッドログ>
 <データベース>システム</データベース>
 <テーブル> query_thread_log </テーブル>
 <partition_by> toYYYYMM (イベント日付) </partition_by>
 <フラッシュ間隔ミリ秒> 7500 </フラッシュ間隔ミリ秒>
 </クエリ_スレッド_ログ>

 <分散DDL >
 <パス> / clickhouse / task_queue / ddl </パス>
 </分散ddl >
 <ロガー>
 <レベル>トレース</レベル>
 <ログ> /var/log/clickhouse-server/clickhouse-server.log </ログ>
 <エラーログ> /var/log/clickhouse-server/clickhouse-server.err.log </errorlog>
 <サイズ> 1000M </サイズ>
 <カウント> 10 </カウント>
 </ロガー>
 </ヤンデックス>

クリックハウスメトリカ(metrica.xml) 

 <ヤンデックス>
 <動物園の飼育係 -サーバー>
 <ノードインデックス= "クリックハウス" >
 <ホスト> zookeeper - 0 .zookeeper - headless .cloud - zookeeper - paas .svc .cluster .local </ホスト>
 <ポート> 2181 </ポート>
 </ノード>
 <ノードインデックス= "クリックハウス" >
 <ホスト> zookeeper - 1 .zookeeper - headless .cloud - zookeeper - paas .svc .cluster .local </ホスト>
 <ポート> 2181 </ポート>
 </ノード>
 <ノードインデックス= "クリックハウス" >
 <ホスト> zookeeper - 2 .zookeeper - headless .cloud - zookeeper - paas .svc .cluster .local </ホスト>
 <ポート> 2181 </ポート>
 </ノード>
 <セッションタイムアウト> 30000 </セッションタイムアウト>
 <操作タイムアウト ミリ秒> 10000 </操作タイムアウト ミリ秒>
 <ルート></ルート>
 <アイデンティティ></アイデンティティ>
 </動物園管理人-サーバー>
 <クリックハウスリモートサーバー>
 <クリックハウス>
 <破片>
 <レプリカ>
 <内部レプリケーション>が true </内部レプリケーション>
 <ホスト> clickhouse - 0 .clickhouse - headless .cloud - clickhouse - paas .svc .cluster .local </ホスト>
 <ポート> 9000 </ポート>
 <ユーザー>デフォルト</ユーザー>
 <圧縮>真</圧縮>
 </レプリカ>
 </シャード>
 <破片>
 <レプリカ>
 <内部レプリケーション>が true </内部レプリケーション>
 <ホスト> clickhouse - 1 .clickhouse - headless .cloud - clickhouse - paas .svc .cluster .local </ホスト>
 <ポート> 9000 </ポート>
 <ユーザー>デフォルト</ユーザー>
 <圧縮>真</圧縮>
 </レプリカ>
 </シャード>
 <破片>
 <レプリカ>
 <内部レプリケーション>が true </内部レプリケーション>
 <ホスト> clickhouse - 2 .clickhouse - headless .cloud - clickhouse - paas .svc .cluster .local </ホスト>
 <ポート> 9000 </ポート>
 <ユーザー>デフォルト</ユーザー>
 <圧縮>真</圧縮>
 </レプリカ>
 </シャード>
 </クリックハウス>
 </クリックハウスリモートサーバー>

 <マクロ>
 <レプリカ from_env = "ホスト名" ></レプリカ>
 <シャード from_env = "SHARD" ></シャード>
 </マクロ>
 </ヤンデックス>

クリックハウスユーザー(users.xml) 

 <ヤンデックス>
 </ヤンデックス>

セントリーヘルムチャートカスタマイズ

ClickHouse PaaSに接続し、複数のノードを持つ単一のクラスター

values.ymlを変更するだけです

Sentry-charts で clickHouse と zookeeper を無効にする

クリックハウス:
 有効: false
飼育員:
 有効: false

外部Clickhouseを変更する

外部クリックハウス:
 データベース:デフォルト
 ホスト: "clickhouse.cloud-clickhouse-paas.svc.cluster.local"
 httpポート: 8123
 パスワード: ""
 シングルノード: false
 クラスター名: "clickhouse"
 tcpポート: 9000
 ユーザー名:デフォルト

知らせ：

  1. ここでは、マルチノードシャードクラスターをクラスターに接続するだけで、Snuba システムは複数の ClickHouse マルチノード マルチシャード マルチコピー クラスターに接続し、複数のスキーマを異なるクラスターに配布できるように設計されているため、超大規模なスループットを実現できます。これは同じクラスターの異なる名前空間間の内部アクセスであるため、タイプを ClusterIP Sevice として入力するだけです。
  2. singleNode は false に設定する必要があることに注意してください。複数のノードがあるため、clusterNameも指定する必要があります。ソースコード分析:
  3. これは、次のことを決定するために使用されます: 異なる ClickHouse テーブル エンジンなどを使用するかどうかを決定するために使用されます。
  4. もちろん、ClickHouse 自体は別の技術的な方向性であり、ここでは説明しません。

どの移行を実行するか（ローカルのみ、またはローカルと分散テーブル）

クエリの違い - _local テーブルと _dist テーブルのどちらが選択されているかなど

展開する

 helm で sentry をインストールします。 /セントリー- f値.yaml - n セントリー

_local および _dist テーブルと system.zookeeper を確認します。 

 kubectl - n クラウド- clickhouse - paas exec - it clickhouse - 0 --clickhouse-client --multiline --host="clickhouse-1.clickhouse-headless.cloud-clickhouse-paas"

データベースを表示します。

テーブルを表示します。

システム.zookeeperから*を選択します(パスは'/clickhouse'です)。

高度な部品とハイパースケールのスループット

ClickHouse マルチクラスタ/マルチノード/マルチシャード/マルチコピーミドルウェア PaaS にアクセス

VKE LoadBlancer + VKE K8S Cluster + ZooKeeper-Operator + ClickHouse-Operator の複数のセットを個別にデプロイして、スキーマを異なるクラスターとマルチノード シャードに配布します。

Snuba システム設計の分析

テストケースのソースコードを表示して、システム設計と高レベルの構成を理解する

ClickHouse クラスターのシャードとレプリカ間の読み取りおよび書き込みの負荷分散、接続プールなどの問題について。 Snuba は、システム設計とコードに関して十分な考慮と最適化を行っています。

ClickHouse Operatorの独立した複数のクラウドネイティブオーケストレーションクラスターやSnubaシステム設計などの高度な部分については、VIPコラムライブクラスで別途解説します。

<<:  グリーンクラウドコンピューティングは持続可能な開発を推進します

>>:  エッジコンピューティングの導入を成功させるための 5 つの戦略

推薦する

再入荷: BandwagonHost、512M メモリ VPS、年間支払い $19.99、Alipay による支払い

BandwagonHostのVPSの価格はどんどん高くなっているようです。CN2ラインに加わり、その...

タオバオSEOは検索マーケティング業界から注目を集めている

報告書によると、2012年にタオバオの店舗総数は500万を超えた。タオバオ店舗の総数が増加するにつれ...

パブリッククラウドコンピューティングを導入すると、環境への影響を軽減できますか?

インターネットは、特に化石燃料エネルギーの使用により、二酸化炭素排出の大きな原因となっています。一夜...

モバイルインターネット広告に関する8つの事実

過去2年間でモバイル広告は新たな現実をもたらした 少なくとも広告収入から判断すると、Facebook...

4月25日の百度発表「外部リンク判定について」に対する私の意見

4月25日、百度ウェブマスタープラットフォームは「外部リンクの判断について」と題する記事を公開した。...

外部リンク構築について: 価値ある外部リンクには多額の費用がかかりますか?

ウェブサイトの最適化のタイムウィンドウが2013年に入ると、従来の最適化方法、特に外部リンクの最適化...

事例: Amazon.comのホームページには推奨アルゴリズムのせいでプロモーションがほとんどない

Amazon では非常に奇妙な現象が起きています。それは、ウェブサイト上でのプロモーション活動が非常...

周宏義：360 Searchの適正シェアは15%

周紅一（写真提供：Sina Technology）著者は、XueqiuのiUS株式アナリストであるT...

Cube Cloud - 建国記念日 VPS 20% オフ プロモーション/CN2 GIA/韓国 KT/シンガポール BGP

Magic Cube Cloudの建国記念日プロモーションが始まりました: [1] 全品12%オフ、...

スタートアップ企業のロゴデザインは妥協できません！ LOGOデザインネットワークはブランドをより際立たせます

月給5,000～50,000のこれらのプロジェクトはあなたの将来です最近では、自分でビジネスを始める...

クラウドコンピューティング開発の8つのトレンドと予測

現在、我が国のデジタル経済は世界第2位のデジタル経済に躍進しました。デジタル経済時代に入り、人工知能...

ウェブサイトのPR価値を効果的に高める3つの方法

PR値、つまりPageRankは、Webページのレベル技術です。これは Google の創設者である...

bgpto: 専用サーバーのサマープロモーション、日本のマシンは 35% オフ、シンガポールのマシンは 25% オフ、20M の帯域幅、月額 93 ドルから

bgp.to は、日本とシンガポールのデータセンターの独立サーバーに特別プロモーションを提供していま...

「数秒で理解できます！」 JVM 仮想マシンの詳細なグラフィックとテキストの説明!全然難しくない

[[335556]]序文： Javaでオブジェクトや変数などが格納されるメモリ領域を理解することは...

2012年に流行したインターネットマーケティング研修を冷静に見る

2012年は、インターネットが急速に発展した年でした。国内のあらゆる業種の企業が次々とオンラインマー...