ClickHouse · Blargian · Jun 9, 2025 · Jun 3, 2025 · Jun 3, 2025 · Jun 3, 2025
@@ -8,7 +8,7 @@
 
 
 
-ClickHouseは、半構造化データおよび動的データ用に設計されたネイティブJSONカラム型を提供しています。重要なことは、**これはデータ形式ではなく、カラム型であることを明確にすること**です。 JSONを文字列としてClickHouseに挿入したり、[JSONEachRow](/docs/interfaces/formats/JSONEachRow)などのサポートされている形式を使用することができますが、JSONカラム型を使用することを意味するわけではありません。ユーザーは、自分のデータの構造が動的である場合にのみJSON型を使用すべきです。単にJSONを保存している場合には使用すべきではありません。
+ClickHouseは、半構造化データおよび動的データ用に設計されたネイティブJSONカラム型を提供しています。重要なことは、**これはデータ形式ではなく、カラム型であることを明確にすること**です。 JSONを文字列としてClickHouseに挿入したり、[JSONEachRow](/interfaces/formats/JSONEachRow)などのサポートされている形式を使用することができますが、JSONカラム型を使用することを意味するわけではありません。ユーザーは、自分のデータの構造が動的である場合にのみJSON型を使用すべきです。単にJSONを保存している場合には使用すべきではありません。
 
 ## JSON型を使用するタイミング {#when-to-use-the-json-type}
 

@@ -16,10 +16,10 @@ in the table of contents, please edit the frontmatter of the files directly.
 -->
 | ページ | 説明 |
 |-----|-----|
-| [要約](/docs/cloud/manage/jan-2025-faq/summary) | 新しい ClickHouse Cloud タイアの要約 |
-| [新しいタイアの説明](/docs/cloud/manage/jan-2025-faq/new-tiers) | 新しいタイアと機能の説明 |
-| [請求](/docs/cloud/manage/jan-2025-faq/billing) | 新しい価格タイアの請求の詳細 |
-| [新しい価格次元](/docs/cloud/manage/jan-2025-faq/pricing-dimensions) | データ転送と ClickPipes の価格次元 |
-| [スケーリング](/docs/cloud/manage/jan-2025-faq/scaling) | 新しい価格タイアのスケーリング動作 |
-| [バックアップポリシー](/docs/cloud/manage/jan-2025-faq/backup) | 新しいタイアのバックアップポリシー |
-| [新プランへの移行](/docs/cloud/manage/jan-2025-faq/plan-migrations) | 新しいプラン、タイア、価格への移行、決定方法、コストの見積もり |
+| [要約](/cloud/manage/jan-2025-faq/summary) | 新しい ClickHouse Cloud タイアの要約 |
+| [新しいタイアの説明](/cloud/manage/jan-2025-faq/new-tiers) | 新しいタイアと機能の説明 |
+| [請求](/cloud/manage/jan-2025-faq/billing) | 新しい価格タイアの請求の詳細 |
+| [新しい価格次元](/cloud/manage/jan-2025-faq/pricing-dimensions) | データ転送と ClickPipes の価格次元 |
+| [スケーリング](/cloud/manage/jan-2025-faq/scaling) | 新しい価格タイアのスケーリング動作 |
+| [バックアップポリシー](/cloud/manage/jan-2025-faq/backup) | 新しいタイアのバックアップポリシー |
+| [新プランへの移行](/cloud/manage/jan-2025-faq/plan-migrations) | 新しいプラン、タイア、価格への移行、決定方法、コストの見積もり |
@@ -28,15 +28,15 @@ ClickHouseでは、各テーブルは複数の「テーブルパーツ」で構
 
  VLDB論文の包括的なパフォーマンス最適化セクション。
 
