but was not found in this run. In case it is a renamed mv that was previously part of this model, drop it manually (!!!) `
-#### データのキャッチアップ
+#### データのキャッチアップ {#data-catch-up}
現在、マテリアライズドビュー (MV) を作成する場合、MV 自体が作成される前に、ターゲットテーブルはまず履歴データで埋められます。
@@ -506,7 +506,7 @@ MV の作成時に履歴データをプリロードしたくない場合は、`c
)}}
```
-#### リフレッシュ可能なマテリアライズドビュー
+#### リフレッシュ可能なマテリアライズドビュー {#refreshable-materialized-views}
[Refreshable Materialized View](https://clickhouse.com/docs/en/materialized-view/refreshable-materialized-view) を利用するには、
MV モデル内で必要に応じて次の設定を調整してください（これらの設定はすべて、
@@ -538,19 +538,19 @@ refreshable 設定オブジェクト内に記述します）。
}}
```
-#### 制限事項
+#### 制限事項 {#limitations}
* 依存関係を持つリフレッシュ可能なマテリアライズドビュー (MV) を ClickHouse で作成する際、指定した依存関係が作成時点で存在しなくても、ClickHouse はエラーをスローしません。代わりに、そのリフレッシュ可能な MV は非アクティブ状態のままとなり、依存関係が満たされるまで更新処理やリフレッシュを開始しません。この挙動は設計によるものですが、必要な依存関係への対応が遅れた場合、データの利用可能性に遅延が生じる可能性があります。ユーザーは、リフレッシュ可能なマテリアライズドビューを作成する前に、すべての依存関係が正しく定義され、実在していることを確認するよう推奨されます。
* 現時点では、MV とその依存関係の間に実際の「dbt linkage」は存在しないため、作成順序は保証されません。
* リフレッシュ可能機能は、同一のターゲットモデルを指す複数の MV に対してはテストされていません。
-### マテリアライゼーション: dictionary（実験的）
+### マテリアライゼーション: dictionary（実験的） {#materialization-dictionary}
ClickHouse の dictionary 用マテリアライゼーションの実装例については、
[https://github.com/ClickHouse/dbt-clickhouse/blob/main/tests/integration/adapter/dictionary/test_dictionary.py](https://github.com/ClickHouse/dbt-clickhouse/blob/main/tests/integration/adapter/dictionary/test_dictionary.py)
のテストを参照してください。
-### マテリアライゼーション: distributed_table（実験的）
+### マテリアライゼーション: distributed_table（実験的） {#materialization-distributed-table}
分散テーブルは次の手順で作成されます:
@@ -563,7 +563,7 @@ ClickHouse の dictionary 用マテリアライゼーションの実装例につ
* 下流のインクリメンタルマテリアライゼーション処理が正しく実行されるようにするため、dbt-clickhouse のクエリには自動的に `insert_distributed_sync = 1` 設定が含まれるようになりました。これにより、一部の分散テーブルへの INSERT が想定より遅くなる可能性があります。
-#### 分散テーブルモデルの例
+#### 分散テーブルモデルの例 {#distributed-table-model-example}
```sql
{{
@@ -579,7 +579,7 @@ select id, created_at, item
from {{ source('db', 'table') }}
```
-#### 生成されたマイグレーション
+#### 生成されたマイグレーション {#distributed-table-generated-migrations}
```sql
CREATE TABLE db.table_local on cluster cluster (
@@ -599,7 +599,7 @@ CREATE TABLE db.table on cluster cluster (
ENGINE = Distributed ('cluster', 'db', 'table_local', cityHash64(id));
```
-### materialization: distributed_incremental (experimental)
+### materialization: distributed_incremental (experimental) {#materialization-distributed-incremental}
分散テーブルと同様の考え方に基づくインクリメンタルモデルであり、主な難しさはすべてのインクリメンタル戦略を正しく処理することにあります。
@@ -610,7 +610,7 @@ CREATE TABLE db.table on cluster cluster (
分散テーブルはデータを保持しないため、置き換えられるのはシャードテーブルのみです。
分散テーブルが再読み込みされるのは、`full_refresh` モードが有効になっている場合か、テーブル構造が変更された可能性がある場合のみです。
-#### 分散インクリメンタルモデルの例
+#### 分散インクリメンタルモデルの例 {#distributed-incremental-model-example}
```sql
@@ -627,7 +627,7 @@ select id, created_at, item
from {{ source('db', 'table') }}
```
-#### 自動生成されたマイグレーション
+#### 自動生成されたマイグレーション {#distributed-incremental-generated-migrations}
```sql
CREATE TABLE db.table_local on cluster cluster (
@@ -646,7 +646,7 @@ CREATE TABLE db.table on cluster cluster (
ENGINE = Distributed ('cluster', 'db', 'table_local', cityHash64(id));
```
-### スナップショット
+### スナップショット {#snapshot}
dbt のスナップショット機能を使用すると、可変なモデルに対する変更を時間の経過とともに記録できます。これにより、アナリストはモデルに対して、モデルの以前の状態を「過去にさかのぼって」確認できる時点指定クエリを実行できます。この機能は ClickHouse コネクタでサポートされており、次の構文で設定します。
@@ -665,7 +665,7 @@ dbt のスナップショット機能を使用すると、可変なモデルに
設定の詳細については、[snapshot configs](https://docs.getdbt.com/docs/build/snapshots#snapshot-configs) のリファレンスページを参照してください。
-### コントラクトと制約
+### コントラクトと制約 {#contracts-and-constraints}
厳密なカラム型コントラクトのみがサポートされます。たとえば、UInt32 カラム型のコントラクトがある場合、モデルが
UInt64 もしくはその他の整数型を返すと失敗します。
@@ -673,9 +673,9 @@ ClickHouse は、テーブル／モデル全体に対する `CHECK` 制約*の
およびカラムレベルの CHECK 制約はサポートされません。
（プライマリキー／ORDER BY キーについては ClickHouse のドキュメントを参照してください。）
-### 追加の ClickHouse マクロ
+### 追加の ClickHouse マクロ {#additional-clickhouse-macros}
-#### モデルのマテリアライゼーション用ユーティリティマクロ
+#### モデルのマテリアライゼーション用ユーティリティマクロ {#model-materialization-utility-macros}
ClickHouse 固有のテーブルおよびビューを作成しやすくするために、次のマクロが含まれています。
@@ -692,7 +692,7 @@ ClickHouse 固有のテーブルおよびビューを作成しやすくするた
* `ttl_config` -- `ttl` モデル設定プロパティを使用して、ClickHouse のテーブル TTL 式を割り当てます。デフォルトでは
TTL は割り当てられません。
-#### s3Source ヘルパーマクロ
+#### s3Source ヘルパーマクロ {#s3source-helper-macro}
`s3source` マクロは、ClickHouse の S3 テーブル関数を使用して S3 から直接 ClickHouse データを選択する処理を簡素化します。
このマクロは、
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/dbt/guides.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/dbt/guides.md
index 2522503b2af..d9fbf9ae53c 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/dbt/guides.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/dbt/guides.md
@@ -20,7 +20,7 @@ import dbt_07 from '@site/static/images/integrations/data-ingestion/etl-tools/db
import ClickHouseSupportedBadge from '@theme/badges/ClickHouseSupported';
-# ガイド
+# ガイド {#guides}
@@ -39,13 +39,13 @@ import ClickHouseSupportedBadge from '@theme/badges/ClickHouseSupported';
-## セットアップ
+## セットアップ {#setup}
環境を準備するには、[dbt と ClickHouse アダプターのセットアップ](/integrations/dbt) セクションの手順に従ってください。
**重要: 以下は python 3.9 環境で検証されています。**
-### ClickHouse の準備
+### ClickHouse の準備 {#prepare-clickhouse}
dbt はリレーショナル性の高いデータのモデリングに優れています。例として、次のようなリレーショナルスキーマを持つ小さな IMDB データセットを用意しています。このデータセットは [relational dataset repository](https://relational.fit.cvut.cz/dataset/IMDb) に由来します。これは dbt で一般的に使われるスキーマと比べると単純ですが、扱いやすいサンプルになっています。
@@ -672,7 +672,7 @@ SELECT * FROM imdb_dbt.actor_summary ORDER BY num_movies DESC LIMIT 2;
+------+-------------------+----------+------------------+------+---------+-------------------+
```
-### 内部動作
+### 内部動作 {#internals}
上記の増分更新を実現するために実行されたステートメントは、ClickHouse のクエリログを参照することで確認できます。
@@ -694,7 +694,7 @@ AND event_time > subtractMinutes(now(), 15) ORDER BY event_time LIMIT 100;
この戦略は、非常に大きなモデルでは問題が発生する可能性があります。詳細については [Limitations](/integrations/dbt#limitations) を参照してください。
-### Append Strategy（挿入のみモード）
+### Append Strategy（挿入のみモード） {#append-strategy-inserts-only-mode}
インクリメンタルモデルにおける大規模データセットの制約を回避するために、アダプターは dbt の設定パラメータ `incremental_strategy` を使用します。これは `append` に設定できます。これを設定すると、更新された行はターゲットテーブル（`imdb_dbt.actor_summary`）に直接挿入され、一時テーブルは作成されません。
注意: Append only モードでは、データが不変であるか、重複を許容できる必要があります。更新された行をサポートするインクリメンタルテーブルモデルが必要な場合、このモードは使用しないでください。
@@ -796,7 +796,7 @@ WHERE id > (SELECT max(id) FROM imdb_dbt.actor_summary) OR updated_at > (SELECT
この実行では、新しい行だけが直接 `imdb_dbt.actor_summary` テーブルに追加され、テーブルの作成は行われません。
-### 削除および挿入モード（実験的）
+### 削除および挿入モード（実験的） {#deleteinsert-mode-experimental}
歴史的には、ClickHouse は非同期の [Mutations](/sql-reference/statements/alter/index.md) としてのみ、更新および削除を限定的にサポートしていました。これらは非常に I/O 負荷が高く、一般的には避けるべきです。
@@ -821,7 +821,7 @@ This process is shown below:
-### insert_overwrite mode (experimental)
+### insert_overwrite mode (experimental) {#insert_overwrite-mode-experimental}
Performs the following steps:
@@ -840,7 +840,7 @@ This approach has the following advantages:
-## スナップショットの作成
+## スナップショットの作成 {#creating-a-snapshot}
dbt のスナップショット機能を使用すると、更新可能なモデルに対する変更を時間の経過とともに記録できます。これにより、アナリストはモデルに対して任意時点のクエリを実行し、モデルの過去の状態を「遡って」確認できるようになります。これは、行が有効であった期間を記録する from 日付列および to 日付列を持つ [タイプ 2 のゆっくり変化する次元 (Slowly Changing Dimensions)](https://en.wikipedia.org/wiki/Slowly_changing_dimension#Type_2:_add_new_row) を使用して実現されます。この機能は ClickHouse アダプターでサポートされており、以下に示します。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/dbt/index.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/dbt/index.md
index 8439abea8c7..f228f238aba 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/dbt/index.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/dbt/index.md
@@ -95,9 +95,9 @@ ClickHouse 向けの[現在のアダプタ](https://github.com/silentsokolov/dbt
-## dbt と ClickHouse アダプターのセットアップ
+## dbt と ClickHouse アダプターのセットアップ {#setup-of-dbt-and-the-clickhouse-adapter}
-### dbt-core と dbt-clickhouse のインストール
+### dbt-core と dbt-clickhouse のインストール {#install-dbt-core-and-dbt-clickhouse}
dbt のコマンドラインインターフェイス (CLI) のインストール方法にはいくつかの選択肢があり、詳細は[こちら](https://docs.getdbt.com/dbt-cli/install/overview)に記載されています。dbt と dbt-clickhouse の両方をインストールするには、`pip` の利用を推奨します。
@@ -105,7 +105,7 @@ dbt のコマンドラインインターフェイス (CLI) のインストール
pip install dbt-core dbt-clickhouse
```
-### ClickHouse インスタンスへの接続情報を dbt に提供する
+### ClickHouse インスタンスへの接続情報を dbt に提供する {#provide-dbt-with-the-connection-details-for-our-clickhouse-instance}
`~/.dbt/profiles.yml` ファイル内で `clickhouse-service` プロファイルを構成し、`schema`、`host`、`port`、`user`、`password` プロパティを指定します。接続構成オプションの全一覧は、[機能と設定](/integrations/dbt/features-and-configurations) ページに記載されています。
@@ -125,7 +125,7 @@ clickhouse-service:
secure: True # TLS(ネイティブプロトコル)またはHTTPS(httpプロトコル)を使用
```
-### dbt プロジェクトを作成する
+### dbt プロジェクトを作成する {#create-a-dbt-project}
これで、このプロファイルを既存のいずれかのプロジェクトで使用することも、次の手順で新しいプロジェクトを作成することもできます。
@@ -139,17 +139,17 @@ dbt init project_name
profile: 'clickhouse-service'
```
-### 接続テスト
+### 接続テスト {#test-connection}
CLI で `dbt debug` を実行し、dbt が ClickHouse に接続できるかどうかを確認します。レスポンスに `Connection test: [OK connection ok]` が含まれていることを確認し、接続が成功していることを確かめてください。
ClickHouse と dbt の連携方法の詳細については、[ガイドページ](/integrations/dbt/guides) を参照してください。
-### モデルのテストとデプロイ (CI/CD)
+### モデルのテストとデプロイ (CI/CD) {#testing-and-deploying-your-models-ci-cd}
dbt プロジェクトをテストおよびデプロイする方法は多数あります。dbt では、[ベストプラクティスとされるワークフロー](https://docs.getdbt.com/best-practices/best-practice-workflows#pro-tips-for-workflows) や [CI ジョブ](https://docs.getdbt.com/docs/deploy/ci-jobs) に関する提案を提供しています。ここではいくつかの戦略について説明しますが、これらの戦略はユースケースに合わせて大きく調整する必要がある場合がある点に注意してください。
-#### シンプルなデータテストおよびユニットテストによる CI/CD
+#### シンプルなデータテストおよびユニットテストによる CI/CD {#ci-with-simple-data-tests-and-unit-tests}
CI パイプラインを手軽に立ち上げる方法の 1 つは、ジョブ内で ClickHouse クラスターを起動し、そのクラスターに対してモデルを実行することです。モデルを実行する前に、このクラスターにデモデータを挿入できます。[seed](https://docs.getdbt.com/reference/commands/seed) を使って、本番データのサブセットをステージング環境に投入することもできます。
@@ -157,7 +157,7 @@ CI パイプラインを手軽に立ち上げる方法の 1 つは、ジョブ
CD ステップは、本番の ClickHouse クラスターに対して `dbt build` を実行するだけのシンプルなものにできます。
-#### より包括的な CI/CD ステージ: 最新のデータを使用し、影響を受けたモデルのみをテスト
+#### より包括的な CI/CD ステージ: 最新のデータを使用し、影響を受けたモデルのみをテスト {#more-complete-ci-stage}
一般的な戦略として、変更されたモデル (およびその上流・下流の依存関係) のみを再デプロイする [Slim CI](https://docs.getdbt.com/best-practices/best-practice-workflows#run-only-modified-models-to-test-changes-slim-ci) ジョブを利用する方法があります。このアプローチでは、本番実行の成果物 (例: [dbt manifest](https://docs.getdbt.com/reference/artifacts/manifest-json)) を利用して、プロジェクトの実行時間を短縮し、環境間でスキーマのずれが生じないようにします。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/dlt-and-clickhouse.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/dlt-and-clickhouse.md
index 6207100b4fe..c64f4515c65 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/dlt-and-clickhouse.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/dlt-and-clickhouse.md
@@ -10,7 +10,7 @@ doc_type: 'guide'
import PartnerBadge from '@theme/badges/PartnerBadge';
-# dlt を ClickHouse に接続する
+# dlt を ClickHouse に接続する {#connect-dlt-to-clickhouse}
@@ -18,9 +18,9 @@ import PartnerBadge from '@theme/badges/PartnerBadge';
-## ClickHouse と併せて dlt をインストールする
+## ClickHouse と併せて dlt をインストールする {#install-dlt-with-clickhouse}
-### ClickHouse の依存関係付きで `dlt` ライブラリをインストールするには:
+### ClickHouse の依存関係付きで `dlt` ライブラリをインストールするには: {#to-install-the-dlt-library-with-clickhouse-dependencies}
```bash
pip install "dlt[clickhouse]"
@@ -99,7 +99,7 @@ ClickHouseサーバーが`http_port`で指定されたポートでHTTP接続を
```bash
-# tomlファイルの先頭、セクション開始前に記述してください。
+# tomlファイルの先頭、セクション開始前に記述してください。 {#keep-it-at-the-top-of-your-toml-file-before-any-section-starts}
destination.clickhouse.credentials="clickhouse://dlt:Dlt*12345789234567@localhost:9000/dlt?secure=1"
```
@@ -157,7 +157,7 @@ ClickHouse は、以下のGCS テーブル関数 によって自動的に処理されます。
@@ -241,10 +241,10 @@ dlt はこれらの認証情報を ClickHouse に渡し、認証および GCS
* filesystem destination を S3 互換モードで GCS と連携できるようにする
* Google Cloud Storage ステージングエリアのサポート
-### dbt サポート
+### dbt サポート {#dbt-support}
dbt との連携は、一般に dbt-clickhouse を通じてサポートされています。
-### `dlt` state の同期
+### `dlt` state の同期 {#syncing-of-dlt-state}
この destination は、dlt state の同期を完全にサポートしています。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/fivetran/index.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/fivetran/index.md
index 254b24d6158..9f1ed82585a 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/fivetran/index.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/fivetran/index.md
@@ -14,7 +14,7 @@ keywords: ['fivetran', 'データ移動', 'ETL', 'ClickHouse 宛先', '自動化
import ClickHouseSupportedBadge from '@theme/badges/ClickHouseSupported';
-# Fivetran と ClickHouse Cloud
+# Fivetran と ClickHouse Cloud {#fivetran-and-clickhouse-cloud}
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/nifi-and-clickhouse.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/nifi-and-clickhouse.md
index 05f92a7548d..bd4aff29010 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/nifi-and-clickhouse.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/nifi-and-clickhouse.md
@@ -11,7 +11,7 @@ integration:
- category: 'data_ingestion'
---
-import ConnectionDetails from '@site/docs/_snippets/_gather_your_details_http.mdx';
+import ConnectionDetails from '@site/i18n/jp/docusaurus-plugin-content-docs/current/_snippets/_gather_your_details_http.mdx';
import Image from '@theme/IdealImage';
import nifi01 from '@site/static/images/integrations/data-ingestion/etl-tools/nifi_01.png';
import nifi02 from '@site/static/images/integrations/data-ingestion/etl-tools/nifi_02.png';
@@ -31,7 +31,7 @@ import nifi15 from '@site/static/images/integrations/data-ingestion/etl-tools/ni
import CommunityMaintainedBadge from '@theme/badges/CommunityMaintained';
-# Apache NiFiをClickHouseに接続する
+# Apache NiFiをClickHouseに接続する {#connect-apache-nifi-to-clickhouse}
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/vector-to-clickhouse.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/vector-to-clickhouse.md
index 934779a27bd..fad3e4819f6 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/vector-to-clickhouse.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/etl-tools/vector-to-clickhouse.md
@@ -18,8 +18,7 @@ import vector01 from '@site/static/images/integrations/data-ingestion/etl-tools/
import vector02 from '@site/static/images/integrations/data-ingestion/etl-tools/vector_02.png';
import PartnerBadge from '@theme/badges/PartnerBadge';
-
-# Vector と ClickHouse の統合
+# Vector と ClickHouse の統合 {#integrating-vector-with-clickhouse}
@@ -31,214 +30,202 @@ ClickHouse は、優れた圧縮率（ログでは最大 [170x](https://clickhou
**前提条件:**
-- ClickHouse がすでに稼働していること
-- Vector がインストールされていること
+* ClickHouse がすでに稼働していること
+* Vector がインストールされていること
+ ## データベースとテーブルを作成する {#1-create-a-database-and-table}
+ ログイベントを保存するためのテーブルを定義します。
-## データベースとテーブルを作成する
-
-ログイベントを保存するためのテーブルを定義します。
-
-1. まず、`nginxdb` という名前の新しいデータベースを作成します:
-
-```sql
-CREATE DATABASE IF NOT EXISTS nginxdb
-```
-
-2. ログイベント全体を1つの文字列として挿入します。もちろん、この形式はログデータを分析するのに適したものではありませんが、その点は後ほど***マテリアライズドビュー***を使って解決していきます。
-
-```sql
-CREATE TABLE IF NOT EXISTS nginxdb.access_logs (
- message String
-)
-ENGINE = MergeTree()
-ORDER BY tuple()
-```
-
-:::note
-**ORDER BY** は、まだ主キーが不要なため、空のタプルである **tuple()** に設定されています。
-:::
-
-
-## Nginx を構成する
-
-このステップでは、Nginx のログ出力を構成する方法を説明します。
-
-1. 次の `access_log` プロパティは、ログを **combined** 形式で `/var/log/nginx/my_access.log` に出力します。
- この値は `nginx.conf` ファイルの `http` セクションに記述します：
-
-```bash
-http {
- include /etc/nginx/mime.types;
- default_type application/octet-stream;
- access_log /var/log/nginx/my_access.log combined;
- sendfile on;
- keepalive_timeout 65;
- include /etc/nginx/conf.d/*.conf;
-}
-```
-
-2. `nginx.conf` を変更した場合は、必ず Nginx を再起動してください。
-
-3. Web サーバー上のページにアクセスして、アクセスログにログイベントをいくつか生成してください。
- **combined** 形式のログは次のようになります。
-
-```bash
-192.168.208.1 - - [12/Oct/2021:03:31:44 +0000] "GET / HTTP/1.1" 200 615 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"
-192.168.208.1 - - [12/Oct/2021:03:31:44 +0000] "GET /favicon.ico HTTP/1.1" 404 555 "http://localhost/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"
-192.168.208.1 - - [12/Oct/2021:03:31:49 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"
-```
-
+ 1. まず、`nginxdb` という名前の新しいデータベースを作成します:
-## Vector を設定する
+ ```sql
+ CREATE DATABASE IF NOT EXISTS nginxdb
+ ```
-Vector はログ、メトリクス、トレース（**sources** と呼ばれます）を収集・変換・ルーティングし、ClickHouse を含む多数の異なるベンダー（**sinks** と呼ばれます）へ送信します。
-Source と sink は **vector.toml** という名前の設定ファイルで定義します。
+ 2. ログイベント全体を1つの文字列として挿入します。もちろん、この形式はログデータを分析するのに適したものではありませんが、その点は後ほど***マテリアライズドビュー***を使って解決していきます。
-1. 次の **vector.toml** ファイルでは、**my_access.log** の末尾を tail する **file** 型の **source** と、上で定義した **access_logs** テーブルを **sink** として定義しています。
+ ```sql
+ CREATE TABLE IF NOT EXISTS nginxdb.access_logs (
+ message String
+ )
+ ENGINE = MergeTree()
+ ORDER BY tuple()
+ ```
-```bash
-[sources.nginx_logs]
-type = "file"
-include = [ "/var/log/nginx/my_access.log" ]
-read_from = "end"
+ :::note
+ **ORDER BY** は、まだ主キーが不要なため、空のタプルである **tuple()** に設定されています。
+ :::
-[sinks.clickhouse]
-type = "clickhouse"
-inputs = ["nginx_logs"]
-endpoint = "http://clickhouse-server:8123"
-database = "nginxdb"
-table = "access_logs"
-skip_unknown_fields = true
-```
+ ## Nginx を構成する {#2--configure-nginx}
-2. 上記の構成を使用して Vector を起動します。ソースおよびシンクの定義についての詳細は、Vector の[ドキュメント](https://vector.dev/docs/)を参照してください。
+ このステップでは、Nginx のログ出力を構成する方法を説明します。
-3. 次のクエリを実行して、アクセスログが ClickHouse に取り込まれていることを確認します。テーブル内にアクセスログが表示されるはずです。
+ 1. 次の `access_log` プロパティは、ログを **combined** 形式で `/var/log/nginx/my_access.log` に出力します。
+ この値は `nginx.conf` ファイルの `http` セクションに記述します：
-```sql
-SELECT * FROM nginxdb.access_logs
-```
+ ```bash
+ http {
+ include /etc/nginx/mime.types;
+ default_type application/octet-stream;
+ access_log /var/log/nginx/my_access.log combined;
+ sendfile on;
+ keepalive_timeout 65;
+ include /etc/nginx/conf.d/*.conf;
+ }
+ ```
-
+ 2. `nginx.conf` を変更した場合は、必ず Nginx を再起動してください。
+ 3. Web サーバー上のページにアクセスして、アクセスログにログイベントをいくつか生成してください。
+ **combined** 形式のログは次のようになります。
-## ログをパースする
+ ```bash
+ 192.168.208.1 - - [12/Oct/2021:03:31:44 +0000] "GET / HTTP/1.1" 200 615 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"
+ 192.168.208.1 - - [12/Oct/2021:03:31:44 +0000] "GET /favicon.ico HTTP/1.1" 404 555 "http://localhost/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"
+ 192.168.208.1 - - [12/Oct/2021:03:31:49 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"
+ ```
-ログを ClickHouse に保存できるのは有用ですが、各イベントを 1 つの文字列として保存するだけでは、十分なデータ分析は行えません。
-次に、[マテリアライズドビュー](/materialized-view/incremental-materialized-view) を使用してログイベントをどのようにパースするかを見ていきます。
+ ## Vector を設定する {#3-configure-vector}
-**マテリアライズドビュー** は、SQL における INSERT トリガーと同様に機能します。ソーステーブルにデータ行が挿入されると、マテリアライズドビューはそれらの行を変換し、その結果をターゲットテーブルに挿入します。
-マテリアライズドビューを設定して、**access_logs** 内のログイベントのパース済み表現を生成できます。
-そのようなログイベントの 1 つの例を以下に示します。
+ Vector はログ、メトリクス、トレース（**sources** と呼ばれます）を収集・変換・ルーティングし、ClickHouse を含む多数の異なるベンダー（**sinks** と呼ばれます）へ送信します。
+ Source と sink は **vector.toml** という名前の設定ファイルで定義します。
-```bash
-192.168.208.1 - - [12/Oct/2021:15:32:43 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"
-```
-
-ClickHouse には、上記の文字列を解析するためのさまざまな関数があります。[`splitByWhitespace`](/sql-reference/functions/splitting-merging-functions#splitByWhitespace) 関数は、文字列を空白文字で分割し、各トークンを配列で返します。
-動作を確認するには、次のコマンドを実行します。
-
-```sql title="Query"
-SELECT splitByWhitespace('192.168.208.1 - - [12/Oct/2021:15:32:43 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"')
-```
-
-```text title="Response"
-["192.168.208.1","-","-","[12/Oct/2021:15:32:43","+0000]","\"GET","/","HTTP/1.1\"","304","0","\"-\"","\"Mozilla/5.0","(Macintosh;","Intel","Mac","OS","X","10_15_7)","AppleWebKit/537.36","(KHTML,","like","Gecko)","Chrome/93.0.4577.63","Safari/537.36\""]
-```
-
-いくつかの文字列には余分な文字が含まれており、ユーザーエージェント（ブラウザ情報）は解析する必要はありませんでしたが、
-結果として得られた配列は、必要なものにかなり近い形になっています。
-
-`splitByWhitespace` と同様に、[`splitByRegexp`](/sql-reference/functions/splitting-merging-functions#splitByRegexp) 関数は、正規表現に基づいて文字列を配列に分割します。
-次のコマンドを実行します。2 つの文字列が返されます。
-
-```sql
-SELECT splitByRegexp('\S \d+ "([^"]*)"', '192.168.208.1 - - [12/Oct/2021:15:32:43 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"')
-```
-
-2 番目に返される文字列が、ログから正常に解析されたユーザーエージェントであることに注目してください。
-
-```text
-["192.168.208.1 - - [12/Oct/2021:15:32:43 +0000] \"GET / HTTP/1.1\" 30"," \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36\""]
-```
-
-最終的な `CREATE MATERIALIZED VIEW` コマンドを見る前に、データをクリーンアップするために使用する、いくつかの関数をさらに確認しておきます。
-たとえば、`RequestMethod` の値は先頭に不要な二重引用符が付いた `"GET` になっています。
-この二重引用符を削除するには、[`trimBoth`（エイリアス `trim`）](/sql-reference/functions/string-functions#trimBoth) 関数を使用できます。
-
-```sql
-SELECT trim(LEADING '"' FROM '"GET')
-```
-
-時刻文字列は先頭に角括弧が付いており、ClickHouse が日付として解析できる形式にもなっていません。
-しかし、区切り文字をコロン（**:**）からカンマ（**,**）に変更すると、問題なく解析できるようになります:
-
-```sql
-SELECT parseDateTimeBestEffort(replaceOne(trim(LEADING '[' FROM '[12/Oct/2021:15:32:43'), ':', ' '))
-```
-
-
-これでマテリアライズドビューを定義する準備が整いました。
-以下の定義には `POPULATE` 句が含まれており、これは **access_logs** に既に存在する行がすぐに処理され、その場で挿入されることを意味します。
-次の SQL ステートメントを実行してください:
-
-```sql
-CREATE MATERIALIZED VIEW nginxdb.access_logs_view
-(
- RemoteAddr String,
- Client String,
- RemoteUser String,
- TimeLocal DateTime,
- RequestMethod String,
- Request String,
- HttpVersion String,
- Status Int32,
- BytesSent Int64,
- UserAgent String
-)
-ENGINE = MergeTree()
-ORDER BY RemoteAddr
-POPULATE AS
-WITH
- splitByWhitespace(message) as split,
- splitByRegexp('\S \d+ "([^"]*)"', message) as referer
-SELECT
- split[1] AS RemoteAddr,
- split[2] AS Client,
- split[3] AS RemoteUser,
- parseDateTimeBestEffort(replaceOne(trim(LEADING '[' FROM split[4]), ':', ' ')) AS TimeLocal,
- trim(LEADING '"' FROM split[6]) AS RequestMethod,
- split[7] AS Request,
- trim(TRAILING '"' FROM split[8]) AS HttpVersion,
- split[9] AS Status,
- split[10] AS BytesSent,
- trim(BOTH '"' from referer[2]) AS UserAgent
-FROM
- (SELECT message FROM nginxdb.access_logs)
-```
-
-続いて、正しく動作しているか確認します。
-アクセスログが列ごとにきれいにパースされて表示されるはずです:
-
-```sql
-SELECT * FROM nginxdb.access_logs_view
-```
-
-
-
-:::note
-上記のレッスンではデータを 2 つのテーブルに保存しましたが、最初の `nginxdb.access_logs` テーブルを [`Null`](/engines/table-engines/special/null) テーブルエンジンを使用するように変更することもできます。
-パース済みデータは変わらず `nginxdb.access_logs_view` テーブルに格納されますが、生のデータはテーブルには保存されません。
-:::
+ 1. 次の **vector.toml** ファイルでは、**my_access.log** の末尾を tail する **file** 型の **source** と、上で定義した **access_logs** テーブルを **sink** として定義しています。
+ ```bash
+ [sources.nginx_logs]
+ type = "file"
+ include = [ "/var/log/nginx/my_access.log" ]
+ read_from = "end"
+
+ [sinks.clickhouse]
+ type = "clickhouse"
+ inputs = ["nginx_logs"]
+ endpoint = "http://clickhouse-server:8123"
+ database = "nginxdb"
+ table = "access_logs"
+ skip_unknown_fields = true
+ ```
+
+ 2. 上記の構成を使用して Vector を起動します。ソースおよびシンクの定義についての詳細は、Vector の[ドキュメント](https://vector.dev/docs/)を参照してください。
+
+ 3. 次のクエリを実行して、アクセスログが ClickHouse に取り込まれていることを確認します。テーブル内にアクセスログが表示されるはずです。
+
+ ```sql
+ SELECT * FROM nginxdb.access_logs
+ ```
+
+
+
+ ## ログをパースする {#4-parse-the-logs}
+
+ ログを ClickHouse に保存できるのは有用ですが、各イベントを 1 つの文字列として保存するだけでは、十分なデータ分析は行えません。
+ 次に、[マテリアライズドビュー](/materialized-view/incremental-materialized-view) を使用してログイベントをどのようにパースするかを見ていきます。
+
+ **マテリアライズドビュー** は、SQL における INSERT トリガーと同様に機能します。ソーステーブルにデータ行が挿入されると、マテリアライズドビューはそれらの行を変換し、その結果をターゲットテーブルに挿入します。
+ マテリアライズドビューを設定して、**access_logs** 内のログイベントのパース済み表現を生成できます。
+ そのようなログイベントの 1 つの例を以下に示します。
+
+ ```bash
+ 192.168.208.1 - - [12/Oct/2021:15:32:43 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"
+ ```
+
+ ClickHouse には、上記の文字列を解析するためのさまざまな関数があります。[`splitByWhitespace`](/sql-reference/functions/splitting-merging-functions#splitByWhitespace) 関数は、文字列を空白文字で分割し、各トークンを配列で返します。
+ 動作を確認するには、次のコマンドを実行します。
+
+ ```sql title="Query"
+ SELECT splitByWhitespace('192.168.208.1 - - [12/Oct/2021:15:32:43 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"')
+ ```
+
+ ```text title="Response"
+ ["192.168.208.1","-","-","[12/Oct/2021:15:32:43","+0000]","\"GET","/","HTTP/1.1\"","304","0","\"-\"","\"Mozilla/5.0","(Macintosh;","Intel","Mac","OS","X","10_15_7)","AppleWebKit/537.36","(KHTML,","like","Gecko)","Chrome/93.0.4577.63","Safari/537.36\""]
+ ```
+
+ いくつかの文字列には余分な文字が含まれており、ユーザーエージェント（ブラウザ情報）は解析する必要はありませんでしたが、
+ 結果として得られた配列は、必要なものにかなり近い形になっています。
+
+ `splitByWhitespace` と同様に、[`splitByRegexp`](/sql-reference/functions/splitting-merging-functions#splitByRegexp) 関数は、正規表現に基づいて文字列を配列に分割します。
+ 次のコマンドを実行します。2 つの文字列が返されます。
+
+ ```sql
+ SELECT splitByRegexp('\S \d+ "([^"]*)"', '192.168.208.1 - - [12/Oct/2021:15:32:43 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36"')
+ ```
+
+ 2 番目に返される文字列が、ログから正常に解析されたユーザーエージェントであることに注目してください。
+
+ ```text
+ ["192.168.208.1 - - [12/Oct/2021:15:32:43 +0000] \"GET / HTTP/1.1\" 30"," \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36\""]
+ ```
+
+ 最終的な `CREATE MATERIALIZED VIEW` コマンドを見る前に、データをクリーンアップするために使用する、いくつかの関数をさらに確認しておきます。
+ たとえば、`RequestMethod` の値は先頭に不要な二重引用符が付いた `"GET` になっています。
+ この二重引用符を削除するには、[`trimBoth`（エイリアス `trim`）](/sql-reference/functions/string-functions#trimBoth) 関数を使用できます。
+
+ ```sql
+ SELECT trim(LEADING '"' FROM '"GET')
+ ```
+
+ 時刻文字列は先頭に角括弧が付いており、ClickHouse が日付として解析できる形式にもなっていません。
+ しかし、区切り文字をコロン（**:**）からカンマ（**,**）に変更すると、問題なく解析できるようになります:
+
+ ```sql
+ SELECT parseDateTimeBestEffort(replaceOne(trim(LEADING '[' FROM '[12/Oct/2021:15:32:43'), ':', ' '))
+ ```
+
+ これでマテリアライズドビューを定義する準備が整いました。
+ 以下の定義には `POPULATE` 句が含まれており、これは **access_logs** に既に存在する行がすぐに処理され、その場で挿入されることを意味します。
+ 次の SQL ステートメントを実行してください:
+
+ ```sql
+ CREATE MATERIALIZED VIEW nginxdb.access_logs_view
+ (
+ RemoteAddr String,
+ Client String,
+ RemoteUser String,
+ TimeLocal DateTime,
+ RequestMethod String,
+ Request String,
+ HttpVersion String,
+ Status Int32,
+ BytesSent Int64,
+ UserAgent String
+ )
+ ENGINE = MergeTree()
+ ORDER BY RemoteAddr
+ POPULATE AS
+ WITH
+ splitByWhitespace(message) as split,
+ splitByRegexp('\S \d+ "([^"]*)"', message) as referer
+ SELECT
+ split[1] AS RemoteAddr,
+ split[2] AS Client,
+ split[3] AS RemoteUser,
+ parseDateTimeBestEffort(replaceOne(trim(LEADING '[' FROM split[4]), ':', ' ')) AS TimeLocal,
+ trim(LEADING '"' FROM split[6]) AS RequestMethod,
+ split[7] AS Request,
+ trim(TRAILING '"' FROM split[8]) AS HttpVersion,
+ split[9] AS Status,
+ split[10] AS BytesSent,
+ trim(BOTH '"' from referer[2]) AS UserAgent
+ FROM
+ (SELECT message FROM nginxdb.access_logs)
+ ```
+
+ 続いて、正しく動作しているか確認します。
+ アクセスログが列ごとにきれいにパースされて表示されるはずです:
+
+ ```sql
+ SELECT * FROM nginxdb.access_logs_view
+ ```
+
+
+
+ :::note
+ 上記のレッスンではデータを 2 つのテーブルに保存しましたが、最初の `nginxdb.access_logs` テーブルを [`Null`](/engines/table-engines/special/null) テーブルエンジンを使用するように変更することもできます。
+ パース済みデータは変わらず `nginxdb.access_logs_view` テーブルに格納されますが、生のデータはテーブルには保存されません。
+ :::
> シンプルなインストールと短時間の設定だけで利用できる Vector を使うと、Nginx サーバーからのログを ClickHouse のテーブルに送信できます。マテリアライズドビューを使用すれば、それらのログを列にパースして、より簡単に分析できるようにできます。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/gcs/index.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/gcs/index.md
index 3bcf12710e0..0e0d4eafddb 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/gcs/index.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/gcs/index.md
@@ -8,13 +8,13 @@ doc_type: 'guide'
keywords: ['Google Cloud Storage ClickHouse', 'GCS ClickHouse 統合', 'GCS バックエンド MergeTree', 'ClickHouse GCS ストレージ', 'Google Cloud ClickHouse']
---
-import BucketDetails from '@site/docs/_snippets/_GCS_authentication_and_bucket.md';
+import BucketDetails from '@site/i18n/jp/docusaurus-plugin-content-docs/current/_snippets/_GCS_authentication_and_bucket.md';
import Image from '@theme/IdealImage';
import GCS_examine_bucket_1 from '@site/static/images/integrations/data-ingestion/s3/GCS-examine-bucket-1.png';
import GCS_examine_bucket_2 from '@site/static/images/integrations/data-ingestion/s3/GCS-examine-bucket-2.png';
-# Google Cloud Storage を ClickHouse と統合する
+# Google Cloud Storage を ClickHouse と統合する {#integrate-google-cloud-storage-with-clickhouse}
:::note
[Google Cloud](https://cloud.google.com) 上の ClickHouse Cloud を利用している場合、このページは対象外です。サービスはすでに [Google Cloud Storage](https://cloud.google.com/storage) を使用しているためです。GCS から `SELECT` または `INSERT` でデータを扱いたい場合は、[`gcs` テーブル関数](/sql-reference/table-functions/gcs) を参照してください。
@@ -24,13 +24,13 @@ ClickHouse は、ストレージとコンピュートを分離したいユーザ
-## GCS バックエンドの MergeTree
+## GCS バックエンドの MergeTree {#gcs-backed-mergetree}
-### ディスクの作成
+### ディスクの作成 {#creating-a-disk}
GCS バケットをディスクとして利用するには、まず `conf.d` 配下のファイルで ClickHouse の設定にディスクを定義する必要があります。GCS ディスク定義の例を以下に示します。この設定には、GCS の「disk」、キャッシュ、およびテーブルを GCS ディスク上に作成する際に DDL クエリで指定されるポリシーを構成するための複数のセクションが含まれます。それぞれについて以下で説明します。
-#### Storage configuration > disks > gcs
+#### Storage configuration > disks > gcs {#storage_configuration--disks--gcs}
この設定の該当部分はハイライトされているセクションであり、次の内容を指定します。
@@ -68,7 +68,7 @@ GCS バケットをディスクとして利用するには、まず `conf.d` 配
```
-#### ストレージ設定 > disks > cache
+#### ストレージ設定 > disks > cache {#storage_configuration--disks--cache}
次の例の設定では、ディスク `gcs` に対して 10Gi のメモリ キャッシュを有効化します。
@@ -106,7 +106,7 @@ GCS バケットをディスクとして利用するには、まず `conf.d` 配
```
-#### Storage configuration > policies > gcs_main
+#### Storage configuration > policies > gcs_main {#storage_configuration--policies--gcs_main}
ストレージ構成ポリシーを使用すると、データを保存する場所を選択できます。以下でハイライトされているポリシーでは、ポリシー `gcs_main` を指定することで、ディスク `gcs` 上にデータを保存できます。たとえば、`CREATE TABLE ... SETTINGS storage_policy='gcs_main'` のように指定します。
@@ -141,7 +141,7 @@ GCS バケットをディスクとして利用するには、まず `conf.d` 配
このディスク定義に関連するすべての設定項目の一覧は[こちら](/engines/table-engines/mergetree-family/mergetree.md/#table_engine-mergetree-s3)にあります。
-### テーブルの作成
+### テーブルの作成 {#creating-a-table}
書き込み権限のあるバケットを使用するようにディスクを設定してあると仮定すると、以下の例のようなテーブルを作成できるはずです。簡潔にするため、NYC タクシー データセットのカラムの一部のみを使用し、データを GCS をバックエンドとするテーブルに直接ストリーミングします。
@@ -179,11 +179,11 @@ INSERT INTO trips_gcs SELECT trip_id, pickup_date, pickup_datetime, dropoff_date
SELECT passenger_count, avg(tip_amount) AS avg_tip, avg(total_amount) AS avg_amount FROM trips_gcs GROUP BY passenger_count;
```
-### レプリケーションの処理
+### レプリケーションの処理 {#handling-replication}
GCS ディスクを用いたレプリケーションは、`ReplicatedMergeTree` テーブルエンジンを使用することで実現できます。詳細については、[GCS を使用して 2 つの GCP リージョン間で単一シャードをレプリケートする](#gcs-multi-region) ガイドを参照してください。
-### さらに詳しく
+### さらに詳しく {#learn-more}
[Cloud Storage XML API](https://cloud.google.com/storage/docs/xml-api/overview) は、Amazon Simple Storage Service (Amazon S3) などのサービスで動作する一部のツールおよびライブラリと相互運用性があります。
@@ -305,13 +305,13 @@ ClickHouse Keeper ノードでデプロイメント手順を実行する際は
```
-### ClickHouse サーバーを構成する
+### ClickHouse サーバーを構成する {#configure-clickhouse-server}
:::note best practice
このガイドのいくつかの手順では、設定ファイルを `/etc/clickhouse-server/config.d/` に配置するように求められます。これは、Linux システムにおける設定オーバーライド用ファイルのデフォルトの配置場所です。このディレクトリにファイルを配置すると、ClickHouse はその内容をデフォルト設定とマージします。`config.d` ディレクトリにこれらのファイルを置くことで、アップグレード時に設定が失われるのを防ぐことができます。
:::
-#### ネットワーキング
+#### ネットワーキング {#networking}
デフォルトでは、ClickHouse はループバックインターフェイスで待ち受けますが、レプリケーション構成ではマシン間のネットワーク接続が必要です。すべてのインターフェイスで待ち受けるには、次のように設定します。
@@ -321,7 +321,7 @@ ClickHouse Keeper ノードでデプロイメント手順を実行する際は
```
-#### リモート ClickHouse Keeper サーバー
+#### リモート ClickHouse Keeper サーバー {#remote-clickhouse-keeper-servers}
レプリケーションは ClickHouse Keeper によって制御されます。この設定ファイルでは、ClickHouse Keeper ノードをホスト名とポート番号で識別します。
@@ -346,7 +346,7 @@ ClickHouse Keeper ノードでデプロイメント手順を実行する際は
```
-#### リモート ClickHouse サーバー
+#### リモート ClickHouse サーバー {#remote-clickhouse-servers}
このファイルでは、クラスタ内の各 ClickHouse サーバーのホスト名とポートを設定します。デフォルトの設定ファイルにはサンプルのクラスタ定義が含まれています。完全に構成されたクラスタのみを使用するために、この設定がデフォルト設定とマージされた際に `remote_servers` セクションへ追加されるのではなく、その内容を置き換えるよう、`remote_servers` エントリにはタグ `replace="true"` が追加されています。
@@ -372,7 +372,7 @@ ClickHouse Keeper ノードでデプロイメント手順を実行する際は
```
-#### レプリカの識別
+#### レプリカの識別 {#replica-identification}
このファイルでは、ClickHouse Keeper 上のパスに関連する設定を行います。具体的には、データがどのレプリカに属しているかを識別するためのマクロを設定します。1 台目のサーバーではレプリカを `replica_1`、もう一方のサーバーでは `replica_2` と指定します。名前は変更しても構いません。たとえば、1 つのレプリカをサウスカロライナ、もう 1 つをノーザンバージニアに配置する例に基づくと、値は `carolina` と `virginia` のようにしてもかまいません。ただし、各マシンで異なる値になるようにしてください。
@@ -390,7 +390,7 @@ ClickHouse Keeper ノードでデプロイメント手順を実行する際は
```
-#### GCS でのストレージ
+#### GCS でのストレージ {#storage-in-gcs}
ClickHouse のストレージ構成には `disks` と `policies` が含まれます。以下で構成しているディスク名は `gcs` で、`type` は `s3` です。`type` が s3 になっているのは、ClickHouse が GCS バケットに対して、AWS S3 バケットと同様の方法でアクセスするためです。この構成は 2 部用意し、ClickHouse サーバーノードごとに 1 つずつ使用します。
@@ -438,7 +438,7 @@ ClickHouse のストレージ構成には `disks` と `policies` が含まれま
```
-### ClickHouse Keeper を起動する
+### ClickHouse Keeper を起動する {#start-clickhouse-keeper}
お使いのオペレーティングシステム向けのコマンドを使用してください。たとえば、次のとおりです。
@@ -448,7 +448,7 @@ sudo systemctl start clickhouse-keeper
sudo systemctl status clickhouse-keeper
```
-#### ClickHouse Keeper のステータスを確認する
+#### ClickHouse Keeper のステータスを確認する {#check-clickhouse-keeper-status}
`netcat` を使って ClickHouse Keeper にコマンドを送信します。たとえば、`mntr` は ClickHouse Keeper クラスターの状態を返します。各 Keeper ノードでこのコマンドを実行すると、1 つがリーダーで、残りの 2 つがフォロワーであることがわかります。
@@ -464,11 +464,11 @@ zk_max_latency 11
zk_min_latency 0
zk_packets_received 1783
zk_packets_sent 1783
-# highlight-start
+# highlight-start {#highlight-start}
zk_num_alive_connections 2
zk_outstanding_requests 0
zk_server_state leader
-# highlight-end
+# highlight-end {#highlight-end}
zk_znode_count 135
zk_watch_count 8
zk_ephemerals_count 3
@@ -477,13 +477,13 @@ zk_key_arena_size 28672
zk_latest_snapshot_size 0
zk_open_file_descriptor_count 182
zk_max_file_descriptor_count 18446744073709551615
-# highlight-start
+# highlight-start {#highlight-start}
zk_followers 2
zk_synced_followers 2
-# highlight-end
+# highlight-end {#highlight-end}
```
-### ClickHouse サーバーを起動する
+### ClickHouse サーバーを起動する {#start-clickhouse-server}
`chnode1` と `chnode` で以下を実行します。
@@ -495,9 +495,9 @@ sudo service clickhouse-server start
sudo service clickhouse-server status
```
-### 検証
+### 検証 {#verification}
-#### ディスク構成の検証
+#### ディスク構成の検証 {#verify-disk-configuration}
`system.disks` には、各ディスクのレコードが含まれている必要があります：
@@ -565,7 +565,7 @@ cache_path:
3 行が結果セットに含まれています。経過時間: 0.002 秒。
````
-#### クラスタ上で作成されたテーブルが両ノードに作成されていることを確認する
+#### クラスタ上で作成されたテーブルが両ノードに作成されていることを確認する {#verify-that-tables-created-on-the-cluster-are-created-on-both-nodes}
```sql
-- highlight-next-line
create table trips on cluster 'cluster_1S_2R' (
@@ -600,7 +600,7 @@ SETTINGS storage_policy='gcs_main'
2行のデータセット。経過時間: 0.641秒
```
-#### データを挿入できることを確認する
+#### データを挿入できることを確認する {#verify-that-data-can-be-inserted}
```sql
INSERT INTO trips SELECT
@@ -621,7 +621,7 @@ FROM s3('https://ch-nyc-taxi.s3.eu-west-3.amazonaws.com/tsv/trips_{0..9}.tsv.gz'
LIMIT 1000000
```
-#### テーブルでストレージポリシー `gcs_main` が使用されていることを確認します。
+#### テーブルでストレージポリシー `gcs_main` が使用されていることを確認します。 {#verify-that-the-storage-policy-gcs_main-is-used-for-the-table}
```sql
SELECT
@@ -647,14 +647,14 @@ formatReadableSize(total_bytes): 36.42 MiB
1行を取得しました。経過時間: 0.002秒
```
-#### Google Cloud コンソールでの確認
+#### Google Cloud コンソールでの確認 {#verify-in-google-cloud-console}
バケットを確認すると、`storage.xml` 構成ファイルで指定した名前のフォルダが、各バケット内に作成されていることがわかります。フォルダを展開すると、多数のファイルがあり、これらがデータパーティションを表しています。
-#### レプリカ 1 用バケット
+#### レプリカ 1 用バケット {#bucket-for-replica-one}
-#### レプリカ 2 用バケット
+#### レプリカ 2 用バケット {#bucket-for-replica-two}
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/dataflow.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/dataflow.md
index e05c5a858e1..170b5f065a5 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/dataflow.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/dataflow.md
@@ -11,7 +11,7 @@ keywords: ['Google Dataflow ClickHouse', 'Dataflow ClickHouse integration', 'Apa
import ClickHouseSupportedBadge from '@theme/badges/ClickHouseSupported';
-# Google Dataflow と ClickHouse の統合
+# Google Dataflow と ClickHouse の統合 {#integrating-google-dataflow-with-clickhouse}
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/java-runner.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/java-runner.md
index def78a71397..9262e134ff7 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/java-runner.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/java-runner.md
@@ -11,7 +11,7 @@ keywords: ['Dataflow Java Runner', 'Google Dataflow ClickHouse', 'Apache Beam Ja
import ClickHouseSupportedBadge from '@theme/badges/ClickHouseSupported';
-# Dataflow Java ランナー
+# Dataflow Java ランナー {#dataflow-java-runner}
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/templates.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/templates.md
index 03b9690b8ad..45ccd449073 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/templates.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/templates.md
@@ -11,7 +11,7 @@ keywords: ['google dataflow', 'gcp', 'データパイプライン', 'テンプ
import ClickHouseSupportedBadge from '@theme/badges/ClickHouseSupported';
-# Google Dataflow テンプレート
+# Google Dataflow テンプレート {#google-dataflow-templates}
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/templates/bigquery-to-clickhouse.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/templates/bigquery-to-clickhouse.md
index 13f288394fc..c6f666db706 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/templates/bigquery-to-clickhouse.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/google-dataflow/templates/bigquery-to-clickhouse.md
@@ -19,7 +19,7 @@ import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# Dataflow BigQuery から ClickHouse へのテンプレート
+# Dataflow BigQuery から ClickHouse へのテンプレート {#dataflow-bigquery-to-clickhouse-template}
BigQuery から ClickHouse への Dataflow テンプレートは、BigQuery テーブルから ClickHouse テーブルへデータをバッチで取り込むパイプラインです。
このテンプレートは、テーブル全体を読み取ることも、指定された SQL クエリを使用して特定のレコードに絞り込むこともできます。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/insert-local-files.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/insert-local-files.md
index 332f305972b..a6bf3d5162b 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/insert-local-files.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/insert-local-files.md
@@ -9,7 +9,7 @@ doc_type: 'guide'
keywords: ['ローカルファイル インポート ClickHouse', 'ClickHouse ローカルファイル インポート', 'clickhouse-client ファイルアップロード']
---
-# ローカルファイルの挿入
+# ローカルファイルの挿入 {#insert-local-files}
`clickhouse-client` を使用して、ローカルファイルを ClickHouse サービスにストリーミングできます。これにより、ClickHouse が備える数多くの強力かつ便利な関数を使ってデータを前処理できます。例を見てみましょう...
@@ -79,7 +79,6 @@ LIMIT 7
結果は以下のとおりです。
-
```response
│ 488 │ comment │ mynameishere │ 2007-02-22 14:48:18 │ "It's too bad. Javascript-in-the-browser and Ajax are both nasty hacks that force programmers to do all sorts of shameful things. And the result is--wanky html tricks. Java, for its faults, is fairly clean when run in the applet environment. It has every superiority over JITBAJAX, except for install issues and a chunky load process. Yahoo games seems like just about the only applet success story. Of course, back in the day, non-trivial Applets tended to be too large for the dial-up accounts people had. At least that is changed." │ [454927] │ ['It','s','too','bad','Javascript','in','the','browser','and','Ajax','are','both','nasty','hacks','that','force','programmers','to','do','all','sorts','of','shameful','things','And','the','result','is','wanky','html','tricks','Java','for','its','faults','is','fairly','clean','when','run','in','the','applet','environment','It','has','every','superiority','over','JITBAJAX','except','for','install','issues','and','a','chunky','load','process','Yahoo','games','seems','like','just','about','the','only','applet','success','story','Of','course','back','in','the','day','non','trivial','Applets','tended','to','be','too','large','for','the','dial','up','accounts','people','had','At','least','that','is','changed'] │
│ 575 │ comment │ leoc │ 2007-02-23 00:09:49 │ "I can't find the reference now, but I *think* I've just read something suggesting that the install process for an Apollo applet will involve an "install-this-application?" confirmation dialog followed by a download of 30 seconds or so. If so then Apollo's less promising than I hoped. That kind of install may be low-friction by desktop-app standards but it doesn't compare to the ease of starting a browser-based AJAX or Flash application. (Consider how easy it is to use maps.google.com for the first time.)Surely it will at least be that Apollo applications will run untrusted by default, and that an already-installed app will start automatically whenever you take your browser to the URL you downloaded it from?" │ [455071] │ ['I','can','t','find','the','reference','now','but','I','think','I','ve','just','read','something','suggesting','that','the','install','process','for','an','Apollo','applet','will','involve','an','34','install','this','application','34','confirmation','dialog','followed','by','a','download','of','30','seconds','or','so','If','so','then','Apollo','s','less','promising','than','I','hoped','That','kind','of','install','may','be','low','friction','by','desktop','app','standards','but','it','doesn','t','compare','to','the','ease','of','starting','a','browser','based','AJAX','or','Flash','application','Consider','how','easy','it','is','to','use','maps','google','com','for','the','first','time','p','Surely','it','will','at','least','be','that','Apollo','applications','will','run','untrusted','by','default','and','that','an','already','installed','app','will','start','automatically','whenever','you','take','your','browser','to','the','URL','you','downloaded','it','from'] │
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/kafka/confluent/confluent-cloud.md b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/kafka/confluent/confluent-cloud.md
index d817065d007..99485d24e43 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/kafka/confluent/confluent-cloud.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/integrations/data-ingestion/kafka/confluent/confluent-cloud.md
@@ -12,11 +12,11 @@ integration:
- website: 'https://clickhouse.com/cloud/clickpipes'
---
-import ConnectionDetails from '@site/docs/_snippets/_gather_your_details_http.mdx';
+import ConnectionDetails from '@site/i18n/jp/docusaurus-plugin-content-docs/current/_snippets/_gather_your_details_http.mdx';
import Image from '@theme/IdealImage';
-# Confluent Cloud と ClickHouse との連携
+# Confluent Cloud と ClickHouse との連携 {#integrating-confluent-cloud-with-clickhouse}
\ No newline at end of file
+
\ No newline at end of file
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/deleting-data/delete_mutations.mdx b/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/deleting-data/delete_mutations.mdx
index d8f1f42532d..4f3b1c98cb4 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/deleting-data/delete_mutations.mdx
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/deleting-data/delete_mutations.mdx
@@ -14,6 +14,6 @@ doc_type: 'reference'
削除を行う場合は、デフォルトの MergeTree テーブルエンジンの代わりに [ReplacingMergeTree](/guides/replacing-merge-tree) や [CollapsingMergeTree](/engines/table-engines/mergetree-family/collapsingmergetree) などの専用テーブルエンジンを使用することで、このような大量の書き込みリクエストを回避できます。
:::
-import DeleteMutations from '@site/docs/sql-reference/statements/alter/delete.md';
+import DeleteMutations from '@site/i18n/jp/docusaurus-plugin-content-docs/current/sql-reference/statements/alter/delete.md';
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/deleting-data/overview.mdx b/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/deleting-data/overview.mdx
index 60d97310aca..16a37f30868 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/deleting-data/overview.mdx
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/deleting-data/overview.mdx
@@ -17,7 +17,7 @@ ClickHouse でデータを削除する方法はいくつかあり、それぞれ
以下は、ClickHouse でデータを削除するさまざまな方法の概要です。
-## 軽量削除
+## 軽量削除 \{#lightweight-deletes\}
軽量削除では、行は即座に削除済みとしてマークされ、その後のすべての `SELECT` クエリから自動的にフィルタリングされます。これらの削除済み行の物理的な削除は、その後の通常のマージサイクル中に実行されるため、I/O 負荷が小さくなります。その結果、しばらくの間はデータがストレージから実際には削除されず、削除済みとしてマークされているだけの場合があります。データが確実に削除されていることを保証する必要がある場合は、上記のミューテーションコマンドの使用を検討してください。
@@ -34,8 +34,7 @@ DELETE FROM posts WHERE toYear(CreationDate) = 2018
[軽量削除](/guides/developer/lightweight-delete)の詳細については、こちらを参照してください。
-
-## 削除ミューテーション
+## 削除ミューテーション \{#delete-mutations\}
削除ミューテーションは、例えば `ALTER TABLE ... DELETE` コマンドで実行できます。
@@ -48,8 +47,7 @@ ALTER TABLE posts DELETE WHERE toYear(CreationDate) = 2018
[delete mutations](/sql-reference/statements/alter/delete) の詳細を参照してください。
-
-## テーブルを空にする
+## テーブルを空にする \{#truncate-table\}
テーブル内のすべてのデータを削除する必要がある場合は、以下の `TRUNCATE TABLE` コマンドを使用します。これは軽量な処理です。
@@ -59,8 +57,7 @@ TRUNCATE TABLE posts
[TRUNCATE TABLE](/sql-reference/statements/truncate) の詳細については、こちらを参照してください。
-
-## パーティションの削除
+## パーティションの削除 \{#drop-partition\}
データに独自のパーティションキーを指定している場合、パーティションを効率的に削除できます。高カーディナリティなパーティション分割は避けてください。
@@ -70,7 +67,6 @@ ALTER TABLE posts (DROP PARTITION '2008')
[DROP PARTITION](/sql-reference/statements/alter/partition) の詳細については、こちらを参照してください。
-
## 参考情報 \{#more-resources\}
-- [ClickHouse での更新と削除の扱い](https://clickhouse.com/blog/handling-updates-and-deletes-in-clickhouse)
\ No newline at end of file
+* [ClickHouse での更新と削除の扱い](https://clickhouse.com/blog/handling-updates-and-deletes-in-clickhouse)
\ No newline at end of file
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/drop_partition.mdx b/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/drop_partition.mdx
index 5d19fa2424b..42f7e154351 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/drop_partition.mdx
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/drop_partition.mdx
@@ -8,7 +8,7 @@ keywords: ['DROP PARTITION', 'drop partition', 'パーティションの削除',
doc_type: 'reference'
---
-## 背景
+## 背景 \{#background\}
パーティションは、テーブルを最初に `PARTITION BY` 句で定義するときに指定します。この句には任意のカラムに対する SQL 式を含めることができ、その評価結果によって各行がどのパーティションに送られるかが決まります。
@@ -33,8 +33,7 @@ PARTITION BY toYear(CreationDate)
ClickHouse では、パーティションは主としてクエリ最適化のテクニックではなく、データ管理機能として捉えるべきです。キーに基づいてデータを論理的に分割することで、各パーティションに対して（たとえば削除などの）操作を個別に実行できます。これにより、ユーザーはパーティション、ひいてはそのサブセットを、時系列に応じて、あるいは[データの有効期限を設定する／クラスタから効率的に削除する](/sql-reference/statements/alter/partition)目的で、[ストレージ階層](/integrations/s3#storage-tiers)間で効率的に移動できるようになります。
-
-## パーティションの削除
+## パーティションの削除 \{#drop-partitions\}
`ALTER TABLE ... DROP PARTITION` は、パーティション全体を削除するためのコスト効率の高い方法です。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/truncate.md b/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/truncate.md
index 27b98526630..87fee90347d 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/truncate.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/truncate.md
@@ -10,6 +10,6 @@ keywords: ['truncate', 'データ削除', 'データの削除', 'テーブルを
TRUNCATE は、テーブルまたはデータベース内のデータを削除しつつ、テーブル／データベース自体は残しておくことを可能にします。これは軽量な操作であり、一度実行すると元に戻すことはできません。
-import Truncate from '@site/docs/sql-reference/statements/truncate.md';
+import Truncate from '@site/i18n/jp/docusaurus-plugin-content-docs/current/sql-reference/statements/truncate.md';
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/updating-data/overview.mdx b/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/updating-data/overview.mdx
index 8f20fdbbe37..9a9cf17217c 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/updating-data/overview.mdx
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/updating-data/overview.mdx
@@ -28,7 +28,7 @@ ClickHouse でデータを更新する方法はいくつかあり、それぞれ
| [ReplacingMergeTree](/engines/table-engines/mergetree-family/replacingmergetree) | `ENGINE = ReplacingMergeTree` | 大量のデータを更新する場合に使用します。このテーブルエンジンは、マージ時のデータ重複排除に最適化されています。 |
| [CollapsingMergeTree](/engines/table-engines/mergetree-family/collapsingmergetree) | `ENGINE = CollapsingMergeTree(Sign)` | 個々の行を頻繁に更新する場合、または時間とともに変化するオブジェクトの最新状態を保持する必要があるシナリオで使用します。たとえば、ユーザーアクティビティや記事の統計を追跡する場合などです。 |
-## 更新ミューテーション
+## 更新ミューテーション \{#update-mutations\}
更新ミューテーションは `ALTER TABLE ... UPDATE` コマンドを使って発行できます。例えば、次のように実行します。
@@ -41,21 +41,20 @@ ALTER TABLE posts_temp
[update mutations](/sql-reference/statements/alter/update) の詳細については、こちらを参照してください。
-
## Lightweight updates \{#lightweight-updates\}
Lightweight updates は、従来の mutation のように列全体を書き換えるのではなく、「patch parts」と呼ばれる特別なデータパーツ（更新された列と行のみを含む）を使って行を更新する ClickHouse の機能です。Lightweight UPDATE の主な特性は次のとおりです。
主な特性:
-- 標準的な `UPDATE` 構文を使用し、マージを待たずに直ちに patch parts を作成する
-- 更新された値は、patch の適用によって `SELECT` クエリから即座に参照可能だが、物理的にマテリアライズされるのはその後のマージ時のみ
-- 予測可能なレイテンシで（テーブル全体のおおよそ 10% 程度までの）小規模な更新向けに設計されている
-- patch を適用する必要がある `SELECT` クエリにはオーバーヘッドが増えるが、列全体の書き換えは回避できる
+* 標準的な `UPDATE` 構文を使用し、マージを待たずに直ちに patch parts を作成する
+* 更新された値は、patch の適用によって `SELECT` クエリから即座に参照可能だが、物理的にマテリアライズされるのはその後のマージ時のみ
+* 予測可能なレイテンシで（テーブル全体のおおよそ 10% 程度までの）小規模な更新向けに設計されている
+* patch を適用する必要がある `SELECT` クエリにはオーバーヘッドが増えるが、列全体の書き換えは回避できる
-詳細は ["The Lightweight UPDATE Statement"](/sql-reference/statements/update) を参照してください。
+詳細は ["The Lightweight UPDATE Statement"](/sql-reference/statements/update) を参照してください。
-## オンザフライ更新
+## オンザフライ更新 \{#on-the-fly-updates\}
オンザフライ更新は、行を即時に更新し、その後の `SELECT` クエリが自動的に更新後の値を返すようにする仕組みを提供します（その分のオーバーヘッドが発生し、クエリは遅くなります）。これにより、通常のミューテーションが持つ原子性に関する制約を実質的に解消できます。以下に例を示します。
@@ -92,8 +91,7 @@ WHERE Id = 404346
[オンザフライ更新](/guides/developer/on-the-fly-mutations)についての詳細はこちらを参照してください。
-
-## `CollapsingMergeTree`
+## `CollapsingMergeTree` \{#collapsing-merge-tree\}
更新はコストが高い一方で、挿入を活用して更新を実現できるという発想に基づき、
[`CollapsingMergeTree`](/engines/table-engines/mergetree-family/collapsingmergetree) テーブルエンジンは
@@ -140,7 +138,6 @@ HAVING sum(Sign) > 0
のドキュメントを参照することを推奨します。
:::
-
## 参考資料 \{#more-resources\}
-- [ClickHouse における更新と削除の処理](https://clickhouse.com/blog/handling-updates-and-deletes-in-clickhouse)
\ No newline at end of file
+* [ClickHouse における更新と削除の処理](https://clickhouse.com/blog/handling-updates-and-deletes-in-clickhouse)
\ No newline at end of file
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/updating-data/update_mutations.mdx b/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/updating-data/update_mutations.mdx
index daef6466d1e..6dca0093e34 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/updating-data/update_mutations.mdx
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/managing-data/updating-data/update_mutations.mdx
@@ -14,6 +14,6 @@ keywords: ['update', 'mutations', 'alter table', 'data manipulation', 'modify da
更新を行う場合、デフォルトの MergeTree テーブルエンジンの代わりに、[ReplacingMergeTree](/guides/replacing-merge-tree) や [CollapsingMergeTree](/engines/table-engines/mergetree-family/collapsingmergetree) などの専用テーブルエンジンを使用することで、このような大量の書き込み要求を回避できます。
:::
-import UpdateMutations from '@site/docs/sql-reference/statements/alter/update.md';
+import UpdateMutations from '@site/i18n/jp/docusaurus-plugin-content-docs/current/sql-reference/statements/alter/update.md';
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/materialized-view/incremental-materialized-view.md b/i18n/jp/docusaurus-plugin-content-docs/current/materialized-view/incremental-materialized-view.md
index 64614df1830..eef74c26f58 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/materialized-view/incremental-materialized-view.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/materialized-view/incremental-materialized-view.md
@@ -25,7 +25,7 @@ ClickHouse のマテリアライズドビューは、それらが基づくテー
-## 例
+## 例 {#example}
例として、["Schema Design"](/data-modeling/schema-design) で説明されている Stack Overflow のデータセットを使用します。
@@ -178,7 +178,7 @@ LIMIT 10
ほとんどの場合、`SummingMergeTree` または `AggregatingMergeTree` テーブルエンジンを使用する際は、マテリアライズドビュー変換の `GROUP BY` 句で使用される列を、対象テーブルの `ORDER BY` 句で使用される列と一致させる必要があります。これらのエンジンは、バックグラウンドのマージ処理中に同一の値を持つ行をマージするために `ORDER BY` 列に依存しています。`GROUP BY` 列と `ORDER BY` 列が一致していないと、クエリパフォーマンスの低下、不十分なマージ、さらにはデータ不整合を引き起こす可能性があります。
:::
-### さらに複雑な例
+### さらに複雑な例 {#a-more-complex-example}
上記の例では、マテリアライズドビューを使用して、1 日あたり 2 つの合計値を計算および保持しています。合計値は部分的な状態を保持するための最も単純な集約形式であり、新しい値が到着したときに既存の値にただ加算していけば済みます。ただし、ClickHouse のマテリアライズドビューは、あらゆる種類の集約に対して使用できます。
@@ -280,11 +280,11 @@ LIMIT 10
ここでは `FINAL` ではなく `GROUP BY` を使用していることに注意してください。
-## その他の用途
+## その他の用途 {#other-applications}
ここまでは主に、マテリアライズドビューを使用してデータの部分集計をインクリメンタルに更新し、計算をクエリ実行時から挿入時へと移動する方法に焦点を当てました。この一般的なユースケースに加えて、マテリアライズドビューには他にもさまざまな用途があります。
-### フィルタリングと変換
+### フィルタリングと変換 {#filtering-and-transformation}
状況によっては、挿入時に行や列の一部だけを取り込めばよい場合があります。この場合、`posts_null` テーブルで挿入を受け付け、`posts` テーブルへ挿入する前に `SELECT` クエリで行をフィルタリングすることができます。例えば、`posts` テーブル内の `Tags` 列を変換したいとします。この列にはパイプ区切りのタグ名リストが含まれています。これを配列に変換することで、個々のタグ値ごとに集計しやすくなります。
@@ -297,7 +297,7 @@ CREATE MATERIALIZED VIEW posts_mv TO posts AS
SELECT * EXCEPT Tags, arrayFilter(t -> (t != ''), splitByChar('|', Tags)) as Tags FROM posts_null
```
-### ルックアップテーブル
+### ルックアップテーブル {#lookup-table}
ユーザーは ClickHouse のソートキーを選択する際、自身のアクセスパターンを考慮する必要があります。フィルタ句や集約句で頻繁に使用されるカラムを含めるべきです。これは、アクセスパターンが多様で単一のカラム集合では表現しきれないシナリオにおいては制約となり得ます。たとえば、次のような `comments` テーブルを考えてみます。
@@ -384,7 +384,7 @@ WHERE PostId IN (
```
-## マテリアライズドビューと JOIN
+## マテリアライズドビューと JOIN {#materialized-views-and-joins}
:::note リフレッシュ型マテリアライズドビュー
以下の内容はインクリメンタルマテリアライズドビューにのみ適用されます。リフレッシュ型マテリアライズドビューは、対象となる全データセットに対して定期的にクエリを実行するため、JOIN を完全にサポートします。結果の鮮度の低下をある程度許容できる場合は、複雑な JOIN ではこちらの利用を検討してください。
@@ -398,7 +398,7 @@ ClickHouse のインクリメンタルマテリアライズドビューは `JOIN
これは、リファレンステーブルやディメンションテーブルを用いてデータを付加する用途にはうまく機能します。しかし、右側のテーブル（例：ユーザーメタデータ）に対する更新は、マテリアライズドビューを遡って更新することはありません。更新されたデータを反映させるには、ソーステーブルに新しい行が挿入される必要があります。
-### 例
+### 例 {#materialized-views-and-joins-example}
[Stack Overflow データセット](/data-modeling/schema-design) を用いた具体例を見ていきます。ここでは、`users` テーブルからユーザーの表示名を含めて、**ユーザーごとの日次バッジ数** を計算するマテリアライズドビューを作成します。
@@ -570,7 +570,7 @@ WHERE DisplayName = 'brand_new_user'
ただし、この結果は正しくありません。
-### マテリアライズドビューにおける JOIN のベストプラクティス
+### マテリアライズドビューにおける JOIN のベストプラクティス {#join-best-practices}
* **左端のテーブルをトリガーとして使用する。** `SELECT` 文の左側のテーブルだけがマテリアライズドビューをトリガーします。右側のテーブルへの変更では更新はトリガーされません。
@@ -588,11 +588,11 @@ WHERE DisplayName = 'brand_new_user'
* **挿入ボリュームと頻度を考慮する。** JOIN は中程度の挿入ワークロードには適していますが、高スループットなインジェストでは、ステージングテーブル、事前 JOIN、あるいは Dictionaries や [Refreshable Materialized Views](/materialized-view/refreshable-materialized-view) などの別のアプローチを検討してください。
-### フィルターや JOIN でのソーステーブルの使用
+### フィルターや JOIN でのソーステーブルの使用 {#using-source-table-in-filters-and-joins-in-materialized-views}
ClickHouse のマテリアライズドビューを扱う際には、マテリアライズドビューのクエリ実行中にソーステーブルがどのように扱われるかを理解しておくことが重要です。具体的には、マテリアライズドビューのクエリ内のソーステーブルは、挿入されたデータブロックに置き換えられます。この挙動を正しく理解していないと、予期しない結果につながる可能性があります。
-#### 例となるシナリオ
+#### 例となるシナリオ {#example-scenario}
次のようなセットアップを考えます：
@@ -631,7 +631,7 @@ SELECT * FROM mvw2;
```
-#### 解説
+#### 解説 {#explanation}
上記の例では、`mvw1` と `mvw2` という 2 つのマテリアライズドビューがあり、同様の処理を行いますが、ソーステーブル `t0` の参照方法にわずかな違いがあります。
@@ -641,7 +641,7 @@ SELECT * FROM mvw2;
重要な違いは、ClickHouse がマテリアライズドビューのクエリ内でソーステーブルをどのように扱うかにあります。マテリアライズドビューが INSERT によってトリガーされた場合、ソーステーブル（この例では `t0`）は挿入されたデータブロックに置き換えられます。この挙動はクエリの最適化に活用できますが、想定外の結果を避けるためには慎重な検討が必要です。
-### ユースケースと注意点
+### ユースケースと注意点 {#use-cases-and-caveats}
実際には、この挙動を利用して、ソーステーブルのデータの一部のみを処理すればよいマテリアライズドビューを最適化することができます。例えば、他のテーブルと JOIN を行う前に、サブクエリを使ってソーステーブルをフィルタリングできます。これにより、マテリアライズドビューが処理するデータ量を減らし、パフォーマンスを向上させることができます。
@@ -661,7 +661,7 @@ ON t0.id = t1.id;
この例では、`IN (SELECT id FROM t0)` サブクエリから構築される集合には、新しく挿入された行のみが含まれます。これにより、その集合を使って `t1` をフィルタリングできます。
-#### Stack Overflow を用いた例
+#### Stack Overflow を用いた例 {#example-with-stack-overflow}
ユーザーごとの**1 日あたりのバッジ数**を計算し、さらに `users` テーブルからユーザーの表示名を含めるために、[前述のマテリアライズドビューの例](/materialized-view/incremental-materialized-view#example)を考えてみます。
@@ -740,7 +740,7 @@ INSERT INTO badges VALUES (53505058, 2936484, 'gingerwizard', now(), 'Gold', 0);
上記の操作では、ユーザー ID `2936484` に対して `users` テーブルから 1 行だけが取得されます。このルックアップは、`Id` をテーブルの並び替えキーとして指定することで最適化されています。
-## マテリアライズドビューと UNION
+## マテリアライズドビューと UNION {#materialized-views-and-unions}
`UNION ALL` クエリは、複数のソーステーブルからのデータを1つの結果セットに結合するためによく使用されます。
@@ -969,7 +969,7 @@ GROUP BY UserId
```
-## 並列処理と逐次処理
+## 並列処理と逐次処理 {#materialized-views-parallel-vs-sequential}
前の例で示したように、1つのテーブルは複数のマテリアライズドビューのソースとして機能できます。これらが実行される順序は、設定 [`parallel_view_processing`](/operations/settings/settings#parallel_view_processing) によって決まります。
@@ -1121,7 +1121,7 @@ ORDER BY now ASC
-## マテリアライズドビューと共通テーブル式 (CTE)
+## マテリアライズドビューと共通テーブル式 (CTE) {#materialized-views-common-table-expressions-ctes}
**非再帰の**共通テーブル式 (CTE) はマテリアライズドビューでサポートされています。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/materialized-view/refreshable-materialized-view.md b/i18n/jp/docusaurus-plugin-content-docs/current/materialized-view/refreshable-materialized-view.md
index 7f3c3351d48..8694182b8a3 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/materialized-view/refreshable-materialized-view.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/materialized-view/refreshable-materialized-view.md
@@ -30,7 +30,7 @@ ClickHouse のインクリメンタルマテリアライズドビューは非常
-## リフレッシュ可能なマテリアライズドビューはどのように更新されますか？
+## リフレッシュ可能なマテリアライズドビューはどのように更新されますか？ {#how-do-you-refresh-a-refreshable-materialized-view}
リフレッシュ可能なマテリアライズドビューは、作成時に定義された間隔で自動的に更新されます。
例えば、次のマテリアライズドビューは 1 分ごとにリフレッシュされます。
@@ -51,7 +51,7 @@ SYSTEM REFRESH VIEW table_name_mv;
詳細については、[リフレッシュ可能なマテリアライズドビューの管理](/sql-reference/statements/system#refreshable-materialized-views) ドキュメントを参照してください。
-## リフレッシュ可能なマテリアライズドビューが最後にリフレッシュされたのはいつですか？
+## リフレッシュ可能なマテリアライズドビューが最後にリフレッシュされたのはいつですか？ {#when-was-a-refreshable-materialized-view-last-refreshed}
リフレッシュ可能なマテリアライズドビューが最後にいつリフレッシュされたかを確認するには、次のように [`system.view_refreshes`](/operations/system-tables/view_refreshes) システムテーブルをクエリします。
@@ -69,7 +69,7 @@ FROM system.view_refreshes;
```
-## リフレッシュ間隔はどのように変更できますか？
+## リフレッシュ間隔はどのように変更できますか？ {#how-can-i-change-the-refresh-rate}
リフレッシュ可能なマテリアライズドビューのリフレッシュ間隔を変更するには、[`ALTER TABLE...MODIFY REFRESH`](/sql-reference/statements/alter/view#alter-table--modify-refresh-statement) 構文を使用します。
@@ -87,7 +87,7 @@ MODIFY REFRESH EVERY 30 SECONDS;
```
-## `APPEND` を使用して新しい行を追加する
+## `APPEND` を使用して新しい行を追加する {#using-append-to-add-new-rows}
`APPEND` 機能を使用すると、ビュー全体を置き換えるのではなく、テーブルの末尾に新しい行を追記できます。
@@ -190,11 +190,11 @@ FORMAT PrettyCompactMonoBlock
```
-## 例
+## 例 {#examples}
ここでは、いくつかのサンプルデータセットを使って、リフレッシュ可能なマテリアライズドビューの使用方法を見ていきます。
-### Stack Overflow
+### Stack Overflow {#stack-overflow}
[非正規化データガイド](/data-modeling/denormalization)では、Stack Overflow のデータセットを使ってデータを非正規化するさまざまな手法を紹介しています。`votes`、`users`、`badges`、`posts`、`postlinks` の各テーブルにデータを格納します。
@@ -244,7 +244,7 @@ LEFT JOIN (
ここでの構文はインクリメンタルなマテリアライズドビューと同一ですが、[`REFRESH`](/sql-reference/statements/create/view#refreshable-materialized-view) 句を含めている点が異なります。
:::
-### IMDb
+### IMDb {#imdb}
[dbt と ClickHouse の統合ガイド](/integrations/dbt) では、`actors`、`directors`、`genres`、`movie_directors`、`movies`、`roles` というテーブルを用いて IMDb データセットを用意しました。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/basics.md b/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/basics.md
index 1c4d4de377c..4f16b16996e 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/basics.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/basics.md
@@ -9,7 +9,7 @@ doc_type: 'guide'
-# 基本
+# 基本 {#basics}
:::note
クライアントプロトコルのリファレンスは現在作成中です。
@@ -121,13 +121,13 @@ data := []byte{
-## 整数
+## 整数 {#integers}
:::tip
ClickHouse は固定サイズの整数に **リトルエンディアン (Little Endian)** を使用します。
:::
-### Int32
+### Int32 {#int32}
```go
v := int32(1000)
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/client.md b/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/client.md
index d86b5a0a194..df378757cf7 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/client.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/client.md
@@ -9,7 +9,7 @@ keywords: ['クライアントパケット', 'ネイティブプロトコルク
-# クライアントパケット
+# クライアントパケット {#client-packets}
| value | name | description |
|-------|-------------------|--------------------------|
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/columns.md b/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/columns.md
index 17996009b7a..595e4c66204 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/columns.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/columns.md
@@ -9,7 +9,7 @@ doc_type: 'reference'
-# 列の型
+# 列の型 {#column-types}
データ型の一般的な説明については、[データ型](/sql-reference/data-types/) を参照してください。
@@ -77,7 +77,7 @@ Tuple は単にカラムの配列です。たとえば、Tuple(String, UInt8)
-## Nullable
+## Nullable {#nullable}
`Nullable(T)` は、行数が同じ `Nulls`（型は `ColUInt8`）列と `Values`（型は `T`）列で構成されます。
@@ -101,7 +101,7 @@ Tuple は単にカラムの配列です。たとえば、Tuple(String, UInt8)
-## `LowCardinality` 型
+## `LowCardinality` 型 {#low-cardinality}
`LowCardinality(T)` は、`Index T` および `Keys K` から構成されます。
ここで `K` は、`Index` のサイズに応じて (UInt8, UInt16, UInt32, UInt64) のいずれかの型です。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/hash.md b/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/hash.md
index 69c16b638a0..67258f9b29a 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/hash.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/hash.md
@@ -9,7 +9,7 @@ keywords: ['CityHash', 'ネイティブプロトコル用ハッシュ', 'ハッ
-# CityHash
+# CityHash {#cityhash}
ClickHouse は [Google 製 CityHash](https://github.com/google/cityhash) の **以前のバージョンの 1 つ**を使用しています。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/server.md b/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/server.md
index a599a4c025d..af6a854ee0a 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/server.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/native-protocol/server.md
@@ -9,7 +9,7 @@ keywords: ['ネイティブプロトコル', 'TCPプロトコル', 'クライア
-# サーバーパケット
+# サーバーパケット {#server-packets}
| value | name | description |
|-------|----------------------------------|--------------------------------------------------------------------|
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/_troubleshooting.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/_troubleshooting.md
index 3b7224b1317..42e4c7c578c 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/_troubleshooting.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/_troubleshooting.md
@@ -8,20 +8,20 @@
-## インストール
+## インストール {#troubleshooting-installation-errors}
-### apt-get を使用して ClickHouse リポジトリから deb パッケージを取得できない
+### apt-get を使用して ClickHouse リポジトリから deb パッケージを取得できない {#you-cannot-get-deb-packages-from-clickhouse-repository-with-apt-get}
* ファイアウォールの設定を確認してください。
* 何らかの理由でリポジトリにアクセスできない場合は、[インストールガイド](../getting-started/install.md)の記事で説明されているようにパッケージをダウンロードし、`sudo dpkg -i
` コマンドを使用して手動でインストールしてください。`tzdata` パッケージも必要です。
-### apt-get を使用して ClickHouse リポジトリから deb パッケージを更新できない
+### apt-get を使用して ClickHouse リポジトリから deb パッケージを更新できない {#you-cannot-update-deb-packages-from-clickhouse-repository-with-apt-get}
* GPG キーが変更された場合にこの問題が発生することがあります。
リポジトリ設定を更新するには、[セットアップ](../getting-started/install.md#setup-the-debian-repository) ページの手順に従ってください。
-### `apt-get update` でさまざまな警告が表示される
+### `apt-get update` でさまざまな警告が表示される {#you-get-different-warnings-with-apt-get-update}
* 実際の警告メッセージは次のいずれかになります:
@@ -53,7 +53,7 @@ sudo apt-get clean
sudo apt-get autoclean
```
-### 誤った署名が原因で yum からパッケージを取得できない
+### 誤った署名が原因で yum からパッケージを取得できない {#you-cant-get-packages-with-yum-because-of-wrong-signature}
起こりうる原因: キャッシュが不正です。2022 年 9 月に GPG キーを更新した後に壊れた可能性があります。
@@ -66,7 +66,7 @@ sudo rm -f /etc/yum.repos.d/clickhouse.repo
その後は、[インストールガイド](../getting-started/install.md#from-rpm-packages) に従ってください。
-### Docker コンテナを実行できない
+### Docker コンテナを実行できない {#you-cant-run-docker-container}
単純に `docker run clickhouse/clickhouse-server` を実行すると、以下のようなスタックトレースが出力されてクラッシュします。
@@ -99,14 +99,14 @@ Poco::Exception. Code: 1000, e.code() = 0, System exception: cannot start thread
```
-## サーバーへの接続
+## サーバーへの接続 {#troubleshooting-accepts-no-connections}
想定される問題:
* サーバーが起動していない
* 想定外または誤った設定パラメータ
-### サーバーが起動していない
+### サーバーが起動していない {#server-is-not-running}
**サーバーが起動しているか確認する**
@@ -175,7 +175,7 @@ $ sudo -u clickhouse /usr/bin/clickhouse-server --config-file /etc/clickhouse-se
このコマンドは、autostart スクリプトの標準パラメータを使用してサーバーを対話型アプリケーションとして起動します。このモードでは、`clickhouse-server` はすべてのイベントメッセージをコンソールに出力します。
-### 設定パラメータ
+### 設定パラメータ {#configuration-parameters}
次の点を確認します。
@@ -207,7 +207,7 @@ $ sudo -u clickhouse /usr/bin/clickhouse-server --config-file /etc/clickhouse-se
誤ったユーザー名またはパスワードを使用している可能性があります。
-## クエリ処理
+## クエリ処理 {#troubleshooting-does-not-process-queries}
ClickHouse がクエリを処理できない場合、エラー内容の説明をクライアントに送信します。`clickhouse-client` を使用している場合は、コンソール上でエラー内容を確認できます。HTTP インターフェイスを使用している場合は、ClickHouse はレスポンスボディ内にエラーの説明を送信します。例えば次のとおりです。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/allocation-profiling-old.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/allocation-profiling-old.md
index 9dd3b85f7ea..12930aa7971 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/allocation-profiling-old.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/allocation-profiling-old.md
@@ -10,14 +10,14 @@ import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# 25.9 以前のバージョン向けのアロケーションプロファイリング
+# 25.9 以前のバージョン向けのアロケーションプロファイリング {#allocation-profiling-for-versions-before-259}
ClickHouse はグローバルアロケータとして [jemalloc](https://github.com/jemalloc/jemalloc) を使用します。jemalloc には、アロケーションのサンプリングとプロファイリングのためのツールが付属しています。
アロケーションプロファイリングをより便利に行えるように、Keeper では `SYSTEM` コマンドに加えて four letter word (4LW) コマンドも提供されています。
-## アロケーションのサンプリングとヒーププロファイルのフラッシュ
+## アロケーションのサンプリングとヒーププロファイルのフラッシュ {#sampling-allocations-and-flushing-heap-profiles}
`jemalloc` でアロケーションのサンプリングとプロファイリングを行う場合は、環境変数 `MALLOC_CONF` を使用してプロファイリングを有効にし、ClickHouse/Keeper を起動する必要があります。
@@ -56,7 +56,7 @@ MALLOC_CONF=background_thread:true,prof:true,prof_prefix:/data/my_current_profil
生成されるファイル名は、接頭辞、PID、シーケンス番号を連結したものになります。
-## ヒーププロファイルの解析
+## ヒーププロファイルの解析 {#analyzing-heap-profiles}
ヒーププロファイルを生成したら、それを解析する必要があります。\
そのために、`jemalloc` のツールである [jeprof](https://github.com/jemalloc/jemalloc/blob/dev/bin/jeprof.in) を使用できます。これは複数の方法でインストールできます:
@@ -92,7 +92,7 @@ jeprof path/to/binary path/to/heap/profile --output_format [ > output_file]
jeprof path/to/binary --base path/to/first/heap/profile path/to/second/heap/profile --output_format [ > output_file]
```
-### 例
+### 例 {#examples}
* 各プロシージャを1行ごとに記述したテキストファイルを生成したい場合:
@@ -106,7 +106,7 @@ jeprof path/to/binary path/to/heap/profile --text > result.txt
jeprof path/to/binary path/to/heap/profile --pdf > result.pdf
```
-### フレームグラフの生成
+### フレームグラフの生成 {#generating-flame-graph}
`jeprof` を使用すると、フレームグラフの作成に必要な折りたたみスタック（collapsed stack）を生成できます。
@@ -127,7 +127,7 @@ cat result.collapsed | /path/to/FlameGraph/flamegraph.pl --color=mem --title="Al
もう 1 つ有用なツールとして [speedscope](https://www.speedscope.app/) があり、収集したスタック情報をよりインタラクティブに解析できます。
-## 実行時のアロケーションプロファイラの制御
+## 実行時のアロケーションプロファイラの制御 {#controlling-allocation-profiler-during-runtime}
ClickHouse/Keeper をプロファイラを有効にした状態で起動した場合、実行時にアロケーションプロファイリングを無効化/有効化するための追加コマンドを使用できます。
これらのコマンドを使用すると、特定の時間区間のみをプロファイルしやすくなります。
@@ -184,7 +184,7 @@ MALLOC_CONF=background_thread:true,prof:true,prof_active:false
-## その他のリソース
+## その他のリソース {#other-resources}
ClickHouse/Keeper は、`jemalloc` 関連のメトリクスをさまざまな方法で公開しています。
@@ -192,7 +192,7 @@ ClickHouse/Keeper は、`jemalloc` 関連のメトリクスをさまざまな方
これらのメトリクスは互いに同期されておらず、値がずれていく可能性があることを認識しておくことが重要です。
:::
-### システムテーブル `asynchronous_metrics`
+### システムテーブル `asynchronous_metrics` {#system-table-asynchronous_metrics}
```sql
SELECT *
@@ -203,19 +203,19 @@ FORMAT Vertical
[リファレンス](/operations/system-tables/asynchronous_metrics)
-### システムテーブル `jemalloc_bins`
+### システムテーブル `jemalloc_bins` {#system-table-jemalloc_bins}
サイズクラス（bin）ごとに `jemalloc` アロケータ経由で行われたメモリ割り当てに関する情報を、すべてのアリーナから集約して格納します。
[リファレンス](/operations/system-tables/jemalloc_bins)
-### Prometheus
+### Prometheus {#prometheus}
`asynchronous_metrics` に含まれるすべての `jemalloc` 関連メトリクスは、ClickHouse と Keeper の両方で Prometheus エンドポイントを通じても公開されます。
[リファレンス](/operations/server-configuration-parameters/settings#prometheus)
-### Keeper における `jmst` 4LW コマンド
+### Keeper における `jmst` 4LW コマンド {#jmst-4lw-command-in-keeper}
Keeper は `jmst` 4LW コマンドをサポートしており、[基本的なアロケータ統計情報](https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Basic-Allocator-Statistics) を返します。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/allocation-profiling.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/allocation-profiling.md
index fdee13466b7..b035ba7cb92 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/allocation-profiling.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/allocation-profiling.md
@@ -10,7 +10,7 @@ import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-# アロケーションプロファイリング
+# アロケーションプロファイリング {#allocation-profiling}
ClickHouse はグローバルアロケータとして [jemalloc](https://github.com/jemalloc/jemalloc) を使用しています。jemalloc には、アロケーションのサンプリングおよびプロファイリング用のツールが付属しています。
アロケーションプロファイリングをより手軽に行えるように、ClickHouse と Keeper では、設定ファイルやクエリ設定、`SYSTEM` コマンド、Keeper の four letter word (4LW) コマンドを使用してサンプリングを制御できます。
@@ -25,7 +25,7 @@ ClickHouse はグローバルアロケータとして [jemalloc](https://github.
-## アロケーションのサンプリング
+## アロケーションのサンプリング {#sampling-allocations}
`jemalloc` でアロケーションのサンプリングおよびプロファイリングを行うには、`jemalloc_enable_global_profiler` 設定を有効にして ClickHouse/Keeper を起動する必要があります。
@@ -44,7 +44,7 @@ ClickHouse はアロケーションが多いアプリケーションであるた
:::
-## `system.trace_log` に jemalloc サンプルを保存する
+## `system.trace_log` に jemalloc サンプルを保存する {#storing-jemalloc-samples-in-system-trace-log}
すべての jemalloc サンプルを `JemallocSample` 型として `system.trace_log` に格納できます。
これをグローバルに有効化するには、設定項目 `jemalloc_collect_global_profile_samples_in_trace_log` を使用します。
@@ -61,7 +61,7 @@ ClickHouse はメモリ割り当てを多用するアプリケーションであ
`jemalloc_collect_profile_samples_in_trace_log` 設定を使用して、クエリごとに有効化することもできます。
-### `system.trace_log` を使用してクエリのメモリ使用量を分析する例
+### `system.trace_log` を使用してクエリのメモリ使用量を分析する例 {#example-analyzing-memory-usage-trace-log}
まず、jemalloc プロファイラを有効にしてクエリを実行し、そのクエリのサンプルを `system.trace_log` に収集する必要があります。
@@ -181,7 +181,7 @@ ORDER BY per_trace_sum ASC
```
-## ヒーププロファイルのフラッシュ
+## ヒーププロファイルのフラッシュ {#flushing-heap-profiles}
デフォルトでは、ヒーププロファイル用ファイルは `/tmp/jemalloc_clickhouse._pid_._seqnum_.heap` に生成されます。ここで `_pid_` は ClickHouse の PID、`_seqnum_` は現在のヒーププロファイルに対応するグローバルなシーケンス番号です。\
Keeper のデフォルトファイルは `/tmp/jemalloc_keeper._pid_._seqnum_.heap` で、同じルールに従います。
@@ -214,7 +214,7 @@ MALLOC_CONF=prof_prefix:/data/my_current_profile
生成されるファイル名には、プレフィックスに続いて PID とシーケンス番号が付加されます。
-## ヒーププロファイルの分析
+## ヒーププロファイルの分析 {#analyzing-heap-profiles}
ヒーププロファイルが生成されたら、それらを分析する必要があります。\
そのために、`jemalloc` のツールである [jeprof](https://github.com/jemalloc/jemalloc/blob/dev/bin/jeprof.in) を使用できます。次のいずれかの方法でインストールできます。
@@ -252,7 +252,7 @@ jeprof path/to/binary path/to/heap/profile --output_format [ > output_file]
jeprof path/to/binary --base path/to/first/heap/profile path/to/second/heap/profile --output_format [ > output_file]
```
-### 例
+### 例 {#examples}
* 各プロシージャを1行ごとに記述したテキストファイルを生成したい場合:
@@ -266,7 +266,7 @@ jeprof path/to/binary path/to/heap/profile --text > result.txt
jeprof path/to/binary path/to/heap/profile --pdf > result.pdf
```
-### フレームグラフの生成
+### フレームグラフの生成 {#generating-flame-graph}
`jeprof` を使用すると、フレームグラフの作成に必要な折り畳みスタック（collapsed stacks）を生成できます。
@@ -297,7 +297,7 @@ cat result.collapsed | /path/to/FlameGraph/flamegraph.pl --color=mem --title="
-## その他のリソース
+## その他のリソース {#other-resources}
ClickHouse/Keeper は、`jemalloc` 関連のメトリクスをさまざまな方法で公開します。
@@ -305,7 +305,7 @@ ClickHouse/Keeper は、`jemalloc` 関連のメトリクスをさまざまな方
これらのメトリクスは相互に同期されておらず、値がずれる可能性があることを認識しておくことが重要です。
:::
-### システムテーブル `asynchronous_metrics`
+### システムテーブル `asynchronous_metrics` {#system-table-asynchronous_metrics}
```sql
SELECT *
@@ -316,19 +316,19 @@ FORMAT Vertical
[リファレンス](/operations/system-tables/asynchronous_metrics)
-### システムテーブル `jemalloc_bins`
+### システムテーブル `jemalloc_bins` {#system-table-jemalloc_bins}
すべてのアリーナから集約された、さまざまなサイズクラス（bin）における jemalloc アロケータによるメモリ割り当てに関する情報を含みます。
[リファレンス](/operations/system-tables/jemalloc_bins)
-### Prometheus
+### Prometheus {#prometheus}
`asynchronous_metrics` に含まれるすべての `jemalloc` 関連メトリクスは、ClickHouse と Keeper の両方で Prometheus エンドポイントからも公開されます。
[リファレンス](/operations/server-configuration-parameters/settings#prometheus)
-### Keeper における `jmst` 4LW コマンド
+### Keeper における `jmst` 4LW コマンド {#jmst-4lw-command-in-keeper}
Keeper は `jmst` 4LW コマンドをサポートしており、[基本的なアロケータ統計情報](https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Basic-Allocator-Statistics)を返します。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/analyzer.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/analyzer.md
index 3516278aebc..7e385323b25 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/analyzer.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/analyzer.md
@@ -7,20 +7,16 @@ title: 'アナライザー'
doc_type: 'reference'
---
-
-
-# Analyzer
+# Analyzer {#analyzer}
ClickHouse バージョン `24.3` では、新しいクエリアナライザーがデフォルトで有効になりました。
その動作の詳細については[こちら](/guides/developer/understanding-query-execution-with-the-analyzer#analyzer)を参照してください。
-
-
-## 既知の非互換性
+## 既知の非互換性 {#known-incompatibilities}
多数のバグ修正と新しい最適化を導入した一方で、ClickHouse の動作には後方互換性を破る変更もいくつか含まれています。新しいアナライザ用にクエリを書き換える方法を判断するために、以下の変更点を確認してください。
-### 無効なクエリはこれ以上最適化されない
+### 無効なクエリはこれ以上最適化されない {#invalid-queries-are-no-longer-optimized}
以前のクエリプランニング基盤では、クエリの検証ステップより前に AST レベルの最適化が適用されていました。
この最適化により、元のクエリを書き換えて有効かつ実行可能にできる場合がありました。
@@ -29,7 +25,7 @@ ClickHouse バージョン `24.3` では、新しいクエリアナライザー
これは、以前は実行可能だった無効なクエリが、現在はサポートされなくなったことを意味します。
そのような場合、そのクエリは手動で修正する必要があります。
-#### 例 1
+#### 例 1 {#example-1}
次のクエリは、集約後に利用可能なのが `toString(number)` だけであるにもかかわらず、SELECT 句でカラム `number` を使用しています。
旧アナライザでは、`GROUP BY toString(number)` は `GROUP BY number` に最適化され、その結果クエリは有効になっていました。
@@ -40,7 +36,7 @@ FROM numbers(1)
GROUP BY toString(number)
```
-#### 例 2
+#### 例 2 {#example-2}
このクエリでも同じ問題が発生します。列 `number` は、別のキーと一緒に集約した後に使用されています。
以前のクエリアナライザーは、`number > 5` というフィルタを `HAVING` 句から `WHERE` 句に移動することで、このクエリを修正しました。
@@ -65,7 +61,7 @@ WHERE number > 5
GROUP BY n
```
-### 無効なクエリを指定した `CREATE VIEW`
+### 無効なクエリを指定した `CREATE VIEW` {#create-view-with-invalid-query}
新しいアナライザは常に型チェックを行います。
以前は、無効な `SELECT` クエリを含む `VIEW` を作成できていました。
@@ -73,7 +69,7 @@ GROUP BY n
このような形で `VIEW` を作成することは、もはやできません。
-#### 例
+#### 例 {#example-view}
```sql
CREATE TABLE source (data String)
@@ -85,9 +81,9 @@ AS SELECT JSONExtract(data, 'test', 'DateTime64(3)')
FROM source;
```
-### `JOIN` 句の既知の非互換性
+### `JOIN` 句の既知の非互換性 {#known-incompatibilities-of-the-join-clause}
-#### プロジェクションの列を使用する `JOIN`
+#### プロジェクションの列を使用する `JOIN` {#join-using-column-from-projection}
`SELECT` リスト内のエイリアスは、デフォルトでは `JOIN USING` のキーとして使用できません。
@@ -107,7 +103,7 @@ USING (b);
設定が `false` の場合、結合条件はデフォルトで `t1.b = t2.b` となり、クエリは `2, 'one'` を返します。
`b` が `t1` に存在しない場合、クエリはエラーとなって失敗します。
-#### `JOIN USING` と `ALIAS` / `MATERIALIZED` カラムにおける動作の変更
+#### `JOIN USING` と `ALIAS` / `MATERIALIZED` カラムにおける動作の変更 {#changes-in-behavior-with-join-using-and-aliasmaterialized-columns}
新しいアナライザでは、`ALIAS` または `MATERIALIZED` カラムを含む `JOIN USING` クエリで `*` を使用すると、それらのカラムもデフォルトで結果セットに含まれます。
@@ -124,14 +120,13 @@ SELECT * FROM t1
FULL JOIN t2 USING (payload);
```
-
新しいアナライザーでは、このクエリの結果には、両方のテーブルからの `id` 列に加えて `payload` 列が含まれます。
これに対して、以前のアナライザーでは、特定の設定（`asterisk_include_alias_columns` または `asterisk_include_materialized_columns`）が有効になっている場合にのみ、これらの `ALIAS` 列が結果に含まれ、
かつ列の並び順が異なる場合がありました。
特に古いクエリを新しいアナライザーに移行する際に、一貫性があり期待どおりの結果を得るためには、`*` を使うのではなく、`SELECT` 句で列を明示的に指定することを推奨します。
-#### `USING` 句内の列に対する型修飾子の扱い
+#### `USING` 句内の列に対する型修飾子の扱い {#handling-of-type-modifiers-for-columns-in-using-clause}
新しいバージョンのアナライザーでは、`USING` 句で指定された列に対して共通スーパータイプを決定するための規則が標準化されており、
特に `LowCardinality` や `Nullable` といった型修飾子を扱う際に、より予測しやすい結果が得られるようになっています。
@@ -150,7 +145,7 @@ USING (id);
このクエリでは、`id` の共通スーパータイプは `String` として判定され、`t1` では `LowCardinality` 修飾子が除外されます。
-### Projection 列名の変更
+### Projection 列名の変更 {#projection-column-names-changes}
Projection 列名を計算する際、エイリアスは展開されません。
@@ -176,7 +171,7 @@ FORMAT PrettyCompact
└───┴────────────┘
```
-### 互換性のない関数引数の型
+### 互換性のない関数引数の型 {#incompatible-function-arguments-types}
新しいアナライザーでは、型推論はクエリの初期解析中に行われます。
この変更により、短絡評価の前に型チェックが行われるようになり、その結果、`if` 関数の引数は常に共通の上位型（スーパータイプ）を持つ必要があります。
@@ -187,18 +182,18 @@ FORMAT PrettyCompact
SELECT toTypeName(if(0, [2, 3, 4], 'String'))
```
-### 異種クラスタ
+### 異種クラスタ {#heterogeneous-clusters}
新しい analyzer は、クラスタ内のサーバー間の通信プロトコルを大きく変更します。\
そのため、`enable_analyzer` の設定値が異なるサーバー間で分散クエリを実行することはできません。
-### ミューテーションは旧 analyzer によって解釈される
+### ミューテーションは旧 analyzer によって解釈される {#mutations-are-interpreted-by-previous-analyzer}
ミューテーションは依然として古い analyzer を使用します。\
これは、一部の新しい ClickHouse SQL 機能（たとえば `QUALIFY` 句）がミューテーションでは使用できないことを意味します。\
対応状況は[こちら](https://github.com/ClickHouse/ClickHouse/issues/61563)で確認できます。
-### 未サポートの機能
+### 未サポートの機能 {#unsupported-features}
新しい analyzer が現在サポートしていない機能の一覧は以下のとおりです。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/backup.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/backup.md
index c853070fb70..0c2265e73fc 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/backup.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/backup.md
@@ -9,7 +9,7 @@ doc_type: 'guide'
-# バックアップと復元
+# バックアップと復元 {#backup-and-restore}
- [ローカルディスクへのバックアップ](#backup-to-a-local-disk)
- [S3 エンドポイントを使用したバックアップ／復元の設定](#configuring-backuprestore-to-use-an-s3-endpoint)
@@ -18,7 +18,7 @@ doc_type: 'guide'
-## コマンドの概要
+## コマンドの概要 {#command-summary}
```bash
BACKUP|RESTORE
@@ -56,9 +56,9 @@ doc_type: 'guide'
-## ローカルディスクへのバックアップ
+## ローカルディスクへのバックアップ {#backup-to-a-local-disk}
-### バックアップ先の設定
+### バックアップ先の設定 {#configure-a-backup-destination}
以下の例では、バックアップ先は `Disk('backups', '1.zip')` のように指定されます。バックアップ先を準備するには、バックアップ先を指定したファイルを `/etc/clickhouse-server/config.d/backup_disk.xml` に追加します。例えば、このファイルでは `backups` という名前のディスクを定義し、そのディスクを **backups > allowed_disk** リストに追加します。
@@ -82,7 +82,7 @@ doc_type: 'guide'
```
-### パラメーター
+### パラメーター {#parameters}
バックアップはフルバックアップまたは増分バックアップとし、テーブル（マテリアライズドビュー、プロジェクション、ディクショナリを含む）やデータベースを対象にできます。バックアップは同期（デフォルト）または非同期で実行できます。圧縮することも可能で、パスワード保護を設定できます。
@@ -105,7 +105,7 @@ doc_type: 'guide'
* `azure_attempt_to_create_container`: Azure Blob Storage を使用する場合、指定されたコンテナーが存在しないときに作成を試みるかどうか。デフォルト: true。
* [コア設定](/operations/settings/settings) もここで使用できます
-### 使用例
+### 使用例 {#usage-examples}
テーブルをバックアップしてからリストアする例:
@@ -139,7 +139,7 @@ RESTORE TABLE test.table AS test.table2 FROM Disk('backups', '1.zip')
BACKUP TABLE test.table3 AS test.table4 TO Disk('backups', '2.zip')
```
-### 増分バックアップ
+### 増分バックアップ {#incremental-backups}
`base_backup` を指定すると、増分バックアップを作成できます。
:::note
@@ -161,7 +161,7 @@ RESTORE TABLE test.table AS test.table2
FROM Disk('backups', 'incremental-a.zip');
```
-### バックアップにパスワードを設定する
+### バックアップにパスワードを設定する {#assign-a-password-to-the-backup}
ディスクに書き込まれるバックアップファイルには、パスワードを設定できます。
@@ -179,7 +179,7 @@ RESTORE TABLE test.table
SETTINGS password='qwerty'
```
-### 圧縮設定
+### 圧縮設定 {#compression-settings}
圧縮方式や圧縮レベルを指定したい場合は、次のように設定します。
@@ -189,7 +189,7 @@ BACKUP TABLE test.table
SETTINGS compression_method='lzma', compression_level=3
```
-### 特定のパーティションを復元する
+### 特定のパーティションを復元する {#restore-specific-partitions}
テーブルに関連付けられた特定のパーティションのみを復元する必要がある場合は、それらを指定できます。バックアップからパーティション 1 と 4 を復元するには：
@@ -198,7 +198,7 @@ RESTORE TABLE test.table PARTITIONS '2', '3'
FROM Disk('backups', 'filename.zip')
```
-### tar アーカイブとしてのバックアップ
+### tar アーカイブとしてのバックアップ {#backups-as-tar-archives}
バックアップは tar アーカイブとして保存することもできます。パスワードがサポートされていない点を除き、機能は zip の場合と同じです。
@@ -222,7 +222,7 @@ BACKUP TABLE test.table TO Disk('backups', '1.tar.gz')
サポートされている圧縮ファイルの拡張子は、`tar.gz`、`.tgz`、`tar.bz2`、`tar.lzma`、`.tar.zst`、`.tzst`、`.tar.xz` です。
-### バックアップのステータスを確認する
+### バックアップのステータスを確認する {#check-the-status-of-backups}
バックアップコマンドは `id` と `status` を返し、その `id` を使ってバックアップのステータスを取得できます。これは、時間のかかる ASYNC バックアップの進行状況を確認するのに非常に便利です。以下の例は、既存のバックアップファイルを上書きしようとしたときに発生した失敗を示しています。
@@ -317,7 +317,7 @@ bytes_read: 0
```
-## S3 エンドポイントを使用するように BACKUP/RESTORE を構成する
+## S3 エンドポイントを使用するように BACKUP/RESTORE を構成する {#configuring-backuprestore-to-use-an-s3-endpoint}
バックアップを S3 バケットに書き込むには、次の 3 つの情報が必要です。
@@ -355,7 +355,7 @@ FROM generateRandom('key Int, value String, array Array(String)')
LIMIT 1000
```
-### ベース（初期）バックアップを作成する
+### ベース（初期）バックアップを作成する {#create-a-base-initial-backup}
増分バックアップを実行するには、開始点となる *ベース* バックアップが必要です。この例では、後でベースバックアップとして使用します。S3 の宛先の最初のパラメーターは S3 エンドポイントであり、その後に、このバックアップで使用するバケット内のディレクトリを指定します。この例では、ディレクトリ名は `my_backup` です。
@@ -369,7 +369,7 @@ BACKUP TABLE data TO S3('https://mars-doc-test.s3.amazonaws.com/backup-S3/my_bac
└──────────────────────────────────────┴────────────────┘
```
-### データをさらに追加する
+### データをさらに追加する {#add-more-data}
増分バックアップには、ベースバックアップとバックアップ対象テーブルの現在の内容との差分が格納されます。増分バックアップを作成する前に、テーブルにデータを追加します。
@@ -379,7 +379,7 @@ FROM generateRandom('key Int, value String, array Array(String)')
LIMIT 100
```
-### 増分バックアップを作成する
+### 増分バックアップを作成する {#take-an-incremental-backup}
このバックアップコマンドはベースバックアップと似ていますが、`SETTINGS base_backup` とベースバックアップの場所を指定する点が異なります。増分バックアップの保存先はベースバックアップと同じディレクトリではなく、同じエンドポイント上のバケット内にある別のターゲットディレクトリであることに注意してください。ベースバックアップは `my_backup` にあり、増分バックアップは `my_incremental` に書き込まれます。
@@ -393,7 +393,7 @@ BACKUP TABLE data TO S3('https://mars-doc-test.s3.amazonaws.com/backup-S3/my_inc
└──────────────────────────────────────┴────────────────┘
```
-### 増分バックアップからのリストア
+### 増分バックアップからのリストア {#restore-from-the-incremental-backup}
このコマンドは、増分バックアップを新しいテーブル `data3` にリストアします。増分バックアップをリストアする場合、ベースバックアップも合わせて含まれることに注意してください。リストア時には、増分バックアップのみを指定してください。
@@ -407,7 +407,7 @@ RESTORE TABLE data AS data3 FROM S3('https://mars-doc-test.s3.amazonaws.com/back
└──────────────────────────────────────┴──────────┘
```
-### 件数を確認する
+### 件数を確認する {#verify-the-count}
元のテーブル `data` には、1,000 行の挿入と 100 行の挿入の 2 回の INSERT が行われており、合計で 1,100 行になっています。復元されたテーブルに 1,100 行あることを確認します。
@@ -424,7 +424,7 @@ FROM data3
```
-### 内容を検証する
+### 内容を検証する {#verify-the-content}
ここでは、元のテーブル `data` の内容を、復元したテーブル `data3` と比較します。
@@ -438,7 +438,7 @@ SELECT throwIf((
), 'BACKUP/RESTORE後にデータが一致しません')
```
-## S3 ディスクを使用した BACKUP/RESTORE
+## S3 ディスクを使用した BACKUP/RESTORE {#backuprestore-using-an-s3-disk}
ClickHouse のストレージ設定で S3 ディスクを設定することで、`BACKUP`/`RESTORE` を S3 を対象として実行することもできます。`/etc/clickhouse-server/config.d` にファイルを追加して、次のようにディスクを設定します。
@@ -516,7 +516,7 @@ ClickHouse では、`ALTER TABLE ... FREEZE PARTITION ...` クエリを使用し
-## バックアップとリストアの並行実行を禁止するための設定
+## バックアップとリストアの並行実行を禁止するための設定 {#settings-to-disallow-concurrent-backuprestore}
バックアップとリストアの並行実行を禁止するには、それぞれ次の設定を使用します。
@@ -533,7 +533,7 @@ ClickHouse では、`ALTER TABLE ... FREEZE PARTITION ...` クエリを使用し
これらの設定がクラスターで false に設定されている場合、そのクラスター上で同時に実行できるバックアップ／リストアは 1 つだけになります。
-## AzureBlobStorage エンドポイントを使用するように BACKUP/RESTORE を構成する
+## AzureBlobStorage エンドポイントを使用するように BACKUP/RESTORE を構成する {#configuring-backuprestore-to-use-an-azureblobstorage-endpoint}
バックアップを書き込む AzureBlobStorage コンテナには、以下の情報が必要です。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/caches.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/caches.md
index 203a440341f..94dab47a3f3 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/caches.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/caches.md
@@ -8,32 +8,32 @@ keywords: ['cache']
doc_type: 'reference'
---
-# キャッシュの種類
+# キャッシュの種類 {#cache-types}
クエリを実行する際には、ClickHouse はさまざまなキャッシュを利用してクエリ処理を高速化し、
ディスクからの読み取りやディスクへの書き込みの必要性を減らします。
主なキャッシュの種類は次のとおりです：
-- `mark_cache` — [`MergeTree`](../engines/table-engines/mergetree-family/mergetree.md) ファミリーのテーブルエンジンで使用される [marks](/development/architecture#merge-tree) のキャッシュ。
-- `uncompressed_cache` — [`MergeTree`](../engines/table-engines/mergetree-family/mergetree.md) ファミリーのテーブルエンジンで使用される非圧縮データのキャッシュ。
-- オペレーティングシステムのページキャッシュ（実データを保持するファイルに対して間接的に利用される）。
+* `mark_cache` — [`MergeTree`](../engines/table-engines/mergetree-family/mergetree.md) ファミリーのテーブルエンジンで使用される [marks](/development/architecture#merge-tree) のキャッシュ。
+* `uncompressed_cache` — [`MergeTree`](../engines/table-engines/mergetree-family/mergetree.md) ファミリーのテーブルエンジンで使用される非圧縮データのキャッシュ。
+* オペレーティングシステムのページキャッシュ（実データを保持するファイルに対して間接的に利用される）。
このほかにも、多数の追加キャッシュがあります：
-- DNS キャッシュ。
-- [Regexp](/interfaces/formats/Regexp) キャッシュ。
-- コンパイル済み式のキャッシュ。
-- [ベクトル類似性インデックス](../engines/table-engines/mergetree-family/annindexes.md) キャッシュ。
-- [テキストインデックス](../engines/table-engines/mergetree-family/invertedindexes.md#caching) キャッシュ。
-- [Avro format](/interfaces/formats/Avro) スキーマキャッシュ。
-- [Dictionaries](../sql-reference/dictionaries/index.md) データキャッシュ。
-- スキーマ推論キャッシュ。
-- S3、Azure、ローカルおよびその他のディスクを対象とした [Filesystem cache](storing-data.md)。
-- [Userspace page cache](/operations/userspace-page-cache)。
-- [Query cache](query-cache.md)。
-- [Query condition cache](query-condition-cache.md)。
-- フォーマットスキーマキャッシュ。
+* DNS キャッシュ。
+* [Regexp](/interfaces/formats/Regexp) キャッシュ。
+* コンパイル済み式のキャッシュ。
+* [ベクトル類似性インデックス](../engines/table-engines/mergetree-family/annindexes.md) キャッシュ。
+* [テキストインデックス](../engines/table-engines/mergetree-family/invertedindexes.md#caching) キャッシュ。
+* [Avro format](/interfaces/formats/Avro) スキーマキャッシュ。
+* [Dictionaries](../sql-reference/dictionaries/index.md) データキャッシュ。
+* スキーマ推論キャッシュ。
+* S3、Azure、ローカルおよびその他のディスクを対象とした [Filesystem cache](storing-data.md)。
+* [Userspace page cache](/operations/userspace-page-cache)。
+* [Query cache](query-cache.md)。
+* [Query condition cache](query-condition-cache.md)。
+* フォーマットスキーマキャッシュ。
パフォーマンスチューニング、トラブルシューティング、またはデータ整合性の観点から
これらのキャッシュのいずれかを削除したい場合は、
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/cluster-discovery.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/cluster-discovery.md
index 24335f17235..c3a3aae87c8 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/cluster-discovery.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/cluster-discovery.md
@@ -6,13 +6,9 @@ title: 'クラスターディスカバリ'
doc_type: 'ガイド'
---
+# クラスターディスカバリ {#cluster-discovery}
-
-# クラスターディスカバリ
-
-
-
-## 概要
+## 概要 {#overview}
ClickHouse の Cluster Discovery 機能は、ノードを設定ファイル内で明示的に定義しなくても、自動的に検出して登録できるようにすることで、クラスタの構成を簡素化します。これは、各ノードを手動で定義することが負担になる場合に特に有用です。
@@ -31,10 +27,9 @@ Cluster Discovery は実験的な機能であり、将来のバージョンで
:::
+## リモートサーバーの設定 {#remote-servers-configuration}
-## リモートサーバーの設定
-
-### 従来の手動設定
+### 従来の手動設定 {#traditional-manual-configuration}
従来は ClickHouse では、クラスタ内の各シャードおよびレプリカを設定ファイルで手動指定する必要がありました。
@@ -66,7 +61,7 @@ Cluster Discovery は実験的な機能であり、将来のバージョンで
```
-### クラスター検出を使用する
+### クラスター検出を使用する {#using-cluster-discovery}
Cluster Discovery を使用すると、各ノードを明示的に定義する代わりに、ZooKeeper 内のパスを 1 つ指定するだけで済みます。ZooKeeper のそのパス配下に登録されたすべてのノードは、自動的に検出されてクラスターに追加されます。
@@ -114,7 +109,7 @@ Cluster Discovery を使用すると、各ノードを明示的に定義する
```
-### オブザーバーモード
+### オブザーバーモード {#observer-mode}
オブザーバーモードで構成されたノードは、自身をレプリカとして登録しません。
これらのノードはクラスター内の他のアクティブなレプリカを監視・検出するだけで、能動的には参加しません。
@@ -127,7 +122,7 @@ Cluster Discovery を使用すると、各ノードを明示的に定義する
```
-### クラスターの検出
+### クラスターの検出 {#discovery-of-clusters}
場合によっては、クラスター内のホストだけでなく、クラスター自体を追加・削除する必要が生じることがあります。複数のクラスターのルートパスを指定するために `` ノードを使用できます。
@@ -168,8 +163,7 @@ Cluster Discovery を使用すると、各ノードを明示的に定義する
* `` と併用できるのは `` のみです。
* Keeper で指定されたパスの最後の部分がクラスタ名として使用されますが、登録時には XML タグに記載された名前が使用されます。
-
-## ユースケースと制限事項
+## ユースケースと制限事項 {#use-cases-and-limitations}
指定された ZooKeeper パスにノードが追加または削除されると、構成変更やサーバーの再起動を行うことなく、それらのノードはクラスターに自動的に認識されて参加するか、クラスターから削除されます。
@@ -223,7 +217,6 @@ INSERT INTO event_table ...
SELECT hostname(), database, table FROM clusterAllReplicas(default, system.tables) WHERE table = 'event_table' FORMAT PrettyCompactMonoBlock
```
-
┌─hostname()───┬─database─┬─table───────┐
│ a6a68731c21b │ default │ event_table │
│ 92d3c04025e8 │ default │ event_table │
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/configuration-files.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/configuration-files.md
index b7f3ea4f507..ebdcbd365f1 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/configuration-files.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/configuration-files.md
@@ -29,7 +29,7 @@ YAML 設定ファイルでは、`clickhouse:` は省略可能であり、省略
-## 設定のマージ
+## 設定のマージ {#merging}
2 つの設定ファイル（通常はメインの設定ファイルと `config.d/` 内の別の設定ファイル）は、次のようにマージされます。
@@ -83,7 +83,7 @@ YAML 設定ファイルでは、`clickhouse:` は省略可能であり、省略
```
-### 環境変数および ZooKeeper ノードによる置換
+### 環境変数および ZooKeeper ノードによる置換 {#from_env_zk}
要素の値を環境変数の値で置き換えることを指定するには、属性 `from_env` を使用できます。
@@ -121,7 +121,7 @@ YAML 設定ファイルでは、`clickhouse:` は省略可能であり、省略
```shell
-# clickhouse-keeper-client
+# clickhouse-keeper-client {#clickhouse-keeper-client}
/ :) touch /zk_configs
/ :) create /zk_configs/postgresql_port "9005"
/ :) get /zk_configs/postgresql_port
@@ -136,7 +136,7 @@ YAML 設定ファイルでは、`clickhouse:` は省略可能であり、省略
```
-#### デフォルト値
+#### デフォルト値 {#default-values}
`from_env` または `from_zk` 属性を持つ要素には、追加で `replace="1"` 属性を指定できます（この属性は `from_env` / `from_zk` より前に記述する必要があります）。
この場合、その要素でデフォルト値を定義できます。
@@ -167,7 +167,7 @@ YAML 設定ファイルでは、`clickhouse:` は省略可能であり、省略
```
-## ファイル内容による置換
+## ファイル内容による置換 {#substitution-with-file-content}
設定の一部をファイルの内容で置き換えることも可能です。これは次の 2 つの方法で行えます。
@@ -192,7 +192,7 @@ YAML 設定ファイルでは、`clickhouse:` は省略可能であり、省略
既存の設定に追記するのではなく、include で差し込む内容を既存の設定とマージしたい場合は、属性 `merge="true"` を使用できます。たとえば、`` のように指定します。この場合、既存の設定は include で読み込まれる内容とマージされ、既存の設定値は読み込まれた側の値で置き換えられます。
-## 設定の暗号化と秘匿
+## 設定の暗号化と秘匿 {#encryption}
共通鍵暗号を使用して、平文のパスワードや秘密鍵などの設定要素を暗号化できます。
そのためには、まず [encryption codec](../sql-reference/statements/create/table.md#encryption-codecs) を設定し、その後、暗号化する要素に対して属性 `encrypted_by` を追加し、その値として暗号化コーデックの名前を指定します。
@@ -325,7 +325,7 @@ YAML 設定ファイルでは、`clickhouse:` は省略可能であり、省略
-## XML の例
+## XML の例 {#example}
例えば、各ユーザーごとにこのように個別の設定ファイルを用意できます：
@@ -349,7 +349,7 @@ $ cat /etc/clickhouse-server/users.d/alice.xml
```
-## YAML の例
+## YAML の例 {#example-1}
ここでは、YAML で記述されたデフォルト設定を確認できます: [`config.yaml.example`](https://github.com/ClickHouse/ClickHouse/blob/master/programs/server/config.yaml.example)。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/http.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/http.md
index d228cffc973..5ca39ec4644 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/http.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/http.md
@@ -5,14 +5,13 @@ title: 'HTTP'
doc_type: 'reference'
---
-import SelfManaged from '@site/docs/_snippets/_self_managed_only_no_roadmap.md';
+import SelfManaged from '@site/i18n/jp/docusaurus-plugin-content-docs/current/_snippets/_self_managed_only_no_roadmap.md';
HTTP サーバーを使用して ClickHouse ユーザーを認証できます。HTTP 認証は、`users.xml` またはローカルのアクセス制御パスで定義された既存ユーザーに対する外部認証方式としてのみ使用できます。現在は、GET メソッドを使用する [Basic](https://datatracker.ietf.org/doc/html/rfc7617) 認証スキームがサポートされています。
-
-## HTTP 認証サーバーの定義
+## HTTP 認証サーバーの定義 {#http-auth-server-definition}
HTTP認証サーバーを定義するには、`config.xml` ファイルに `http_authentication_servers` セクションを追加する必要があります。
@@ -63,7 +62,7 @@ HTTP認証サーバーを定義するには、`config.xml` ファイルに `http
ここでは、クライアントリクエストのヘッダーから外部 HTTP 認証サーバーへ転送されるヘッダーを定義します。ヘッダーは設定済みのものと大文字小文字を区別せずに照合されますが、転送時は元の形、すなわち変更されずに送信されます。
-### `users.xml` での HTTP 認証の有効化
+### `users.xml` での HTTP 認証の有効化 {#enabling-http-auth-in-users-xml}
ユーザーに対して HTTP 認証を有効にするには、ユーザー定義内で `password` などのセクションの代わりに `http_authentication` セクションを指定します。
@@ -91,7 +90,7 @@ HTTP認証サーバーを定義するには、`config.xml` ファイルに `http
HTTP 認証は、他の認証メカニズムと併用できない点に注意してください。`http_authentication` と一緒に `password` など他のセクションが存在する場合、ClickHouse は強制終了されます。
:::
-### SQL を使用した HTTP 認証の有効化
+### SQL を使用した HTTP 認証の有効化 {#enabling-http-auth-using-sql}
ClickHouse で [SQL ベースのアクセス制御とアカウント管理](/operations/access-rights#access-control-usage) が有効になっている場合、HTTP 認証で認証されるユーザーは、SQL 文を使用して作成することもできます。
@@ -105,6 +104,6 @@ CREATE USER my_user IDENTIFIED WITH HTTP SERVER 'basic_server' SCHEME 'Basic'
CREATE USER my_user IDENTIFIED WITH HTTP SERVER 'basic_server'
```
-### セッション設定の受け渡し
+### セッション設定の受け渡し {#passing-session-settings}
HTTP 認証サーバーからのレスポンスボディが JSON 形式で、`settings` サブオブジェクトを含んでいる場合、ClickHouse はそのキーと値のペアを文字列値として解析しようとし、認証済みユーザーの現在のセッションのセッション設定としてそれらを設定します。解析に失敗した場合、サーバーからのレスポンスボディは無視されます。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/index.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/index.md
index 17ac1e731b4..0271dbcac34 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/index.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/index.md
@@ -8,7 +8,7 @@ title: '外部ユーザー認証およびディレクトリ'
doc_type: 'reference'
---
-import SelfManaged from '@site/docs/_snippets/_self_managed_only_no_roadmap.md';
+import SelfManaged from '@site/i18n/jp/docusaurus-plugin-content-docs/current/_snippets/_self_managed_only_no_roadmap.md';
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/kerberos.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/kerberos.md
index 04baf77d2fa..bb288768131 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/kerberos.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/kerberos.md
@@ -5,10 +5,9 @@ title: 'Kerberos'
doc_type: 'reference'
---
-import SelfManaged from '@site/docs/_snippets/_self_managed_only_no_roadmap.md';
+import SelfManaged from '@site/i18n/jp/docusaurus-plugin-content-docs/current/_snippets/_self_managed_only_no_roadmap.md';
-
-# Kerberos
+# Kerberos {#kerberos}
@@ -18,13 +17,11 @@ import SelfManaged from '@site/docs/_snippets/_self_managed_only_no_roadmap.md';
この方式を利用するには、システム側で Kerberos が設定されており、かつ ClickHouse の設定で有効化されている必要があります。
-
-
-## ClickHouse で Kerberos を有効化する
+## ClickHouse で Kerberos を有効化する {#enabling-kerberos-in-clickhouse}
Kerberos を有効化するには、`config.xml` に `kerberos` セクションを追加する必要があります。このセクションには追加のパラメータを含めることができます。
-#### パラメータ
+#### パラメータ {#parameters}
* `principal` - セキュリティコンテキストを受け入れる際に取得・使用される正規のサービスプリンシパル名。
* このパラメータは省略可能で、省略された場合はデフォルトのプリンシパルが使用されます。
@@ -74,8 +71,7 @@ Kerberos を有効化するには、`config.xml` に `kerberos` セクション
`principal` セクションと `realm` セクションは同時に指定できません。`principal` と `realm` の両方のセクションが存在する場合、ClickHouse は Kerberos 認証を無効にします。
:::
-
-## 既存ユーザー向けの外部認証方式としての Kerberos
+## 既存ユーザー向けの外部認証方式としての Kerberos {#kerberos-as-an-external-authenticator-for-existing-users}
Kerberos は、ローカルに定義されたユーザー（`users.xml` またはローカルのアクセス制御パスで定義されたユーザー）の認証方法として使用できます。現在のところ、**HTTP インターフェイス経由のリクエストのみ**が（GSS-SPNEGO メカニズムを通じて）*Kerberos 対応*とできます。
@@ -85,7 +81,7 @@ Kerberos プリンシパル名の形式は通常、次のパターンに従い
*/instance* の部分は 0 回以上出現する可能性があります。**イニシエーターの正規（canonical）なプリンシパル名の *primary* 部分が Kerberos 対応ユーザー名と一致している必要があり、一致した場合にのみ認証が成功します。**
-### `users.xml` で Kerberos を有効化する
+### `users.xml` で Kerberos を有効化する {#enabling-kerberos-in-users-xml}
ユーザーに対して Kerberos 認証を有効にするには、ユーザー定義内で `password` などのセクションの代わりに `kerberos` セクションを指定します。
@@ -119,7 +115,7 @@ Kerberos 認証は、他の認証メカニズムと同時に使用できない
ここで、ユーザー `my_user` が `kerberos` を使用するようになった場合、前述のとおり、メインの `config.xml` ファイルで Kerberos を有効化しておく必要がある点に注意してください。
:::
-### SQL を使用した Kerberos の有効化
+### SQL を使用した Kerberos の有効化 {#enabling-kerberos-using-sql}
ClickHouse で [SQL-driven Access Control and Account Management](/operations/access-rights#access-control-usage) が有効化されている場合、Kerberos で識別されるユーザーも SQL 文を使用して作成できます。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/ldap.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/ldap.md
index b4da31d7483..965b69fcedd 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/ldap.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/ldap.md
@@ -5,7 +5,7 @@ title: 'LDAP'
doc_type: 'reference'
---
-import SelfManaged from '@site/docs/_snippets/_self_managed_only_no_roadmap.md';
+import SelfManaged from '@site/i18n/jp/docusaurus-plugin-content-docs/current/_snippets/_self_managed_only_no_roadmap.md';
@@ -16,8 +16,7 @@ LDAP サーバーは ClickHouse ユーザーの認証に使用できます。こ
これら 2 つのアプローチのいずれにおいても、ClickHouse の設定内で内部名を持つ LDAP サーバーを定義し、設定の他の箇所からそれを参照できるようにする必要があります。
-
-## LDAP サーバーの定義
+## LDAP サーバーの定義 {#ldap-server-definition}
LDAP サーバーを定義するには、`config.xml` に `ldap_servers` セクションを追加する必要があります。
@@ -62,39 +61,36 @@ LDAP サーバーを定義するには、`config.xml` に `ldap_servers` セク
**パラメータ**
-
-- `host` — LDAP サーバーのホスト名または IP。このパラメータは必須であり、空にはできません。
-- `port` — LDAP サーバーのポート。`enable_tls` が `true` に設定されている場合のデフォルトは `636`、それ以外の場合は `389` です。
-- `bind_dn` — バインドに使用する DN を構築するためのテンプレート。
- - 認証が試行されるたびに、このテンプレート内のすべての `{user_name}` 文字列が実際のユーザー名で置き換えられ、最終的な DN が構築されます。
-- `user_dn_detection` — バインドされたユーザーの実際のユーザー DN を検出するための LDAP 検索パラメータのセクション。
- - これは主にサーバーが Active Directory の場合に、追加のロールマッピングのための検索フィルタで使用されます。最終的なユーザー DN は、`{user_dn}` 文字列を許可されている場所で置き換える際に使用されます。デフォルトではユーザー DN は bind DN と同一に設定されますが、検索が実行されると、検出された実際のユーザー DN の値で更新されます。
- - `base_dn` — LDAP 検索用の base DN を構築するために使用されるテンプレート。
- - LDAP 検索中に、このテンプレート内のすべての `{user_name}` および `{bind_dn}` 文字列が実際のユーザー名および bind DN で置き換えられ、最終的な DN が構築されます。
- - `scope` — LDAP 検索のスコープ。
- - 受け付けられる値は `base`、`one_level`、`children`、`subtree`（デフォルト）です。
- - `search_filter` — LDAP 検索用の検索フィルタを構築するために使用されるテンプレート。
- - LDAP 検索中に、このテンプレート内のすべての `{user_name}`、`{bind_dn}`、`{base_dn}` 文字列が、実際のユーザー名、bind DN、base DN で置き換えられ、最終的なフィルタが構築されます。
- - 特殊文字は XML で正しくエスケープする必要がある点に注意してください。
-- `verification_cooldown` — バインドが成功した後、この秒数の間は LDAP サーバーに問い合わせることなく、連続するすべてのリクエストについてユーザーが認証済みであるとみなされる期間。
- - キャッシュを無効化し、認証リクエストごとに LDAP サーバーへの問い合わせを強制するには、`0`（デフォルト）を指定します。
-- `enable_tls` — LDAP サーバーへのセキュア接続を使用するかどうかを制御するフラグ。
- - プレーンテキストの `ldap://` プロトコル（推奨されません）を使用するには `no` を指定します。
- - SSL/TLS 上の LDAP `ldaps://` プロトコル（推奨、デフォルト）を使用するには `yes` を指定します。
- - レガシーな StartTLS プロトコル（TLS へアップグレードされるプレーンテキストの `ldap://` プロトコル）を使用するには `starttls` を指定します。
-- `tls_minimum_protocol_version` — SSL/TLS の最小プロトコルバージョン。
- - 受け付けられる値は `ssl2`、`ssl3`、`tls1.0`、`tls1.1`、`tls1.2`（デフォルト）です。
-- `tls_require_cert` — SSL/TLS ピア証明書の検証動作。
- - 受け付けられる値は `never`、`allow`、`try`、`demand`（デフォルト）です。
-- `tls_cert_file` — 証明書ファイルへのパス。
-- `tls_key_file` — 証明書鍵ファイルへのパス。
-- `tls_ca_cert_file` — CA 証明書ファイルへのパス。
-- `tls_ca_cert_dir` — CA 証明書を含むディレクトリへのパス。
-- `tls_cipher_suite` — 許可される暗号スイート（OpenSSL の表記）。
-
-
-
-## LDAP 外部認証
+* `host` — LDAP サーバーのホスト名または IP。このパラメータは必須であり、空にはできません。
+* `port` — LDAP サーバーのポート。`enable_tls` が `true` に設定されている場合のデフォルトは `636`、それ以外の場合は `389` です。
+* `bind_dn` — バインドに使用する DN を構築するためのテンプレート。
+ * 認証が試行されるたびに、このテンプレート内のすべての `{user_name}` 文字列が実際のユーザー名で置き換えられ、最終的な DN が構築されます。
+* `user_dn_detection` — バインドされたユーザーの実際のユーザー DN を検出するための LDAP 検索パラメータのセクション。
+ * これは主にサーバーが Active Directory の場合に、追加のロールマッピングのための検索フィルタで使用されます。最終的なユーザー DN は、`{user_dn}` 文字列を許可されている場所で置き換える際に使用されます。デフォルトではユーザー DN は bind DN と同一に設定されますが、検索が実行されると、検出された実際のユーザー DN の値で更新されます。
+ * `base_dn` — LDAP 検索用の base DN を構築するために使用されるテンプレート。
+ * LDAP 検索中に、このテンプレート内のすべての `{user_name}` および `{bind_dn}` 文字列が実際のユーザー名および bind DN で置き換えられ、最終的な DN が構築されます。
+ * `scope` — LDAP 検索のスコープ。
+ * 受け付けられる値は `base`、`one_level`、`children`、`subtree`（デフォルト）です。
+ * `search_filter` — LDAP 検索用の検索フィルタを構築するために使用されるテンプレート。
+ * LDAP 検索中に、このテンプレート内のすべての `{user_name}`、`{bind_dn}`、`{base_dn}` 文字列が、実際のユーザー名、bind DN、base DN で置き換えられ、最終的なフィルタが構築されます。
+ * 特殊文字は XML で正しくエスケープする必要がある点に注意してください。
+* `verification_cooldown` — バインドが成功した後、この秒数の間は LDAP サーバーに問い合わせることなく、連続するすべてのリクエストについてユーザーが認証済みであるとみなされる期間。
+ * キャッシュを無効化し、認証リクエストごとに LDAP サーバーへの問い合わせを強制するには、`0`（デフォルト）を指定します。
+* `enable_tls` — LDAP サーバーへのセキュア接続を使用するかどうかを制御するフラグ。
+ * プレーンテキストの `ldap://` プロトコル（推奨されません）を使用するには `no` を指定します。
+ * SSL/TLS 上の LDAP `ldaps://` プロトコル（推奨、デフォルト）を使用するには `yes` を指定します。
+ * レガシーな StartTLS プロトコル（TLS へアップグレードされるプレーンテキストの `ldap://` プロトコル）を使用するには `starttls` を指定します。
+* `tls_minimum_protocol_version` — SSL/TLS の最小プロトコルバージョン。
+ * 受け付けられる値は `ssl2`、`ssl3`、`tls1.0`、`tls1.1`、`tls1.2`（デフォルト）です。
+* `tls_require_cert` — SSL/TLS ピア証明書の検証動作。
+ * 受け付けられる値は `never`、`allow`、`try`、`demand`（デフォルト）です。
+* `tls_cert_file` — 証明書ファイルへのパス。
+* `tls_key_file` — 証明書鍵ファイルへのパス。
+* `tls_ca_cert_file` — CA 証明書ファイルへのパス。
+* `tls_ca_cert_dir` — CA 証明書を含むディレクトリへのパス。
+* `tls_cipher_suite` — 許可される暗号スイート（OpenSSL の表記）。
+
+## LDAP 外部認証 {#ldap-external-authenticator}
リモートの LDAP サーバーを、ローカルで定義されたユーザー（`users.xml` またはローカルのアクセス制御パスで定義されたユーザー）のパスワード検証方法として使用できます。これを行うには、ユーザー定義内で `password` などのセクションの代わりに、事前に定義した LDAP サーバー名を指定します。
@@ -127,8 +123,7 @@ SQL 駆動の[アクセス制御とアカウント管理](/operations/access-rig
CREATE USER my_user IDENTIFIED WITH ldap SERVER 'my_ldap_server';
```
-
-## LDAP 外部ユーザーディレクトリ
+## LDAP 外部ユーザーディレクトリ {#ldap-external-user-directory}
ローカルで定義されたユーザーに加えて、リモートの LDAP サーバーをユーザー定義のソースとして使用できます。これを行うには、`config.xml` ファイルの `users_directories` セクション内の `ldap` セクションで、事前に定義した LDAP サーバー名（[LDAP Server Definition](#ldap-server-definition) を参照）を指定します。
@@ -177,19 +172,18 @@ CREATE USER my_user IDENTIFIED WITH ldap SERVER 'my_ldap_server';
**パラメータ**
-
-- `server` — 上記の `ldap_servers` 設定セクションで定義されている LDAP サーバー名の 1 つ。このパラメータは必須で、空にはできません。
-- `roles` — LDAP サーバーから取得した各ユーザーに割り当てられる、ローカルで定義されたロールの一覧を含むセクション。
- - ここでロールが指定されていない場合、または（下記の）ロールマッピング時にロールが割り当てられない場合、ユーザーは認証後に一切の操作を行うことができません。
-- `role_mapping` — LDAP 検索パラメータとマッピングルールを定義するセクション。
- - ユーザーが認証するとき、LDAP にバインドした状態のまま、`search_filter` とログインしたユーザー名を使って LDAP 検索が実行されます。その検索で見つかった各エントリについて、指定された属性の値が抽出されます。指定されたプレフィックスを持つ各属性値については、プレフィックスが削除され、その残りの値が ClickHouse 内で定義されたローカルロールの名前になります。このロールはあらかじめ [CREATE ROLE](/sql-reference/statements/create/role) ステートメントで作成されている必要があります。
- - 同じ `ldap` セクション内には複数の `role_mapping` セクションを定義できます。それらはすべて適用されます。
- - `base_dn` — LDAP 検索用のベース DN を構築するために使用されるテンプレート。
- - 実際の DN は、各 LDAP 検索時にテンプレート内の `{user_name}`、`{bind_dn}`、`{user_dn}` の各部分文字列を、それぞれ実際のユーザー名、バインド DN、ユーザー DN に置き換えることで構築されます。
- - `scope` — LDAP 検索のスコープ。
- - 指定可能な値は `base`、`one_level`、`children`、`subtree`（デフォルト）です。
- - `search_filter` — LDAP 検索用の検索フィルタを構築するために使用されるテンプレート。
- - 実際のフィルタは、各 LDAP 検索時にテンプレート内の `{user_name}`、`{bind_dn}`、`{user_dn}`、`{base_dn}` の各部分文字列を、実際のユーザー名、バインド DN、ユーザー DN、およびベース DN に置き換えることで構築されます。
- - 特殊文字は XML では正しくエスケープする必要があることに注意してください。
- - `attribute` — LDAP 検索によって返される値を持つ属性名。デフォルトは `cn` です。
- - `prefix` — LDAP 検索で返される元の文字列リストの各文字列の先頭に付いていることが期待されるプレフィックス。プレフィックスは元の文字列から削除され、その結果の文字列がローカルロール名として扱われます。デフォルトは空です。
+* `server` — 上記の `ldap_servers` 設定セクションで定義されている LDAP サーバー名の 1 つ。このパラメータは必須で、空にはできません。
+* `roles` — LDAP サーバーから取得した各ユーザーに割り当てられる、ローカルで定義されたロールの一覧を含むセクション。
+ * ここでロールが指定されていない場合、または（下記の）ロールマッピング時にロールが割り当てられない場合、ユーザーは認証後に一切の操作を行うことができません。
+* `role_mapping` — LDAP 検索パラメータとマッピングルールを定義するセクション。
+ * ユーザーが認証するとき、LDAP にバインドした状態のまま、`search_filter` とログインしたユーザー名を使って LDAP 検索が実行されます。その検索で見つかった各エントリについて、指定された属性の値が抽出されます。指定されたプレフィックスを持つ各属性値については、プレフィックスが削除され、その残りの値が ClickHouse 内で定義されたローカルロールの名前になります。このロールはあらかじめ [CREATE ROLE](/sql-reference/statements/create/role) ステートメントで作成されている必要があります。
+ * 同じ `ldap` セクション内には複数の `role_mapping` セクションを定義できます。それらはすべて適用されます。
+ * `base_dn` — LDAP 検索用のベース DN を構築するために使用されるテンプレート。
+ * 実際の DN は、各 LDAP 検索時にテンプレート内の `{user_name}`、`{bind_dn}`、`{user_dn}` の各部分文字列を、それぞれ実際のユーザー名、バインド DN、ユーザー DN に置き換えることで構築されます。
+ * `scope` — LDAP 検索のスコープ。
+ * 指定可能な値は `base`、`one_level`、`children`、`subtree`（デフォルト）です。
+ * `search_filter` — LDAP 検索用の検索フィルタを構築するために使用されるテンプレート。
+ * 実際のフィルタは、各 LDAP 検索時にテンプレート内の `{user_name}`、`{bind_dn}`、`{user_dn}`、`{base_dn}` の各部分文字列を、実際のユーザー名、バインド DN、ユーザー DN、およびベース DN に置き換えることで構築されます。
+ * 特殊文字は XML では正しくエスケープする必要があることに注意してください。
+ * `attribute` — LDAP 検索によって返される値を持つ属性名。デフォルトは `cn` です。
+ * `prefix` — LDAP 検索で返される元の文字列リストの各文字列の先頭に付いていることが期待されるプレフィックス。プレフィックスは元の文字列から削除され、その結果の文字列がローカルロール名として扱われます。デフォルトは空です。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/ssl-x509.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/ssl-x509.md
index 79d52b702e2..7e9c30cfa63 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/ssl-x509.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/external-authenticators/ssl-x509.md
@@ -5,7 +5,7 @@ title: 'SSL X.509 証明書認証'
doc_type: 'reference'
---
-import SelfManaged from '@site/docs/_snippets/_self_managed_only_no_roadmap.md';
+import SelfManaged from '@site/i18n/jp/docusaurus-plugin-content-docs/current/_snippets/_self_managed_only_no_roadmap.md';
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/monitoring.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/monitoring.md
index 394189668ff..f10c5de5447 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/monitoring.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/monitoring.md
@@ -11,7 +11,7 @@ doc_type: 'reference'
import Image from '@theme/IdealImage';
-# 監視
+# 監視 {#monitoring}
:::note
このガイドで説明している監視データは、ClickHouse Cloud で参照できます。以下で説明する組み込みダッシュボードで表示できるだけでなく、基本および高度なパフォーマンスメトリクスの両方をメインのサービスコンソールで直接確認することもできます。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/named-collections.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/named-collections.md
index b44ab90dc9c..0489d7456aa 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/named-collections.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/named-collections.md
@@ -24,10 +24,9 @@ import CloudNotSupportedBadge from '@theme/badges/CloudNotSupportedBadge';
その目的で名前付きコレクションを使用している場合は、デフォルトで有効になっている `allow_named_collection_override_by_default` を無効化する必要があります。
:::
+## system データベースに名前付きコレクションを保存する {#storing-named-collections-in-the-system-database}
-## system データベースに名前付きコレクションを保存する
-
-### DDLの例
+### DDLの例 {#ddl-example}
```sql
CREATE NAMED COLLECTION name AS
@@ -42,7 +41,7 @@ url = 'https://connection.url/'
* `key_2` は上書きすることはできません。
* `url` は、`allow_named_collection_override_by_default` の値に応じて上書きできる場合とできない場合があります。
-### DDL で名前付きコレクションを作成するための権限
+### DDL で名前付きコレクションを作成するための権限 {#permissions-to-create-named-collections-with-ddl}
DDL で名前付きコレクションを管理するには、ユーザーは `named_collection_control` 権限を持っている必要があります。これは `/etc/clickhouse-server/users.d/` にファイルを追加することで付与できます。次の例では、ユーザー `default` に `access_management` と `named_collection_control` の両方の権限を付与しています。
@@ -64,7 +63,7 @@ DDL で名前付きコレクションを管理するには、ユーザーは `na
上記の例では、`password_sha256_hex` の値は、パスワードの SHA256 ハッシュを 16 進数で表現したものです。ユーザー `default` 向けのこの設定では、デフォルト設定で平文の `password` が設定されているため、属性 `replace=true` を指定しています。同一ユーザーに対して、平文パスワードと SHA256 の 16 進数パスワードを同時に設定することはできません。
:::
-### 名前付きコレクションのストレージ
+### 名前付きコレクションのストレージ {#storage-for-named-collections}
名前付きコレクションはローカルディスクまたは ZooKeeper/Keeper に保存できます。デフォルトではローカルストレージが使用されます。
また、[ディスク暗号化](storing-data#encrypted-virtual-file-system) と同じアルゴリズムを使用して暗号化して保存することもでき、その際にはデフォルトで `aes_128_ctr` が使用されます。
@@ -88,10 +87,9 @@ ZooKeeper/Keeper を使用するには、構成ファイルの `named_collection
オプションの設定パラメーター `update_timeout_ms` のデフォルト値は `5000` です。
+## 設定ファイルに名前付きコレクションを保存する {#storing-named-collections-in-configuration-files}
-## 設定ファイルに名前付きコレクションを保存する
-
-### XML の例
+### XML の例 {#xml-example}
```xml title='/etc/clickhouse-server/config.d/named_collections.xml'
@@ -111,12 +109,11 @@ ZooKeeper/Keeper を使用するには、構成ファイルの `named_collection
* `key_2` は上書きすることはできません。
* `url` は、`allow_named_collection_override_by_default` の値に応じて、上書きできる場合とできない場合があります。
-
-## 名前付きコレクションの変更
+## 名前付きコレクションの変更 {#modifying-named-collections}
DDL クエリで作成された名前付きコレクションは、DDL によって変更または削除できます。XML ファイルで作成された名前付きコレクションは、対応する XML を編集または削除することで管理できます。
-### DDL で作成された名前付きコレクションを変更する
+### DDL で作成された名前付きコレクションを変更する {#alter-a-ddl-named-collection}
コレクション `collection2` のキー `key1` と `key3` を変更または追加します
（この操作では、それらのキーに対する `overridable` フラグの値は変更されません）:
@@ -151,18 +148,17 @@ ALTER NAMED COLLECTION collection2 DELETE key1;
ALTER NAMED COLLECTION collection2 SET key1=4;
```
-### DDL の名前付きコレクション `collection2` を削除:
+### DDL の名前付きコレクション `collection2` を削除: {#drop-the-ddl-named-collection-collection2}
```sql
DROP NAMED COLLECTION collection2
```
-
-## S3 にアクセスするための名前付きコレクション
+## S3 にアクセスするための名前付きコレクション {#named-collections-for-accessing-s3}
パラメータの説明については、[s3 テーブル関数](../sql-reference/table-functions/s3.md)を参照してください。
-### DDL の例
+### DDL の例 {#ddl-example-1}
```sql
CREATE NAMED COLLECTION s3_mydata AS
@@ -172,7 +168,7 @@ format = 'CSV',
url = 'https://s3.us-east-1.amazonaws.com/yourbucket/mydata/'
```
-### XML の例
+### XML の例 {#xml-example-1}
```xml
@@ -187,11 +183,11 @@ url = 'https://s3.us-east-1.amazonaws.com/yourbucket/mydata/'
```
-### s3() 関数と S3 テーブルの名前付きコレクションの例
+### s3() 関数と S3 テーブルの名前付きコレクションの例 {#s3-function-and-s3-table-named-collection-examples}
次の 2 つの例では、同じ名前付きコレクション `s3_mydata` を使用します。
-#### s3() 関数
+#### s3() 関数 {#s3-function}
```sql
INSERT INTO FUNCTION s3(s3_mydata, filename = 'test_file.tsv.gz',
@@ -203,7 +199,7 @@ SELECT * FROM numbers(10000);
上記の `s3()` 関数の最初の引数には、コレクション名 `s3_mydata` を指定しています。名前付きコレクションを使用しない場合は、`s3()` 関数を呼び出すたびにアクセスキー ID、シークレット、フォーマット、URL をすべて渡す必要があります。
:::
-#### S3 テーブル
+#### S3 テーブル {#s3-table}
```sql
CREATE TABLE s3_engine_table (number Int64)
@@ -218,12 +214,11 @@ SELECT * FROM s3_engine_table LIMIT 3;
└────────┘
```
-
-## MySQL データベースにアクセスするための名前付きコレクション
+## MySQL データベースにアクセスするための名前付きコレクション {#named-collections-for-accessing-mysql-database}
パラメータの説明については、[mysql](../sql-reference/table-functions/mysql.md) を参照してください。
-### DDL の例
+### DDL の例 {#ddl-example-2}
```sql
CREATE NAMED COLLECTION mymysql AS
@@ -236,7 +231,7 @@ connection_pool_size = 8,
replace_query = 1
```
-### XML の例
+### XML の例 {#xml-example-2}
```xml
@@ -254,11 +249,11 @@ replace_query = 1
```
-### mysql() 関数、MySQL テーブル、MySQL データベース、および Dictionary 名前付きコレクションの例
+### mysql() 関数、MySQL テーブル、MySQL データベース、および Dictionary 名前付きコレクションの例 {#mysql-function-mysql-table-mysql-database-and-dictionary-named-collection-examples}
以下の 4 つの例では、同じ名前付きコレクション `mymysql` を使用します。
-#### mysql() 関数
+#### mysql() 関数 {#mysql-function}
```sql
SELECT count() FROM mysql(mymysql, table = 'test');
@@ -272,7 +267,7 @@ SELECT count() FROM mysql(mymysql, table = 'test');
この名前付きコレクションでは `table` パラメータが指定されていないため、関数呼び出し時に `table = 'test'` として指定します。
:::
-#### MySQL テーブル
+#### MySQL テーブル {#mysql-table}
```sql
CREATE TABLE mytable(A Int64) ENGINE = MySQL(mymysql, table = 'test', connection_pool_size=3, replace_query=0);
@@ -287,7 +282,7 @@ SELECT count() FROM mytable;
この DDL ステートメントは、`connection_pool_size` に対する名前付きコレクションの設定を上書きします。
:::
-#### MySQL データベース
+#### MySQL データベース {#mysql-database}
```sql
CREATE DATABASE mydatabase ENGINE = MySQL(mymysql);
@@ -300,7 +295,7 @@ SHOW TABLES FROM mydatabase;
└────────┘
```
-#### MySQL 辞書
+#### MySQL 辞書 {#mysql-dictionary}
```sql
CREATE DICTIONARY dict (A Int64, B String)
@@ -316,8 +311,7 @@ SELECT dictGet('dict', 'B', 2);
└─────────────────────────┘
```
-
-## PostgreSQL データベースへのアクセス用名前付きコレクション
+## PostgreSQL データベースへのアクセス用名前付きコレクション {#named-collections-for-accessing-postgresql-database}
パラメータの説明については [postgresql](../sql-reference/table-functions/postgresql.md) を参照してください。さらに、次のエイリアスがあります：
@@ -363,7 +357,7 @@ schema = 'test_schema'
```
-### PostgreSQL 関数で名前付きコレクションを使用する例
+### PostgreSQL 関数で名前付きコレクションを使用する例 {#example-of-using-named-collections-with-the-postgresql-function}
```sql
SELECT * FROM postgresql(mypg, table = 'test');
@@ -381,7 +375,7 @@ SELECT * FROM postgresql(mypg, table = 'test', schema = 'public');
└───┘
```
-### PostgreSQL エンジンを使用するデータベースで名前付きコレクションを利用する例
+### PostgreSQL エンジンを使用するデータベースで名前付きコレクションを利用する例 {#example-of-using-named-collections-with-database-with-engine-postgresql}
```sql
CREATE TABLE mypgtable (a Int64) ENGINE = PostgreSQL(mypg, table = 'test', schema = 'public');
@@ -399,7 +393,7 @@ SELECT * FROM mypgtable;
PostgreSQL は、テーブル作成時に名前付きコレクションからデータをコピーします。コレクションが変更されても、既存のテーブルには影響しません。
:::
-### PostgreSQL エンジンを使用するデータベースで名前付きコレクションを使用する例
+### PostgreSQL エンジンを使用するデータベースで名前付きコレクションを使用する例 {#example-of-using-named-collections-with-database-with-engine-postgresql-1}
```sql
CREATE DATABASE mydatabase ENGINE = PostgreSQL(mypg);
@@ -411,7 +405,7 @@ SHOW TABLES FROM mydatabase
└──────┘
```
-### ソースに POSTGRESQL を使用する辞書での名前付きコレクションの使用例
+### ソースに POSTGRESQL を使用する辞書での名前付きコレクションの使用例 {#example-of-using-named-collections-with-a-dictionary-with-source-postgresql}
```sql
CREATE DICTIONARY dict (a Int64, b String)
@@ -427,8 +421,7 @@ SELECT dictGet('dict', 'b', 2);
└─────────────────────────┘
```
-
-## リモート ClickHouse データベースにアクセスするための名前付きコレクション
+## リモート ClickHouse データベースにアクセスするための名前付きコレクション {#named-collections-for-accessing-a-remote-clickhouse-database}
パラメータの説明については、[remote](../sql-reference/table-functions/remote.md/#parameters) を参照してください。
@@ -461,7 +454,7 @@ secure = 1
接続では `remoteSecure` を使用するため `secure` は不要ですが、ディクショナリには使用できます。
-### `remote` / `remoteSecure` 関数で名前付きコレクションを使用する例
+### `remote` / `remoteSecure` 関数で名前付きコレクションを使用する例 {#example-of-using-named-collections-with-the-remoteremotesecure-functions}
```sql
SELECT * FROM remote(remote1, table = one);
@@ -482,7 +475,7 @@ SELECT * FROM remote(remote1, database = default, table = test);
└───┴───┘
```
-### ClickHouse をソースとする辞書での名前付きコレクションの使用例
+### ClickHouse をソースとする辞書での名前付きコレクションの使用例 {#example-of-using-named-collections-with-a-dictionary-with-source-clickhouse}
```sql
CREATE DICTIONARY dict(a Int64, b String)
@@ -497,12 +490,11 @@ SELECT dictGet('dict', 'b', 1);
└─────────────────────────┘
```
-
-## Kafka へのアクセスに使用する名前付きコレクション
+## Kafka へのアクセスに使用する名前付きコレクション {#named-collections-for-accessing-kafka}
パラメータの説明については [Kafka](../engines/table-engines/integrations/kafka.md) を参照してください。
-### DDL の例
+### DDL の例 {#ddl-example-3}
```sql
CREATE NAMED COLLECTION my_kafka_cluster AS
@@ -514,7 +506,7 @@ kafka_max_block_size = '1048576';
```
-### XML の例
+### XML の例 {#xml-example-3}
```xml
@@ -530,7 +522,7 @@ kafka_max_block_size = '1048576';
```
-### Kafka テーブルで名前付きコレクションを使用する例
+### Kafka テーブルで名前付きコレクションを使用する例 {#example-of-using-named-collections-with-a-kafka-table}
次の 2 つの例では、いずれも同じ名前付きコレクション `my_kafka_cluster` を使用します。
@@ -554,18 +546,17 @@ SETTINGS kafka_num_consumers = 4,
kafka_thread_per_consumer = 1;
```
-
-## バックアップ用の名前付きコレクション
+## バックアップ用の名前付きコレクション {#named-collections-for-backups}
パラメータの説明については[バックアップとリストア](./backup.md)を参照してください。
-### DDL の例
+### DDL の例 {#ddl-example-4}
```sql
BACKUP TABLE default.test to S3(named_collection_s3_backups, 'directory')
```
-### XML の例
+### XML の例 {#xml-example-4}
```xml
@@ -579,12 +570,11 @@ BACKUP TABLE default.test to S3(named_collection_s3_backups, 'directory')
```
-
-## MongoDB テーブルおよび辞書にアクセスするための名前付きコレクション
+## MongoDB テーブルおよび辞書にアクセスするための名前付きコレクション {#named-collections-for-accessing-mongodb-table-and-dictionary}
パラメータの説明については [mongodb](../sql-reference/table-functions/mongodb.md) を参照してください。
-### DDL の例
+### DDL の例 {#ddl-example-5}
```sql
CREATE NAMED COLLECTION mymongo AS
@@ -597,7 +587,7 @@ collection = 'my_collection',
options = 'connectTimeoutMS=10000'
```
-### XML の例
+### XML の例 {#xml-example-5}
```xml
@@ -615,7 +605,7 @@ options = 'connectTimeoutMS=10000'
```
-#### MongoDB テーブル
+#### MongoDB テーブル {#mongodb-table}
```sql
CREATE TABLE mytable(log_type VARCHAR, host VARCHAR, command VARCHAR) ENGINE = MongoDB(mymongo, options='connectTimeoutMS=10000&compressors=zstd')
@@ -630,7 +620,7 @@ SELECT count() FROM mytable;
DDL は、オプションで指定した名前付きコレクションの設定を上書きします。
:::
-#### MongoDB 辞書
+#### MongoDB 辞書 {#mongodb-dictionary}
```sql
CREATE DICTIONARY dict
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/opentelemetry.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/opentelemetry.md
index aae90119801..77eb3eb8231 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/opentelemetry.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/opentelemetry.md
@@ -47,7 +47,7 @@ ClickHouse は、各クエリおよびクエリ計画や分散クエリなど一
-## 監視システムとの統合
+## 監視システムとの統合 {#integration-with-monitoring-systems}
現時点では、ClickHouse から監視システムへトレースデータをエクスポートするための既製ツールは用意されていません。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/optimizing-performance/profile-guided-optimization.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/optimizing-performance/profile-guided-optimization.md
index df3df140230..2bd995f1b62 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/optimizing-performance/profile-guided-optimization.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/optimizing-performance/profile-guided-optimization.md
@@ -7,10 +7,9 @@ title: 'プロファイルガイド最適化'
doc_type: 'guide'
---
-import SelfManaged from '@site/docs/_snippets/_self_managed_only_no_roadmap.md';
+import SelfManaged from '@site/i18n/jp/docusaurus-plugin-content-docs/current/_snippets/_self_managed_only_no_roadmap.md';
-
-# プロファイルガイド最適化
+# プロファイルガイド最適化 {#profile-guided-optimization}
Profile-Guided Optimization (PGO) は、実行時プロファイルに基づいてプログラムを最適化するコンパイラ最適化手法です。
@@ -18,8 +17,6 @@ Profile-Guided Optimization (PGO) は、実行時プロファイルに基づい
ClickHouse における PGO の詳細については、該当する GitHub の[issue](https://github.com/ClickHouse/ClickHouse/issues/44567)を参照してください。
-
-
## PGO を使って ClickHouse をビルドする方法 {#how-to-build-clickhouse-with-pgo}
PGO には大きく分けて 2 種類あります。[Instrumentation](https://clang.llvm.org/docs/UsersManual.html#using-sampling-profilers) と [Sampling](https://clang.llvm.org/docs/UsersManual.html#using-sampling-profilers)（AutoFDO とも呼ばれます）です。このガイドでは、ClickHouse における Instrumentation PGO について説明します。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/optimizing-performance/sampling-query-profiler.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/optimizing-performance/sampling-query-profiler.md
index c17075114c5..b7e6b68bb79 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/optimizing-performance/sampling-query-profiler.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/optimizing-performance/sampling-query-profiler.md
@@ -7,10 +7,9 @@ title: 'サンプリングクエリプロファイラー'
doc_type: 'reference'
---
-import SelfManaged from '@site/docs/_snippets/_self_managed_only_no_roadmap.md';
+import SelfManaged from '@site/i18n/jp/docusaurus-plugin-content-docs/current/_snippets/_self_managed_only_no_roadmap.md';
-
-# サンプリングクエリプロファイラ
+# サンプリングクエリプロファイラ {#sampling-query-profiler}
ClickHouse にはクエリ実行を解析できるサンプリングプロファイラが搭載されています。プロファイラを使用すると、クエリ実行中に最も頻繁に使用されたソースコード内のルーチンを特定できます。CPU 時間と、アイドル時間を含むウォールクロック時間（実時間）を追跡できます。
@@ -55,8 +54,7 @@ SETTINGS allow_introspection_functions = 1
`trace_log` の情報を可視化する必要がある場合は、[flamegraph](/interfaces/third-party/gui#clickhouse-flamegraph) や [speedscope](https://github.com/laplab/clickhouse-speedscope) の使用を検討してください。
-
-## 例
+## 例 {#example}
この例では次のことを行います。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/performance-test.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/performance-test.md
index dab0c651b37..4076158f97b 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/performance-test.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/performance-test.md
@@ -7,14 +7,13 @@ title: 'ClickHouse でハードウェア性能をテストする方法'
doc_type: 'guide'
---
-import SelfManaged from '@site/docs/_snippets/_self_managed_only_no_roadmap.md';
+import SelfManaged from '@site/i18n/jp/docusaurus-plugin-content-docs/current/_snippets/_self_managed_only_no_roadmap.md';
ClickHouse パッケージをインストールしなくても、どのサーバー上でも ClickHouse の基本的な性能テストを実行できます。
-
-## 自動実行
+## 自動実行 {#automated-run}
ベンチマークは 1 つのスクリプトだけで実行できます。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/query-cache.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/query-cache.md
index 4ba837f5118..3819a9b8a80 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/query-cache.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/query-cache.md
@@ -1,5 +1,5 @@
---
-description: 'ClickHouse におけるクエリキャッシュ機能の使用方法と設定に関するガイド'
+description: 'ClickHouse のクエリキャッシュ機能の利用と設定に関するガイド'
sidebar_label: 'クエリキャッシュ'
sidebar_position: 65
slug: /operations/query-cache
@@ -7,36 +7,34 @@ title: 'クエリキャッシュ'
doc_type: 'guide'
---
+# クエリキャッシュ {#query-cache}
-
-# クエリキャッシュ
-
-クエリキャッシュを使用すると、`SELECT` クエリを一度だけ計算し、その後の同一クエリの結果をキャッシュから直接返すことができます。
-クエリの種類によっては、これにより ClickHouse サーバーのレイテンシとリソース消費を大幅に削減できます。
-
-
+クエリキャッシュを使用すると、`SELECT` クエリを一度だけ実行して結果を保存し、同じクエリの後続の実行にはキャッシュから直接結果を返すことができます。
+クエリの種類によっては、これにより ClickHouse サーバーのレイテンシとリソース消費を劇的に削減できます。
## 背景、設計、および制限事項 {#background-design-and-limitations}
-クエリキャッシュは一般的に、トランザクション整合性があるものとないものに分類できます。
-
-- トランザクション整合性があるキャッシュでは、`SELECT`クエリの結果が変更された場合、または変更される可能性がある場合に、データベースはキャッシュされたクエリ結果を無効化(破棄)します。ClickHouseでは、データを変更する操作には、テーブルへの挿入/更新/削除、または圧縮マージが含まれます。トランザクション整合性があるキャッシュは、特にOLTPデータベースに適しています。例えば、[MySQL](https://dev.mysql.com/doc/refman/5.6/en/query-cache.html)(v8.0以降でクエリキャッシュを削除)や[Oracle](https://docs.oracle.com/database/121/TGDBA/tune_result_cache.htm)などです。
-- トランザクション整合性がないキャッシュでは、すべてのキャッシュエントリに有効期限(例:1分)が設定され、その期間中に基礎データがわずかしか変化しないという前提のもと、クエリ結果にわずかな不正確さが許容されます。このアプローチは全体的にOLAPデータベースにより適しています。トランザクション整合性がないキャッシュで十分な例として、複数のユーザーが同時にアクセスするレポートツールの時間別売上レポートを考えてみましょう。売上データは通常、十分にゆっくりと変化するため、データベースはレポートを一度だけ計算すればよく(最初の`SELECT`クエリで表される)、それ以降のクエリはクエリキャッシュから直接提供できます。この例では、妥当な有効期限は30分程度です。
+クエリキャッシュは一般的に、トランザクション一貫性があるものと、ないものに分類できます。
-トランザクション整合性がないキャッシュは、従来、データベースと連携するクライアントツールやプロキシパッケージ(例:[chproxy](https://www.chproxy.org/configuration/caching/))によって提供されてきました。その結果、同じキャッシュロジックと設定が重複することがよくありました。ClickHouseのクエリキャッシュでは、キャッシュロジックがサーバー側に移行します。これにより、保守作業が軽減され、冗長性が回避されます。
+* トランザクション一貫性のあるキャッシュでは、`SELECT` クエリの結果が変化した場合、または変化する可能性がある場合に、データベースがキャッシュ済みのクエリ結果を無効化（破棄）します。ClickHouse においてデータを変更する操作には、テーブルへの挿入・更新・削除や、テーブルからの削除、あるいは collapsing merge が含まれます。トランザクション一貫性のあるキャッシュは、特に OLTP データベースに適しており、たとえば
+ [MySQL](https://dev.mysql.com/doc/refman/5.6/en/query-cache.html)（v8.0 でクエリキャッシュは削除）や
+ [Oracle](https://docs.oracle.com/database/121/TGDBA/tune_result_cache.htm) などがあります。
+* トランザクション一貫性のないキャッシュでは、すべてのキャッシュエントリに有効期間（例: 1 分）を割り当て、その期間経過後に期限切れになること、そしてその期間内には基盤となるデータの変更がごくわずかにとどまることを前提として、クエリ結果がわずかに不正確になることを許容します。この手法は、全体として OLAP データベースにより適しています。トランザクション一貫性のないキャッシュで十分な例としては、複数ユーザーが同時にアクセスするレポーティングツールにおける毎時の売上レポートが挙げられます。売上データの変化は通常十分に遅いため、データベースはレポートを一度だけ計算すればよく（最初の `SELECT` クエリ）、以降のクエリはすべてクエリキャッシュから直接提供できます。この例では、妥当な有効期間は 30 分程度と考えられます。
+トランザクション一貫性のないキャッシュは、従来はデータベースと連携するクライアントツールやプロキシパッケージ（例:
+[chproxy](https://www.chproxy.org/configuration/caching/)）によって提供されてきました。その結果、同じキャッシュロジックや設定が重複しがちです。ClickHouse のクエリキャッシュでは、キャッシュロジックがサーバー側に移動します。これにより、保守作業が軽減され、冗長性を回避できます。
-## 設定とその使用方法 {#configuration-settings-and-usage}
+## 設定と使用方法 {#configuration-settings-and-usage}
:::note
-ClickHouse Cloudでは、クエリキャッシュの設定を編集するために[クエリレベル設定](/operations/settings/query-level)を使用する必要があります。[設定ファイルレベルの設定](/operations/configuration-files)の編集は現在サポートされていません。
+ClickHouse Cloud では、クエリキャッシュ設定を編集するには [クエリレベルの設定](/operations/settings/query-level) を使用する必要があります。[コンフィグレベルの設定](/operations/configuration-files) の編集は現在サポートされていません。
:::
:::note
-[clickhouse-local](utilities/clickhouse-local.md)は一度に1つのクエリのみを実行します。クエリ結果のキャッシュは意味をなさないため、clickhouse-localではクエリ結果キャッシュが無効になっています。
+[clickhouse-local](utilities/clickhouse-local.md) は一度に 1 つのクエリのみを実行します。クエリ結果キャッシュを利用する意味がないため、clickhouse-local ではクエリ結果キャッシュは無効になっています。
:::
-設定[use_query_cache](/operations/settings/settings#use_query_cache)を使用して、特定のクエリまたは現在のセッションのすべてのクエリがクエリキャッシュを利用するかどうかを制御できます。例えば、次のクエリの最初の実行では
+[use_query_cache](/operations/settings/settings#use_query_cache) 設定を使用すると、特定のクエリ、または現在のセッション内のすべてのクエリでクエリキャッシュを利用するかどうかを制御できます。例えば、あるクエリを最初に実行したときは
```sql
SELECT some_expensive_calculation(column_1, column_2)
@@ -44,13 +42,16 @@ FROM table
SETTINGS use_query_cache = true;
```
-クエリ結果がクエリキャッシュに保存されます。同じクエリの後続の実行（同様に`use_query_cache = true`パラメータを指定）では、計算された結果がキャッシュから読み取られ、即座に返されます。
+クエリ結果はクエリキャッシュに保存されます。その後に同じクエリを実行した場合（パラメータ `use_query_cache = true` を指定した場合も同様）、計算済みの結果をキャッシュから読み取り、即座に返します。
:::note
-設定`use_query_cache`およびその他すべてのクエリキャッシュ関連の設定は、独立した`SELECT`文に対してのみ効果があります。特に、`CREATE VIEW AS SELECT [...] SETTINGS use_query_cache = true`で作成されたビューへの`SELECT`の結果は、`SELECT`文が`SETTINGS use_query_cache = true`で実行されない限りキャッシュされません。
+`use_query_cache` およびその他すべてのクエリキャッシュ関連設定は、スタンドアロンの `SELECT` 文に対してのみ効果があります。とくに、
+`CREATE VIEW AS SELECT [...] SETTINGS use_query_cache = true` で作成されたビューに対する `SELECT` の結果は、その `SELECT`
+文が `SETTINGS use_query_cache = true` を指定して実行されない限りキャッシュされません。
:::
-キャッシュの利用方法は、設定[enable_writes_to_query_cache](/operations/settings/settings#enable_writes_to_query_cache)と[enable_reads_from_query_cache](/operations/settings/settings#enable_reads_from_query_cache)（両方ともデフォルトで`true`）を使用してより詳細に設定できます。前者の設定はクエリ結果がキャッシュに保存されるかどうかを制御し、後者の設定はデータベースがキャッシュからクエリ結果を取得しようとするかどうかを決定します。例えば、次のクエリはキャッシュを受動的にのみ使用します。つまり、キャッシュからの読み取りは試みますが、結果をキャッシュに保存しません：
+キャッシュの利用方法は、設定 [enable_writes_to_query_cache](/operations/settings/settings#enable_writes_to_query_cache)
+および [enable_reads_from_query_cache](/operations/settings/settings#enable_reads_from_query_cache)（どちらもデフォルトは `true`）を使って、より細かく設定できます。前者の設定はクエリ結果をキャッシュに保存するかどうかを制御し、後者の設定はデータベースがキャッシュからクエリ結果を取得しようとするかどうかを決定します。たとえば、次のクエリはキャッシュを受動的にのみ使用します。つまり、キャッシュからの読み取りは試みますが、自身の結果をキャッシュに保存しません。
```sql
SELECT some_expensive_calculation(column_1, column_2)
@@ -58,18 +59,21 @@ FROM table
SETTINGS use_query_cache = true, enable_writes_to_query_cache = false;
```
-最大限の制御を行うには、設定`use_query_cache`、`enable_writes_to_query_cache`、`enable_reads_from_query_cache`を特定のクエリに対してのみ指定することが一般的に推奨されます。ユーザーレベルまたはプロファイルレベルでキャッシュを有効にすること（例：`SET use_query_cache = true`経由）も可能ですが、その場合すべての`SELECT`クエリがキャッシュされた結果を返す可能性があることに留意する必要があります。
+最大限の制御を行うため、一般的には `use_query_cache`、`enable_writes_to_query_cache`、`enable_reads_from_query_cache` の設定は特定のクエリに対してのみ指定することを推奨します。ユーザーまたはプロファイル単位（例：`SET
+use_query_cache = true`）でキャッシュを有効化することも可能ですが、その場合、すべての `SELECT` クエリがキャッシュされた結果を返すようになることに注意してください。
-クエリキャッシュは`SYSTEM DROP QUERY CACHE`文を使用してクリアできます。クエリキャッシュの内容はシステムテーブル[system.query_cache](system-tables/query_cache.md)に表示されます。データベース起動以降のクエリキャッシュのヒット数とミス数は、システムテーブル[system.events](system-tables/events.md)のイベント「QueryCacheHits」と「QueryCacheMisses」として表示されます。両方のカウンターは、設定`use_query_cache = true`で実行される`SELECT`クエリに対してのみ更新され、その他のクエリは「QueryCacheMisses」に影響しません。システムテーブル[system.query_log](system-tables/query_log.md)のフィールド`query_cache_usage`は、実行された各クエリについて、クエリ結果がクエリキャッシュに書き込まれたか、またはクエリキャッシュから読み取られたかを示します。システムテーブル[system.metrics](system-tables/metrics.md)のメトリクス`QueryCacheEntries`と`QueryCacheBytes`は、クエリキャッシュが現在含んでいるエントリ数とバイト数を示します。
+クエリキャッシュは `SYSTEM DROP QUERY CACHE` ステートメントを使用してクリアできます。クエリキャッシュの内容はシステムテーブル
+[system.query_cache](system-tables/query_cache.md) に表示されます。データベース起動以降のクエリキャッシュのヒット数とミス数は、システムテーブル [system.events](system-tables/events.md) 内のイベント
+"QueryCacheHits" および "QueryCacheMisses" として表示されます。両方のカウンタは、設定 `use_query_cache = true` で実行される `SELECT` クエリに対してのみ更新され、それ以外のクエリは "QueryCacheMisses" には影響しません。システムテーブル [system.query_log](system-tables/query_log.md) 内のフィールド `query_cache_usage` は、各実行クエリについて、その結果がクエリキャッシュに書き込まれたか、あるいはクエリキャッシュから読み出されたかを示します。システムテーブル
+[system.metrics](system-tables/metrics.md) 内のメトリクス `QueryCacheEntries` および `QueryCacheBytes` は、現在クエリキャッシュに含まれるエントリ数およびバイト数を示します。
-クエリキャッシュはClickHouseサーバープロセスごとに1つ存在します。ただし、キャッシュ結果はデフォルトではユーザー間で共有されません。これは変更可能ですが（後述）、セキュリティ上の理由から推奨されません。
+クエリキャッシュは ClickHouse サーバープロセスごとに 1 つ存在します。ただし、キャッシュ結果はデフォルトではユーザー間で共有されません。これは（後述のように）変更可能ですが、セキュリティ上の理由から推奨されません。
-クエリ結果は、クエリの[抽象構文木（AST）](https://en.wikipedia.org/wiki/Abstract_syntax_tree)によってクエリキャッシュ内で参照されます。これは、キャッシュが大文字・小文字を区別しないことを意味します。例えば、`SELECT 1`と`select 1`は同じクエリとして扱われます。マッチングをより自然にするため、クエリキャッシュに関連するすべてのクエリレベル設定と[出力フォーマット](settings/settings-formats.md)の設定はASTから除外されます。
+クエリ結果は、そのクエリの [抽象構文木 (AST)](https://en.wikipedia.org/wiki/Abstract_syntax_tree) によってクエリキャッシュ内で参照されます。これは、キャッシュが大文字・小文字を区別しないことを意味し、たとえば `SELECT 1` と `select 1` は同一のクエリとして扱われます。より自然なマッチングを行うため、クエリキャッシュおよび[出力フォーマット](settings/settings-formats.md)に関連するクエリレベルのすべての設定は AST から削除されます。
-例外またはユーザーによるキャンセルによってクエリが中止された場合、クエリキャッシュにエントリは書き込まれません。
-
-クエリキャッシュのバイト単位のサイズ、キャッシュエントリの最大数、および個々のキャッシュエントリの最大サイズ（バイト単位およびレコード単位）は、さまざまな[サーバー設定オプション](/operations/server-configuration-parameters/settings#query_cache)を使用して設定できます。
+クエリが例外またはユーザーによるキャンセルによって中断された場合、そのエントリはクエリキャッシュに書き込まれません。
+クエリキャッシュのサイズ（バイト数）、キャッシュエントリの最大数、および個々のキャッシュエントリの最大サイズ（バイト数およびレコード数）は、さまざまな[サーバー構成オプション](/operations/server-configuration-parameters/settings#query_cache)を使用して設定できます。
```xml
@@ -81,19 +85,18 @@ SETTINGS use_query_cache = true, enable_writes_to_query_cache = false;
```
[settings profiles](settings/settings-profiles.md) と [settings
-constraints](settings/constraints-on-settings.md) を使用して、個々のユーザーごとにキャッシュ使用量を制限することもできます。具体的には、クエリキャッシュ内でユーザーが割り当て可能なメモリの最大量（バイト単位）や、保存されるクエリ結果の最大数を制限できます。そのためには、まず `users.xml` 内のユーザープロファイルで
+constraints](settings/constraints-on-settings.md) を使用して、個々のユーザーのキャッシュ利用量を制限することもできます。具体的には、ユーザーがクエリキャッシュ内で割り当て可能なメモリの最大量（バイト単位）と、保存できるクエリ結果の最大数を制限できます。そのためには、まず `users.xml` 内のユーザープロファイルで
[query_cache_max_size_in_bytes](/operations/settings/settings#query_cache_max_size_in_bytes) と
-[query_cache_max_entries](/operations/settings/settings#query_cache_max_entries) を設定し、そのうえで両方の設定を
-readonly にします。
+[query_cache_max_entries](/operations/settings/settings#query_cache_max_entries) を設定し、その後両方の設定を読み取り専用（readonly）にします。
```xml
-
+
10000
-
+
100
-
+
@@ -106,7 +109,7 @@ readonly にします。
```
-クエリの結果をキャッシュ対象とするために、そのクエリが少なくともどの程度の時間実行されている必要があるかを指定するには、設定
+クエリ結果をキャッシュ対象とするための最小実行時間を定義するには、設定
[query_cache_min_query_duration](/operations/settings/settings#query_cache_min_query_duration) を使用できます。たとえば、次のクエリの結果は
```sql
@@ -115,67 +118,73 @@ FROM table
SETTINGS use_query_cache = true, query_cache_min_query_duration = 5000;
```
-は、クエリの実行時間が 5 秒を超えた場合にのみキャッシュされます。クエリの結果がキャッシュされるまでに、そのクエリを何回実行する必要があるかを指定することもできます。その場合は、設定 [query_cache_min_query_runs](/operations/settings/settings#query_cache_min_query_runs) を使用します。
+クエリ結果は、クエリの実行時間が 5 秒より長い場合にのみキャッシュされます。クエリの結果がキャッシュされるまでに、そのクエリを何回実行する必要があるかも指定できます。その場合は設定 [query_cache_min_query_runs](/operations/settings/settings#query_cache_min_query_runs) を使用します。
+
+クエリキャッシュ内のエントリは、一定時間が経過すると古くなります（time-to-live）。デフォルトではこの期間は 60 秒ですが、[query_cache_ttl](/operations/settings/settings#query_cache_ttl) 設定を使って、セッション、プロファイル、またはクエリ単位で別の値を指定できます。クエリキャッシュはエントリを「遅延的に」追い出します。つまり、エントリが古くなっても、キャッシュから即座には削除されません。代わりに、新しいエントリをクエリキャッシュに挿入しようとしたとき、データベースは新しいエントリ用の空き領域がキャッシュ内に十分あるかどうかを確認します。そうでない場合、データベースはすべての古いエントリを削除しようとします。それでもキャッシュに十分な空き領域がない場合は、新しいエントリは挿入されません。
-クエリキャッシュ内のエントリは、一定時間が経過すると期限切れ（stale）になります（TTL: time-to-live）。デフォルトでは、この期間は 60 秒ですが、設定 [query_cache_ttl](/operations/settings/settings#query_cache_ttl) を使用して、セッション、プロファイル、またはクエリ単位で異なる値を指定できます。クエリキャッシュはエントリを「遅延（lazy）」方式で削除します。つまり、エントリが期限切れになっても、すぐにはキャッシュから削除されません。代わりに、新しいエントリをクエリキャッシュに挿入しようとしたとき、データベースは新しいエントリ用の空き容量がキャッシュに十分あるかどうかを確認します。十分でない場合、データベースはすべての期限切れエントリを削除しようとします。それでもキャッシュに十分な空き容量がない場合、新しいエントリは挿入されません。
+クエリが HTTP 経由で実行される場合、ClickHouse はキャッシュされたエントリの経過時間（秒単位）と有効期限のタイムスタンプを示す `Age` および `Expires` ヘッダーを設定します。
-クエリキャッシュ内のエントリは、デフォルトで圧縮されます。これにより、クエリキャッシュ全体のメモリ消費量が削減されますが、その代わりにクエリキャッシュへの書き込み／読み出しは遅くなります。圧縮を無効にするには、設定 [query_cache_compress_entries](/operations/settings/settings#query_cache_compress_entries) を使用します。
+クエリキャッシュ内のエントリは、デフォルトで圧縮されます。これは、クエリキャッシュへの書き込み／読み取りが遅くなる代わりに、全体的なメモリ使用量を削減するためです。圧縮を無効にするには、設定 [query_cache_compress_entries](/operations/settings/settings#query_cache_compress_entries) を使用します。
-同じクエリに対して複数の結果をキャッシュしておきたい場合があります。これは、クエリキャッシュエントリのラベル（または名前空間）のように機能する設定 [query_cache_tag](/operations/settings/settings#query_cache_tag) を使用することで実現できます。クエリキャッシュは、同じクエリであってもタグが異なる結果は別物として扱います。
+同じクエリに対して複数の結果をキャッシュしておきたい場合があります。これは、クエリキャッシュエントリのラベル（またはネームスペース）の役割を果たす設定 [query_cache_tag](/operations/settings/settings#query_cache_tag) を使用することで実現できます。クエリキャッシュは、同じクエリでもタグが異なれば、結果を別物として扱います。
同じクエリに対して 3 つの異なるクエリキャッシュエントリを作成する例:
```sql
-SELECT 1 SETTINGS use_query_cache = true; -- query_cache_tagは暗黙的に''(空文字列)です
+SELECT 1 SETTINGS use_query_cache = true; -- query_cache_tag は暗黙的に ''（空文字列）になります
SELECT 1 SETTINGS use_query_cache = true, query_cache_tag = 'tag 1';
SELECT 1 SETTINGS use_query_cache = true, query_cache_tag = 'tag 2';
```
-クエリキャッシュからタグ `tag` の付いたエントリだけを削除するには、`SYSTEM DROP QUERY CACHE TAG 'tag'` ステートメントを使用できます。
+クエリキャッシュからタグ `tag` が付いたエントリのみを削除するには、`SYSTEM DROP QUERY CACHE TAG 'tag'` 文を使用します。
+ClickHouse は、テーブルデータを [max_block_size](/operations/settings/settings#max_block_size) 行のブロック単位で読み取ります。フィルタリングや集約などにより、
+結果ブロックは通常は `max_block_size` よりかなり小さくなりますが、逆にそれより大きくなる場合もあります。
+[query_cache_squash_partial_results](/operations/settings/settings#query_cache_squash_partial_results)（デフォルトで有効）を設定すると、
+クエリ結果キャッシュへの挿入前に、結果ブロックが（非常に小さい場合は）まとめられ、（大きい場合は）`max_block_size` の大きさのブロックに分割されるかどうかを制御できます。
+これによりクエリキャッシュへの書き込み性能は低下しますが、キャッシュエントリの圧縮率が向上し、
+後でクエリキャッシュからクエリ結果を提供する際に、より自然なブロック粒度が得られます。
-ClickHouse はテーブルデータを [max_block_size](/operations/settings/settings#max_block_size) 行のブロック単位で読み込みます。フィルタリングや集約などにより、
-結果ブロックは通常は `max_block_size` よりかなり小さくなりますが、場合によってはそれよりも大きくなることもあります。
-[query_cache_squash_partial_results](/operations/settings/settings#query_cache_squash_partial_results)（デフォルトで有効）は、結果ブロックがクエリ結果
-キャッシュに挿入される前に、ブロックが非常に小さい場合にはまとめ、大きい場合には `max_block_size` のサイズのブロックに分割するかどうかを制御します。
-これによりクエリキャッシュへの書き込み性能は低下しますが、キャッシュエントリの圧縮率が向上し、後でクエリキャッシュからクエリ結果を返す際の
-ブロック粒度がより自然になります。
+その結果として、クエリキャッシュは各クエリに対して複数の（部分）結果ブロックを保存します。
+この挙動は有用なデフォルトですが、設定
+[query_cache_squash_partial_results](/operations/settings/settings#query_cache_squash_partial_results) によって無効化できます。
-その結果、クエリキャッシュは各クエリに対して複数の（部分的な）結果ブロックを保存します。この挙動はデフォルトとしては有用ですが、設定
-[query_cache_squash_partial_results](/operations/settings/settings#query_cache_squash_partial_results) を用いて抑制できます。
+また、非決定的関数を含むクエリの結果は、デフォルトではキャッシュされません。これらの関数には次のようなものが含まれます。
-また、非決定的関数を含むクエリの結果はデフォルトではキャッシュされません。そのような関数には次のものが含まれます。
-- 辞書へのアクセス用関数: [`dictGet()`](/sql-reference/functions/ext-dict-functions#dictget-dictgetordefault-dictgetornull) など
-- XML 定義内にタグ `true` を持たない [ユーザー定義関数](../sql-reference/statements/create/function.md)
-- 現在の日付や時刻を返す関数: [`now()`](../sql-reference/functions/date-time-functions.md#now),
+* 辞書にアクセスする関数（[`dictGet()`](/sql-reference/functions/ext-dict-functions#dictget-dictgetordefault-dictgetornull) など）
+* XML 定義内にタグ `true` を持たない
+ [ユーザー定義関数](../sql-reference/statements/create/function.md)
+* 現在の日付または時刻を返す関数:
+ [`now()`](../sql-reference/functions/date-time-functions.md#now),
[`today()`](../sql-reference/functions/date-time-functions.md#today),
[`yesterday()`](../sql-reference/functions/date-time-functions.md#yesterday) など
-- ランダムな値を返す関数: [`randomString()`](../sql-reference/functions/random-functions.md#randomString),
+* ランダムな値を返す関数:
+ [`randomString()`](../sql-reference/functions/random-functions.md#randomString),
[`fuzzBits()`](../sql-reference/functions/random-functions.md#fuzzBits) など
-- クエリ処理に用いられる内部チャンクのサイズや順序に結果が依存する関数:
+* クエリ処理に使用される内部チャンクのサイズと順序に応じて結果が変化する関数:
[`nowInBlock()`](../sql-reference/functions/date-time-functions.md#nowInBlock) など、
[`rowNumberInBlock()`](../sql-reference/functions/other-functions.md#rowNumberInBlock),
[`runningDifference()`](../sql-reference/functions/other-functions.md#runningDifference),
[`blockSize()`](../sql-reference/functions/other-functions.md#blockSize) など
-- 環境に依存する関数: [`currentUser()`](../sql-reference/functions/other-functions.md#currentUser),
+* 実行環境に依存する関数:
+ [`currentUser()`](../sql-reference/functions/other-functions.md#currentUser),
[`queryID()`](/sql-reference/functions/other-functions#queryID),
[`getMacro()`](../sql-reference/functions/other-functions.md#getMacro) など。
-非決定的関数を含むクエリの結果を、デフォルト設定に関係なく強制的にキャッシュしたい場合は、
-[query_cache_nondeterministic_function_handling](/operations/settings/settings#query_cache_nondeterministic_function_handling) 設定を使用します。
+非決定的関数を含むクエリの結果であっても強制的にキャッシュしたい場合は、
+[query_cache_nondeterministic_function_handling](/operations/settings/settings#query_cache_nondeterministic_function_handling) を設定します。
system テーブル（例: [system.processes](system-tables/processes.md) や
-[information_schema.tables](system-tables/information_schema.md)）を含むクエリの結果は、デフォルトではキャッシュされません。
+[information_schema.tables](system-tables/information_schema.md)）を含むクエリの結果は、デフォルトではキャッシュされません。
system テーブルを含むクエリの結果を強制的にキャッシュしたい場合は、
-[query_cache_system_table_handling](/operations/settings/settings#query_cache_system_table_handling) 設定を使用します。
-
-最後に、セキュリティ上の理由から、クエリキャッシュ内のエントリはユーザー間で共有されません。例えば、ユーザー A が、行ポリシーが存在しない別の
-ユーザー B と同じクエリを実行することで、あるテーブル上の行ポリシーを回避できてはなりません。しかし、必要であれば、
-[query_cache_share_between_users](/operations/settings/settings#query_cache_share_between_users) 設定を指定することで、キャッシュエントリを他のユーザー
-からアクセス可能（すなわち共有）としてマークできます。
-
+[query_cache_system_table_handling](/operations/settings/settings#query_cache_system_table_handling) を設定します。
+最後に、セキュリティ上の理由から、クエリキャッシュ内のエントリはユーザー間で共有されません。たとえば、ユーザー A は、
+ユーザー B（そのようなポリシーが存在しないユーザー）と同じクエリを実行することで、テーブルに対する行ポリシーを回避できてはなりません。
+ただし、必要に応じて、設定
+[query_cache_share_between_users](/operations/settings/settings#query_cache_share_between_users) を指定することで、
+キャッシュエントリを他のユーザーからアクセス可能（すなわち共有）としてマークできます。
## 関連コンテンツ {#related-content}
-- ブログ: [ClickHouseクエリキャッシュの紹介](https://clickhouse.com/blog/introduction-to-the-clickhouse-query-cache-and-design)
+* ブログ記事: [Introducing the ClickHouse Query Cache](https://clickhouse.com/blog/introduction-to-the-clickhouse-query-cache-and-design)
\ No newline at end of file
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/query-condition-cache.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/query-condition-cache.md
index 165157f7fc4..e9d11898a1f 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/query-condition-cache.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/query-condition-cache.md
@@ -9,7 +9,7 @@ doc_type: 'guide'
-# クエリ条件キャッシュ
+# クエリ条件キャッシュ {#query-condition-cache}
:::note
クエリ条件キャッシュは、[enable_analyzer](https://clickhouse.com/docs/operations/settings/settings#enable_analyzer) が true に設定されている場合にのみ動作します。これはデフォルト値です。
@@ -45,7 +45,7 @@ ClickHouse には、そのようなクエリパターンを最適化するため
-## 設定項目と使用方法
+## 設定項目と使用方法 {#configuration-settings-and-usage}
[use_query_condition_cache](settings/settings#use_query_condition_cache) 設定は、特定のクエリ、または現在のセッション内のすべてのクエリでクエリ条件キャッシュを利用するかどうかを制御します。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/server-configuration-parameters/_server_settings_outside_source.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/server-configuration-parameters/_server_settings_outside_source.md
index 1b8f6b68a95..af5fdc2b69a 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/server-configuration-parameters/_server_settings_outside_source.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/server-configuration-parameters/_server_settings_outside_source.md
@@ -1,4 +1,4 @@
-## asynchronous_metric_log
+## asynchronous_metric_log {#asynchronous_metric_log}
ClickHouse Cloud のデプロイメントでは、デフォルトで有効になっています。
@@ -103,7 +103,7 @@ ClickHouse Cloud のデプロイメントでは、デフォルトで有効にな
```
-## bcrypt_workfactor
+## bcrypt_workfactor {#bcrypt_workfactor}
[Bcrypt アルゴリズム](https://wildlyinaccurate.com/bcrypt-choosing-a-work-factor/) を使用する `bcrypt_password` 認証タイプのワークファクターです。
ワークファクターは、ハッシュを計算してパスワードを検証するのに必要な計算量と時間を決定します。
@@ -129,7 +129,7 @@ true に設定した場合、ユーザーが特定のエンジンを使用して
-## builtin_dictionaries_reload_interval
+## builtin_dictionaries_reload_interval {#builtin_dictionaries_reload_interval}
組み込みディクショナリを再読み込みする間隔（秒）。
@@ -142,7 +142,7 @@ ClickHouse は、組み込みディクショナリを x 秒ごとに再読み込
```
-## 圧縮
+## 圧縮 {#compression}
[MergeTree](../../engines/table-engines/mergetree-family/mergetree.md) エンジンテーブル向けのデータ圧縮設定です。
@@ -198,7 +198,7 @@ ClickHouse を使い始めたばかりの場合は、この設定は変更しな
```
-## encryption
+## encryption {#encryption}
[暗号化コーデック](/sql-reference/statements/create/table#encryption-codecs)で使用するキーを取得するためのコマンドを設定します。キー（複数可）は環境変数として指定するか、設定ファイルで設定する必要があります。
@@ -281,7 +281,7 @@ ClickHouse を使い始めたばかりの場合は、この設定は変更しな
:::
-## error_log
+## error_log {#error_log}
これはデフォルトでは無効です。
@@ -317,7 +317,7 @@ ClickHouse を使い始めたばかりの場合は、この設定は変更しな
-## custom_settings_prefixes
+## custom_settings_prefixes {#custom_settings_prefixes}
[カスタム設定](/operations/settings/query-level#custom_settings) に使用するプレフィックスのリスト。プレフィックスはカンマ区切りで指定する必要があります。
@@ -332,7 +332,7 @@ ClickHouse を使い始めたばかりの場合は、この設定は変更しな
* [カスタム設定](/operations/settings/query-level#custom_settings)
-## core_dump
+## core_dump {#core_dump}
コアダンプファイルサイズのソフトリミットを設定します。
@@ -349,7 +349,7 @@ ClickHouse を使い始めたばかりの場合は、この設定は変更しな
```
-## default_profile
+## default_profile {#default_profile}
デフォルトの設定プロファイルです。設定プロファイルは、`user_config` 設定で指定されたファイル内に定義されます。
@@ -360,7 +360,7 @@ ClickHouse を使い始めたばかりの場合は、この設定は変更しな
```
-## dictionaries_config
+## dictionaries_config {#dictionaries_config}
辞書の設定ファイルへのパス。
@@ -380,7 +380,7 @@ ClickHouse を使い始めたばかりの場合は、この設定は変更しな
```
-## user_defined_executable_functions_config
+## user_defined_executable_functions_config {#user_defined_executable_functions_config}
実行可能なユーザー定義関数用の設定ファイルのパスです。
@@ -400,7 +400,7 @@ See also:
```
-## format_schema_path
+## format_schema_path {#format_schema_path}
入力データ用のスキーマ（例：[CapnProto](/interfaces/formats/CapnProto) フォーマットのスキーマ）が格納されているディレクトリへのパス。
@@ -412,7 +412,7 @@ See also:
```
-## graphite
+## graphite {#graphite}
[Graphite](https://github.com/graphite-project) にデータを送信します。
@@ -447,7 +447,7 @@ See also:
```
-## graphite_rollup
+## graphite_rollup {#graphite_rollup}
Graphite データを間引くための設定です。
@@ -476,7 +476,7 @@ Graphite データを間引くための設定です。
```
-## google_protos_path
+## google_protos_path {#google_protos_path}
Protobuf 型の proto ファイルを格納したディレクトリを指定します。
@@ -487,7 +487,7 @@ Protobuf 型の proto ファイルを格納したディレクトリを指定し
```
-## http_handlers
+## http_handlers {#http_handlers}
カスタム HTTP ハンドラーを使用できるようにします。
新しい http ハンドラーを追加するには、新しい `` を追加するだけです。
@@ -553,7 +553,7 @@ Protobuf 型の proto ファイルを格納したディレクトリを指定し
```
-## http_server_default_response
+## http_server_default_response {#http_server_default_response}
ClickHouse の HTTP(S) サーバーにアクセスしたときに、デフォルトで表示されるページです。
デフォルト値は「Ok.」（末尾に改行文字付き）です。
@@ -569,7 +569,7 @@ ClickHouse の HTTP(S) サーバーにアクセスしたときに、デフォル
```
-## http_options_response
+## http_options_response {#http_options_response}
`OPTIONS` HTTP リクエストに対するレスポンスにヘッダーを追加するために使用します。
`OPTIONS` メソッドは、CORS プリフライトリクエストを行う際に使用されます。
@@ -600,7 +600,7 @@ ClickHouse の HTTP(S) サーバーにアクセスしたときに、デフォル
```
-## hsts_max_age
+## hsts_max_age {#hsts_max_age}
HSTS の有効期限（秒単位）。
@@ -615,7 +615,7 @@ HSTS の有効期限（秒単位）。
```
-## mlock_executable
+## mlock_executable {#mlock_executable}
起動後に `mlockall` を実行して、最初のクエリのレイテンシーを下げ、高い I/O 負荷時に ClickHouse の実行ファイルがページアウトされるのを防ぎます。
@@ -631,7 +631,7 @@ HSTS の有効期限（秒単位）。
```
-## include_from
+## include_from {#include_from}
置換設定を含むファイルへのパスです。XML と YAML の両方の形式がサポートされています。
@@ -644,7 +644,7 @@ HSTS の有効期限（秒単位）。
```
-## interserver_listen_host
+## interserver_listen_host {#interserver_listen_host}
ClickHouse サーバー間でデータを交換できるホストを制限する設定。
Keeper が使用されている場合は、異なる Keeper インスタンス間の通信にも同じ制限が適用されます。
@@ -665,7 +665,7 @@ Keeper が使用されている場合は、異なる Keeper インスタンス
デフォルト値:
-## interserver_http_port
+## interserver_http_port {#interserver_http_port}
ClickHouse サーバー間のデータ交換に使用するポート。
@@ -676,7 +676,7 @@ ClickHouse サーバー間のデータ交換に使用するポート。
```
-## interserver_http_host
+## interserver_http_host {#interserver_http_host}
他のサーバーがこのサーバーにアクセスする際に使用されるホスト名です。
@@ -691,7 +691,7 @@ ClickHouse サーバー間のデータ交換に使用するポート。
```
-## interserver_https_port
+## interserver_https_port {#interserver_https_port}
`HTTPS` 経由で ClickHouse サーバー間のデータを交換するためのポート。
@@ -702,7 +702,7 @@ ClickHouse サーバー間のデータ交換に使用するポート。
```
-## interserver_https_host
+## interserver_https_host {#interserver_https_host}
[`interserver_http_host`](#interserver_http_host) と同様ですが、このホスト名は他のサーバーが `HTTPS` 経由でこのサーバーにアクセスする際に使用されます。
@@ -713,7 +713,7 @@ ClickHouse サーバー間のデータ交換に使用するポート。
```
-## interserver_http_credentials
+## interserver_http_credentials {#interserver_http_credentials}
[レプリケーション](../../engines/table-engines/mergetree-family/replication.md)中に他のサーバーへ接続するために使用されるユーザー名とパスワードです。さらに、サーバーはこれらの認証情報を使用して他のレプリカを認証します。
そのため、`interserver_http_credentials` はクラスター内のすべてのレプリカで同一である必要があります。
@@ -837,7 +837,7 @@ ClickHouse は、すべてのレプリカを同時に停止して設定を更新
```
-## listen_host
+## listen_host {#listen_host}
リクエスト元ホストを制限します。サーバーがすべてのホストからのリクエストを受け付けるようにするには、`::` を指定します。
@@ -849,7 +849,7 @@ ClickHouse は、すべてのレプリカを同時に停止して設定を更新
```
-## listen_try
+## listen_try {#listen_try}
`listen` しようとした際に IPv6 または IPv4 ネットワークが利用できなくても、サーバーは終了しません。
@@ -860,7 +860,7 @@ ClickHouse は、すべてのレプリカを同時に停止して設定を更新
```
-## listen_reuse_port
+## listen_reuse_port {#listen_reuse_port}
複数のサーバーが同じアドレスとポート番号で待ち受けできるようにします。リクエストはオペレーティングシステムによってランダムなサーバーにルーティングされます。この設定を有効にすることは推奨されていません。
@@ -875,7 +875,7 @@ ClickHouse は、すべてのレプリカを同時に停止して設定を更新
デフォルト:
-## listen_backlog
+## listen_backlog {#listen_backlog}
listen ソケットのバックログ（保留中の接続のキューサイズ）。デフォルト値 `4096` は Linux [5.4+](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=19f92a030ca6d772ab44b22ee6a01378a8cb32d4)) と同じです。
@@ -1089,7 +1089,7 @@ JSON ログ出力を有効にするには、以下のスニペットを使用し
ログプロパティは、そのプロパティをコメントアウトすることで省略できます。たとえば、ログに `query_id` を出力したくない場合は、`` タグをコメントアウトします。
-## send_crash_reports
+## send_crash_reports {#send_crash_reports}
ClickHouse コア開発チームへクラッシュレポートを送信するための設定です。
@@ -1112,7 +1112,7 @@ Keys:
```
-## ssh_server
+## ssh_server {#ssh_server}
ホスト鍵の公開鍵部分は、最初に接続した際に SSH クライアント側の known_hosts ファイルに書き込まれます。
@@ -1130,7 +1130,7 @@ Host Key Configurations のコメントアウトを解除し、それぞれに
```
-## tcp_ssh_port
+## tcp_ssh_port {#tcp_ssh_port}
ユーザーが組み込みクライアントを使用して PTY 経由で接続し、対話的にクエリを実行できるようにする SSH サーバーのポートです。
@@ -1141,7 +1141,7 @@ Host Key Configurations のコメントアウトを解除し、それぞれに
```
-## storage_configuration
+## storage_configuration {#storage_configuration}
ストレージの複数ディスク構成を行うための設定です。
@@ -1158,7 +1158,7 @@ Host Key Configurations のコメントアウトを解除し、それぞれに
```
-### ディスクの構成
+### ディスクの構成 {#configuration-of-disks}
`disks` の構成は、以下に示す構造に従います。
@@ -1193,7 +1193,7 @@ Host Key Configurations のコメントアウトを解除し、それぞれに
ディスクの順序は関係ありません。
:::
-### ポリシーの設定
+### ポリシーの設定 {#configuration-of-policies}
上記のサブタグでは、`policies` に対して次の設定を行います:
@@ -1219,7 +1219,7 @@ Host Key Configurations のコメントアウトを解除し、それぞれに
-## マクロ
+## マクロ {#macros}
レプリケーテッドテーブル向けのパラメータ置換です。
@@ -1234,7 +1234,7 @@ Host Key Configurations のコメントアウトを解除し、それぞれに
```
-## replica_group_name
+## replica_group_name {#replica_group_name}
Replicated データベースのレプリカグループ名。
@@ -1250,7 +1250,7 @@ DDL クエリは同一グループ内のレプリカに対してのみ待機し
```
-## remap_executable
+## remap_executable {#remap_executable}
ヒュージページを使用して、マシンコード（「text」）用のメモリを再割り当てするための設定です。
@@ -1265,7 +1265,7 @@ DDL クエリは同一グループ内のレプリカに対してのみ待機し
```
-## max_open_files
+## max_open_files {#max_open_files}
同時に開くことができるファイルの最大数です。
@@ -1280,7 +1280,7 @@ DDL クエリは同一グループ内のレプリカに対してのみ待機し
```
-## max_session_timeout
+## max_session_timeout {#max_session_timeout}
セッションの最大タイムアウト時間（秒）。
@@ -1291,7 +1291,7 @@ DDL クエリは同一グループ内のレプリカに対してのみ待機し
```
-## merge_tree
+## merge_tree {#merge_tree}
[MergeTree](../../engines/table-engines/mergetree-family/mergetree.md) テーブル向けの微調整。
@@ -1306,7 +1306,7 @@ DDL クエリは同一グループ内のレプリカに対してのみ待機し
```
-## metric_log
+## metric_log {#metric_log}
デフォルトでは無効になっています。
@@ -1342,7 +1342,7 @@ DDL クエリは同一グループ内のレプリカに対してのみ待機し
-## replicated_merge_tree
+## replicated_merge_tree {#replicated_merge_tree}
[ReplicatedMergeTree](../../engines/table-engines/mergetree-family/mergetree.md) テーブル向けの微調整用設定です。この設定はより高い優先度を持ちます。
@@ -1357,7 +1357,7 @@ DDL クエリは同一グループ内のレプリカに対してのみ待機し
```
-## opentelemetry_span_log
+## opentelemetry_span_log {#opentelemetry_span_log}
[`opentelemetry_span_log`](../system-tables/opentelemetry_span_log.md) システムテーブルの設定。
@@ -1447,7 +1447,7 @@ SSL のサポートは `libpoco` ライブラリによって提供されます
```
-## part_log
+## part_log {#part_log}
[MergeTree](../../engines/table-engines/mergetree-family/mergetree.md) に関連するイベントを記録するログです。たとえば、データの追加やマージなどです。ログを使用してマージアルゴリズムをシミュレートし、その特性を比較できます。マージ処理を可視化することもできます。
@@ -1471,7 +1471,7 @@ SSL のサポートは `libpoco` ライブラリによって提供されます
```
-## path
+## path {#path}
データが格納されているディレクトリへのパス。
@@ -1486,7 +1486,7 @@ SSL のサポートは `libpoco` ライブラリによって提供されます
```
-## processors_profile_log
+## processors_profile_log {#processors_profile_log}
[`processors_profile_log`](../system-tables/processors_profile_log.md) システムテーブルの設定です。
@@ -1508,7 +1508,7 @@ SSL のサポートは `libpoco` ライブラリによって提供されます
```
-## prometheus
+## prometheus {#prometheus}
[Prometheus](https://prometheus.io) からスクレイプできるようにメトリクスデータを公開します。
@@ -1548,7 +1548,7 @@ curl 127.0.0.1:9363/metrics
```
-## query_log
+## query_log {#query_log}
[log_queries=1](../../operations/settings/settings.md) 設定が有効な場合に受信したクエリをログに記録するための設定です。
@@ -1574,7 +1574,7 @@ curl 127.0.0.1:9363/metrics
```
-## query_metric_log
+## query_metric_log {#query_metric_log}
デフォルトでは無効です。
@@ -1610,7 +1610,7 @@ curl 127.0.0.1:9363/metrics
-## query_cache
+## query_cache {#query_cache}
[クエリキャッシュ](../query-cache.md)の設定です。
@@ -1641,7 +1641,7 @@ curl 127.0.0.1:9363/metrics
```
-## query_thread_log
+## query_thread_log {#query_thread_log}
[log_query_threads=1](/operations/settings/settings#log_query_threads) が設定されたクエリのスレッドをログに記録するための設定です。
@@ -1667,7 +1667,7 @@ curl 127.0.0.1:9363/metrics
```
-## query_views_log
+## query_views_log {#query_views_log}
[log_query_views=1](/operations/settings/settings#log_query_views) 設定を指定して受信したクエリに応じて、ビュー（live、materialized など）をログに記録するための設定です。
@@ -1693,7 +1693,7 @@ curl 127.0.0.1:9363/metrics
```
-## text_log
+## text_log {#text_log}
テキストメッセージをログに記録するための [text_log](/operations/system-tables/text_log) システムテーブルの設定。
@@ -1725,7 +1725,7 @@ curl 127.0.0.1:9363/metrics
```
-## trace_log
+## trace_log {#trace_log}
[trace_log](/operations/system-tables/trace_log) システムテーブルの動作設定。
@@ -1748,7 +1748,7 @@ curl 127.0.0.1:9363/metrics
```
-## asynchronous_insert_log
+## asynchronous_insert_log {#asynchronous_insert_log}
非同期挿入をログとして記録するための [asynchronous_insert_log](/operations/system-tables/asynchronous_insert_log) システムテーブル用の設定です。
@@ -1773,7 +1773,7 @@ curl 127.0.0.1:9363/metrics
```
-## crash_log
+## crash_log {#crash_log}
[crash_log](../../operations/system-tables/crash_log.md) システムテーブルの動作に関する設定です。
@@ -1811,7 +1811,7 @@ curl 127.0.0.1:9363/metrics
```
-## custom_cached_disks_base_directory
+## custom_cached_disks_base_directory {#custom_cached_disks_base_directory}
この設定は、カスタム（SQL から作成した）キャッシュディスクのキャッシュパスを指定します。
`custom_cached_disks_base_directory` は、カスタムディスクに対しては `filesystem_caches_path`（`filesystem_caches_path.xml` に記載）より高い優先度を持ち、
@@ -1831,7 +1831,7 @@ curl 127.0.0.1:9363/metrics
```
-## backup_log
+## backup_log {#backup_log}
`BACKUP` および `RESTORE` 操作をログに記録するための [backup_log](../../operations/system-tables/backup_log.md) システムテーブル用の設定です。
@@ -1856,7 +1856,7 @@ curl 127.0.0.1:9363/metrics
```
-## blob_storage_log
+## blob_storage_log {#blob_storage_log}
[`blob_storage_log`](../system-tables/blob_storage_log.md) システムテーブルに関する設定です。
@@ -1875,7 +1875,7 @@ curl 127.0.0.1:9363/metrics
```
-## query_masking_rules
+## query_masking_rules {#query_masking_rules}
正規表現に基づくルールです。クエリおよびすべてのログメッセージに対して、サーバーログ
[`system.query_log`](/operations/system-tables/query_log)、[`system.text_log`](/operations/system-tables/text_log)、[`system.processes`](/operations/system-tables/processes) テーブルに保存される前と、クライアントに送信されるログの両方に適用されます。これにより、名前、メールアドレス、個人識別子、クレジットカード番号などの機密データが、SQL クエリからログへ漏洩するのを防ぐことができます。
@@ -1907,7 +1907,7 @@ curl 127.0.0.1:9363/metrics
分散クエリの場合は、各サーバーを個別に設定する必要があります。そうしないと、他ノードに渡されるサブクエリはマスクされないまま保存されます。
-## remote_servers
+## remote_servers {#remote_servers}
[Distributed](../../engines/table-engines/special/distributed.md) テーブルエンジンおよび `cluster` テーブル関数で使用されるクラスタの設定です。
@@ -1926,7 +1926,7 @@ curl 127.0.0.1:9363/metrics
* [Replicatedデータベースエンジン](../../engines/database-engines/replicated.md)
-## remote_url_allow_hosts
+## remote_url_allow_hosts {#remote_url_allow_hosts}
URL 関連のストレージエンジンおよびテーブル関数で使用を許可するホストのリスト。
@@ -1947,7 +1947,7 @@ URL 関連のストレージエンジンおよびテーブル関数で使用を
```
-## timezone
+## timezone {#timezone}
サーバーのタイムゾーンです。
@@ -1966,7 +1966,7 @@ UTC タイムゾーンまたは地理的位置を表す IANA 識別子として
* [session_timezone](../settings/settings.md#session_timezone)
-## tcp_port
+## tcp_port {#tcp_port}
TCP プロトコルでクライアントと通信するためのポート。
@@ -1977,7 +1977,7 @@ TCP プロトコルでクライアントと通信するためのポート。
```
-## tcp_port_secure
+## tcp_port_secure {#tcp_port_secure}
クライアントとの安全な通信に使用する TCP ポートです。[OpenSSL](#openssl) の設定と併用します。
@@ -1988,7 +1988,7 @@ TCP プロトコルでクライアントと通信するためのポート。
```
-## mysql_port
+## mysql_port {#mysql_port}
MySQL プロトコル経由でクライアントと通信するためのポート。
@@ -2005,7 +2005,7 @@ MySQL プロトコル経由でクライアントと通信するためのポー
```
-## postgresql_port
+## postgresql_port {#postgresql_port}
PostgreSQL プロトコル経由でクライアントと通信するためのポートです。
@@ -2034,7 +2034,7 @@ true に設定すると、[postgresql_port](#postgresql_port) を介したクラ
-## tmp_path
+## tmp_path {#tmp_path}
大規模なクエリを処理するための一時データを保存する、ローカルファイルシステム上のパスです。
@@ -2051,7 +2051,7 @@ true に設定すると、[postgresql_port](#postgresql_port) を介したクラ
```
-## url_scheme_mappers
+## url_scheme_mappers {#url_scheme_mappers}
短縮またはシンボリックな URL プレフィックスを完全な URL にマッピングするための設定です。
@@ -2072,7 +2072,7 @@ true に設定すると、[postgresql_port](#postgresql_port) を介したクラ
```
-## user_files_path
+## user_files_path {#user_files_path}
ユーザーファイルを格納するディレクトリです。テーブル関数 [file()](../../sql-reference/table-functions/file.md)、[fileCluster()](../../sql-reference/table-functions/fileCluster.md) で使用されます。
@@ -2083,7 +2083,7 @@ true に設定すると、[postgresql_port](#postgresql_port) を介したクラ
```
-## user_scripts_path
+## user_scripts_path {#user_scripts_path}
ユーザースクリプトファイルを格納するディレクトリです。[Executable User Defined Functions](/sql-reference/functions/udf#executable-user-defined-functions) で使用されます。
@@ -2098,7 +2098,7 @@ true に設定すると、[postgresql_port](#postgresql_port) を介したクラ
デフォルト:
-## user_defined_path
+## user_defined_path {#user_defined_path}
ユーザー定義ファイルを格納するディレクトリです。SQL のユーザー定義関数で使用されます。詳細は [SQL User Defined Functions](/sql-reference/functions/udf) を参照してください。
@@ -2109,7 +2109,7 @@ true に設定すると、[postgresql_port](#postgresql_port) を介したクラ
```
-## users_config
+## users_config {#users_config}
次の内容を含むファイルへのパス:
@@ -2125,7 +2125,7 @@ true に設定すると、[postgresql_port](#postgresql_port) を介したクラ
```
-## access_control_improvements
+## access_control_improvements {#access_control_improvements}
アクセス制御システムにおける任意の改善用設定です。
@@ -2154,7 +2154,7 @@ true に設定すると、[postgresql_port](#postgresql_port) を介したクラ
```
-## s3queue_log
+## s3queue_log {#s3queue_log}
`s3queue_log` システムテーブルの設定です。
@@ -2172,7 +2172,7 @@ true に設定すると、[postgresql_port](#postgresql_port) を介したクラ
```
-## dead_letter_queue
+## dead_letter_queue {#dead_letter_queue}
'dead_letter_queue' システムテーブルの設定です。
@@ -2190,7 +2190,7 @@ true に設定すると、[postgresql_port](#postgresql_port) を介したクラ
```
-## zookeeper
+## zookeeper {#zookeeper}
ClickHouse が [ZooKeeper](http://zookeeper.apache.org/) クラスターと連携するための設定です。ClickHouse は、レプリケーテッドテーブルを使用する場合に、レプリカのメタデータを保存するために ZooKeeper を使用します。レプリケーテッドテーブルを使用しない場合は、このセクションのパラメーターは省略できます。
@@ -2275,7 +2275,7 @@ ClickHouse はサーバー上のすべてのテーブルに対してこの設定
-## distributed_ddl
+## distributed_ddl {#distributed_ddl}
クラスタ上での[分散 DDL クエリ](../../sql-reference/distributed-ddl.md)（`CREATE`、`DROP`、`ALTER`、`RENAME`）の実行を管理します。
[ZooKeeper](/operations/server-configuration-parameters/settings#zookeeper) が有効な場合にのみ動作します。
@@ -2330,7 +2330,7 @@ ClickHouse サーバーが SQL コマンドで作成したユーザーおよび
-## allow_plaintext_password
+## allow_plaintext_password {#allow_plaintext_password}
平文パスワードタイプ（安全ではない）の使用を許可するかどうかを設定します。
@@ -2339,7 +2339,7 @@ ClickHouse サーバーが SQL コマンドで作成したユーザーおよび
```
-## allow_no_password
+## allow_no_password {#allow_no_password}
安全ではないパスワード種別 `no_password` を許可するかどうかを設定します。
@@ -2348,7 +2348,7 @@ ClickHouse サーバーが SQL コマンドで作成したユーザーおよび
```
-## allow_implicit_no_password
+## allow_implicit_no_password {#allow_implicit_no_password}
明示的に 'IDENTIFIED WITH no_password' が指定されていない限り、パスワードなしのユーザーは作成できません。
@@ -2357,7 +2357,7 @@ ClickHouse サーバーが SQL コマンドで作成したユーザーおよび
```
-## default_session_timeout
+## default_session_timeout {#default_session_timeout}
セッションのデフォルトのタイムアウト時間（秒）。
@@ -2366,7 +2366,7 @@ ClickHouse サーバーが SQL コマンドで作成したユーザーおよび
```
-## default_password_type
+## default_password_type {#default_password_type}
`CREATE USER u IDENTIFIED BY 'p'` のようなクエリにおいて、自動的に設定されるパスワードの種類を指定します。
@@ -2382,7 +2382,7 @@ ClickHouse サーバーが SQL コマンドで作成したユーザーおよび
```
-## user_directories
+## user_directories {#user_directories}
次の設定を含む設定ファイルのセクションです:
@@ -2442,7 +2442,7 @@ ClickHouse サーバーが SQL コマンドで作成したユーザーおよび
```
-## top_level_domains_list
+## top_level_domains_list {#top_level_domains_list}
追加で登録するカスタムトップレベルドメインのリストを定義します。各エントリは `/path/to/file` という形式です。
@@ -2460,7 +2460,7 @@ See also:
カスタムの TLD リスト名を受け取り、最初の有意なサブドメインまでのトップレベルサブドメインを含むドメイン部分を返します。
-## proxy
+## proxy {#proxy}
HTTP および HTTPS リクエスト向けのプロキシサーバーを定義します。現在、S3 ストレージ、S3 テーブル関数、および URL 関数でサポートされています。
@@ -2599,7 +2599,7 @@ ClickHouse は、リクエストプロトコルに対して最も優先度の高
-## disable_tunneling_for_https_requests_over_http_proxy
+## disable_tunneling_for_https_requests_over_http_proxy {#disable_tunneling_for_https_requests_over_http_proxy}
デフォルトでは、`HTTP` プロキシ経由で `HTTPS` リクエストを行う際にトンネリング（`HTTP CONNECT`）が利用されます。この設定でトンネリングを無効化できます。
@@ -2628,7 +2628,7 @@ GitLab についても同様で、先頭にドットが付いていても同じ
```
-## workload_path
+## workload_path {#workload_path}
すべての `CREATE WORKLOAD` クエリおよび `CREATE RESOURCE` クエリの保存先として使用されるディレクトリです。デフォルトでは、サーバーの作業ディレクトリ配下の `/workload/` フォルダが使用されます。
@@ -2644,7 +2644,7 @@ GitLab についても同様で、先頭にドットが付いていても同じ
* [workload_zookeeper_path](#workload_zookeeper_path)
-## workload_zookeeper_path
+## workload_zookeeper_path {#workload_zookeeper_path}
ZooKeeper ノードへのパスです。すべての `CREATE WORKLOAD` および `CREATE RESOURCE` クエリの保存先として使用されます。一貫性を保つため、すべての SQL 定義はこの単一の znode に値として保存されます。デフォルトでは ZooKeeper は使用されず、定義は [ディスク](#workload_path) 上に保存されます。
@@ -2660,7 +2660,7 @@ ZooKeeper ノードへのパスです。すべての `CREATE WORKLOAD` および
* [workload_path](#workload_path)
-## zookeeper_log
+## zookeeper_log {#zookeeper_log}
[`zookeeper_log`](/operations/system-tables/zookeeper_log) システムテーブルに関する設定です。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/server-configuration-parameters/settings.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/server-configuration-parameters/settings.md
index 445d6b228f2..240c2837cac 100644
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/server-configuration-parameters/settings.md
+++ b/i18n/jp/docusaurus-plugin-content-docs/current/operations/server-configuration-parameters/settings.md
@@ -1,6 +1,6 @@
---
-description: 'このセクションでは、サーバー設定、すなわちセッションレベルやクエリレベルでは変更できない設定について説明します。'
-keywords: ['グローバルサーバー設定']
+description: 'このセクションでは、セッション単位やクエリ単位では変更できないサーバー設定について説明します。'
+keywords: ['グローバルなサーバー設定']
sidebar_label: 'サーバー設定'
sidebar_position: 57
slug: /operations/server-configuration-parameters/settings
@@ -8,5131 +8,6 @@ title: 'サーバー設定'
doc_type: 'reference'
---
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-import SystemLogParameters from '@site/docs/operations/server-configuration-parameters/_snippets/_system-log-parameters.md';
-import SettingsInfoBlock from '@theme/SettingsInfoBlock/SettingsInfoBlock';
-
-
-# サーバー設定
-
-このセクションでは、サーバー設定について説明します。これらはセッションやクエリ単位では変更できない設定です。
-
-ClickHouse における設定ファイルの詳細については、[「Configuration Files」](/operations/configuration-files) を参照してください。
-
-その他の設定については、「[Settings](/operations/settings/overview)」セクションで説明しています。
-設定について理解する前に、[Configuration files](/operations/configuration-files) セクションを読み、置換（`incl` および `optional` 属性）の使い方に注意することを推奨します。
-
-
-
-## abort_on_logical_error {#abort_on_logical_error}
-
-LOGICAL_ERROR 例外発生時にサーバーをクラッシュさせます。上級者向けの設定です。
-
-
-
-## access_control_improvements
-
-アクセス制御システムに対する任意の改善用設定です。
-
-| Setting | Description | Default |
-| ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
-| `users_without_row_policies_can_read_rows` | 行ポリシーを持たないユーザーでも、`SELECT` クエリを使用して行を読み取れるかどうかを設定します。たとえば、ユーザー A と B がいて、行ポリシーが A に対してのみ定義されている場合、この設定が true であれば、ユーザー B はすべての行を閲覧できます。この設定が false の場合、ユーザー B はいずれの行も閲覧できません。 | `true` |
-| `on_cluster_queries_require_cluster_grant` | `ON CLUSTER` クエリに `CLUSTER` 権限が必要かどうかを設定します。 | `true` |
-| `select_from_system_db_requires_grant` | `SELECT * FROM system.` を実行する際に、権限が必要かどうか、また任意のユーザーが実行できるかどうかを設定します。true に設定した場合、このクエリには `system` 以外のテーブルと同様に `GRANT SELECT ON system.` が必要です。例外として、いくつかの `system` テーブル（`tables`、`columns`、`databases`、および `one`、`contributors` のような一部の定数テーブル）は引き続き全ユーザーが参照可能です。また、`SHOW` 権限（例: `SHOW USERS`）が付与されている場合、対応する `system` テーブル（つまり `system.users`）にはアクセスできます。 | `true` |
-| `select_from_information_schema_requires_grant` | `SELECT * FROM information_schema.` を実行する際に、権限が必要かどうか、また任意のユーザーが実行できるかどうかを設定します。true に設定した場合、このクエリには通常のテーブルと同様に `GRANT SELECT ON information_schema.` が必要です。 | `true` |
-| `settings_constraints_replace_previous` | ある設定に対する設定プロファイル内の制約が、その設定に対して以前に定義された制約（他のプロファイル内で定義されたもの）の動作を、新しい制約で値が設定されていないフィールドも含めて打ち消すかどうかを設定します。また、`changeable_in_readonly` 制約タイプを有効にします。 | `true` |
-| `table_engines_require_grant` | 特定のテーブルエンジンを用いてテーブルを作成する際に、権限が必要かどうかを設定します。 | `false` |
-| `role_cache_expiration_time_seconds` | 最終アクセスからの経過秒数として、ロールが `Role Cache` に保持される時間を設定します。 | `600` |
-
-Example:
-
-```xml
-
- true
- true
- true
- true
- true
- false
- 600
-
-```
-
-
-## access_control_path {#access_control_path}
-
-ClickHouse サーバーが、SQL コマンドで作成されたユーザーおよびロールの設定を格納するディレクトリへのパス。
-
-**関連項目**
-
-- [アクセス制御とアカウント管理](/operations/access-rights#access-control-usage)
-
-
-
-## aggregate_function_group_array_action_when_limit_is_reached {#aggregate_function_group_array_action_when_limit_is_reached}
-
-groupArray で配列要素数の上限を超えた場合に実行する動作: 例外を `throw` するか、超過した値を `discard` するかを指定します
-
-
-
-## aggregate_function_group_array_max_element_size {#aggregate_function_group_array_max_element_size}
-
-groupArray 関数における配列要素の最大サイズ（バイト単位）。この制限はシリアル化時に検証され、集約状態が過度に大きくなるのを防ぎます。
-
-
-
-## allow_feature_tier {#allow_feature_tier}
-
-
-異なる機能ティアごとの設定をユーザーが変更できるかどうかを制御します。
-
-- `0` - すべての設定の変更が許可されます（experimental、beta、production）。
-- `1` - beta および production の機能設定のみ変更が許可されます。experimental 設定の変更は拒否されます。
-- `2` - production の設定のみ変更が許可されます。experimental および beta の設定の変更は拒否されます。
-
-これは、すべての `EXPERIMENTAL` / `BETA` 機能に読み取り専用の制約を設定するのと同等です。
-
-:::note
-値が `0` の場合、すべての設定を変更できます。
-:::
-
-
-
-
-## allow_impersonate_user {#allow_impersonate_user}
-
-`IMPERSONATE` 機能（`EXECUTE AS target_user`）を有効または無効にします。
-
-
-
-## allow_implicit_no_password
-
-'IDENTIFIED WITH no_password' が明示的に指定されていない限り、ユーザーをパスワードなしで作成することを禁止します。
-
-```xml
-1
-```
-
-
-## allow_no_password
-
-安全ではないパスワード種別である no_password を許可するかどうかを設定します。
-
-```xml
-1
-```
-
-
-## allow_plaintext_password
-
-プレーンテキストのパスワード方式（安全ではない）を許可するかどうかを設定します。
-
-```xml
-1
-```
-
-
-## allow_use_jemalloc_memory {#allow_use_jemalloc_memory}
-
-jemalloc によるメモリの使用を許可します。
-
-
-
-## allowed_disks_for_table_engines {#allowed_disks_for_table_engines}
-
-Iceberg で使用が許可されているディスクの一覧
-
-
-
-## async_insert_queue_flush_on_shutdown {#async_insert_queue_flush_on_shutdown}
-
-`true` の場合、グレースフルシャットダウン時に非同期挿入キューがフラッシュされます
-
-
-
-## async_insert_threads {#async_insert_threads}
-
-バックグラウンドでデータを解析して挿入するために使用されるスレッドの最大数。0 の場合、非同期モードは無効になります
-
-
-
-## async_load_databases
-
-
-
-データベースおよびテーブルの非同期ロード。
-
-* `true` の場合、すべての非システムデータベースのうち、エンジンが `Ordinary`、`Atomic`、`Replicated` のものは、ClickHouse サーバーの起動後に非同期でロードされます。`system.asynchronous_loader` テーブルおよび `tables_loader_background_pool_size`、`tables_loader_foreground_pool_size` サーバー設定を参照してください。まだロードされていないテーブルへアクセスしようとするクエリは、そのテーブルが起動して利用可能になるまで待機します。ロードジョブが失敗した場合、クエリは（`async_load_databases = false` の場合のようにサーバー全体をシャットダウンするのではなく）エラーを再スローします。少なくとも 1 つのクエリが待機しているテーブルは、より高い優先度でロードされます。データベースに対する DDL クエリは、そのデータベースが起動して利用可能になるまで待機します。また、待機中のクエリ総数に対する制限として `max_waiting_queries` の設定も検討してください。
-* `false` の場合、すべてのデータベースはサーバー起動時にロードされます。
-
-**例**
-
-```xml
-true
-```
-
-
-## async_load_system_database
-
-
-
-`system` データベース内に多数のログテーブルやパーツがある場合に有用な、システムテーブルの非同期読み込みを有効にします。`async_load_databases` 設定とは独立しています。
-
-* `true` に設定した場合、ClickHouse サーバー起動後に、`Ordinary`、`Atomic`、`Replicated` エンジンを持つすべての `system` データベースが非同期に読み込まれます。`system.asynchronous_loader` テーブル、およびサーバー設定 `tables_loader_background_pool_size` と `tables_loader_foreground_pool_size` を参照してください。まだ読み込まれていないシステムテーブルへアクセスしようとするクエリは、そのテーブルの読み込みが完了するまで待機します。少なくとも 1 件のクエリから待機されているテーブルは、より高い優先度で読み込まれます。また、待機中のクエリ総数を制限するために `max_waiting_queries` 設定の利用も検討してください。
-* `false` に設定した場合、システムデータベースはサーバー起動前に読み込まれます。
-
-**例**
-
-```xml
-true
-```
-
-
-## asynchronous_heavy_metrics_update_period_s {#asynchronous_heavy_metrics_update_period_s}
-
-負荷の高い非同期メトリクスを更新する間隔（秒単位）。
-
-
-
-## asynchronous_insert_log
-
-非同期インサートのログを記録するための [asynchronous_insert_log](/operations/system-tables/asynchronous_insert_log) システムテーブルの設定。
-
-
-
-**例**
-
-```xml
-
-
- system
-
- 7500
- toYYYYMM(event_date)
- 1048576
- 8192
- 524288
- false
-
-
-
-```
-
-
-## asynchronous_metric_log
-
-ClickHouse Cloud のデプロイメントでは、デフォルトで有効になっています。
-
-お使いの環境でこの設定がデフォルトで有効になっていない場合は、ClickHouse のインストール方法に応じて、以下の手順に従って設定を有効化または無効化できます。
-
-**有効化**
-
-非同期メトリックログ履歴の収集 [`system.asynchronous_metric_log`](../../operations/system-tables/asynchronous_metric_log.md) を手動で有効にするには、次の内容で `/etc/clickhouse-server/config.d/asynchronous_metric_log.xml` を作成します。
-
-```xml
-
-
- system
-
- 7500
- 1000
- 1048576
- 8192
- 524288
- false
-
-
-```
-
-**無効化**
-
-`asynchronous_metric_log` 設定を無効にするには、次の内容のファイル `/etc/clickhouse-server/config.d/disable_asynchronous_metric_log.xml` を作成します：
-
-```xml
-
-```
-
-
-
-
-## asynchronous_metrics_enable_heavy_metrics {#asynchronous_metrics_enable_heavy_metrics}
-
-負荷の高い非同期メトリクスの計算を有効にします。
-
-
-
-## asynchronous_metrics_update_period_s {#asynchronous_metrics_update_period_s}
-
-非同期メトリクスの更新間隔（秒）。
-
-
-
-## auth_use_forwarded_address {#auth_use_forwarded_address}
-
-プロキシ経由で接続されたクライアントに対して、認証時に元の発信元アドレスを使用します。
-
-:::note
-転送されたアドレスは容易に偽装できるため、この設定は細心の注意を払って使用する必要があります。そのような認証を受け入れるサーバーには、直接アクセスせず、必ず信頼できるプロキシ経由でのみアクセスするようにしてください。
-:::
-
-
-
-## background_buffer_flush_schedule_pool_size {#background_buffer_flush_schedule_pool_size}
-
-バックグラウンドで [Buffer エンジン](/engines/table-engines/special/buffer) テーブルのフラッシュ処理を実行するために使用されるスレッドの最大数。
-
-
-
-## background_common_pool_size {#background_common_pool_size}
-
-バックグラウンドで [*MergeTree エンジン](/engines/table-engines/mergetree-family) テーブルに対して各種処理（主にガーベジコレクション）を実行するために使用されるスレッド数の最大値。
-
-
-
-## background_distributed_schedule_pool_size {#background_distributed_schedule_pool_size}
-
-分散送信の実行に使用されるスレッド数の上限。
-
-
-
-## background_fetches_pool_size {#background_fetches_pool_size}
-
-バックグラウンドで [*MergeTree-engine](/engines/table-engines/mergetree-family) テーブルの他のレプリカからデータパーツを取得するために使用されるスレッド数の最大値です。
-
-
-
-## background_merges_mutations_concurrency_ratio {#background_merges_mutations_concurrency_ratio}
-
-
-スレッド数に対する、同時に実行できるバックグラウンドのマージおよびミューテーション処理数の比率を設定します。
-
-たとえば、この比率が 2 で、[`background_pool_size`](/operations/server-configuration-parameters/settings#background_pool_size) が 16 に設定されている場合、ClickHouse は 32 個のバックグラウンドマージを同時に実行できます。これは、バックグラウンド処理を一時停止および延期できるためです。これは、小さいマージにより高い実行優先度を与えるために必要です。
-
-:::note
-この比率は実行時には増やすことしかできません。値を下げるにはサーバーを再起動する必要があります。
-
-[`background_pool_size`](/operations/server-configuration-parameters/settings#background_pool_size) 設定と同様に、[`background_merges_mutations_concurrency_ratio`](/operations/server-configuration-parameters/settings#background_merges_mutations_concurrency_ratio) も後方互換性のために `default` プロファイルから適用できます。
-:::
-
-
-
-
-## background_merges_mutations_scheduling_policy {#background_merges_mutations_scheduling_policy}
-
-
-バックグラウンドマージおよびミューテーションのスケジューリング方法を決定するポリシーです。指定可能な値は `round_robin` と `shortest_task_first` です。
-
-バックグラウンドスレッドプールが、次に実行するマージまたはミューテーションを選択する際に用いるアルゴリズムです。ポリシーはサーバーの再起動なしに、実行時に変更できます。
-後方互換性のために `default` プロファイルから適用することができます。
-
-設定可能な値:
-
-- `round_robin` — すべての同時マージおよびミューテーションは、ラウンドロビン順に実行され、飢餓状態が発生しないようにします。小さいマージはマージ対象のブロック数が少ないため、大きいマージよりも速く完了します。
-- `shortest_task_first` — 常にサイズの小さいマージまたはミューテーションを実行します。マージおよびミューテーションには、結果のサイズに基づいて優先度が割り当てられます。サイズの小さいマージは大きいマージよりも厳密に優先されます。このポリシーは小さいパーツを可能な限り速くマージすることを保証しますが、`INSERT` が大量に発生しているパーティションでは、大きなマージが無期限に実行されないまま飢餓状態になる可能性があります。
-
-
-
-
-## background_message_broker_schedule_pool_size {#background_message_broker_schedule_pool_size}
-
-メッセージストリーミングのバックグラウンド処理を実行するために使用されるスレッドの最大数。
-
-
-
-## background_move_pool_size {#background_move_pool_size}
-
-バックグラウンドでデータパーツを別のディスクまたはボリュームに移動する際に使用される、*MergeTree エンジンテーブル用の最大スレッド数です。
-
-
-
-## background_pool_size
-
-
-
-MergeTree エンジンを使用するテーブルに対して、バックグラウンドでマージおよびミューテーションを実行するスレッド数を設定します。
-
-:::note
-
-* この設定は、後方互換性のために、ClickHouse サーバー起動時に `default` プロファイルの設定から適用することもできます。
-* 実行中に変更できるのは、スレッド数を増やす場合のみです。
-* スレッド数を減らすにはサーバーを再起動する必要があります。
-* この設定を調整することで、CPU とディスクの負荷を制御できます。
- :::
-
-:::danger
-プールサイズを小さくすると CPU とディスクのリソース消費は減りますが、バックグラウンド処理の進行が遅くなり、最終的にはクエリ性能に影響を与える可能性があります。
-:::
-
-この値を変更する前に、次のような関連する MergeTree 設定も確認してください。
-
-* [`number_of_free_entries_in_pool_to_lower_max_size_of_merge`](../../operations/settings/merge-tree-settings.md#number_of_free_entries_in_pool_to_lower_max_size_of_merge).
-* [`number_of_free_entries_in_pool_to_execute_mutation`](../../operations/settings/merge-tree-settings.md#number_of_free_entries_in_pool_to_execute_mutation).
-* [`number_of_free_entries_in_pool_to_execute_optimize_entire_partition`](/operations/settings/merge-tree-settings#number_of_free_entries_in_pool_to_execute_optimize_entire_partition)
-
-**例**
-
-```xml
-16
-```
-
-
-## background_schedule_pool_max_parallel_tasks_per_type_ratio {#background_schedule_pool_max_parallel_tasks_per_type_ratio}
-
-同一種別のタスクを同時に実行できる、プール内スレッド数の最大比率。
-
-
-
-## background_schedule_pool_size {#background_schedule_pool_size}
-
-レプリケーテッドテーブル、Kafka ストリーミング、DNS キャッシュの更新などの軽量な定期的処理を継続的に実行するために使用されるスレッドの最大数です。
-
-
-
-## backup_log
-
-`BACKUP` および `RESTORE` 操作を記録するための [backup_log](../../operations/system-tables/backup_log.md) システムテーブル用の設定。
-
-
-
-**例**
-
-```xml
-
-
- system
-
- 1000
- toYYYYMM(event_date)
- 1048576
- 8192
- 524288
- false
-
-
-
-```
-
-
-## backup_threads {#backup_threads}
-
-`BACKUP` リクエストを実行するスレッド数の上限。
-
-
-
-## backups {#backups}
-
-[`BACKUP` および `RESTORE`](../backup.md) ステートメントを実行する際に使用されるバックアップ設定です。
-
-次の設定はサブタグごとに構成できます。
-
-
-
-{/* SQL
- WITH settings AS (
- SELECT arrayJoin([
- ('allow_concurrent_backups', 'Bool','同一ホスト上で複数のバックアップ処理を同時に実行できるかどうかを決定します。', 'true'),
- ('allow_concurrent_restores', 'Bool', '同一ホスト上で複数のリストア処理を同時に実行できるかどうかを決定します。', 'true'),
- ('allowed_disk', 'String', '`File()` を使用する際のバックアップ先ディスクです。この設定は `File` を使用するために必須です。', ''),
- ('allowed_path', 'String', '`File()` を使用する際のバックアップ先パスです。この設定は `File` を使用するために必須です。', ''),
- ('attempts_to_collect_metadata_before_sleep', 'UInt', '収集したメタデータの比較後に不整合があった場合、スリープに入る前にメタデータ収集を試行する回数です。', '2'),
- ('collect_metadata_timeout', 'UInt64', 'バックアップ中にメタデータを収集する際のタイムアウト（ミリ秒）です。', '600000'),
- ('compare_collected_metadata', 'Bool', '`true` の場合、バックアップ中にメタデータが変更されていないことを保証するために、収集したメタデータを既存のメタデータと比較します。', 'true'),
- ('create_table_timeout', 'UInt64', 'リストア中にテーブルを作成する際のタイムアウト（ミリ秒）です。', '300000'),
- ('max_attempts_after_bad_version', 'UInt64', '協調バックアップ／リストア中に bad version エラーが発生した後にリトライを行う最大試行回数です。', '3'),
- ('max_sleep_before_next_attempt_to_collect_metadata', 'UInt64', '次回のメタデータ収集を試行する前にスリープする最大時間（ミリ秒）です。', '100'),
- ('min_sleep_before_next_attempt_to_collect_metadata', 'UInt64', '次回のメタデータ収集を試行する前にスリープする最小時間（ミリ秒）です。', '5000'),
- ('remove_backup_files_after_failure', 'Bool', '`BACKUP` コマンドが失敗した場合、ClickHouse は失敗前にバックアップへコピー済みのファイルを削除しようとします。そうしない場合、コピー済みファイルはそのまま残ります。', 'true'),
- ('sync_period_ms', 'UInt64', '協調バックアップ／リストアの同期間隔（ミリ秒）です。', '5000'),
- ('test_inject_sleep', 'Bool', 'テスト用途のスリープ挿入設定です。', 'false'),
- ('test_randomize_order', 'Bool', '`true` の場合、テスト目的で特定の処理順序をランダム化します。', 'false'),
- ('zookeeper_path', 'String', '`ON CLUSTER` 句を使用する場合に、バックアップおよびリストアのメタデータが保存される ZooKeeper 上のパスです。', '/clickhouse/backups')
- ]) AS t )
- SELECT concat('`', t.1, '`') AS Setting, t.2 AS Type, t.3 AS Description, concat('`', t.4, '`') AS Default FROM settings FORMAT Markdown
+{/* NOTE: このファイル内の設定は自動生成されています。
+ 詳細については、次を参照してください: ["Generating documentation from source code"](https://github.com/ClickHouse/clickhouse-docs/blob/main/contribute/autogenerated-documentation-from-source.md)
*/ }
-
-| 設定 | 型 | 概要 | デフォルト |
-| :-------------------------------------------------- | :-------- | :---------------------------------------------------------------------------------------------------- | :-------------------- |
-| `allow_concurrent_backups` | Bool | 同一ホスト上で複数のバックアップ処理を同時に実行できるかどうかを制御します。 | `true` |
-| `allow_concurrent_restores` | Bool（ブール） | 同一ホストで複数の復元処理を並行実行できるかどうかを指定します。 | `true` |
-| `allowed_disk` | 文字列 | `File()` を使用する際にバックアップ先として利用するディスク。この設定を行わないと `File()` は使用できません。 | `` |
-| `allowed_path` | String | `File()` 使用時のバックアップ先パス。この設定を指定しないと `File` は使用できません。 | `` |
-| `attempts_to_collect_metadata_before_sleep` | UInt | 収集したメタデータを比較して不整合があった場合に、スリープに入る前にメタデータの収集を再試行する回数。 | `2` |
-| `collect_metadata_timeout` | UInt64 | バックアップ時のメタデータ収集のタイムアウト（ミリ秒単位）。 | `600000` |
-| `compare_collected_metadata` | Bool | true の場合、収集したメタデータを既存のメタデータと比較し、バックアップ中に変更されていないことを検証します。 | `true` |
-| `create_table_timeout` | UInt64 | 復元中のテーブル作成タイムアウト（ミリ秒）。 | `300000` |
-| `max_attempts_after_bad_version` | UInt64 | 協調バックアップ／リストア処理中に「bad version」エラーが発生した場合に行う再試行の最大回数。 | `3` |
-| `max_sleep_before_next_attempt_to_collect_metadata` | UInt64 | 次回のメタデータ収集試行までの最大スリープ時間（ミリ秒）。 | `100` |
-| `min_sleep_before_next_attempt_to_collect_metadata` | UInt64 | 次のメタデータ収集を試行するまでの最小スリープ時間（ミリ秒）。 | `5000` |
-| `remove_backup_files_after_failure` | Bool | `BACKUP` コマンドが失敗した場合、ClickHouse は失敗が発生する前にバックアップにコピーされたファイルを削除しようとしますが、削除できなかったファイルについてはコピーされたまま残します。 | `true` |
-| `sync_period_ms` | UInt64 | バックアップ／リストアを連携して実行するための同期間隔（ミリ秒単位）。 | `5000` |
-| `test_inject_sleep` | Bool | テスト用スリープ処理 | `false` |
-| `test_randomize_order` | Bool | true に設定すると、テスト目的で一部の操作の実行順序をランダム化します。 | `false` |
-| `zookeeper_path` | String | `ON CLUSTER` 句使用時に、バックアップおよびリストアのメタデータが保存される ZooKeeper 内のパス。 | `/clickhouse/backups` |
-
-この設定はデフォルトで次のように構成されています：
-
-```xml
-
- ....
-
-```
-
-
-## backups_io_thread_pool_queue_size {#backups_io_thread_pool_queue_size}
-
-
-Backups IO Thread プールにスケジュールできるジョブの最大数です。現在の S3 バックアップのロジック上、このキューは無制限のままにしておくことが推奨されます。
-
-:::note
-`0`（デフォルト）の値は無制限を意味します。
-:::
-
-
-
-
-## bcrypt_workfactor
-
-`bcrypt_password` 認証タイプで使用される [Bcrypt アルゴリズム](https://wildlyinaccurate.com/bcrypt-choosing-a-work-factor/) のワークファクタです。
-ワークファクタは、ハッシュの計算およびパスワード検証に必要な計算量と時間を定義します。
-
-```xml
-12
-```
-
-:::warning
-認証処理を頻繁に行うアプリケーションでは、
-高いワークファクター設定時の bcrypt の計算コストを考慮し、
-別の認証方式の利用を検討してください。
-:::
-
-
-## blob_storage_log
-
-[`blob_storage_log`](../system-tables/blob_storage_log.md) システムテーブルに関する設定です。
-
-
-
-例：
-
-```xml
-
- systemblob_storage_log
toYYYYMM(event_date)
- 7500event_date + INTERVAL 30 DAY
-
-```
-
-
-## builtin_dictionaries_reload_interval
-
-組み込みディクショナリを再読み込みするまでの間隔を秒単位で指定します。
-
-ClickHouse は、組み込みディクショナリを x 秒ごとに再読み込みします。これにより、サーバーを再起動することなくディクショナリを即時に編集できます。
-
-**例**
-
-```xml
-3600
-```
-
-
-## cache_size_to_ram_max_ratio {#cache_size_to_ram_max_ratio}
-
-キャッシュサイズを RAM の最大値に対する比率として設定します。メモリ容量の小さいシステムでキャッシュサイズを小さく抑えることができます。
-
-
-
-## cannot_allocate_thread_fault_injection_probability {#cannot_allocate_thread_fault_injection_probability}
-
-テスト目的のための設定です。
-
-
-
-## cgroups_memory_usage_observer_wait_time {#cgroups_memory_usage_observer_wait_time}
-
-
-サーバーの最大許容メモリ使用量を、cgroups 内の対応するしきい値に基づいて調整する際の、秒単位の間隔。
-
-cgroup オブザーバーを無効にするには、この値を `0` に設定します。
-
-
-
-
-## compiled_expression_cache_elements_size {#compiled_expression_cache_elements_size}
-
-[コンパイル済み式](../../operations/caches.md)用キャッシュのサイズ（要素数）を設定します。
-
-
-
-## compiled_expression_cache_size {#compiled_expression_cache_size}
-
-[コンパイル済み式](../../operations/caches.md)のキャッシュサイズをバイト単位で設定します。
-
-
-
-## compression
-
-[MergeTree](../../engines/table-engines/mergetree-family/mergetree.md) エンジンのテーブルに対するデータ圧縮設定です。
-
-:::note
-ClickHouse を使い始めたばかりの場合は、この設定は変更しないことをお勧めします。
-:::
-
-**設定テンプレート**:
-
-```xml
-
-
- ...
- ...
- ...
- ...
-
- ...
-
-```
-
-**`` フィールド**:
-
-* `min_part_size` – データパートの最小サイズ。
-* `min_part_size_ratio` – データパートサイズとテーブルサイズの比率。
-* `method` – 圧縮方式。指定可能な値: `lz4`, `lz4hc`, `zstd`, `deflate_qpl`。
-* `level` – 圧縮レベル。[Codecs](/sql-reference/statements/create/table#general-purpose-codecs) を参照。
-
-:::note
-複数の `` セクションを設定できます。
-:::
-
-**条件が満たされたときの動作**:
-
-* データパートがいずれかの条件セットに一致した場合、ClickHouse は指定された圧縮方式を使用します。
-* データパートが複数の条件セットに一致した場合、ClickHouse は最初に一致した条件セットを使用します。
-
-:::note
-データパートに対していずれの条件も満たされない場合、ClickHouse は `lz4` 圧縮を使用します。
-:::
-
-**例**
-
-```xml
-
-
- 10000000000
- 0.01
- zstd
- 1
-
-
-```
-
-
-## concurrent_threads_scheduler {#concurrent_threads_scheduler}
-
-
-`concurrent_threads_soft_limit_num` と `concurrent_threads_soft_limit_ratio_to_cores` で指定された CPU スロットをどのようにスケジューリングするかを決定するポリシーです。制限された数の CPU スロットを同時実行クエリ間でどのように分配するかを制御するアルゴリズムでもあります。スケジューラは、サーバーを再起動することなく実行時に変更できます。
-
-設定可能な値:
-
-- `round_robin` — `use_concurrency_control` = 1 に設定された各クエリは、最大で `max_threads` 個の CPU スロットを確保します。スレッドごとに 1 スロットです。競合が発生した場合、CPU スロットはクエリ間でラウンドロビン方式で割り当てられます。最初のスロットは無条件に付与される点に注意してください。このため、多数の `max_threads` = 1 のクエリが存在する状況では、`max_threads` が大きいクエリが不公平に扱われ、レイテンシーが増加する可能性があります。
-- `fair_round_robin` — `use_concurrency_control` = 1 に設定された各クエリは、最大で `max_threads - 1` 個の CPU スロットを確保します。各クエリの最初のスレッドには CPU スロットを必要としないという点で、`round_robin` のバリエーションです。これにより、`max_threads` = 1 のクエリはスロットを一切必要とせず、不公平に全スロットを占有してしまうことがなくなります。無条件に付与されるスロットは存在しません。
-
-
-
-
-## concurrent_threads_soft_limit_num {#concurrent_threads_soft_limit_num}
-
-
-リモートサーバーからデータを取得するスレッドを除き、すべてのクエリで使用できるクエリ処理スレッドの最大数です。これはハードリミットではありません。制限に達した場合でも、そのクエリには少なくとも 1 つのスレッドが割り当てられて実行されます。より多くのスレッドが利用可能になった場合、実行中のクエリは必要なスレッド数までスケールアップできます。
-
-:::note
-`0`（デフォルト）の場合は無制限を意味します。
-:::
-
-
-
-
-## concurrent_threads_soft_limit_ratio_to_cores {#concurrent_threads_soft_limit_ratio_to_cores}
-
-[`concurrent_threads_soft_limit_num`](#concurrent_threads_soft_limit_num) と同様ですが、コア数に対する比率として指定します。
-
-
-
-## config_reload_interval_ms {#config_reload_interval_ms}
-
-
-ClickHouse が設定を再読み込みし、新しい変更の有無を確認する間隔
-
-
-
-
-## core_dump
-
-コアダンプファイルサイズのソフトリミットを設定します。
-
-:::note
-ハードリミットはシステムツールで構成します
-:::
-
-**例**
-
-```xml
-
- 1073741824
-
-```
-
-
-## cpu_slot_preemption
-
-
-
-CPU リソース（MASTER THREAD と WORKER THREAD）のワークロードスケジューリング方法を定義します。
-
-* `true`（推奨）の場合、実際に消費された CPU 時間に基づいて使用状況の計測が行われます。競合するワークロードに対して、公平な量の CPU 時間が割り当てられます。スロットは一定時間のみ割り当てられ、有効期限後に再度要求されます。CPU リソースが過負荷の場合、スロット要求がスレッド実行をブロックすることがあり、つまりプリエンプションが発生する可能性があります。これにより CPU 時間の公平性が確保されます。
-* `false`（デフォルト）の場合、計測は割り当てられた CPU スロット数に基づいて行われます。競合するワークロードに対して、公平な数の CPU スロットが割り当てられます。スレッド開始時にスロットが割り当てられ、スレッドの実行が終了するまで継続的に保持され、その後解放されます。クエリ実行に割り当てられるスレッド数は 1 から `max_threads` までしか増加せず、減少することはありません。これは長時間実行されるクエリに有利に働き、短時間クエリが CPU リソースの飢餓状態に陥る可能性があります。
-
-**例**
-
-```xml
-true
-```
-
-**関連項目**
-
-* [Workload Scheduling](/operations/workload-scheduling.md)
-
-
-## cpu_slot_preemption_timeout_ms
-
-
-
-プリエンプション中、つまり別の CPU スロットが付与されるのを待つ間に、ワーカースレッドが待機できる時間（ミリ秒）を定義します。このタイムアウト後も新しい CPU スロットを取得できなかった場合、そのスレッドは終了し、クエリは同時実行スレッド数がより少ない状態へ動的にスケールダウンされます。マスタースレッド自体がスケールダウンされることはありませんが、無期限にプリエンプトされる可能性がある点に注意してください。`cpu_slot_preemption` が有効であり、かつ WORKER THREAD に対して CPU リソースが定義されている場合にのみ意味を持ちます。
-
-**例**
-
-```xml
-1000
-```
-
-**関連項目**
-
-* [Workload Scheduling](/operations/workload-scheduling.md)
-
-
-## cpu_slot_quantum_ns
-
-
-
-これは、スレッドが CPU スロットを取得してから、別の CPU スロットを再度要求するまでに消費できる CPU ナノ秒数を定義します。`cpu_slot_preemption` が有効であり、かつ MASTER THREAD または WORKER THREAD に CPU リソースが定義されている場合にのみ有効です。
-
-**例**
-
-```xml
-10000000
-```
-
-**関連項目**
-
-* [ワークロードのスケジューリング](/operations/workload-scheduling.md)
-
-
-## crash_log
-
-[crash_log](../../operations/system-tables/crash_log.md) システムテーブルの動作に関する設定です。
-
-以下の設定はサブタグで構成できます。
-
-| Setting | Description | Default | Note |
-| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------- | ----------------------------------------------------------------------------------- |
-| `database` | データベース名。 | | |
-| `table` | システムテーブル名。 | | |
-| `engine` | システムテーブル用の [MergeTree エンジン定義](/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-creating-a-table)。 | | `partition_by` または `order_by` が定義されている場合は使用できません。指定しない場合、デフォルトで `MergeTree` が選択されます |
-| `partition_by` | システムテーブル用の [カスタムパーティショニングキー](/engines/table-engines/mergetree-family/custom-partitioning-key.md)。 | | システムテーブルに対して `engine` を指定する場合、`partition_by` パラメータは直接 `engine` 内で指定する必要があります |
-| `ttl` | テーブルの [TTL](/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-ttl) を指定します。 | | システムテーブルに対して `engine` を指定する場合、`ttl` パラメータは直接 `engine` 内で指定する必要があります |
-| `order_by` | システムテーブル用の [カスタムソートキー](/engines/table-engines/mergetree-family/mergetree#order_by)。`engine` が定義されている場合は使用できません。 | | システムテーブルに対して `engine` を指定する場合、`order_by` パラメータは直接 `engine` 内で指定する必要があります |
-| `storage_policy` | テーブルに使用するストレージポリシー名（任意）。 | | システムテーブルに対して `engine` を指定する場合、`storage_policy` パラメータは直接 `engine` 内で指定する必要があります |
-| `settings` | MergeTree の動作を制御する [追加パラメータ](/engines/table-engines/mergetree-family/mergetree/#settings)（任意）。 | | システムテーブルに対して `engine` を指定する場合、`settings` パラメータは直接 `engine` 内で指定する必要があります |
-| `flush_interval_milliseconds` | メモリ上のバッファからテーブルへデータをフラッシュする間隔。 | `7500` | |
-| `max_size_rows` | ログの最大行数。未フラッシュのログ数が `max_size_rows` に達すると、ログがディスクにダンプされます。 | `1024` | |
-| `reserved_size_rows` | ログ用に事前に確保しておくメモリサイズ（行数）。 | `1024` | |
-| `buffer_size_rows_flush_threshold` | 行数に対するしきい値。このしきい値に達すると、バックグラウンドでログのディスクへのフラッシュが実行されます。 | `max_size_rows / 2` | |
-| `flush_on_crash` | クラッシュ時にログをディスクへダンプするかどうかを設定します。 | `false` | |
-
-デフォルトのサーバー設定ファイル `config.xml` には、次の設定セクションが含まれています。
-
-```xml
-
- system
-
- toYYYYMM(event_date)
- 7500
- 1024
- 1024
- 512
- false
-
-```
-
-
-## custom_cached_disks_base_directory
-
-この設定は、カスタム（SQL から作成された）キャッシュディスクのキャッシュパスを指定します。
-`custom_cached_disks_base_directory` はカスタムディスクに対して `filesystem_caches_path`（`filesystem_caches_path.xml` 内にあります）よりも高い優先度を持ち、
-前者が存在しない場合に後者が使用されます。
-ファイルシステムキャッシュのパスは必ずこのディレクトリ配下でなければなりません。
-そうでない場合は、ディスクの作成を防ぐために例外がスローされます。
-
-:::note
-これは、サーバーのアップグレード前に古いバージョンで作成されたディスクには影響しません。
-この場合、サーバーが正常に起動できるように、例外はスローされません。
-:::
-
-例:
-
-```xml
-/var/lib/clickhouse/caches/
-```
-
-
-## custom_settings_prefixes
-
-[カスタム設定](/operations/settings/query-level#custom_settings)用のプレフィックスの一覧です。複数指定する場合はカンマ区切りで指定します。
-
-**例**
-
-```xml
-custom_
-```
-
-**関連項目**
-
-* [カスタム設定](/operations/settings/query-level#custom_settings)
-
-
-## database_atomic_delay_before_drop_table_sec {#database_atomic_delay_before_drop_table_sec}
-
-
-[`UNDROP`](/sql-reference/statements/undrop.md) ステートメントを使用して削除されたテーブルを復元できる猶予時間です。`DROP TABLE` が `SYNC` 修飾子付きで実行された場合、この設定は無視されます。
-この設定のデフォルト値は `480`（8 分）です。
-
-
-
-
-## database_catalog_drop_error_cooldown_sec {#database_catalog_drop_error_cooldown_sec}
-
-テーブルの削除に失敗した場合、ClickHouse はこのタイムアウト時間が経過するまで待機してから操作を再試行します。
-
-
-
-## database_catalog_drop_table_concurrency {#database_catalog_drop_table_concurrency}
-
-テーブルを削除する際に使用されるスレッドプールのサイズ。
-
-
-
-## database_catalog_unused_dir_cleanup_period_sec {#database_catalog_unused_dir_cleanup_period_sec}
-
-
-`store/` ディレクトリから不要なデータをクリーンアップするタスクのパラメータです。
-このタスクの実行間隔（スケジューリング周期）を設定します。
-
-:::note
-`0` を指定するとタスクは実行されません。デフォルト値は 1 日に相当します。
-:::
-
-
-
-
-## database_catalog_unused_dir_hide_timeout_sec {#database_catalog_unused_dir_hide_timeout_sec}
-
-
-`store/` ディレクトリから不要なデータをクリーンアップするタスクのパラメータです。
-あるサブディレクトリが clickhouse-server によって使用されておらず、かつ直近
-[`database_catalog_unused_dir_hide_timeout_sec`](/operations/server-configuration-parameters/settings#database_catalog_unused_dir_hide_timeout_sec) 秒の間に更新されていない場合、このタスクはそのディレクトリの
-すべてのアクセス権を削除することで、そのディレクトリを「非表示」にします。これは、clickhouse-server が
-`store/` 内に存在することを想定していないディレクトリにも適用されます。
-
-:::note
-`0` の値は「即時」を意味します。
-:::
-
-
-
-
-## database_catalog_unused_dir_rm_timeout_sec {#database_catalog_unused_dir_rm_timeout_sec}
-
-
-`store/` ディレクトリから不要なディレクトリをクリーンアップするタスクのパラメータです。
-サブディレクトリが clickhouse-server によって使用されておらず、以前に「非表示」
-（[database_catalog_unused_dir_hide_timeout_sec](/operations/server-configuration-parameters/settings#database_catalog_unused_dir_hide_timeout_sec) を参照）
-にされていて、そのディレクトリが直近
-[`database_catalog_unused_dir_rm_timeout_sec`](/operations/server-configuration-parameters/settings#database_catalog_unused_dir_rm_timeout_sec) 秒間変更されていない場合、このタスクはそのディレクトリを削除します。
-また、clickhouse-server が
-`store/` 内に存在することを想定していないディレクトリに対しても動作します。
-
-:::note
-値が `0` の場合は「削除しない（無期限に保持する）」ことを意味します。デフォルト値は 30 日に相当します。
-:::
-
-
-
-
-## database_replicated_allow_detach_permanently {#database_replicated_allow_detach_permanently}
-
-Replicated データベースでテーブルを恒久的にデタッチできるようにします
-
-
-
-## database_replicated_drop_broken_tables {#database_replicated_drop_broken_tables}
-
-予期しないテーブルを、別のローカルデータベースに移動するのではなく Replicated データベースから削除します
-
-
-
-## dead_letter_queue
-
-「dead_letter_queue」システムテーブルの設定です。
-
-
-
-デフォルトの設定は次のとおりです。
-
-```xml
-
- system
-
- toYYYYMM(event_date)
- 7500
-
-```
-
-
-## default_database {#default_database}
-
-デフォルトのデータベース名です。
-
-
-
-## default_password_type
-
-`CREATE USER u IDENTIFIED BY 'p'` のようなクエリで、自動的に使用されるパスワードの種類を指定します。
-
-指定可能な値は次のとおりです:
-
-* `plaintext_password`
-* `sha256_password`
-* `double_sha1_password`
-* `bcrypt_password`
-
-```xml
-sha256_password
-```
-
-
-## default_profile
-
-既定の設定プロファイルです。設定プロファイルは、設定 `user_config` で指定されたファイルに定義されています。
-
-**例**
-
-```xml
-default
-```
-
-
-## default_replica_name
-
-
-
-ZooKeeper 上のレプリカ名。
-
-**例**
-
-```xml
-{replica}
-```
-
-
-## default_replica_path
-
-
-
-ZooKeeper 上のテーブルへのパス。
-
-**例**
-
-```xml
-/clickhouse/tables/{uuid}/{shard}
-```
-
-
-## default_session_timeout
-
-セッションのデフォルトタイムアウト時間（秒単位）。
-
-```xml
-60
-```
-
-
-## dictionaries_config
-
-ディクショナリ設定ファイルへのパス。
-
-パス:
-
-* 絶対パス、またはサーバー設定ファイルからの相対パスを指定します。
-* パスにはワイルドカードの * や ? を含めることができます。
-
-関連項目:
-
-* "[Dictionaries](../../sql-reference/dictionaries/index.md)"。
-
-**例**
-
-```xml
-*_dictionary.xml
-```
-
-
-## dictionaries_lazy_load
-
-
-
-ディクショナリを遅延ロードします。
-
-* `true` の場合、各ディクショナリは最初に使用されたときに読み込まれます。読み込みに失敗した場合、そのディクショナリを使用していた関数は例外をスローします。
-* `false` の場合、サーバーは起動時にすべてのディクショナリを読み込みます。
-
-:::note
-サーバーは、すべてのディクショナリの読み込みが完了するまで起動時に待機し、それまでは接続を受け付けません
-（例外: [`wait_dictionaries_load_at_startup`](/operations/server-configuration-parameters/settings#wait_dictionaries_load_at_startup) が `false` に設定されている場合）。
-:::
-
-**例**
-
-```xml
-true
-```
-
-
-## dictionary_background_reconnect_interval {#dictionary_background_reconnect_interval}
-
-`background_reconnect` が有効になっている、接続に失敗した MySQL および Postgres 辞書に対して行う再接続試行の間隔（ミリ秒単位）。
-
-
-
-## disable_insertion_and_mutation {#disable_insertion_and_mutation}
-
-
-`INSERT`/`ALTER`/`DELETE` クエリを無効化します。読み取り専用ノードが必要で、挿入やミューテーションが読み取りパフォーマンスに影響するのを防ぎたい場合に、この設定を有効化します。この設定が有効な場合でも、外部エンジン（S3、DataLake、MySQL、PostgreSQL、Kafka など）への `INSERT` は許可されます。
-
-
-
-
-## disable_internal_dns_cache {#disable_internal_dns_cache}
-
-内部 DNS キャッシュを無効にします。Kubernetes など、インフラが頻繁に変化するシステムで ClickHouse を運用する場合に推奨されます。
-
-
-
-## disable_tunneling_for_https_requests_over_http_proxy
-
-デフォルトでは、`HTTP` プロキシ経由で `HTTPS` リクエストを送信する際、トンネリング（つまり `HTTP CONNECT`）が使用されます。この設定でトンネリングを無効化できます。
-
-**no_proxy**
-
-デフォルトでは、すべてのリクエストがプロキシを経由します。特定のホストに対してプロキシ経由を無効化するには、`no_proxy` 変数を設定する必要があります。
-これは、list resolver と remote resolver では `` 句の中で、environment resolver では環境変数として設定できます。
-IP アドレス、ドメイン、サブドメインに加え、完全にバイパスするためのワイルドカード `'*'` をサポートします。curl と同様に、先頭のドットは取り除かれます。
-
-**Example**
-
-次の設定では、`clickhouse.cloud` およびそのすべてのサブドメイン（例: `auth.clickhouse.cloud`）へのリクエストはプロキシを経由しません。
-GitLab に対しても同様で、先頭にドットが付いていても同じ挙動になります。`gitlab.com` と `about.gitlab.com` の両方がプロキシをバイパスします。
-
-```xml
-
- clickhouse.cloud,.gitlab.com
-
- http://proxy1
- http://proxy2:3128
-
-
- http://proxy1:3128
-
-
-```
-
-
-## disk_connections_soft_limit {#disk_connections_soft_limit}
-
-この制限を超える接続は、保持期間が大幅に短くなります。この制限はディスクへの接続に適用されます。
-
-
-
-## disk_connections_store_limit {#disk_connections_store_limit}
-
-この上限を超えると、使用後に接続はリセットされます。接続キャッシュを無効にするには 0 を設定します。この上限はディスク接続に適用されます。
-
-
-
-## disk_connections_warn_limit {#disk_connections_warn_limit}
-
-使用中の接続数がこの制限を超えると、警告メッセージがログに書き込まれます。この制限はディスクへの接続に適用されます。
-
-
-
-## display_secrets_in_show_and_select {#display_secrets_in_show_and_select}
-
-
-テーブル、データベース、テーブル関数、およびディクショナリに対する `SHOW` および `SELECT` クエリでシークレットを表示するかどうかを切り替えます。
-
-シークレットを表示したいユーザーは、
-[`format_display_secrets_in_show_and_select` フォーマット設定](../settings/formats#format_display_secrets_in_show_and_select)
-を有効にし、
-[`displaySecretsInShowAndSelect`](/sql-reference/statements/grant#displaysecretsinshowandselect) 権限
-を付与されている必要があります。
-
-設定可能な値:
-
-- `0` — 無効。
-- `1` — 有効。
-
-
-
-
-## distributed_cache_apply_throttling_settings_from_client {#distributed_cache_apply_throttling_settings_from_client}
-
-キャッシュサーバーがクライアントから受信したスロットリング設定を適用するかどうか。
-
-
-
-## distributed_cache_keep_up_free_connections_ratio {#distributed_cache_keep_up_free_connections_ratio}
-
-分散キャッシュが空き状態として確保しておこうとするアクティブ接続数のソフトリミットです。空き接続数が distributed_cache_keep_up_free_connections_ratio * max_connections を下回ると、空き接続数がこの閾値を上回るまで、最後にアクティビティが発生してからの経過時間が最も長い接続から順に閉じられます。
-
-
-
-## distributed_ddl
-
-クラスタ上で [分散 DDL クエリ](../../sql-reference/distributed-ddl.md)（`CREATE`、`DROP`、`ALTER`、`RENAME`）の実行を管理します。
-[ZooKeeper](/operations/server-configuration-parameters/settings#zookeeper) が有効化されている場合にのみ機能します。
-
-`` 内で設定可能な項目は次のとおりです。
-
-| Setting | Description | Default Value |
-| ---------------------- | ----------------------------------------------------------------------------------- | ----------------------------- |
-| `path` | DDL クエリ用の `task_queue` に対応する Keeper 上のパス | |
-| `profile` | DDL クエリの実行に使用されるプロファイル | |
-| `pool_size` | 同時に実行できる `ON CLUSTER` クエリの数 | |
-| `max_tasks_in_queue` | キュー内に保持できるタスクの最大数 | `1,000` |
-| `task_max_lifetime` | ノードの存続時間がこの値を超えた場合に、そのノードを削除します。 | `7 * 24 * 60 * 60`（秒換算で 1 週間） |
-| `cleanup_delay_period` | 直近のクリーンアップが `cleanup_delay_period` 秒よりも前に実行されている場合に、新しいノードイベントを受信した後でクリーンアップを開始します。 | `60` 秒 |
-
-**例**
-
-```xml
-
-
- /clickhouse/task_queue/ddl
-
-
- default
-
-
- 1
-
-
-
-
- 604800
-
-
- 60
-
-
- 1000
-
-```
-
-
-## distributed_ddl_use_initial_user_and_roles {#distributed_ddl_use_initial_user_and_roles}
-
-有効にすると、ON CLUSTER クエリはリモートシャード上での実行時に、実行元のユーザーおよびロールを保持して使用します。これによりクラスタ全体で一貫したアクセス制御が実現されますが、そのユーザーおよびロールがすべてのノードに存在している必要があります。
-
-
-
-## dns_allow_resolve_names_to_ipv4 {#dns_allow_resolve_names_to_ipv4}
-
-ホスト名を IPv4 アドレスに解決することを許可します。
-
-
-
-## dns_allow_resolve_names_to_ipv6 {#dns_allow_resolve_names_to_ipv6}
-
-IPv6 アドレスへの名前解決を許可します。
-
-
-
-## dns_cache_max_entries {#dns_cache_max_entries}
-
-内部 DNS キャッシュに格納されるエントリの最大数。
-
-
-
-## dns_cache_update_period {#dns_cache_update_period}
-
-内部 DNS キャッシュの更新間隔（秒）。
-
-
-
-## dns_max_consecutive_failures {#dns_max_consecutive_failures}
-
-あるホスト名が ClickHouse の DNS キャッシュから削除されるまでに許容される DNS 解決失敗の最大回数。
-
-
-
-## drop_distributed_cache_pool_size {#drop_distributed_cache_pool_size}
-
-分散キャッシュを削除する際に使用されるスレッドプールのサイズ。
-
-
-
-## drop_distributed_cache_queue_size {#drop_distributed_cache_queue_size}
-
-分散キャッシュの削除に使用されるスレッドプールのキューサイズ。
-
-
-
-## enable_azure_sdk_logging {#enable_azure_sdk_logging}
-
-Azure SDK からのログ出力を有効にします
-
-
-
-## encryption
-
-[encryption codecs](/sql-reference/statements/create/table#encryption-codecs) で使用するキーを取得するためのコマンドを構成します。キー（複数可）は環境変数で指定するか、設定ファイルで設定する必要があります。
-
-キーは長さ 16 バイトの 16 進数値または文字列でなければなりません。
-
-**例**
-
-設定ファイルから読み込む場合:
-
-```xml
-
-
- 1234567812345678
-
-
-```
-
-:::note
-キーを設定ファイルに保存することは推奨されません。安全ではないためです。キーは安全なディスク上の別の設定ファイルに移動し、その設定ファイルへのシンボリックリンクを `config.d/` フォルダに配置できます。
-:::
-
-キーが16進数表現である場合の、設定ファイルからの読み込み:
-
-```xml
-
-
- 00112233445566778899aabbccddeeff
-
-
-```
-
-環境変数からキーを読み込む:
-
-```xml
-
-
-
-
-
-```
-
-ここでは `current_key_id` で暗号化に使用する現在のキーを指定し、指定したすべてのキーを復号に使用できます。
-
-これらの各手法は、複数のキーに対して適用できます。
-
-```xml
-
-
- 00112233445566778899aabbccddeeff
-
- 1
-
-
-```
-
-ここで `current_key_id` は、暗号化に使用されている現在のキーを示します。
-
-また、ユーザーは長さ 12 バイトの nonce を追加できます（デフォルトでは、暗号化および復号処理では、すべてゼロバイトの nonce が使用されます）:
-
-```xml
-
-
- 012345678910
-
-
-```
-
-または 16進数で指定できます：
-
-```xml
-
-
- abcdefabcdef
-
-
-```
-
-:::note
-上記で説明した内容は、`aes_256_gcm_siv` にもすべて適用できます（ただしキーは 32 バイトである必要があります）。
-:::
-
-
-## error_log
-
-デフォルトでは無効になっています。
-
-**有効化**
-
-エラー履歴の収集 [`system.error_log`](../../operations/system-tables/error_log.md) を手動で有効にするには、次の内容で `/etc/clickhouse-server/config.d/error_log.xml` を作成します。
-
-```xml
-
-
- system
-
- 7500
- 1000
- 1048576
- 8192
- 524288
- false
-
-
-```
-
-**無効化**
-
-`error_log` 設定を無効化するには、次の内容で `/etc/clickhouse-server/config.d/disable_error_log.xml` ファイルを作成します。
-
-```xml
-
-
-
-```
-
-
-
-
-## format_parsing_thread_pool_queue_size {#format_parsing_thread_pool_queue_size}
-
-
-入力のパース用スレッドプールにスケジュールできるジョブの最大数。
-
-:::note
-`0` の値は無制限を意味します。
-:::
-
-
-
-
-## format_schema_path
-
-[CapnProto](/interfaces/formats/CapnProto) フォーマットなどの入力データ用スキーマファイルを含むディレクトリへのパスです。
-
-**例**
-
-```xml
-
-format_schemas/
-```
-
-
-## global_profiler_cpu_time_period_ns {#global_profiler_cpu_time_period_ns}
-
-グローバルプロファイラにおける CPU クロックタイマーの周期（ナノ秒単位）です。CPU クロックグローバルプロファイラを無効にするには、値 0 を設定します。推奨値は、単一クエリのプロファイリングには少なくとも 10000000（1 秒間に 100 回）、クラスタ全体のプロファイリングには 1000000000（1 秒に 1 回）です。
-
-
-
-## global_profiler_real_time_period_ns {#global_profiler_real_time_period_ns}
-
-グローバルプロファイラの実時間クロックタイマーの周期（ナノ秒単位）。実時間グローバルプロファイラを無効にするには、値を 0 に設定します。推奨値は、単一クエリの場合は少なくとも 10000000（1 秒あたり 100 回）、クラスタ全体のプロファイリングの場合は 1000000000（1 秒に 1 回）です。
-
-
-
-## google_protos_path
-
-Protobuf 型の proto ファイルを含むディレクトリを指定します。
-
-例:
-
-```xml
-/usr/share/clickhouse/protos/
-```
-
-
-## graphite
-
-[Graphite](https://github.com/graphite-project) へデータを送信します。
-
-設定:
-
-* `host` – Graphite サーバー。
-* `port` – Graphite サーバーのポート。
-* `interval` – 送信間隔（秒）。
-* `timeout` – データ送信のタイムアウト（秒）。
-* `root_path` – キーのプレフィックス。
-* `metrics` – [system.metrics](/operations/system-tables/metrics) テーブルからデータを送信。
-* `events` – [system.events](/operations/system-tables/events) テーブルから、指定期間に蓄積された差分データを送信。
-* `events_cumulative` – [system.events](/operations/system-tables/events) テーブルから累積データを送信。
-* `asynchronous_metrics` – [system.asynchronous_metrics](/operations/system-tables/asynchronous_metrics) テーブルからデータを送信。
-
-複数の `` 句を設定できます。たとえば、異なるデータを異なる間隔で送信する用途に利用できます。
-
-**例**
-
-```xml
-
- localhost
- 42000
- 0.1
- 60
- one_min
- true
- true
- false
- true
-
-```
-
-
-## graphite_rollup
-
-Graphite のデータを間引くための設定です。
-
-詳細については、[GraphiteMergeTree](../../engines/table-engines/mergetree-family/graphitemergetree.md) を参照してください。
-
-**例**
-
-```xml
-
-
- max
-
- 0
- 60
-
-
- 3600
- 300
-
-
- 86400
- 3600
-
-
-
-```
-
-
-## hsts_max_age
-
-HSTS の有効期限を秒単位で指定します。
-
-:::note
-`0` を指定すると、ClickHouse は HSTS を無効化します。正の数値を設定すると HSTS が有効化され、max-age は設定した数値になります。
-:::
-
-**例**
-
-```xml
-600000
-```
-
-
-## http_connections_soft_limit {#http_connections_soft_limit}
-
-この制限を超えた接続は、有効期間が大幅に短くなります。この制限は、いずれのディスクやストレージにも属さない HTTP 接続に適用されます。
-
-
-
-## http_connections_store_limit {#http_connections_store_limit}
-
-この制限を超えた接続は、使用後にリセットされます。接続キャッシュを無効にするには 0 を設定します。この制限は、いずれのディスクやストレージにも紐づけられていない HTTP 接続に適用されます。
-
-
-
-## http_connections_warn_limit {#http_connections_warn_limit}
-
-使用中の接続数がこの制限値を超えた場合、警告メッセージがログに書き込まれます。この制限は、ディスクやストレージのいずれにも属さない HTTP 接続に適用されます。
-
-
-
-## http_handlers
-
-カスタム HTTP ハンドラーを使用できるようにします。
-新しい HTTP ハンドラーを追加するには、新しい `` を追加するだけです。
-ルールは定義された順に上からチェックされ、
-最初にマッチしたもののハンドラーが実行されます。
-
-以下の設定はサブタグによって構成できます:
-
-| Sub-tags | Definition |
-| -------------------- | ----------------------------------------------------------------------------------------------- |
-| `url` | リクエスト URL にマッチさせます。正規表現マッチを使用するには、プレフィックスとして 'regex:' を付与します（任意） |
-| `methods` | リクエストメソッドにマッチさせます。複数のメソッドを指定する場合はカンマ区切りで指定します（任意） |
-| `headers` | リクエストヘッダーにマッチさせます。各子要素（子要素名がヘッダー名）ごとにマッチさせ、正規表現マッチを使用するにはプレフィックスとして 'regex:' を付与します（任意） |
-| `handler` | リクエストハンドラー |
-| `empty_query_string` | URL にクエリ文字列が存在しないことをチェックします |
-
-`handler` には以下の設定が含まれており、サブタグによって構成できます:
-
-| Sub-tags | Definition |
-| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
-| `url` | リダイレクト先の場所 |
-| `type` | サポートされるタイプ: static, dynamic_query_handler, predefined_query_handler, redirect |
-| `status` | static タイプと併用し、レスポンスのステータスコードを指定します |
-| `query_param_name` | dynamic_query_handler タイプと併用し、HTTP リクエストパラメータから `` に対応する値を抽出して実行します |
-| `query` | predefined_query_handler タイプと併用し、ハンドラーが呼び出されたときにクエリを実行します |
-| `content_type` | static タイプと併用し、レスポンスの Content-Type を指定します |
-| `response_content` | static タイプと併用し、クライアントに送信するレスポンスコンテンツを指定します。プレフィックスに 'file://' または 'config://' を使用すると、ファイルまたは設定からコンテンツを取得してクライアントに送信します |
-
-ルールの一覧に加えて、すべてのデフォルトハンドラーを有効にする `` を指定できます。
-
-例:
-
-```xml
-
-
- /
- POST,GET
- no-cache
-
- dynamic_query_handler
- query
-
-
-
-
- /predefined_query
- POST,GET
-
- predefined_query_handler
- SELECT * FROM system.settings
-
-
-
-
-
- static
- 200
- text/plain; charset=UTF-8
- config://http_server_default_response
-
-
-
-```
-
-
-## http_options_response
-
-`OPTIONS` HTTP リクエストのレスポンスにヘッダーを追加するために使用します。
-`OPTIONS` メソッドは、CORS プリフライト リクエストを行う際に使用されます。
-
-詳細については、[OPTIONS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS) を参照してください。
-
-例:
-
-```xml
-
-
- Access-Control-Allow-Origin
- *
-
-
- Access-Control-Allow-Headers
- origin, x-requested-with, x-clickhouse-format, x-clickhouse-user, x-clickhouse-key, Authorization
-
-
- Access-Control-Allow-Methods
- POST, GET, OPTIONS
-
-
- Access-Control-Max-Age
- 86400
-
-
-```
-
-
-## http_server_default_response
-
-ClickHouse の HTTP(S) サーバーにアクセスしたときに、デフォルトで表示されるページです。
-デフォルト値は "Ok."（末尾に改行（LF）付き）です。
-
-**例**
-
-`http://localhost: http_port` にアクセスしたときに `https://tabix.io/` が開きます。
-
-```xml
-
-