Merge pull request #3411 from ClickHouse/translate_ja

move images to static

Author: gingerwizard

docs/chdb/guides/jupysql.md

@@ -6,6 +6,8 @@ description: How to install chDB for Bun
 keywords: [chdb, JupySQL]
 ---
 
+import PlayersPerRank from '@site/static/images/chdb/guides/players_per_rank.png';
+
 [JupySQL](https://jupysql.ploomber.io/en/latest/quick-start.html) is a Python library that lets you run SQL in Jupyter notebooks and the IPython shell.
 In this guide, we're going to learn how to query data using chDB and JupySQL.
 
@@ -71,7 +73,7 @@ Next, let's import the `dbapi` module for chDB:
 from chdb import dbapi
 ```
 
-And we'll create a chDB connection. 
+And we'll create a chDB connection.
 Any data that we persist will be saved to the `atp.chdb` directory:
 
 ```python
@@ -93,7 +95,7 @@ Next, we'll display the display limit so that results of queries won't be trunca
 
 ## Querying data in CSV files {#querying-data-in-csv-files}
 
-We've downloaded a bunch of files with the `atp_rankings` prefix. 
+We've downloaded a bunch of files with the `atp_rankings` prefix.
 Let's use the `DESCRIBE` clause to understand the schema:
 
 
@@ -273,7 +275,7 @@ We're going to write a query that finds the maximum points accumulate by each pl
 
 ```python
 %%sql
-SELECT name_first, name_last, 
+SELECT name_first, name_last,
        max(points) as maxPoints,
        argMax(rank, points) as rank,
        argMax(ranking_date, points) as date
@@ -305,12 +307,12 @@ It's quite interesting that some of the players in this list accumulated a lot o
 
 ## Saving queries {#saving-queries}
 
-We can save queries using the `--save` parameter on the same line as the `%%sql` magic. 
+We can save queries using the `--save` parameter on the same line as the `%%sql` magic.
 The `--no-execute` parameter means that query execution will be skipped.
 
 ```python
 %%sql --save best_points --no-execute
-SELECT name_first, name_last, 
+SELECT name_first, name_last,
        max(points) as maxPoints,
        argMax(rank, points) as rank,
        argMax(ranking_date, points) as date
@@ -357,7 +359,7 @@ Parameters are just normal variables:
 rank = 10
 ```
 
-And then we can use the `{{variable}}` syntax in our query. 
+And then we can use the `{{variable}}` syntax in our query.
 The following query finds the players who had the least number of days between when they first had a ranking in the top 10 and last had a ranking in the top 10:
 
 ```python
@@ -422,4 +424,4 @@ plot = (
 )
 ```
 
-<img src={require('./images/players_per_rank.png').default} class="image" alt="Migrating Self-managed ClickHouse" style={{width: '90%', padding: '30px'}}/>
+<img src={PlayersPerRank} alt="Histogram of player rankings in ATP dataset" class="image" style={{width: '90%', padding: '30px'}} />

docs/data-compression/compression-modes.md

@@ -6,6 +6,8 @@ description: ClickHouse column compression modes
 keywords: [compression, codec, encoding, modes]
 ---
 
+import CompressionBlock from '@site/static/images/data-compression/ch_compression_block.png';
+
 # Compression modes
 
 ClickHouse protocol supports **data blocks** compression with checksums.
@@ -41,7 +43,7 @@ From [Facebook benchmarks](https://facebook.github.io/zstd/#benchmarks):
 | mode            | byte    | Compression mode                                 |
 | compressed_data | binary  | Block of compressed data                         |
 
-![compression block diagram](./images/ch_compression_block.png)
+<img src={CompressionBlock} alt="Diagram illustrating ClickHouse compression block structure" />
 
 Header is (raw_size + data_size + mode), raw size consists of len(header + compressed_data).
 

docs/deployment-guides/horizontal-scaling.md

@@ -6,7 +6,7 @@ title: Scaling out
 ---
 import ReplicationShardingTerminology from '@site/docs/_snippets/_replication-sharding-terminology.md';
 import ConfigFileNote from '@site/docs/_snippets/_config-files.md';
-
+import scalingOut1 from '@site/static/images/deployment-guides/scaling-out-1.png';
 
 ## Description {#description}
 This example architecture is designed to provide scalability.  It includes three nodes: two combined ClickHouse plus coordination (ClickHouse Keeper) servers, and a third server with only ClickHouse Keeper to finish the quorum of three. With this example, we'll create a database, table, and a distributed table that will be able to query the data on both of the nodes.
@@ -17,7 +17,8 @@ This example architecture is designed to provide scalability.  It includes three
 
 ## Environment {#environment}
 ### Architecture Diagram {#architecture-diagram}
-![Architecture diagram for 2 shards and 1 replica](@site/docs/deployment-guides/images/scaling-out-1.png)
+
+<img src={scalingOut1} alt="Architecture diagram for 2 shards and 1 replica" />
 
 |Node|Description|
 |----|-----------|
@@ -31,7 +32,7 @@ In production environments we strongly recommend that ClickHouse Keeper runs on
 
 ## Install {#install}
 
-Install Clickhouse on three servers following the [instructions for your archive type](/getting-started/install.md/#available-installation-options) (.deb, .rpm, .tar.gz, etc.). For this example, you will follow the installation instructions for ClickHouse Server and Client on all three machines.       
+Install Clickhouse on three servers following the [instructions for your archive type](/getting-started/install.md/#available-installation-options) (.deb, .rpm, .tar.gz, etc.). For this example, you will follow the installation instructions for ClickHouse Server and Client on all three machines.
 
 ## Editing configuration files {#editing-configuration-files}
 
@@ -45,7 +46,7 @@ For `chnode1`, there are five configuration files.  You may choose to combine th
 
 These values can be customized as you wish.  This example configuration gives you a debug log that will roll over at 1000M three times.  ClickHouse will listen on the IPv4 network on ports 8123 and 9000, and will use port 9009 for interserver communication.
 
-```xml title="network-and-logging.xml on chnode1" 
+```xml title="network-and-logging.xml on chnode1"
 <clickhouse>
         <logger>
                 <level>debug</level>
@@ -110,8 +111,8 @@ If for any reason a Keeper node is replaced or rebuilt, do not reuse an existing
 
 ### Macros configuration {#macros-configuration}
 
-The macros `shard` and `replica` reduce the complexity of distributed DDL.  The values configured are automatically substituted in your DDL queries, which simplifies your DDL.  The macros for this configuration specify the shard and replica number for each node.  
-In this 2 shard 1 replica example, the replica macro is `replica_1` on both chnode1 and chnode2 as there is only one replica.  The shard macro is `1` on chnode1 and `2` on chnode2. 
+The macros `shard` and `replica` reduce the complexity of distributed DDL.  The values configured are automatically substituted in your DDL queries, which simplifies your DDL.  The macros for this configuration specify the shard and replica number for each node.
+In this 2 shard 1 replica example, the replica macro is `replica_1` on both chnode1 and chnode2 as there is only one replica.  The shard macro is `1` on chnode1 and `2` on chnode2.
 
 ```xml title="macros.xml on chnode1"
 <clickhouse>
@@ -126,7 +127,7 @@ In this 2 shard 1 replica example, the replica macro is `replica_1` on both chno
 ### Replication and sharding configuration {#replication-and-sharding-configuration}
 
 Starting from the top:
-- The `remote_servers` section of the XML specifies each of the clusters in the environment. The attribute `replace=true` replaces the sample `remote_servers` in the default ClickHouse configuration with the `remote_servers` configuration specified in this file.  Without this attribute, the remote servers in this file would be appended to the list of samples in the default.  
+- The `remote_servers` section of the XML specifies each of the clusters in the environment. The attribute `replace=true` replaces the sample `remote_servers` in the default ClickHouse configuration with the `remote_servers` configuration specified in this file.  Without this attribute, the remote servers in this file would be appended to the list of samples in the default.
 - In this example, there is one cluster named `cluster_2S_1R`.
 - A secret is created for the cluster named `cluster_2S_1R` with the value `mysecretphrase`.  The secret is shared across all of the remote servers in the environment to ensure that the correct servers are joined together.
 - The cluster `cluster_2S_1R` has two shards, and each of those shards has one replica.  Take a look at the architecture diagram toward the beginning of this document, and compare it with the two `shard` definitions in the XML below.  In each of the shard definitions there is one replica.  The replica is for that specific shard.  The host and port for that replica is specified.  The replica for the first shard in the configuration is stored on `chnode1`, and the replica for the second shard in the configuration is stored on `chnode2`.
@@ -158,7 +159,7 @@ Starting from the top:
 
 ### Configuring the use of Keeper {#configuring-the-use-of-keeper}
 
-Up above a few files ClickHouse Keeper was configured.  This configuration file `use-keeper.xml` is configuring ClickHouse Server to use ClickHouse Keeper for the coordination of replication and distributed DDL.  This file specifies that ClickHouse Server should use Keeper on nodes chnode1 - 3 on port 9181, and the file is the same on `chnode1` and `chnode2`.  
+Up above a few files ClickHouse Keeper was configured.  This configuration file `use-keeper.xml` is configuring ClickHouse Server to use ClickHouse Keeper for the coordination of replication and distributed DDL.  This file specifies that ClickHouse Server should use Keeper on nodes chnode1 - 3 on port 9181, and the file is the same on `chnode1` and `chnode2`.
 
 ```xml title="use-keeper.xml on chnode1"
 <clickhouse>
@@ -185,7 +186,7 @@ As the configuration is very similar on `chnode1` and `chnode2`, only the differ
 
 ### Network and logging configuration {#network-and-logging-configuration-1}
 
-```xml title="network-and-logging.xml on chnode2" 
+```xml title="network-and-logging.xml on chnode2"
 <clickhouse>
         <logger>
                 <level>debug</level>
@@ -311,7 +312,7 @@ As `chnode3` is not storing data and is only used for ClickHouse Keeper to provi
 
 ### Network and logging configuration {#network-and-logging-configuration-2}
 
-```xml title="network-and-logging.xml on chnode3" 
+```xml title="network-and-logging.xml on chnode3"
 <clickhouse>
         <logger>
                 <level>debug</level>
@@ -480,4 +481,3 @@ SELECT * FROM db1.table1_dist;
 
 - The [Distributed Table Engine](/engines/table-engines/special/distributed.md)
 - [ClickHouse Keeper](/guides/sre/keeper/index.md)
-

docs/deployment-guides/replicated.md

@@ -4,10 +4,11 @@ sidebar_label: Replication for fault tolerance
 sidebar_position: 10
 title: Replication for fault tolerance
 ---
+
 import ReplicationShardingTerminology from '@site/docs/_snippets/_replication-sharding-terminology.md';
 import ConfigFileNote from '@site/docs/_snippets/_config-files.md';
 import KeeperConfigFileNote from '@site/docs/_snippets/_keeper-config-files.md';
-
+import ReplicationArchitecture from '@site/static/images/deployment-guides/architecture_1s_2r_3_nodes.png';
 
 ## Description {#description}
 In this architecture, there are five servers configured. Two are used to host copies of the data. The other three servers are used to coordinate the replication of data. With this example, we'll create a database and table that will be replicated across both data nodes using the ReplicatedMergeTree table engine.
@@ -18,7 +19,8 @@ In this architecture, there are five servers configured. Two are used to host co
 
 ## Environment {#environment}
 ### Architecture Diagram {#architecture-diagram}
-![Architecture diagram for 1 shard and 2 replicas with ReplicatedMergeTree](@site/docs/deployment-guides/images/Architecture.1S_2R_ReplicatedMergeTree_5-nodes.3.CH.Keeper.nodes.2.CH.nodes.png)
+
+<img src={ReplicationArchitecture} alt="Architecture diagram for 1 shard and 2 replicas with ReplicatedMergeTree" />
 
 |Node|Description|
 |----|-----------|
@@ -34,7 +36,7 @@ In production environments, we strongly recommend using *dedicated* hosts for Cl
 
 ## Install {#install}
 
-Install ClickHouse server and client on the two servers `clickhouse-01` and `clickhouse-02` following the [instructions for your archive type](/getting-started/install.md/#available-installation-options) (.deb, .rpm, .tar.gz, etc.). 
+Install ClickHouse server and client on the two servers `clickhouse-01` and `clickhouse-02` following the [instructions for your archive type](/getting-started/install.md/#available-installation-options) (.deb, .rpm, .tar.gz, etc.).
 
 Install ClickHouse Keeper on the three servers `clickhouse-keeper-01`, `clickhouse-keeper-02` and `clickhouse-keeper-03` following the [instructions for your archive type](/getting-started/install.md/#install-standalone-clickhouse-keeper) (.deb, .rpm, .tar.gz, etc.).
 
@@ -53,7 +55,7 @@ These values can be customized as you wish.  This example configuration gives yo
 - the name displayed when you connect with `clickhouse-client` is `cluster_1S_2R node 1`
 - ClickHouse will listen on the IPV4 network on ports 8123 and 9000.
 
-```xml title="/etc/clickhouse-server/config.d/network-and-logging.xml on clickhouse-01" 
+```xml title="/etc/clickhouse-server/config.d/network-and-logging.xml on clickhouse-01"
 <clickhouse>
     <logger>
         <level>debug</level>
@@ -71,8 +73,8 @@ These values can be customized as you wish.  This example configuration gives yo
 
 ### Macros configuration {#macros-configuration}
 
-The macros `shard` and `replica` reduce the complexity of distributed DDL.  The values configured are automatically substituted in your DDL queries, which simplifies your DDL.  The macros for this configuration specify the shard and replica number for each node.  
-In this 1 shard 2 replica example, the replica macro is `replica_1` on clickhouse-01 and `replica_2` on clickhouse-02.  The shard macro is `1` on both clickhouse-01 and clickhouse-02 as there is only one shard. 
+The macros `shard` and `replica` reduce the complexity of distributed DDL.  The values configured are automatically substituted in your DDL queries, which simplifies your DDL.  The macros for this configuration specify the shard and replica number for each node.
+In this 1 shard 2 replica example, the replica macro is `replica_1` on clickhouse-01 and `replica_2` on clickhouse-02.  The shard macro is `1` on both clickhouse-01 and clickhouse-02 as there is only one shard.
 
 ```xml title="/etc/clickhouse-server/config.d/macros.xml on clickhouse-01"
 <clickhouse>
@@ -88,7 +90,7 @@ In this 1 shard 2 replica example, the replica macro is `replica_1` on clickhous
 ### Replication and sharding configuration {#replication-and-sharding-configuration}
 
 Starting from the top:
-- The remote_servers section of the XML specifies each of the clusters in the environment. The attribute `replace=true` replaces the sample remote_servers in the default ClickHouse configuration with the remote_server configuration specified in this file.  Without this attribute the remote servers in this file would be appended to the list of samples in the default.  
+- The remote_servers section of the XML specifies each of the clusters in the environment. The attribute `replace=true` replaces the sample remote_servers in the default ClickHouse configuration with the remote_server configuration specified in this file.  Without this attribute the remote servers in this file would be appended to the list of samples in the default.
 - In this example, there is one cluster named `cluster_1S_2R`.
 - A secret is created for the cluster named `cluster_1S_2R` with the value `mysecretphrase`.  The secret is shared across all of the remote servers in the environment to ensure that the correct servers are joined together.
 - The cluster `cluster_1S_2R` has one shard, and two replicas.  Take a look at the architecture diagram toward the beginning of this document, and compare it with the `shard` definition in the XML below.  The shard definition contains two replicas.  The host and port for each replica is specified.  One replica is stored on `clickhouse-01`, and the other replica is stored on `clickhouse-02`.
@@ -117,7 +119,7 @@ Starting from the top:
 
 ### Configuring the use of Keeper {#configuring-the-use-of-keeper}
 
-This configuration file `use-keeper.xml` is configuring ClickHouse Server to use ClickHouse Keeper for the coordination of replication and distributed DDL.  This file specifies that ClickHouse Server should use Keeper on nodes clickhouse-keeper-01 - 03 on port 9181, and the file is the same on `clickhouse-01` and `clickhouse-02`.  
+This configuration file `use-keeper.xml` is configuring ClickHouse Server to use ClickHouse Keeper for the coordination of replication and distributed DDL.  This file specifies that ClickHouse Server should use Keeper on nodes clickhouse-keeper-01 - 03 on port 9181, and the file is the same on `clickhouse-01` and `clickhouse-02`.
 
 ```xml title="/etc/clickhouse-server/config.d/use-keeper.xml on clickhouse-01"
 <clickhouse>
@@ -147,7 +149,7 @@ As the configuration is very similar on clickhouse-01 and clickhouse-02 only the
 
 This file is the same on both clickhouse-01 and clickhouse-02, with the exception of `display_name`.
 
-```xml title="/etc/clickhouse-server/config.d/network-and-logging.xml on clickhouse-02" 
+```xml title="/etc/clickhouse-server/config.d/network-and-logging.xml on clickhouse-02"
 <clickhouse>
     <logger>
         <level>debug</level>

docs/faq/general/columnar-database.md

@@ -5,6 +5,9 @@ toc_hidden: true
 toc_priority: 101
 ---
 
+import RowOriented from '@site/static/images/row-oriented.gif';
+import ColumnOriented from '@site/static/images/column-oriented.gif';
+
 # What Is a Columnar Database? {#what-is-a-columnar-database}
 
 A columnar database stores the data of each column independently. This allows reading data from disk only for those columns that are used in any given query. The cost is that operations that affect whole rows become proportionally more expensive. The synonym for a columnar database is a column-oriented database management system. ClickHouse is a typical example of such a system.
@@ -18,10 +21,10 @@ Key columnar database advantages are:
 Here is the illustration of the difference between traditional row-oriented systems and columnar databases when building reports:
 
 **Traditional row-oriented**
-![Traditional row-oriented](@site/docs/images/row-oriented.gif#)
+<img src={RowOriented} alt="Traditional row-oriented database" />
 
 **Columnar**
-![Columnar](@site/docs/images/column-oriented.gif#)
+<img src={ColumnOriented} alt="Columnar database" />
 
 A columnar database is the preferred choice for analytical applications because it allows having many columns in a table just in case, but to not pay the cost for unused columns on read query execution time (a traditional OLTP database reads all of the data during queries as the data is stored in rows and not columns). Column-oriented databases are designed for big data processing and data warehousing, they often natively scale using distributed clusters of low-cost hardware to increase throughput. ClickHouse does it with combination of [distributed](../../engines/table-engines/special/distributed.md) and [replicated](../../engines/table-engines/mergetree-family/replication.md) tables.