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
deleted file mode 100644
index 3b7224b1317..00000000000
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/_troubleshooting.md
+++ /dev/null
@@ -1,228 +0,0 @@
-
-[//]: # (This file is included in FAQ > Troubleshooting)
-
-- [インストール](#troubleshooting-installation-errors)
-- [サーバーへの接続](#troubleshooting-accepts-no-connections)
-- [クエリ処理](#troubleshooting-does-not-process-queries)
-- [クエリ処理のパフォーマンス](#troubleshooting-too-slow)
-
-
-
-## インストール
-
-### apt-get を使用して ClickHouse リポジトリから deb パッケージを取得できない
-
-* ファイアウォールの設定を確認してください。
-* 何らかの理由でリポジトリにアクセスできない場合は、[インストールガイド](../getting-started/install.md)の記事で説明されているようにパッケージをダウンロードし、`sudo dpkg -i
` コマンドを使用して手動でインストールしてください。`tzdata` パッケージも必要です。
-
-### apt-get を使用して ClickHouse リポジトリから deb パッケージを更新できない
-
-* GPG キーが変更された場合にこの問題が発生することがあります。
-
-リポジトリ設定を更新するには、[セットアップ](../getting-started/install.md#setup-the-debian-repository) ページの手順に従ってください。
-
-### `apt-get update` でさまざまな警告が表示される
-
-* 実際の警告メッセージは次のいずれかになります:
-
-```bash
-N: リポジトリ 'https://packages.clickhouse.com/deb stable InRelease' はアーキテクチャ 'i386' に対応していないため、設定ファイル 'main/binary-i386/Packages' の取得をスキップします
-```
-
-```bash
-E: https://packages.clickhouse.com/deb/dists/stable/main/binary-amd64/Packages.gz の取得に失敗しました ファイルサイズが想定と異なります (30451 != 28154)。ミラー同期中ですか?
-```
-
-```text
-E: リポジトリ 'https://packages.clickhouse.com/deb stable InRelease' の 'Origin' 値が 'Artifactory' から 'ClickHouse' に変更されました
-E: リポジトリ 'https://packages.clickhouse.com/deb stable InRelease' の 'Label' 値が 'Artifactory' から 'ClickHouse' に変更されました
-N: リポジトリ 'https://packages.clickhouse.com/deb stable InRelease' の 'Suite' 値が 'stable' から '' に変更されました
-N: このリポジトリの更新を適用するには、明示的に承認する必要があります。詳細は apt-secure(8) マニュアルページを参照してください。
-```
-
-```bash
-Err:11 https://packages.clickhouse.com/deb stable InRelease
- 400 Bad Request [IP: 172.66.40.249 443]
-```
-
-上記の問題を解決するには、以下のスクリプトを使用してください。
-
-```bash
-sudo rm /var/lib/apt/lists/packages.clickhouse.com_* /var/lib/dpkg/arch /var/lib/apt/lists/partial/packages.clickhouse.com_*
-sudo apt-get clean
-sudo apt-get autoclean
-```
-
-### 誤った署名が原因で yum からパッケージを取得できない
-
-起こりうる原因: キャッシュが不正です。2022 年 9 月に GPG キーを更新した後に壊れた可能性があります。
-
-解決策は、yum のキャッシュと lib ディレクトリをクリアすることです。
-
-```bash
-sudo find /var/lib/yum/repos/ /var/cache/yum/ -name 'clickhouse-*' -type d -exec rm -rf {} +
-sudo rm -f /etc/yum.repos.d/clickhouse.repo
-```
-
-その後は、[インストールガイド](../getting-started/install.md#from-rpm-packages) に従ってください。
-
-### Docker コンテナを実行できない
-
-単純に `docker run clickhouse/clickhouse-server` を実行すると、以下のようなスタックトレースが出力されてクラッシュします。
-
-```bash
-$ docker run -it clickhouse/clickhouse-server
-........
-Poco::Exception. Code: 1000, e.code() = 0, System exception: cannot start thread, Stack trace (このメッセージをコピーする際は、以下の行を必ず含めてください):
-```
-
-
-0. Poco::ThreadImpl::startImpl(Poco::SharedPtr>) @ 0x00000000157c7b34
-1. Poco::Thread::start(Poco::Runnable&) @ 0x00000000157c8a0e
-2. BaseDaemon::initializeTerminationAndSignalProcessing() @ 0x000000000d267a14
-3. BaseDaemon::initialize(Poco::Util::Application&) @ 0x000000000d2652cb
-4. DB::Server::initialize(Poco::Util::Application&) @ 0x000000000d128b38
-5. Poco::Util::Application::run() @ 0x000000001581cfda
-6. DB::Server::run() @ 0x000000000d1288f0
-7. Poco::Util::ServerApplication::run(int, char\*\*) @ 0x0000000015825e27
-8. mainEntryClickHouseServer(int, char\*\*) @ 0x000000000d125b38
-9. main @ 0x0000000007ea4eee
-10. ? @ 0x00007f67ff946d90
-11. ? @ 0x00007f67ff946e40
-12. \_start @ 0x00000000062e802e
- (version 24.10.1.2812 (official build))
-
-```
-
-原因は、`20.10.10`より古いバージョンのDockerデーモンです。修正するには、アップグレードするか、`docker run [--privileged | --security-opt seccomp=unconfined]`を実行してください。後者にはセキュリティ上の影響があります。
-
-```
-
-
-## サーバーへの接続
-
-想定される問題:
-
-* サーバーが起動していない
-* 想定外または誤った設定パラメータ
-
-### サーバーが起動していない
-
-**サーバーが起動しているか確認する**
-
-コマンド:
-
-```bash
-$ sudo service clickhouse-server status
-```
-
-サーバーが起動していない場合は、次のコマンドで起動してください。
-
-```bash
-$ sudo service clickhouse-server start
-```
-
-**ログを確認する**
-
-`clickhouse-server` のメインログは、デフォルトで `/var/log/clickhouse-server/clickhouse-server.log` に出力されます。
-
-サーバーが正常に起動していれば、次のような行が表示されます。
-
-* ` Application: starting up.` — サーバーが起動しました。
-* ` Application: Ready for connections.` — サーバーが稼働中で、接続を受け付ける準備ができています。
-
-`clickhouse-server` の起動が設定エラーで失敗した場合は、エラー内容の説明とともに `` という行が表示されます。例えば、次のようになります。
-
-```text
-2019.01.11 15:23:25.549505 [ 45 ] {} ExternalDictionaries: 外部ディクショナリ 'event2id' の再読み込みに失敗しました: Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused
-```
-
-ファイルの末尾にエラーが表示されていない場合は、次の文字列以降を起点にファイル全体を確認してください。
-
-```text
- Application: 起動中。
-```
-
-サーバー上で 2 つ目の `clickhouse-server` インスタンスを起動しようとすると、次のようなログが表示されます。
-
-```text
-2019.01.11 15:25:11.151730 [ 1 ] {} : Starting ClickHouse 19.1.0 with revision 54413
-2019.01.11 15:25:11.154578 [ 1 ] {} Application: starting up
-2019.01.11 15:25:11.156361 [ 1 ] {} StatusFile: Status file ./status already exists - unclean restart. Contents:
-PID: 8510
-Started at: 2019-01-11 15:24:23
-Revision: 54413
-
-2019.01.11 15:25:11.156673 [ 1 ] {} Application: DB::Exception: Cannot lock file ./status. Another server instance in same directory is already running.
-2019.01.11 15:25:11.156682 [ 1 ] {} Application: shutting down
-2019.01.11 15:25:11.156686 [ 1 ] {} Application: Uninitializing subsystem: Logging Subsystem
-2019.01.11 15:25:11.156716 [ 2 ] {} BaseDaemon: Stop SignalListener thread
-```
-
-**systemd のログを確認する**
-
-`clickhouse-server` のログに有用な情報が見つからない場合や、ログ自体が存在しない場合は、次のコマンドを実行して `systemd` のログを確認できます。
-
-```bash
-$ sudo journalctl -u clickhouse-server
-```
-
-**対話モードで clickhouse-server を起動する**
-
-```bash
-$ sudo -u clickhouse /usr/bin/clickhouse-server --config-file /etc/clickhouse-server/config.xml
-```
-
-このコマンドは、autostart スクリプトの標準パラメータを使用してサーバーを対話型アプリケーションとして起動します。このモードでは、`clickhouse-server` はすべてのイベントメッセージをコンソールに出力します。
-
-### 設定パラメータ
-
-次の点を確認します。
-
-* Docker 設定
-
- IPv6 ネットワーク上の Docker で ClickHouse を実行している場合は、`network=host` が設定されていることを確認します。
-
-* エンドポイント設定
-
- [listen_host](../operations/server-configuration-parameters/settings.md#listen_host) と [tcp_port](../operations/server-configuration-parameters/settings.md#tcp_port) の設定を確認します。
-
- ClickHouse サーバーは、デフォルトでは localhost からの接続のみを受け付けます。
-
-* HTTP プロトコル設定
-
- HTTP API のプロトコル設定を確認します。
-
-* セキュア接続の設定
-
- 次を確認します。
-
- * [tcp_port_secure](../operations/server-configuration-parameters/settings.md#tcp_port_secure) の設定
- * [SSL certificates](../operations/server-configuration-parameters/settings.md#openssl) の設定
-
- 接続時には適切なパラメータを使用します。たとえば、`clickhouse_client` では `port_secure` パラメータを使用します。
-
-* ユーザー設定
-
- 誤ったユーザー名またはパスワードを使用している可能性があります。
-
-
-## クエリ処理
-
-ClickHouse がクエリを処理できない場合、エラー内容の説明をクライアントに送信します。`clickhouse-client` を使用している場合は、コンソール上でエラー内容を確認できます。HTTP インターフェイスを使用している場合は、ClickHouse はレスポンスボディ内にエラーの説明を送信します。例えば次のとおりです。
-
-```bash
-$ curl 'http://localhost:8123/' --data-binary "SELECT a"
-Code: 47, e.displayText() = DB::Exception: Unknown identifier: a. Note that there are no tables (FROM clause) in your query, context: required_names: 'a' source_tables: table_aliases: private_aliases: column_aliases: public_columns: 'a' masked_columns: array_join_columns: source_columns: , e.what() = DB::Exception
-```
-
-`clickhouse-client` を `stack-trace` パラメータを指定して起動すると、ClickHouse はエラーの説明とともにサーバーのスタックトレースを返します。
-
-接続が切断されたことを示すメッセージが表示される場合があります。この場合は、クエリを再実行してみてください。クエリを実行するたびに接続が切断される場合は、サーバーログにエラーが出力されていないか確認してください。
-
-
-## クエリ処理の効率 {#troubleshooting-too-slow}
-
-ClickHouse の動作が遅すぎると感じる場合は、クエリに対するサーバーリソースやネットワークへの負荷をプロファイリングする必要があります。
-
-`clickhouse-benchmark` ユーティリティを使用してクエリをプロファイリングできます。1 秒あたりのクエリ処理数、1 秒あたりの行処理数、およびクエリ処理時間のパーセンタイルを表示します。
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
deleted file mode 100644
index 9dd3b85f7ea..00000000000
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/allocation-profiling-old.md
+++ /dev/null
@@ -1,224 +0,0 @@
----
-description: 'ClickHouse におけるアロケーションプロファイリングの詳細ページ'
-sidebar_label: 'バージョン 25.9 以前のアロケーションプロファイリング'
-slug: /operations/allocation-profiling-old
-title: 'バージョン 25.9 以前のアロケーションプロファイリング'
-doc_type: 'reference'
----
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-
-# 25.9 以前のバージョン向けのアロケーションプロファイリング
-
-ClickHouse はグローバルアロケータとして [jemalloc](https://github.com/jemalloc/jemalloc) を使用します。jemalloc には、アロケーションのサンプリングとプロファイリングのためのツールが付属しています。
-アロケーションプロファイリングをより便利に行えるように、Keeper では `SYSTEM` コマンドに加えて four letter word (4LW) コマンドも提供されています。
-
-
-
-## アロケーションのサンプリングとヒーププロファイルのフラッシュ
-
-`jemalloc` でアロケーションのサンプリングとプロファイリングを行う場合は、環境変数 `MALLOC_CONF` を使用してプロファイリングを有効にし、ClickHouse/Keeper を起動する必要があります。
-
-```sh
-MALLOC_CONF=background_thread:true,prof:true
-```
-
-`jemalloc` はアロケーションをサンプリングし、その情報を内部に保持します。
-
-現在のプロファイルをフラッシュするように `jemalloc` に指示するには、次を実行します:
-
-
-
- ```sql
- SYSTEM JEMALLOC FLUSH PROFILE
- ```
-
-
-
- ```sh
- echo jmfp | nc localhost 9181
- ```
-
-
-
-デフォルトでは、ヒーププロファイル用のファイルは `/tmp/jemalloc_clickhouse._pid_._seqnum_.heap` に生成されます。ここで `_pid_` は ClickHouse の PID、`_seqnum_` は現在のヒーププロファイルに対するグローバルシーケンス番号です。\
-Keeper の場合、デフォルトファイルは `/tmp/jemalloc_keeper._pid_._seqnum_.heap` であり、同じルールに従います。
-
-`MALLOC_CONF` 環境変数に `prof_prefix` オプションを追加することで、別の場所を指定できます。\
-たとえば、`/data` ディレクトリ内に、ファイル名のプレフィックスを `my_current_profile` としてプロファイルを生成したい場合は、ClickHouse/Keeper を次の環境変数を指定して実行します:
-
-```sh
-MALLOC_CONF=background_thread:true,prof:true,prof_prefix:/data/my_current_profile
-```
-
-生成されるファイル名は、接頭辞、PID、シーケンス番号を連結したものになります。
-
-
-## ヒーププロファイルの解析
-
-ヒーププロファイルを生成したら、それを解析する必要があります。\
-そのために、`jemalloc` のツールである [jeprof](https://github.com/jemalloc/jemalloc/blob/dev/bin/jeprof.in) を使用できます。これは複数の方法でインストールできます:
-
-* システムのパッケージマネージャーを使用する
-* [jemalloc リポジトリ](https://github.com/jemalloc/jemalloc) をクローンし、ルートディレクトリで `autogen.sh` を実行する。この方法では、`bin` ディレクトリ内で `jeprof` スクリプトが利用できるようになります
-
-:::note
-`jeprof` はスタックトレースを生成するために `addr2line` を使用しますが、これは非常に遅くなる場合があります。\
-その場合は、このツールの[代替実装](https://github.com/gimli-rs/addr2line)をインストールすることを推奨します。
-
-```bash
-git clone https://github.com/gimli-rs/addr2line.git --depth=1 --branch=0.23.0
-cd addr2line
-cargo build --features bin --release
-cp ./target/release/addr2line path/to/current/addr2line
-```
-
-:::
-
-`jeprof` を使用してヒーププロファイルから生成できる形式には、さまざまなものがあります。
-ツールの使い方および利用可能な各種オプションについては、`jeprof --help` を実行して確認することをお勧めします。
-
-一般的に、`jeprof` コマンドは次のように使用します。
-
-```sh
-jeprof path/to/binary path/to/heap/profile --output_format [ > output_file]
-```
-
-2つのプロファイル間でどの割り当てが行われたかを比較したい場合は、`base` 引数を指定できます。
-
-```sh
-jeprof path/to/binary --base path/to/first/heap/profile path/to/second/heap/profile --output_format [ > output_file]
-```
-
-### 例
-
-* 各プロシージャを1行ごとに記述したテキストファイルを生成したい場合:
-
-```sh
-jeprof path/to/binary path/to/heap/profile --text > result.txt
-```
-
-* コールグラフを含む PDF ファイルを生成したい場合:
-
-```sh
-jeprof path/to/binary path/to/heap/profile --pdf > result.pdf
-```
-
-### フレームグラフの生成
-
-`jeprof` を使用すると、フレームグラフの作成に必要な折りたたみスタック（collapsed stack）を生成できます。
-
-`--collapsed` 引数を指定する必要があります。
-
-```sh
-jeprof path/to/binary path/to/heap/profile --collapsed > result.collapsed
-```
-
-その後、折り畳まれたスタックを可視化するために、さまざまなツールを利用できます。
-
-最も一般的なのは [FlameGraph](https://github.com/brendangregg/FlameGraph) で、`flamegraph.pl` というスクリプトが付属しています。
-
-```sh
-cat result.collapsed | /path/to/FlameGraph/flamegraph.pl --color=mem --title="Allocation Flame Graph" --width 2400 > result.svg
-```
-
-もう 1 つ有用なツールとして [speedscope](https://www.speedscope.app/) があり、収集したスタック情報をよりインタラクティブに解析できます。
-
-
-## 実行時のアロケーションプロファイラの制御
-
-ClickHouse/Keeper をプロファイラを有効にした状態で起動した場合、実行時にアロケーションプロファイリングを無効化/有効化するための追加コマンドを使用できます。
-これらのコマンドを使用すると、特定の時間区間のみをプロファイルしやすくなります。
-
-プロファイラを無効にするには:
-
-
-
- ```sql
- SYSTEM JEMALLOC DISABLE PROFILE
- ```
-
-
-
- ```sh
- echo jmdp | nc localhost 9181
- ```
-
-
-
-プロファイラを有効にするには:
-
-
-
- ```sql
- SYSTEM JEMALLOC ENABLE PROFILE
- ```
-
-
-
- ```sh
- echo jmep | nc localhost 9181
- ```
-
-
-
-`prof_active` オプションを設定することで、プロファイラの初期状態を制御することも可能です。このオプションはデフォルトで有効になっています。\
-たとえば、起動時にはアロケーションをサンプリングせず、起動後のみサンプリングしたい場合は、その時点でプロファイラを有効にします。次の環境変数を指定して ClickHouse/Keeper を起動できます:
-
-```sh
-MALLOC_CONF=background_thread:true,prof:true,prof_active:false
-```
-
-プロファイラは後から有効化することもできます。
-
-
-## プロファイラの追加オプション {#additional-options-for-profiler}
-
-`jemalloc` にはプロファイラに関連する多数のオプションが用意されており、`MALLOC_CONF` 環境変数を変更して制御できます。
-たとえば、アロケーションサンプル間の間隔は `lg_prof_sample` で制御できます。
-ヒーププロファイルを N バイトごとにダンプしたい場合は、`lg_prof_interval` を有効化してください。
-
-利用可能なオプションの一覧については、`jemalloc` の[リファレンスページ](https://jemalloc.net/jemalloc.3.html)を参照してください。
-
-
-
-## その他のリソース
-
-ClickHouse/Keeper は、`jemalloc` 関連のメトリクスをさまざまな方法で公開しています。
-
-:::warning 注意
-これらのメトリクスは互いに同期されておらず、値がずれていく可能性があることを認識しておくことが重要です。
-:::
-
-### システムテーブル `asynchronous_metrics`
-
-```sql
-SELECT *
-FROM system.asynchronous_metrics
-WHERE metric LIKE '%jemalloc%'
-FORMAT Vertical
-```
-
-[リファレンス](/operations/system-tables/asynchronous_metrics)
-
-### システムテーブル `jemalloc_bins`
-
-サイズクラス（bin）ごとに `jemalloc` アロケータ経由で行われたメモリ割り当てに関する情報を、すべてのアリーナから集約して格納します。
-
-[リファレンス](/operations/system-tables/jemalloc_bins)
-
-### Prometheus
-
-`asynchronous_metrics` に含まれるすべての `jemalloc` 関連メトリクスは、ClickHouse と Keeper の両方で Prometheus エンドポイントを通じても公開されます。
-
-[リファレンス](/operations/server-configuration-parameters/settings#prometheus)
-
-### Keeper における `jmst` 4LW コマンド
-
-Keeper は `jmst` 4LW コマンドをサポートしており、[基本的なアロケータ統計情報](https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Basic-Allocator-Statistics) を返します。
-
-```sh
-echo jmst | nc localhost 9181
-```
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
deleted file mode 100644
index fdee13466b7..00000000000
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/allocation-profiling.md
+++ /dev/null
@@ -1,337 +0,0 @@
----
-description: 'ClickHouse におけるアロケーションプロファイリングを詳しく説明するページ'
-sidebar_label: 'アロケーションプロファイリング'
-slug: /operations/allocation-profiling
-title: 'アロケーションプロファイリング'
-doc_type: 'guide'
----
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-
-# アロケーションプロファイリング
-
-ClickHouse はグローバルアロケータとして [jemalloc](https://github.com/jemalloc/jemalloc) を使用しています。jemalloc には、アロケーションのサンプリングおよびプロファイリング用のツールが付属しています。
-アロケーションプロファイリングをより手軽に行えるように、ClickHouse と Keeper では、設定ファイルやクエリ設定、`SYSTEM` コマンド、Keeper の four letter word (4LW) コマンドを使用してサンプリングを制御できます。
-さらに、サンプルは `JemallocSample` 型として `system.trace_log` テーブルに収集できます。
-
-:::note
-
-このガイドはバージョン 25.9 以降に適用されます。
-それ以前のバージョンについては、[25.9 より前のバージョン向けアロケーションプロファイリング](/operations/allocation-profiling-old.md) を参照してください。
-
-:::
-
-
-
-## アロケーションのサンプリング
-
-`jemalloc` でアロケーションのサンプリングおよびプロファイリングを行うには、`jemalloc_enable_global_profiler` 設定を有効にして ClickHouse/Keeper を起動する必要があります。
-
-```xml
-
- 1
-
-```
-
-`jemalloc` はアロケーションをサンプリングし、その情報を内部に保持します。
-
-`jemalloc_enable_profiler` 設定を使用することで、クエリ単位のアロケーションを有効にすることもできます。
-
-:::warning 警告
-ClickHouse はアロケーションが多いアプリケーションであるため、jemalloc のサンプリングによりパフォーマンス上のオーバーヘッドが発生する可能性があります。
-:::
-
-
-## `system.trace_log` に jemalloc サンプルを保存する
-
-すべての jemalloc サンプルを `JemallocSample` 型として `system.trace_log` に格納できます。
-これをグローバルに有効化するには、設定項目 `jemalloc_collect_global_profile_samples_in_trace_log` を使用します。
-
-```xml
-
- 1
-
-```
-
-:::warning 警告
-ClickHouse はメモリ割り当てを多用するアプリケーションであるため、`system.trace_log` ですべてのサンプルを収集すると高負荷になる可能性があります。
-:::
-
-`jemalloc_collect_profile_samples_in_trace_log` 設定を使用して、クエリごとに有効化することもできます。
-
-### `system.trace_log` を使用してクエリのメモリ使用量を分析する例
-
-まず、jemalloc プロファイラを有効にしてクエリを実行し、そのクエリのサンプルを `system.trace_log` に収集する必要があります。
-
-```sql
-SELECT *
-FROM numbers(1000000)
-ORDER BY number DESC
-SETTINGS max_bytes_ratio_before_external_sort = 0
-FORMAT `Null`
-SETTINGS jemalloc_enable_profiler = 1, jemalloc_collect_profile_samples_in_trace_log = 1
-
-Query id: 8678d8fe-62c5-48b8-b0cd-26851c62dd75
-
-Ok.
-
-0 rows in set. Elapsed: 0.009 sec. Processed 1.00 million rows, 8.00 MB (108.58 million rows/s., 868.61 MB/s.)
-Peak memory usage: 12.65 MiB.
-```
-
-:::note
-ClickHouse を起動するときに `jemalloc_enable_global_profiler` を有効にしている場合、`jemalloc_enable_profiler` を有効にする必要はありません。\
-`jemalloc_collect_global_profile_samples_in_trace_log` と `jemalloc_collect_profile_samples_in_trace_log` についても同様です。
-:::
-
-ここで `system.trace_log` をフラッシュします。
-
-```sql
-SYSTEM FLUSH LOGS trace_log
-```
-
-そして、各時点において実行したクエリのメモリ使用量を取得するためにクエリします。
-
-```sql
-WITH per_bucket AS
-(
- SELECT
- event_time_microseconds AS bucket_time,
- sum(size) AS bucket_sum
- FROM system.trace_log
- WHERE trace_type = 'JemallocSample'
- AND query_id = '8678d8fe-62c5-48b8-b0cd-26851c62dd75'
- GROUP BY bucket_time
-)
-SELECT
- bucket_time,
- sum(bucket_sum) OVER (
- ORDER BY bucket_time ASC
- ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
- ) AS cumulative_size,
- formatReadableSize(cumulative_size) AS cumulative_size_readable
-FROM per_bucket
-ORDER BY bucket_time
-```
-
-メモリ使用量が最大だった時刻も確認できます：
-
-```sql
-SELECT
- argMax(bucket_time, cumulative_size),
- max(cumulative_size)
-FROM
-(
- WITH per_bucket AS
- (
- SELECT
- event_time_microseconds AS bucket_time,
- sum(size) AS bucket_sum
- FROM system.trace_log
- WHERE trace_type = 'JemallocSample'
- AND query_id = '8678d8fe-62c5-48b8-b0cd-26851c62dd75'
- GROUP BY bucket_time
- )
- SELECT
- bucket_time,
- sum(bucket_sum) OVER (
- ORDER BY bucket_time ASC
- ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
- ) AS cumulative_size,
- formatReadableSize(cumulative_size) AS cumulative_size_readable
- FROM per_bucket
- ORDER BY bucket_time
-)
-```
-
-その結果を使って、その時点でどこが最も活発に割り当てを行っていたかを確認できます。
-
-
-```sql
-SELECT
- concat(
- '\n',
- arrayStringConcat(
- arrayMap(
- (x, y) -> concat(x, ': ', y),
- arrayMap(x -> addressToLine(x), allocation_trace),
- arrayMap(x -> demangle(addressToSymbol(x)), allocation_trace)
- ),
- '\n'
- )
- ) AS symbolized_trace,
- sum(s) AS per_trace_sum
-FROM
-(
- SELECT
- ptr,
- sum(size) AS s,
- argMax(trace, event_time_microseconds) AS allocation_trace
- FROM system.trace_log
- WHERE trace_type = 'JemallocSample'
- AND query_id = '8678d8fe-62c5-48b8-b0cd-26851c62dd75'
- AND event_time_microseconds <= '2025-09-04 11:56:21.737139'
- GROUP BY ptr
- HAVING s > 0
-)
-GROUP BY ALL
-ORDER BY per_trace_sum ASC
-```
-
-
-## ヒーププロファイルのフラッシュ
-
-デフォルトでは、ヒーププロファイル用ファイルは `/tmp/jemalloc_clickhouse._pid_._seqnum_.heap` に生成されます。ここで `_pid_` は ClickHouse の PID、`_seqnum_` は現在のヒーププロファイルに対応するグローバルなシーケンス番号です。\
-Keeper のデフォルトファイルは `/tmp/jemalloc_keeper._pid_._seqnum_.heap` で、同じルールに従います。
-
-`jemalloc` に現在のプロファイルをフラッシュさせるには、次を実行します。
-
-
-
- ```sql
- SYSTEM JEMALLOC FLUSH PROFILE
- ```
-
- フラッシュされたプロファイルの保存先パスが返されます。
-
-
-
- ```sh
- echo jmfp | nc localhost 9181
- ```
-
-
-
-`MALLOC_CONF` 環境変数に `prof_prefix` オプションを追加することで、別の保存場所を指定できます。\
-例えば、`/data` ディレクトリ内に、ファイル名のプレフィックスを `my_current_profile` としてプロファイルを生成したい場合は、次の環境変数を指定して ClickHouse/Keeper を実行します。
-
-```sh
-MALLOC_CONF=prof_prefix:/data/my_current_profile
-```
-
-生成されるファイル名には、プレフィックスに続いて PID とシーケンス番号が付加されます。
-
-
-## ヒーププロファイルの分析
-
-ヒーププロファイルが生成されたら、それらを分析する必要があります。\
-そのために、`jemalloc` のツールである [jeprof](https://github.com/jemalloc/jemalloc/blob/dev/bin/jeprof.in) を使用できます。次のいずれかの方法でインストールできます。
-
-* システムのパッケージマネージャーを使用する
-* [jemalloc リポジトリ](https://github.com/jemalloc/jemalloc)をクローンし、ルートディレクトリで `autogen.sh` を実行する。これにより、`bin` ディレクトリ内に `jeprof` スクリプトが作成されます
-
-:::note
-`jeprof` はスタックトレースを生成するために `addr2line` を使用しますが、処理が非常に遅くなる場合があります。\
-そのような場合には、このツールの[代替実装](https://github.com/gimli-rs/addr2line)をインストールすることを推奨します。
-
-```bash
-git clone https://github.com/gimli-rs/addr2line.git --depth=1 --branch=0.23.0
-cd addr2line
-cargo build --features bin --release
-cp ./target/release/addr2line path/to/current/addr2line
-```
-
-また、`llvm-addr2line` も同様に問題なく動作します。
-
-:::
-
-`jeprof` を使用して、ヒーププロファイルからさまざまな形式を生成できます。
-ツールの使い方や提供される各種オプションについては、`jeprof --help` を実行して確認することを推奨します。
-
-一般的に、`jeprof` コマンドは次のように使用します。
-
-```sh
-jeprof path/to/binary path/to/heap/profile --output_format [ > output_file]
-```
-
-2つのプロファイルを比較して、その間にどの割り当てが発生したかを確認したい場合は、`base` 引数を指定します。
-
-```sh
-jeprof path/to/binary --base path/to/first/heap/profile path/to/second/heap/profile --output_format [ > output_file]
-```
-
-### 例
-
-* 各プロシージャを1行ごとに記述したテキストファイルを生成したい場合:
-
-```sh
-jeprof path/to/binary path/to/heap/profile --text > result.txt
-```
-
-* コールグラフを含む PDF ファイルを生成したい場合:
-
-```sh
-jeprof path/to/binary path/to/heap/profile --pdf > result.pdf
-```
-
-### フレームグラフの生成
-
-`jeprof` を使用すると、フレームグラフの作成に必要な折り畳みスタック（collapsed stacks）を生成できます。
-
-`--collapsed` 引数を使用する必要があります。
-
-```sh
-jeprof path/to/binary path/to/heap/profile --collapsed > result.collapsed
-```
-
-その後は、コラプスされたスタックを可視化するために利用できるツールが多数あります。
-
-最も広く使われているのは [FlameGraph](https://github.com/brendangregg/FlameGraph) で、`flamegraph.pl` というスクリプトが含まれています。
-
-```sh
-cat result.collapsed | /path/to/FlameGraph/flamegraph.pl --color=mem --title="メモリ割り当てフレームグラフ" --width 2400 > result.svg
-```
-
-もう 1 つ便利なツールに [speedscope](https://www.speedscope.app/) があり、収集したスタックをよりインタラクティブに分析できます。
-
-
-## プロファイラ用の追加オプション {#additional-options-for-profiler}
-
-`jemalloc` にはプロファイラに関連する多くのオプションがあり、`MALLOC_CONF` 環境変数を変更することで制御できます。
-例えば、メモリ割り当てサンプル間の間隔は `lg_prof_sample` で制御できます。
-ヒーププロファイルを N バイトごとにダンプしたい場合は、`lg_prof_interval` を有効にします。
-
-利用可能なオプションの完全な一覧については、`jemalloc` の [リファレンスページ](https://jemalloc.net/jemalloc.3.html) を参照してください。
-
-
-
-## その他のリソース
-
-ClickHouse/Keeper は、`jemalloc` 関連のメトリクスをさまざまな方法で公開します。
-
-:::warning 警告
-これらのメトリクスは相互に同期されておらず、値がずれる可能性があることを認識しておくことが重要です。
-:::
-
-### システムテーブル `asynchronous_metrics`
-
-```sql
-SELECT *
-FROM system.asynchronous_metrics
-WHERE metric LIKE '%jemalloc%'
-FORMAT Vertical
-```
-
-[リファレンス](/operations/system-tables/asynchronous_metrics)
-
-### システムテーブル `jemalloc_bins`
-
-すべてのアリーナから集約された、さまざまなサイズクラス（bin）における jemalloc アロケータによるメモリ割り当てに関する情報を含みます。
-
-[リファレンス](/operations/system-tables/jemalloc_bins)
-
-### Prometheus
-
-`asynchronous_metrics` に含まれるすべての `jemalloc` 関連メトリクスは、ClickHouse と Keeper の両方で Prometheus エンドポイントからも公開されます。
-
-[リファレンス](/operations/server-configuration-parameters/settings#prometheus)
-
-### Keeper における `jmst` 4LW コマンド
-
-Keeper は `jmst` 4LW コマンドをサポートしており、[基本的なアロケータ統計情報](https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Basic-Allocator-Statistics)を返します。
-
-```sh
-echo jmst | nc localhost 9181
-```
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/analyzer.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/analyzer.md
deleted file mode 100644
index 3516278aebc..00000000000
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/analyzer.md
+++ /dev/null
@@ -1,207 +0,0 @@
----
-description: 'ClickHouse クエリ アナライザーの詳細ページ'
-keywords: ['analyzer']
-sidebar_label: 'アナライザー'
-slug: /operations/analyzer
-title: 'アナライザー'
-doc_type: 'reference'
----
-
-
-
-# Analyzer
-
-ClickHouse バージョン `24.3` では、新しいクエリアナライザーがデフォルトで有効になりました。
-その動作の詳細については[こちら](/guides/developer/understanding-query-execution-with-the-analyzer#analyzer)を参照してください。
-
-
-
-## 既知の非互換性
-
-多数のバグ修正と新しい最適化を導入した一方で、ClickHouse の動作には後方互換性を破る変更もいくつか含まれています。新しいアナライザ用にクエリを書き換える方法を判断するために、以下の変更点を確認してください。
-
-### 無効なクエリはこれ以上最適化されない
-
-以前のクエリプランニング基盤では、クエリの検証ステップより前に AST レベルの最適化が適用されていました。
-この最適化により、元のクエリを書き換えて有効かつ実行可能にできる場合がありました。
-
-新しいアナライザでは、最適化ステップより前にクエリ検証が行われます。
-これは、以前は実行可能だった無効なクエリが、現在はサポートされなくなったことを意味します。
-そのような場合、そのクエリは手動で修正する必要があります。
-
-#### 例 1
-
-次のクエリは、集約後に利用可能なのが `toString(number)` だけであるにもかかわらず、SELECT 句でカラム `number` を使用しています。
-旧アナライザでは、`GROUP BY toString(number)` は `GROUP BY number` に最適化され、その結果クエリは有効になっていました。
-
-```sql
-SELECT number
-FROM numbers(1)
-GROUP BY toString(number)
-```
-
-#### 例 2
-
-このクエリでも同じ問題が発生します。列 `number` は、別のキーと一緒に集約した後に使用されています。
-以前のクエリアナライザーは、`number > 5` というフィルタを `HAVING` 句から `WHERE` 句に移動することで、このクエリを修正しました。
-
-```sql
-SELECT
- number % 2 AS n,
- sum(number)
-FROM numbers(10)
-GROUP BY n
-HAVING number > 5
-```
-
-このクエリを修正するには、標準的な SQL 構文に従うよう、集約されていない列に適用されるすべての条件を `WHERE` 句に移動する必要があります。
-
-```sql
-SELECT
- number % 2 AS n,
- sum(number)
-FROM numbers(10)
-WHERE number > 5
-GROUP BY n
-```
-
-### 無効なクエリを指定した `CREATE VIEW`
-
-新しいアナライザは常に型チェックを行います。
-以前は、無効な `SELECT` クエリを含む `VIEW` を作成できていました。
-その場合、最初の `SELECT` または（`MATERIALIZED VIEW` の場合は）`INSERT` で失敗していました。
-
-このような形で `VIEW` を作成することは、もはやできません。
-
-#### 例
-
-```sql
-CREATE TABLE source (data String)
-ENGINE=MergeTree
-ORDER BY tuple();
-
-CREATE VIEW some_view
-AS SELECT JSONExtract(data, 'test', 'DateTime64(3)')
-FROM source;
-```
-
-### `JOIN` 句の既知の非互換性
-
-#### プロジェクションの列を使用する `JOIN`
-
-`SELECT` リスト内のエイリアスは、デフォルトでは `JOIN USING` のキーとして使用できません。
-
-新しい設定 `analyzer_compatibility_join_using_top_level_identifier` を有効にすると、`JOIN USING` の動作が変更され、左側テーブルの列を直接使用するのではなく、`SELECT` クエリのプロジェクションリストに含まれる式を基に識別子を優先的に解決するようになります。
-
-例：
-
-```sql
-SELECT a + 1 AS b, t2.s
-FROM VALUES('a UInt64, b UInt64', (1, 1)) AS t1
-JOIN VALUES('b UInt64, s String', (1, 'one'), (2, 'two')) t2
-USING (b);
-```
-
-`analyzer_compatibility_join_using_top_level_identifier` を `true` に設定すると、結合条件は `t1.a + 1 = t2.b` と解釈され、以前のバージョンと同じ動作になります。
-結果は `2, 'two'` になります。
-設定が `false` の場合、結合条件はデフォルトで `t1.b = t2.b` となり、クエリは `2, 'one'` を返します。
-`b` が `t1` に存在しない場合、クエリはエラーとなって失敗します。
-
-#### `JOIN USING` と `ALIAS` / `MATERIALIZED` カラムにおける動作の変更
-
-新しいアナライザでは、`ALIAS` または `MATERIALIZED` カラムを含む `JOIN USING` クエリで `*` を使用すると、それらのカラムもデフォルトで結果セットに含まれます。
-
-例えば次のようになります。
-
-```sql
-CREATE TABLE t1 (id UInt64, payload ALIAS sipHash64(id)) ENGINE = MergeTree ORDER BY id;
-INSERT INTO t1 VALUES (1), (2);
-
-CREATE TABLE t2 (id UInt64, payload ALIAS sipHash64(id)) ENGINE = MergeTree ORDER BY id;
-INSERT INTO t2 VALUES (2), (3);
-
-SELECT * FROM t1
-FULL JOIN t2 USING (payload);
-```
-
-
-新しいアナライザーでは、このクエリの結果には、両方のテーブルからの `id` 列に加えて `payload` 列が含まれます。
-これに対して、以前のアナライザーでは、特定の設定（`asterisk_include_alias_columns` または `asterisk_include_materialized_columns`）が有効になっている場合にのみ、これらの `ALIAS` 列が結果に含まれ、
-かつ列の並び順が異なる場合がありました。
-
-特に古いクエリを新しいアナライザーに移行する際に、一貫性があり期待どおりの結果を得るためには、`*` を使うのではなく、`SELECT` 句で列を明示的に指定することを推奨します。
-
-#### `USING` 句内の列に対する型修飾子の扱い
-
-新しいバージョンのアナライザーでは、`USING` 句で指定された列に対して共通スーパータイプを決定するための規則が標準化されており、
-特に `LowCardinality` や `Nullable` といった型修飾子を扱う際に、より予測しやすい結果が得られるようになっています。
-
-* `LowCardinality(T)` と `T`: 型 `LowCardinality(T)` の列が型 `T` の列と結合される場合、結果の共通スーパータイプは `T` となり、`LowCardinality` 修飾子は実質的に破棄されます。
-* `Nullable(T)` と `T`: 型 `Nullable(T)` の列が型 `T` の列と結合される場合、結果の共通スーパータイプは `Nullable(T)` となり、NULL 許容であるという性質が保持されます。
-
-例：
-
-```sql
-SELECT id, toTypeName(id)
-FROM VALUES('id LowCardinality(String)', ('a')) AS t1
-FULL OUTER JOIN VALUES('id String', ('b')) AS t2
-USING (id);
-```
-
-このクエリでは、`id` の共通スーパータイプは `String` として判定され、`t1` では `LowCardinality` 修飾子が除外されます。
-
-### Projection 列名の変更
-
-Projection 列名を計算する際、エイリアスは展開されません。
-
-```sql
-SELECT
- 1 + 1 AS x,
- x + 1
-SETTINGS enable_analyzer = 0
-FORMAT PrettyCompact
-
- ┌─x─┬─plus(plus(1, 1), 1)─┐
-1. │ 2 │ 3 │
- └───┴─────────────────────┘
-
-SELECT
- 1 + 1 AS x,
- x + 1
-SETTINGS enable_analyzer = 1
-FORMAT PrettyCompact
-
- ┌─x─┬─plus(x, 1)─┐
-1. │ 2 │ 3 │
- └───┴────────────┘
-```
-
-### 互換性のない関数引数の型
-
-新しいアナライザーでは、型推論はクエリの初期解析中に行われます。
-この変更により、短絡評価の前に型チェックが行われるようになり、その結果、`if` 関数の引数は常に共通の上位型（スーパータイプ）を持つ必要があります。
-
-例えば、次のクエリは `There is no supertype for types Array(UInt8), String because some of them are Array and some of them are not` というエラーで失敗します。
-
-```sql
-SELECT toTypeName(if(0, [2, 3, 4], 'String'))
-```
-
-### 異種クラスタ
-
-新しい analyzer は、クラスタ内のサーバー間の通信プロトコルを大きく変更します。\
-そのため、`enable_analyzer` の設定値が異なるサーバー間で分散クエリを実行することはできません。
-
-### ミューテーションは旧 analyzer によって解釈される
-
-ミューテーションは依然として古い analyzer を使用します。\
-これは、一部の新しい ClickHouse SQL 機能（たとえば `QUALIFY` 句）がミューテーションでは使用できないことを意味します。\
-対応状況は[こちら](https://github.com/ClickHouse/ClickHouse/issues/61563)で確認できます。
-
-### 未サポートの機能
-
-新しい analyzer が現在サポートしていない機能の一覧は以下のとおりです。
-
-* Annoy インデックス。
-* Hypothesis インデックス。作業状況は[こちら](https://github.com/ClickHouse/ClickHouse/pull/48381)。
-* Window view はサポートされていません。今後もサポートする予定はありません。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/backup.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/backup.md
deleted file mode 100644
index c853070fb70..00000000000
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/backup.md
+++ /dev/null
@@ -1,574 +0,0 @@
----
-description: 'ClickHouse データベースおよびテーブルのバックアップおよび復元に関するガイド'
-sidebar_label: 'バックアップと復元'
-sidebar_position: 10
-slug: /operations/backup
-title: 'バックアップと復元'
-doc_type: 'guide'
----
-
-
-
-# バックアップと復元
-
-- [ローカルディスクへのバックアップ](#backup-to-a-local-disk)
-- [S3 エンドポイントを使用したバックアップ／復元の設定](#configuring-backuprestore-to-use-an-s3-endpoint)
-- [S3 ディスクを使用したバックアップ／復元](#backuprestore-using-an-s3-disk)
-- [代替案](#alternatives)
-
-
-
-## コマンドの概要
-
-```bash
- BACKUP|RESTORE
- TABLE [db.]table_name [AS [db.]table_name_in_backup]
- [PARTITION[S] partition_expr [, ...]] |
- DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup] |
- DATABASE database_name [AS database_name_in_backup]
- [EXCEPT TABLES ...] |
- TEMPORARY TABLE table_name [AS table_name_in_backup] |
- VIEW view_name [AS view_name_in_backup] |
- ALL [EXCEPT {TABLES|DATABASES}...] } [, ...]
- [ON CLUSTER 'cluster_name']
- TO|FROM File('/') | Disk('', '/') | S3('/', '', '')
- [SETTINGS base_backup = File('/') | Disk(...) | S3('/', '', '')]
- [SYNC|ASYNC]
-
-```
-
-:::note ALL
-バージョン 23.4 より前の ClickHouse では、`ALL` は `RESTORE` コマンドにのみ適用されていました。
-:::
-
-
-## 背景 {#background}
-
-[レプリケーション](../engines/table-engines/mergetree-family/replication.md) はハードウェア障害からの保護を提供しますが、人為的なミスからは保護しません。たとえば、データの誤削除、誤ったテーブルや誤ったクラスタ上のテーブルの削除、不正なデータ処理やデータ破損を引き起こすソフトウェアバグなどです。多くの場合、このようなミスはすべてのレプリカに影響します。ClickHouse には、特定の種類のミスを防ぐための組み込みの安全機構があります。たとえばデフォルトでは、[50 GB を超えるデータを含む MergeTree 系エンジンのテーブルを、そのまま DROP することはできません](/operations/settings/settings#max_table_size_to_drop)。しかし、これらの安全機構はあらゆるケースを網羅しているわけではなく、回避されてしまう可能性もあります。
-
-起こり得る人為的なミスの影響を効果的に軽減するためには、**事前に** データのバックアップおよび復元戦略を慎重に準備しておく必要があります。
-
-各社で利用可能なリソースやビジネス要件は異なるため、あらゆる状況に適合するような ClickHouse のバックアップおよび復元の汎用的な解決策は存在しません。1 GB のデータで有効な方法が、数十 PB のデータでも有効とは限りません。長所と短所を併せ持つさまざまなアプローチが存在し、それらについては後述します。個々の欠点を補うために、1 つのアプローチだけではなく、複数のアプローチを併用することが望ましいです。
-
-:::note
-バックアップを取得しただけで一度も復元を試していない場合、いざというときに復元が正しく動作しない（少なくとも、ビジネスが許容できるよりも長い時間がかかる）可能性が高いことを忘れないでください。どのようなバックアップ手法を選択するにせよ、復元プロセスも必ず自動化し、予備の ClickHouse クラスタで定期的に復元演習を行ってください。
-:::
-
-
-
-## ローカルディスクへのバックアップ
-
-### バックアップ先の設定
-
-以下の例では、バックアップ先は `Disk('backups', '1.zip')` のように指定されます。バックアップ先を準備するには、バックアップ先を指定したファイルを `/etc/clickhouse-server/config.d/backup_disk.xml` に追加します。例えば、このファイルでは `backups` という名前のディスクを定義し、そのディスクを **backups > allowed_disk** リストに追加します。
-
-```xml
-
-
-
-
-
- local
- /backups/
-
-
-
-
-
- backups
- /backups/
-
-
-
-```
-
-### パラメーター
-
-バックアップはフルバックアップまたは増分バックアップとし、テーブル（マテリアライズドビュー、プロジェクション、ディクショナリを含む）やデータベースを対象にできます。バックアップは同期（デフォルト）または非同期で実行できます。圧縮することも可能で、パスワード保護を設定できます。
-
-`BACKUP` および `RESTORE` ステートメントは、`DATABASE` および `TABLE` 名のリスト、宛先（またはソース）、オプション、および設定を受け取ります。
-
-* バックアップの宛先、またはリストアのソースです。これは前に定義したディスクに基づきます。例: `Disk('backups', 'filename.zip')`
-* ASYNC: バックアップまたはリストアを非同期で実行
-* PARTITIONS: リストアするパーティションのリスト
-* SETTINGS:
- * `id`: バックアップまたはリストア処理の識別子。設定されていないか空の場合は、ランダムに生成された UUID が使用されます。
- 明示的に空でない文字列に設定する場合は、毎回異なる値にする必要があります。この `id` は、特定のバックアップまたはリストア処理に関連する `system.backups` テーブル内の行を検索するために使用されます。
- * [`compression_method`](/sql-reference/statements/create/table#column_compression_codec) と `compression_level`
- * ディスク上のファイルに対する `password`
- * `base_backup`: このソースの前回のバックアップの宛先。例: `Disk('backups', '1.zip')`
- * `use_same_s3_credentials_for_base_backup`: S3 へのベースバックアップがクエリで使用されている認証情報を継承するかどうか。`S3` でのみ動作します。
- * `use_same_password_for_base_backup`: ベースバックアップアーカイブがクエリからパスワードを継承するかどうか。
- * `structure_only`: 有効にすると、テーブルデータなしで `CREATE` ステートメントのみをバックアップまたはリストアできます。
- * `storage_policy`: リストアされるテーブルに対するストレージポリシー。[複数のブロックデバイスを使用したデータストレージ](../engines/table-engines/mergetree-family/mergetree.md#table_engine-mergetree-multiple-volumes) を参照してください。この設定は `RESTORE` コマンドにのみ適用されます。指定されたストレージポリシーは、`MergeTree` ファミリーのエンジンを持つテーブルにのみ適用されます。
- * `s3_storage_class`: S3 バックアップに使用されるストレージクラス。例: `STANDARD`
- * `azure_attempt_to_create_container`: Azure Blob Storage を使用する場合、指定されたコンテナーが存在しないときに作成を試みるかどうか。デフォルト: true。
- * [コア設定](/operations/settings/settings) もここで使用できます
-
-### 使用例
-
-テーブルをバックアップしてからリストアする例:
-
-```sql
-BACKUP TABLE test.table TO Disk('backups', '1.zip')
-```
-
-対応するリストア：
-
-```sql
-RESTORE TABLE test.table FROM Disk('backups', '1.zip')
-```
-
-:::note
-上記の RESTORE は、テーブル `test.table` にデータが含まれている場合は失敗します。RESTORE をテストする場合は、テーブルを削除するか、設定 `allow_non_empty_tables=true` を有効にする必要があります。
-
-```sql
-RESTORE TABLE test.table FROM Disk('backups', '1.zip')
-SETTINGS allow_non_empty_tables=true
-```
-
-:::
-
-テーブルは、新しい名前を指定してリストアしたりバックアップを作成したりできます。
-
-```sql
-RESTORE TABLE test.table AS test.table2 FROM Disk('backups', '1.zip')
-```
-
-```sql
-BACKUP TABLE test.table3 AS test.table4 TO Disk('backups', '2.zip')
-```
-
-### 増分バックアップ
-
-`base_backup` を指定すると、増分バックアップを作成できます。
-:::note
-増分バックアップはベースバックアップに依存します。増分バックアップからリストアできるようにするには、ベースバックアップを利用可能な状態で保持しておく必要があります。
-:::
-
-
-新しいデータを増分的に保存します。設定 `base_backup` により、以前のバックアップ `Disk('backups', 'd.zip')` 以降に追加されたデータが `Disk('backups', 'incremental-a.zip')` に保存されます。
-
-```sql
-BACKUP TABLE test.table TO Disk('backups', 'incremental-a.zip')
- SETTINGS base_backup = Disk('backups', 'd.zip')
-```
-
-インクリメンタルバックアップと `base_backup` からすべてのデータを、新しいテーブル `test.table2` に復元します：
-
-```sql
-RESTORE TABLE test.table AS test.table2
- FROM Disk('backups', 'incremental-a.zip');
-```
-
-### バックアップにパスワードを設定する
-
-ディスクに書き込まれるバックアップファイルには、パスワードを設定できます。
-
-```sql
-BACKUP TABLE test.table
- TO Disk('backups', 'password-protected.zip')
- SETTINGS password='qwerty'
-```
-
-復元：
-
-```sql
-RESTORE TABLE test.table
- FROM Disk('backups', 'password-protected.zip')
- SETTINGS password='qwerty'
-```
-
-### 圧縮設定
-
-圧縮方式や圧縮レベルを指定したい場合は、次のように設定します。
-
-```sql
-BACKUP TABLE test.table
- TO Disk('backups', 'filename.zip')
- SETTINGS compression_method='lzma', compression_level=3
-```
-
-### 特定のパーティションを復元する
-
-テーブルに関連付けられた特定のパーティションのみを復元する必要がある場合は、それらを指定できます。バックアップからパーティション 1 と 4 を復元するには：
-
-```sql
-RESTORE TABLE test.table PARTITIONS '2', '3'
- FROM Disk('backups', 'filename.zip')
-```
-
-### tar アーカイブとしてのバックアップ
-
-バックアップは tar アーカイブとして保存することもできます。パスワードがサポートされていない点を除き、機能は zip の場合と同じです。
-
-バックアップを tar 形式で作成します:
-
-```sql
-BACKUP TABLE test.table TO Disk('backups', '1.tar')
-```
-
-対応するリストア：
-
-```sql
-RESTORE TABLE test.table FROM Disk('backups', '1.tar')
-```
-
-圧縮方式を変更するには、バックアップ名に適切なファイル拡張子を付ける必要があります。例えば、tar アーカイブを gzip で圧縮するには次のようにします。
-
-```sql
-BACKUP TABLE test.table TO Disk('backups', '1.tar.gz')
-```
-
-サポートされている圧縮ファイルの拡張子は、`tar.gz`、`.tgz`、`tar.bz2`、`tar.lzma`、`.tar.zst`、`.tzst`、`.tar.xz` です。
-
-### バックアップのステータスを確認する
-
-バックアップコマンドは `id` と `status` を返し、その `id` を使ってバックアップのステータスを取得できます。これは、時間のかかる ASYNC バックアップの進行状況を確認するのに非常に便利です。以下の例は、既存のバックアップファイルを上書きしようとしたときに発生した失敗を示しています。
-
-```sql
-BACKUP TABLE helloworld.my_first_table TO Disk('backups', '1.zip') ASYNC
-```
-
-```response
-┌─id───────────────────────────────────┬─status──────────┐
-│ 7678b0b3-f519-4e6e-811f-5a0781a4eb52 │ CREATING_BACKUP │
-└──────────────────────────────────────┴─────────────────┘
-
-1行が返されました。経過時間: 0.001秒
-```
-
-```sql
-SELECT
- *
-FROM system.backups
-WHERE id='7678b0b3-f519-4e6e-811f-5a0781a4eb52'
-FORMAT Vertical
-```
-
-```response
-行 1:
-──────
-id: 7678b0b3-f519-4e6e-811f-5a0781a4eb52
-name: Disk('backups', '1.zip')
-#highlight-next-line
-status: BACKUP_FAILED
-num_files: 0
-uncompressed_size: 0
-compressed_size: 0
-#highlight-next-line
-error: Code: 598. DB::Exception: Backup Disk('backups', '1.zip') already exists. (BACKUP_ALREADY_EXISTS) (version 22.8.2.11 (official build))
-start_time: 2022-08-30 09:21:46
-end_time: 2022-08-30 09:21:46
-
-1行のセット。経過時間: 0.002秒
-```
-
-
-`system.backups` テーブルに加えて、すべてのバックアップおよびリストア操作は、システムログテーブル [backup_log](../operations/system-tables/backup_log.md) にも記録されます。
-
-```sql
-SELECT *
-FROM system.backup_log
-WHERE id = '7678b0b3-f519-4e6e-811f-5a0781a4eb52'
-ORDER BY event_time_microseconds ASC
-FORMAT Vertical
-```
-
-```response
-Row 1:
-──────
-event_date: 2023-08-18
-event_time_microseconds: 2023-08-18 11:13:43.097414
-id: 7678b0b3-f519-4e6e-811f-5a0781a4eb52
-name: Disk('backups', '1.zip')
-status: CREATING_BACKUP
-error:
-start_time: 2023-08-18 11:13:43
-end_time: 1970-01-01 03:00:00
-num_files: 0
-total_size: 0
-num_entries: 0
-uncompressed_size: 0
-compressed_size: 0
-files_read: 0
-bytes_read: 0
-
-Row 2:
-──────
-event_date: 2023-08-18
-event_time_microseconds: 2023-08-18 11:13:43.174782
-id: 7678b0b3-f519-4e6e-811f-5a0781a4eb52
-name: Disk('backups', '1.zip')
-status: BACKUP_FAILED
-#highlight-next-line
-error: Code: 598. DB::Exception: Backup Disk('backups', '1.zip') already exists. (BACKUP_ALREADY_EXISTS) (version 23.8.1.1)
-start_time: 2023-08-18 11:13:43
-end_time: 2023-08-18 11:13:43
-num_files: 0
-total_size: 0
-num_entries: 0
-uncompressed_size: 0
-compressed_size: 0
-files_read: 0
-bytes_read: 0
-
-2 rows in set. Elapsed: 0.075 sec.
-```
-
-
-## S3 エンドポイントを使用するように BACKUP/RESTORE を構成する
-
-バックアップを S3 バケットに書き込むには、次の 3 つの情報が必要です。
-
-* S3 エンドポイント\
- 例: `https://mars-doc-test.s3.amazonaws.com/backup-S3/`
-* アクセスキー ID\
- 例: `ABC123`
-* シークレットアクセスキー\
- 例: `Abc+123`
-
-:::note
-S3 バケットの作成手順については、[Use S3 Object Storage as a ClickHouse disk](/integrations/data-ingestion/s3/index.md#configuring-s3-for-clickhouse-use) で説明しています。ポリシーを保存したらこのドキュメントに戻ってください。S3 バケットを使用するように ClickHouse を設定する必要はありません。
-:::
-
-バックアップの保存先は次のように指定します。
-
-```sql
-S3('/<ディレクトリ>', '<アクセスキーID>', '<シークレットアクセスキー>')
-```
-
-```sql
-CREATE TABLE data
-(
- `key` Int,
- `value` String,
- `array` Array(String)
-)
-ENGINE = MergeTree
-ORDER BY tuple()
-```
-
-```sql
-INSERT INTO data SELECT *
-FROM generateRandom('key Int, value String, array Array(String)')
-LIMIT 1000
-```
-
-### ベース（初期）バックアップを作成する
-
-増分バックアップを実行するには、開始点となる *ベース* バックアップが必要です。この例では、後でベースバックアップとして使用します。S3 の宛先の最初のパラメーターは S3 エンドポイントであり、その後に、このバックアップで使用するバケット内のディレクトリを指定します。この例では、ディレクトリ名は `my_backup` です。
-
-```sql
-BACKUP TABLE data TO S3('https://mars-doc-test.s3.amazonaws.com/backup-S3/my_backup', 'ABC123', 'Abc+123')
-```
-
-```response
-┌─id───────────────────────────────────┬─status─────────┐
-│ de442b75-a66c-4a3c-a193-f76f278c70f3 │ BACKUP_CREATED │
-└──────────────────────────────────────┴────────────────┘
-```
-
-### データをさらに追加する
-
-増分バックアップには、ベースバックアップとバックアップ対象テーブルの現在の内容との差分が格納されます。増分バックアップを作成する前に、テーブルにデータを追加します。
-
-```sql
-INSERT INTO data SELECT *
-FROM generateRandom('key Int, value String, array Array(String)')
-LIMIT 100
-```
-
-### 増分バックアップを作成する
-
-このバックアップコマンドはベースバックアップと似ていますが、`SETTINGS base_backup` とベースバックアップの場所を指定する点が異なります。増分バックアップの保存先はベースバックアップと同じディレクトリではなく、同じエンドポイント上のバケット内にある別のターゲットディレクトリであることに注意してください。ベースバックアップは `my_backup` にあり、増分バックアップは `my_incremental` に書き込まれます。
-
-```sql
-BACKUP TABLE data TO S3('https://mars-doc-test.s3.amazonaws.com/backup-S3/my_incremental', 'ABC123', 'Abc+123') SETTINGS base_backup = S3('https://mars-doc-test.s3.amazonaws.com/backup-S3/my_backup', 'ABC123', 'Abc+123')
-```
-
-```response
-┌─id───────────────────────────────────┬─status─────────┐
-│ f6cd3900-850f-41c9-94f1-0c4df33ea528 │ BACKUP_CREATED │
-└──────────────────────────────────────┴────────────────┘
-```
-
-### 増分バックアップからのリストア
-
-このコマンドは、増分バックアップを新しいテーブル `data3` にリストアします。増分バックアップをリストアする場合、ベースバックアップも合わせて含まれることに注意してください。リストア時には、増分バックアップのみを指定してください。
-
-```sql
-RESTORE TABLE data AS data3 FROM S3('https://mars-doc-test.s3.amazonaws.com/backup-S3/my_incremental', 'ABC123', 'Abc+123')
-```
-
-```response
-┌─id───────────────────────────────────┬─status───┐
-│ ff0c8c39-7dff-4324-a241-000796de11ca │ RESTORED │
-└──────────────────────────────────────┴──────────┘
-```
-
-### 件数を確認する
-
-
-元のテーブル `data` には、1,000 行の挿入と 100 行の挿入の 2 回の INSERT が行われており、合計で 1,100 行になっています。復元されたテーブルに 1,100 行あることを確認します。
-
-```sql
-SELECT count()
-FROM data3
-```
-
-```response
-┌─count()─┐
-│ 1100 │
-└─────────┘
-```
-
-
-### 内容を検証する
-
-ここでは、元のテーブル `data` の内容を、復元したテーブル `data3` と比較します。
-
-```sql
-SELECT throwIf((
- SELECT groupArray(tuple(*))
- FROM data
- ) != (
- SELECT groupArray(tuple(*))
- FROM data3
- ), 'BACKUP/RESTORE後にデータが一致しません')
-```
-
-## S3 ディスクを使用した BACKUP/RESTORE
-
-ClickHouse のストレージ設定で S3 ディスクを設定することで、`BACKUP`/`RESTORE` を S3 を対象として実行することもできます。`/etc/clickhouse-server/config.d` にファイルを追加して、次のようにディスクを設定します。
-
-```xml
-
-
-
-
- s3_plain
-
-
-
-
-
-
-
-
-
- s3_plain
-
-
-
-
-
-
-
- s3_plain
-
-
-```
-
-あとは通常どおり `BACKUP`/`RESTORE` を行います。
-
-```sql
-BACKUP TABLE data TO Disk('s3_plain', 'cloud_backup');
-RESTORE TABLE data AS data_restored FROM Disk('s3_plain', 'cloud_backup');
-```
-
-:::note
-ただし、次の点に注意してください。
-
-* このディスクは `MergeTree` 自体には使用せず、`BACKUP`/`RESTORE` のみに使用してください
-* テーブルが S3 ストレージをバックエンドとしている場合、パーツを宛先バケットにコピーする際には、宛先側のクレデンシャルを用いて、`CopyObject` 呼び出しによる S3 のサーバーサイドコピーを試行します。認証エラーが発生した場合は、パーツを一度ダウンロードしてからアップロードするバッファ経由のコピー方式にフォールバックしますが、これは非常に非効率です。この場合、宛先バケットのクレデンシャルに、ソースバケットに対する `read` 権限が付与されていることを確認してください。
- :::
-
-
-## 名前付きコレクションの使用 {#using-named-collections}
-
-名前付きコレクションは `BACKUP/RESTORE` のパラメータとして使用できます。例については [こちら](./named-collections.md#named-collections-for-backups) を参照してください。
-
-
-
-## 代替案 {#alternatives}
-
-ClickHouse はデータをディスク上に保存しますが、ディスクをバックアップする方法は多数あります。以下はこれまでに利用されてきた代替手段の一部であり、お使いの環境にも適合する可能性があります。
-
-### ソースデータを別の場所に複製する {#duplicating-source-data-somewhere-else}
-
-ClickHouse に取り込まれるデータは、多くの場合、[Apache Kafka](https://kafka.apache.org) のような永続的なキューを通じて配信されます。この場合、ClickHouse に書き込まれているのと同じデータストリームを読み取り、どこかのコールドストレージに保存するための追加のサブスクライバーセットを構成することができます。ほとんどの企業には、オブジェクトストアや [HDFS](https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html) のような分散ファイルシステムといった、推奨される標準的なコールドストレージが既に存在します。
-
-### ファイルシステムスナップショット {#filesystem-snapshots}
-
-一部のローカルファイルシステムはスナップショット機能を提供します（たとえば [ZFS](https://en.wikipedia.org/wiki/ZFS)）。しかし、それらはライブクエリを処理する用途には最適とは限りません。考えられる解決策としては、この種のファイルシステムを用いた追加レプリカを作成し、`SELECT` クエリに使用される [Distributed](../engines/table-engines/special/distributed.md) テーブルからそれらを除外する方法があります。このようなレプリカ上のスナップショットは、データを変更するクエリの影響を受けません。さらに、これらのレプリカは 1 サーバーあたりより多くのディスクを接続した特別なハードウェア構成にでき、コスト効率を高められます。
-
-データ量が小さい場合には、リモートテーブルへの単純な `INSERT INTO ... SELECT ...` でも有効な場合があります。
-
-### パーツの操作 {#manipulations-with-parts}
-
-ClickHouse では、`ALTER TABLE ... FREEZE PARTITION ...` クエリを使用してテーブルパーティションのローカルコピーを作成できます。これは `/var/lib/clickhouse/shadow/` フォルダへのハードリンクを使って実装されているため、通常は古いデータに対して追加のディスク容量を消費しません。作成されたファイルのコピーは ClickHouse サーバーによっては扱われないため、そのまま残しておくこともできます。これにより、追加の外部システムを必要としない単純なバックアップが得られますが、それでもハードウェア障害の影響は受けます。このため、別の場所にリモートコピーを行い、その後ローカルコピーを削除する方が望ましいです。この用途には分散ファイルシステムやオブジェクトストアが引き続き有効な選択肢ですが、十分な容量を持つ通常の接続ファイルサーバーも利用可能です（この場合、転送はネットワークファイルシステム経由、または [rsync](https://en.wikipedia.org/wiki/Rsync) によって行われる可能性があります）。
-バックアップからのデータ復元は `ALTER TABLE ... ATTACH PARTITION ...` を用いて実行できます。
-
-パーティション操作に関連するクエリの詳細については、[ALTER のドキュメント](/sql-reference/statements/alter/partition)を参照してください。
-
-このアプローチを自動化するためのサードパーティーツールが利用可能です: [clickhouse-backup](https://github.com/AlexAkulov/clickhouse-backup)。
-
-
-
-## バックアップとリストアの並行実行を禁止するための設定
-
-バックアップとリストアの並行実行を禁止するには、それぞれ次の設定を使用します。
-
-```xml
-
-
- false
- false
-
-
-```
-
-両方のデフォルト値は true なので、デフォルトではバックアップ／リストアの並行実行が許可されています。
-これらの設定がクラスターで false に設定されている場合、そのクラスター上で同時に実行できるバックアップ／リストアは 1 つだけになります。
-
-
-## AzureBlobStorage エンドポイントを使用するように BACKUP/RESTORE を構成する
-
-バックアップを書き込む AzureBlobStorage コンテナには、以下の情報が必要です。
-
-* AzureBlobStorage エンドポイントの接続文字列 / URL
-* コンテナ
-* パス
-* アカウント名（URL が指定されている場合）
-* アカウント キー（URL が指定されている場合）
-
-バックアップの保存先は次のように指定します。
-
-```sql
-AzureBlobStorage('/', '', '', '', '')
-```
-
-```sql
-BACKUP TABLE data TO AzureBlobStorage('DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;BlobEndpoint=http://azurite1:10000/devstoreaccount1/;',
- 'testcontainer', 'data_backup');
-RESTORE TABLE data AS data_restored FROM AzureBlobStorage('DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;BlobEndpoint=http://azurite1:10000/devstoreaccount1/;',
- 'testcontainer', 'data_backup');
-```
-
-
-## システムテーブルのバックアップ {#backup-up-system-tables}
-
-システムテーブルもバックアップおよびリストアのワークフローに含めることができますが、含めるかどうかはユースケースによって異なります。
-
-### ログテーブルのバックアップ {#backing-up-log-tables}
-
-`query_log` や `part_log` のように、`_log` サフィックスを持ち履歴データを保存するシステムテーブルは、他のテーブルと同様にバックアップおよびリストアできます。ユースケースとして履歴データの分析に依存している場合、たとえば `query_log` を使ってクエリパフォーマンスを追跡したり、問題のデバッグに利用したりしている場合には、これらのテーブルをバックアップ戦略に含めることを推奨します。一方で、これらのテーブルの履歴データが不要な場合は、バックアップストレージ容量を節約するために除外できます。
-
-### アクセス管理テーブルのバックアップ {#backing-up-access-management-tables}
-
-`users`、`roles`、`row_policies`、`settings_profiles`、`quotas` など、アクセス管理に関連するシステムテーブルは、バックアップおよびリストア処理の際に特別な扱いを受けます。これらのテーブルがバックアップに含まれている場合、その内容は特別な `accessXX.txt` ファイルにエクスポートされます。このファイルには、アクセスエンティティを作成および構成するための同等の SQL ステートメントが格納されます。リストア時には、リストア処理がこれらのファイルを解釈し、ユーザー、ロール、およびその他の設定を再作成するための SQL コマンドが再適用されます。
-
-この機能により、ClickHouse クラスターのアクセス制御構成を、クラスター全体のセットアップの一部としてバックアップおよびリストアできます。
-
-Note: この機能は、SQL コマンドによって管理される構成（["SQL-driven Access Control and Account Management"](/operations/access-rights#enabling-access-control) と呼ばれます）に対してのみ動作します。ClickHouse サーバーの設定ファイル（例: `users.xml`）で定義されたアクセス構成はバックアップに含まれず、この方法でリストアすることはできません。
diff --git a/i18n/jp/docusaurus-plugin-content-docs/current/operations/caches.md b/i18n/jp/docusaurus-plugin-content-docs/current/operations/caches.md
deleted file mode 100644
index 203a440341f..00000000000
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/caches.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-description: 'クエリの実行時に、ClickHouse はさまざまな種類のキャッシュを使用します。'
-sidebar_label: 'キャッシュ'
-sidebar_position: 65
-slug: /operations/caches
-title: 'キャッシュの種類'
-keywords: ['cache']
-doc_type: 'reference'
----
-
-# キャッシュの種類
-
-クエリを実行する際には、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) ファミリーのテーブルエンジンで使用される非圧縮データのキャッシュ。
-- オペレーティングシステムのページキャッシュ（実データを保持するファイルに対して間接的に利用される）。
-
-このほかにも、多数の追加キャッシュがあります：
-
-- 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)。
-- フォーマットスキーマキャッシュ。
-
-パフォーマンスチューニング、トラブルシューティング、またはデータ整合性の観点から
-これらのキャッシュのいずれかを削除したい場合は、
-[`SYSTEM DROP ... CACHE`](../sql-reference/statements/system.md) ステートメントを使用できます。
\ No newline at end of file
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
deleted file mode 100644
index 24335f17235..00000000000
--- a/i18n/jp/docusaurus-plugin-content-docs/current/operations/cluster-discovery.md
+++ /dev/null
@@ -1,236 +0,0 @@
----
-description: 'ClickHouse のクラスターディスカバリに関するドキュメント'
-sidebar_label: 'クラスターディスカバリ'
-slug: /operations/cluster-discovery
-title: 'クラスターディスカバリ'
-doc_type: 'ガイド'
----
-
-
-
-# クラスターディスカバリ
-
-
-
-## 概要
-
-ClickHouse の Cluster Discovery 機能は、ノードを設定ファイル内で明示的に定義しなくても、自動的に検出して登録できるようにすることで、クラスタの構成を簡素化します。これは、各ノードを手動で定義することが負担になる場合に特に有用です。
-
-:::note
-
-Cluster Discovery は実験的な機能であり、将来のバージョンで変更または削除される可能性があります。
-この機能を有効にするには、設定ファイルに `allow_experimental_cluster_discovery` 設定項目を追加してください。
-
-```xml
-
-
- 1
-
-
-```
-
-:::
-
-
-## リモートサーバーの設定
-
-### 従来の手動設定
-
-従来は ClickHouse では、クラスタ内の各シャードおよびレプリカを設定ファイルで手動指定する必要がありました。
-
-```xml
-
-
-
-
- node1
- 9000
-
-
- node2
- 9000
-
-
-
-
- node3
- 9000
-
-
- node4
- 9000
-
-
-
-
-
-```
-
-### クラスター検出を使用する
-
-Cluster Discovery を使用すると、各ノードを明示的に定義する代わりに、ZooKeeper 内のパスを 1 つ指定するだけで済みます。ZooKeeper のそのパス配下に登録されたすべてのノードは、自動的に検出されてクラスターに追加されます。
-
-```xml
-
-
-
- /clickhouse/discovery/cluster_name
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-特定のノードに対してシャード番号を指定したい場合は、`` セクション内に `` タグを記述できます。
-
-`node1` および `node2` の場合:
-
-```xml
-
- /clickhouse/discovery/cluster_name
- 1
-
-```
-
-`node3` および `node4` の場合:
-
-```xml
-
- /clickhouse/discovery/cluster_name
- 2
-
-```
-
-### オブザーバーモード
-
-オブザーバーモードで構成されたノードは、自身をレプリカとして登録しません。
-これらのノードはクラスター内の他のアクティブなレプリカを監視・検出するだけで、能動的には参加しません。
-オブザーバーモードを有効にするには、`` セクション内に `` タグを追加します。
-
-```xml
-
- /clickhouse/discovery/cluster_name
-
-
-```
-
-### クラスターの検出
-
-場合によっては、クラスター内のホストだけでなく、クラスター自体を追加・削除する必要が生じることがあります。複数のクラスターのルートパスを指定するために `` ノードを使用できます。
-
-```xml
-
-
-
- /clickhouse/discovery
-
-
-
-
-```
-
-この場合、別のホストがパス `/clickhouse/discovery/some_new_cluster` で自分自身を登録すると、名前が `some_new_cluster` のクラスタが追加されます。
-
-両方の機能を同時に使用できます。ホストはクラスタ `my_cluster` に自分自身を登録しつつ、他の任意のクラスタを検出することもできます。
-
-```xml
-
-
-
- /clickhouse/discovery/my_cluster
-
-
-
-
- /clickhouse/discovery
-
-
-
-
-```
-
-制限事項:
-
-* 同じ `remote_servers` サブツリー内で `` と `` を同時に使用することはできません。
-* `` と併用できるのは `` のみです。
-* Keeper で指定されたパスの最後の部分がクラスタ名として使用されますが、登録時には XML タグに記載された名前が使用されます。
-
-
-## ユースケースと制限事項
-
-指定された ZooKeeper パスにノードが追加または削除されると、構成変更やサーバーの再起動を行うことなく、それらのノードはクラスターに自動的に認識されて参加するか、クラスターから削除されます。
-
-ただし、変更の対象はクラスター構成のみであり、データや既存のデータベースおよびテーブルには影響しません。
-
-3 ノードのクラスターを用いた次の例を考えます。
-
-```xml
-
-
-
-