-🤿 これは、私たちのVLDB 2024論文のウェブ版の[ディスク上フォーマット](/docs/academic_overview#3-1-on-disk-format)セクションで詳しく述べています。
+🤿 これは、私たちのVLDB 2024論文のウェブ版の[ディスク上フォーマット](/academic_overview#3-1-on-disk-format)セクションで詳しく述べています。
 
 ## Storage Layer: Concurrent inserts and selects are isolated {#storage-layer-concurrent-inserts-and-selects-are-isolated}
 
 <iframe width="1024" height="576" src="https://www.youtube.com/embed/dvGlPh2bJFo?si=F3MSALPpe0gAoq5k" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
 
 挿入はSELECTクエリから完全に隔離されており、挿入されたデータパーツのマージは、同時クエリに影響を与えることなくバックグラウンドで行われます。
 
-🤿 これは、私たちのVLDB 2024論文のウェブ版の[ストレージ層](/docs/academic_overview#3-storage-layer)セクションで詳しく述べています。
+🤿 これは、私たちのVLDB 2024論文のウェブ版の[ストレージ層](/academic_overview#3-storage-layer)セクションで詳しく述べています。
 
 ## Storage Layer: Merge-time computation {#storage-layer-merge-time-computation}
 
@@ -56,7 +56,7 @@ ClickHouseは、他のデータベースとは異なり、すべての追加デ
 
 他方では、マージのランタイムの大部分が入力パーツの読み込みと出力パーツの保存に消費されます。マージ中のデータ変換のための追加の努力は、通常、マージのランタイムにあまり影響しません。これらすべてのマジックは完全に透明であり、クエリの結果に影響を与えることはありません（性能を除いて）。
 
-🤿 これは、私たちのVLDB 2024論文のウェブ版の[マージ時間データ変換](/docs/academic_overview#3-3-merge-time-data-transformation)セクションで詳しく述べています。
+🤿 これは、私たちのVLDB 2024論文のウェブ版の[マージ時間データ変換](/academic_overview#3-3-merge-time-data-transformation)セクションで詳しく述べています。
 
 ## Storage Layer: Data pruning {#storage-layer-data-pruning}
 
@@ -72,7 +72,7 @@ ClickHouseは、他のデータベースとは異なり、すべての追加デ
 
 これら3つの技術の目的は、フルカラムリード中にできるだけ多くの行をスキップすることであり、データを読み込む最も速い方法は、データをまったく読み込まないことです。
 
-🤿 これは、私たちのVLDB 2024論文のウェブ版の[データプルーニング](/docs/academic_overview#3-2-data-pruning)セクションで詳しく述べています。
+🤿 これは、私たちのVLDB 2024論文のウェブ版の[データプルーニング](/academic_overview#3-2-data-pruning)セクションで詳しく述べています。
 
 ## Storage Layer: Data compression {#storage-layer-data-compression}
 
@@ -86,7 +86,7 @@ ClickHouseは、他のデータベースとは異なり、すべての追加デ
 
 データ圧縮は、データベーステーブルのストレージサイズを減少させるだけでなく、多くの場合、ローカルディスクやネットワークI/Oのスループットが低いため、クエリのパフォーマンスも向上させます。
 
-🤿 これは、私たちのVLDB 2024論文のウェブ版の[ディスク上フォーマット](/docs/academic_overview#3-1-on-disk-format)セクションで詳しく述べています。
+🤿 これは、私たちのVLDB 2024論文のウェブ版の[ディスク上フォーマット](/academic_overview#3-1-on-disk-format)セクションで詳しく述べています。
 
 ## State-of-the-art query processing layer {#state-of-the-art-query-processing-layer}
 
@@ -139,7 +139,7 @@ ClickHouseを[特徴付ける](https://www.youtube.com/watch?v=CAS2otEoerM)の
 VLDBは非常に大規模なデータベースに関する国際会議であり、データ管理の分野でリーディングカンファレンスの一つと広く見なされています。
 数百件の投稿の中から、VLDBは一般的に約20％の受理率を持っています。
 
-論文の[PDF](https://www.vldb.org/pvldb/vol17/p3731-schulze.pdf)や、ClickHouseの最も興味深いアーキテクチャやシステム設計コンポーネントを簡潔に説明する[ウェブ版](/docs/academic_overview)を読むことができます。
+論文の[PDF](https://www.vldb.org/pvldb/vol17/p3731-schulze.pdf)や、ClickHouseの最も興味深いアーキテクチャやシステム設計コンポーネントを簡潔に説明する[ウェブ版](/academic_overview)を読むことができます。
 
 私たちのCTOでありClickHouseの創設者であるAlexey Milovidovが論文を発表しました（スライドは[こちら](https://raw.githubusercontent.com/ClickHouse/clickhouse-presentations/master/2024-vldb/VLDB_2024_presentation.pdf)）その後、Q&Aが行われました（すぐに時間切れになりました！）。
 録画されたプレゼンテーションはこちらで確認できます：

@@ -441,5 +441,5 @@ LIMIT 100
 
 ## 関連コンテンツ {#related-content}
 - [ClickHouseにおける主インデックスの実用的な導入](/guides/best-practices/sparse-primary-indexes#option-3-projections)
-- [Materialized Views](/docs/materialized-views)
+- [Materialized Views](/materialized-views)
 - [ALTER PROJECTION](/sql-reference/statements/alter/projection)
@@ -65,7 +65,7 @@ ClickHouse Cloudは、上記のアーキテクチャとは非常に異なるア
 ただし、クエリの実行を複数のサーバーに分散するには、どうすればよいのでしょうか？ シャーディングアーキテクチャでは、各シャードがデータのサブセットに対してクエリを実行できるため、それは非常に明白でした。シャーディングがない場合、これはどのように機能するのでしょうか？
 ## 並列レプリカの導入 {#introducing-parallel-replicas}
 
-複数のサーバーを通じてクエリ実行を並列化するには、まずコーディネーターとして機能するサーバーを指定できる必要があります。コーディネーターは、実行される必要があるタスクのリストを作成し、それらがすべて実行され、集約され、結果がクライアントに返されることを保証します。ほとんどの分散システムと同様に、これは初期クエリを受け取ったノードの役割となります。また、作業の単位を定義する必要があります。シャーディングアーキテクチャでは、作業の単位はシャードであり、データのサブセットです。並列レプリカでは、[グラニュール](/docs/guides/best-practices/sparse-primary-indexes#data-is-organized-into-granules-for-parallel-data-processing)と呼ばれるテーブルの小さな部分を作業の単位として使用します。
+複数のサーバーを通じてクエリ実行を並列化するには、まずコーディネーターとして機能するサーバーを指定できる必要があります。コーディネーターは、実行される必要があるタスクのリストを作成し、それらがすべて実行され、集約され、結果がクライアントに返されることを保証します。ほとんどの分散システムと同様に、これは初期クエリを受け取ったノードの役割となります。また、作業の単位を定義する必要があります。シャーディングアーキテクチャでは、作業の単位はシャードであり、データのサブセットです。並列レプリカでは、[グラニュール](/guides/best-practices/sparse-primary-indexes#data-is-organized-into-granules-for-parallel-data-processing)と呼ばれるテーブルの小さな部分を作業の単位として使用します。
 
 次に、以下の図を使って、実践でどのように機能するかを見てみましょう：
 
@@ -225,7 +225,7 @@ ClickHouse Cloudは、上記のアーキテクチャとは非常に異なるア
 | 制限事項                                     | 説明                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
 |--------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | 複雑なクエリ                                   | 現在、並列レプリカは単純なクエリにはかなりうまく機能します。CTE、サブクエリ、JOIN、非平坦クエリなどの複雑さがクエリ性能に悪影響を及ぼす可能性があります。                                                                                                                                                                                                                                                                                   |
-| 小規模なクエリ                                  | 多くの行を処理しないクエリを実行する場合、複数のレプリカで実行すると、レプリカ間のコーディネーションのネットワーク時間がクエリ実行に追加のサイクルをもたらす可能性があるため、パフォーマンスが向上しない場合があります。これらの問題を制限するために、設定を使用することができます：[`parallel_replicas_min_number_of_rows_per_replica`](/docs/operations/settings/settings#parallel_replicas_min_number_of_rows_per_replica)。  |
+| 小規模なクエリ                                  | 多くの行を処理しないクエリを実行する場合、複数のレプリカで実行すると、レプリカ間のコーディネーションのネットワーク時間がクエリ実行に追加のサイクルをもたらす可能性があるため、パフォーマンスが向上しない場合があります。これらの問題を制限するために、設定を使用することができます：[`parallel_replicas_min_number_of_rows_per_replica`](/operations/settings/settings#parallel_replicas_min_number_of_rows_per_replica)。  |
 | FINALで並列レプリカは無効                     |                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
 | 高いカーディナリティデータと複雑な集計            | 多くのデータを送信する必要がある高いカーディナリティの集計が、クエリを著しく遅くする可能性があります。                                                                                                                                                                                                                                                                                                                                                                     |
 | 新しいアナライザーとの互換性                     | 新しいアナライザーは、特定のシナリオでクエリ実行を大幅に遅くしたり、早くしたりする可能性があります。                                                                                                                                                                                                                                                                                                                                                                       |
@@ -240,7 +240,7 @@ ClickHouse Cloudは、上記のアーキテクチャとは非常に異なるア
 | `allow_experimental_analyzer`                | `0`: 古いアナライザーを使用<br/> `1`: 新しいアナライザーを使用します。<br/><br/>並列レプリカの動作は使用するアナライザーによって変わる可能性があります。                                                                                                                                    |
 ## 並列レプリカの問題調査 {#investigating-issues-with-parallel-replicas}
 
-各クエリに使用されている設定を確認するには、[`system.query_log`](/docs/operations/system-tables/query_log) テーブルを使用できます。また、[`system.events`](/docs/operations/system-tables/events) テーブルを見ることで、サーバー上で発生したすべてのイベントを確認できます。さらに、[`clusterAllReplicas`](/docs/sql-reference/table-functions/cluster) テーブル関数を使用して、すべてのレプリカ上のテーブルを確認できます（クラウドユーザーの場合は、`default`を使用します）。
+各クエリに使用されている設定を確認するには、[`system.query_log`](/operations/system-tables/query_log) テーブルを使用できます。また、[`system.events`](/operations/system-tables/events) テーブルを見ることで、サーバー上で発生したすべてのイベントを確認できます。さらに、[`clusterAllReplicas`](/sql-reference/table-functions/cluster) テーブル関数を使用して、すべてのレプリカ上のテーブルを確認できます（クラウドユーザーの場合は、`default`を使用します）。
 
 ```sql title="クエリ"
 SELECT
@@ -299,7 +299,7 @@ WHERE event ILIKE '%ParallelReplicas%'
 
 </details>
 
-[`system.text_log`](/docs/operations/system-tables/text_log) テーブルには、並列レプリカを使用したクエリの実行に関する情報も含まれています：
+[`system.text_log`](/operations/system-tables/text_log) テーブルには、並列レプリカを使用したクエリの実行に関する情報も含まれています：
 
 ```sql title="クエリ"
 SELECT message

@@ -16,7 +16,7 @@
 
 # ClickHouseと他のシステムの統合に関する質問
 
-- [ClickHouseからファイルにデータをエクスポートするには？](https://clickhouse.com/docs/knowledgebase/file-export)
+- [ClickHouseからファイルにデータをエクスポートするには？](/knowledgebase/file-export)
 - [JSONをClickHouseにインポートする方法は？](/integrations/data-ingestion/data-formats/json/intro.md)
 - [KafkaをClickHouseに接続するには？](/integrations/data-ingestion/kafka/index.md)
 - [JavaアプリケーションをClickHouseに接続できますか？](/integrations/data-ingestion/dbms/jdbc-with-clickhouse.md)

@@ -20,7 +20,7 @@
 
 ## 説明 {#description}
 
-[`SimpleState`](/sql-reference/aggregate-functions/combinators#-simplestate) コンビネーターは、[`min`](/sql-reference/aggregate-functions/reference/min) 関数に適用され、すべての入力値の中で最小値を返します。結果は [`SimpleAggregateFunction`](/docs/sql-reference/data-types/simpleaggregatefunction) 型で返されます。
+[`SimpleState`](/sql-reference/aggregate-functions/combinators#-simplestate) コンビネーターは、[`min`](/sql-reference/aggregate-functions/reference/min) 関数に適用され、すべての入力値の中で最小値を返します。結果は [`SimpleAggregateFunction`](/sql-reference/data-types/simpleaggregatefunction) 型で返されます。
 
 ## 使用例 {#example-usage}
Original file line number	Diff line number	Diff line change
Expand Up		@@ -8,7 +8,7 @@



		ClickHouseは、半構造化データおよび動的データ用に設計されたネイティブJSONカラム型を提供しています。重要なことは、これはデータ形式ではなく、カラム型であることを明確にすることです。 JSONを文字列としてClickHouseに挿入したり、[JSONEachRow](/docs/interfaces/formats/JSONEachRow)などのサポートされている形式を使用することができますが、JSONカラム型を使用することを意味するわけではありません。ユーザーは、自分のデータの構造が動的である場合にのみJSON型を使用すべきです。単にJSONを保存している場合には使用すべきではありません。
		ClickHouseは、半構造化データおよび動的データ用に設計されたネイティブJSONカラム型を提供しています。重要なことは、これはデータ形式ではなく、カラム型であることを明確にすることです。 JSONを文字列としてClickHouseに挿入したり、[JSONEachRow](/interfaces/formats/JSONEachRow)などのサポートされている形式を使用することができますが、JSONカラム型を使用することを意味するわけではありません。ユーザーは、自分のデータの構造が動的である場合にのみJSON型を使用すべきです。単にJSONを保存している場合には使用すべきではありません。

		## JSON型を使用するタイミング {#when-to-use-the-json-type}

Expand Down