more images

Author: gingerwizard

docs/data-modeling/schema-design.md

@@ -8,6 +8,7 @@ keywords: ['schema', 'schema design', 'query optimization']
 import stackOverflowSchema from '@site/static/images/data-modeling/stackoverflow-schema.png';
 import schemaDesignTypes from '@site/static/images/data-modeling/schema-design-types.png';
 import schemaDesignIndices from '@site/static/images/data-modeling/schema-design-indices.png';
+import Image from '@theme/IdealImage';
 
 Understanding effective schema design is key to optimizing ClickHouse performance and includes choices that often involve trade-offs, with the optimal approach depending on the queries being served as well as factors such as data update frequency, latency requirements, and data volume. This guide provides an overview of schema design best practices and data modeling techniques for optimizing ClickHouse performance.
 
@@ -17,7 +18,7 @@ For the examples in this guide, we use a subset of the Stack Overflow dataset. T
 
 > The primary keys and relationships indicated are not enforced through constraints (Parquet is file not table format) and purely indicate how the data is related and the unique keys it possesses.
 
-<img src={stackOverflowSchema} class="image" alt="Stack Overflow Schema" style={{width: '800px', background: 'none'}} />
+<Image img={stackOverflowSchema} size="lg" alt="Stack Overflow Schema"/>
 
 <br />
 
@@ -150,7 +151,7 @@ FixedString for special cases - Strings which have a fixed length can be encoded
 
 By applying these simple rules to our posts table, we can identify an optimal type for each column:
 
-<img src={schemaDesignTypes} class="image" alt="Schema Design - Optimized Types" style={{width: '1000px', background: 'none'}} />
+<Image img={schemaDesignTypes} size="lg" alt="Schema Design - Optimized Types"/>
 
 <br />
 
@@ -203,9 +204,7 @@ Users coming from OLTP databases often look for the equivalent concept in ClickH
 
 At the scale at which ClickHouse is often used, memory and disk efficiency are paramount. Data is written to ClickHouse tables in chunks known as parts, with rules applied for merging the parts in the background. In ClickHouse, each part has its own primary index. When parts are merged, then the merged part's primary indexes are also merged. The primary index for a part has one index entry per group of rows - this technique is called sparse indexing.
 
-<img src={schemaDesignIndices} class="image" alt="Sparse Indexing in ClickHouse" style={{width: '600px', background: 'none'}} />
-
-<br />
+<Image img={schemaDesignIndices} size="md" alt="Sparse Indexing in ClickHouse"/>
 
 The selected key in ClickHouse will determine not only the index, but also order in which data is written on disk. Because of this, it can dramatically impact compression levels which can in turn affect query performance. An ordering key which causes the values of most columns to be written in contiguous order will allow the selected compression algorithm (and codecs) to compress the data more effectively.
 

docs/dictionary/index.md

@@ -7,6 +7,7 @@ description: 'A dictionary provides a key-value representation of data for fast
 
 import dictionaryUseCases from '@site/static/images/dictionary/dictionary-use-cases.png';
 import dictionaryLeftAnyJoin from '@site/static/images/dictionary/dictionary-left-any-join.png';
+import Image from '@theme/IdealImage';
 
 # Dictionary
 
@@ -16,19 +17,13 @@ Dictionaries are useful for:
 - Improving the performance of queries, especially when used with `JOIN`s
 - Enriching ingested data on the fly without slowing down the ingestion process
 
-<img src={dictionaryUseCases}
-  class="image"
-  alt="Use cases for Dictionary in ClickHouse"
-  style={{width: '100%', background: 'none'}} />
+<Image img={dictionaryUseCases} size="lg" alt="Use cases for Dictionary in ClickHouse"/>
 
 ## Speeding up joins using a Dictionary {#speeding-up-joins-using-a-dictionary}
 
 Dictionaries can be used to speed up a specific type of `JOIN`: the [`LEFT ANY` type](/sql-reference/statements/select/join#supported-types-of-join) where the join key needs to match the key attribute of the underlying key-value storage.
 
-<img src={dictionaryLeftAnyJoin}
-  class="image"
-  alt="Using Dictionary with LEFT ANY JOIN"
-  style={{width: '300px', background: 'none'}} />
+<Image img={dictionaryLeftAnyJoin} size="sm" alt="Using Dictionary with LEFT ANY JOIN"/>
 
 If this is the case, ClickHouse can exploit the dictionary to perform a [Direct Join](https://clickhouse.com/blog/clickhouse-fully-supports-joins-direct-join-part4#direct-join). This is ClickHouse's fastest join algorithm and is applicable when the underlying [table engine](/engines/table-engines) for the right-hand side table supports low-latency key-value requests. ClickHouse has three table engines providing this: [Join](/engines/table-engines/special/join) (that is basically a pre-calculated hash table), [EmbeddedRocksDB](/engines/table-engines/integrations/embedded-rocksdb) and [Dictionary](/engines/table-engines/special/dictionary). We will describe the dictionary-based approach, but the mechanics are the same for all three engines.
 

docs/managing-data/drop_partition.md

@@ -29,7 +29,7 @@ PARTITION BY toYear(CreationDate)
 
 Read about setting the partition expression in a section [How to set the partition expression](/sql-reference/statements/alter/partition/#how-to-set-partition-expression).
 
-In ClickHouse, users should principally consider partitioning to be a data management feature, not a query optimization technique. By separating data logically based on a key, each partition can be operated on independently e.g. deleted. This allows users to move partitions, and thus subsets, between [storage tiers](/integrations/s3#storage-tiers) efficiently on time or [expire data/efficiently delete from the cluster](/sql-reference/statements/alter/partition). 
+In ClickHouse, users should principally consider partitioning to be a data management feature, not a query optimization technique. By separating data logically based on a key, each partition can be operated on independently e.g. deleted. This allows users to move partitions, and thus subsets, between [storage tiers](/integrations/s3#storage-tiers) efficiently on time or [expire data/efficiently delete from the cluster](/sql-reference/statements/alter/partition).
 
 ## Drop Partitions {#drop-partitions}
 
@@ -69,7 +69,7 @@ WHERE `table` = 'posts'
 └───────────┘
 
 17 rows in set. Elapsed: 0.002 sec.
-	
+
 	ALTER TABLE posts
 	(DROP PARTITION '2008')
 

docs/materialized-view/incremental-materialized-view.md

@@ -7,6 +7,7 @@ score: 10000
 ---
 
 import materializedViewDiagram from '@site/static/images/materialized-view/materialized-view-diagram.png';
+import Image from '@theme/IdealImage';
 
 # Incremental Materialized Views
 
@@ -18,10 +19,7 @@ The principal motivation for materialized views is that the results inserted int
 
 Materialized views in ClickHouse are updated in real time as data flows into the table they are based on, functioning more like continually updating indexes. This is in contrast to other databases where materialized views are typically static snapshots of a query that must be refreshed (similar to ClickHouse [refreshable materialized views](/sql-reference/statements/create/view#refreshable-materialized-view)).
 
-<img src={materializedViewDiagram}
-     class="image"
-     alt="Materialized view diagram"
-     style={{width: '500px'}} />
+<Image img={materializedViewDiagram} size="md" alt="Materialized view diagram"/>
 
 ## Example {#example}
 

docs/materialized-view/index.md

@@ -11,4 +11,4 @@ keywords: ['materialized views', 'speed up queries', 'query optimization', 'refr
 | [Refreshable Materialized View](/materialized-view/refreshable-materialized-view) | Conceptually similar to incremental materialized views but require the periodic execution of the query over the full dataset - the results of which are stored in a target table for querying. |
 
 
-<iframe width="560" height="315" src="https://www.youtube.com/embed/-A3EtQgDn_0?si=TBiN_E80BKZ0DPpd" 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>
+<iframe width="1024" height="576" src="https://www.youtube.com/embed/-A3EtQgDn_0?si=TBiN_E80BKZ0DPpd" 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>

docs/materialized-view/refreshable-materialized-view.md

@@ -6,15 +6,14 @@ keywords: ['refreshable materialized view', 'refresh', 'materialized views', 'sp
 ---
 
 import refreshableMaterializedViewDiagram from '@site/static/images/materialized-view/refreshable-materialized-view-diagram.png';
+import Image from '@theme/IdealImage';
 
 [Refreshable materialized views](/sql-reference/statements/create/view#refreshable-materialized-view) are conceptually similar to materialized views in traditional OLTP databases, storing the result of a specified query for quick retrieval and reducing the need to repeatedly execute resource-intensive queries. Unlike ClickHouse’s [incremental materialized views](/materialized-view/incremental-materialized-view), this requires the periodic execution of the query over the full dataset - the results of which are stored in a target table for querying. This result set should, in theory, be smaller than the original dataset, allowing the subsequent query to execute faster.
 
 The diagram explains how Refreshable Materialized Views work:
 
-<img src={refreshableMaterializedViewDiagram}
-  class="image"
-  alt="Refreshable materialized view diagram"
-  style={{width: '100%', background: 'none'}} />
+<Image img={refreshableMaterializedViewDiagram} size="lg" alt="Refreshable materialized view diagram"/>
+
 
 You can also see the following video:
 

docs/migrations/postgres/replacing-merge-tree.md

@@ -6,6 +6,7 @@ keywords: ['replacingmergetree', 'inserts', 'deduplication']
 ---
 
 import postgres_replacingmergetree from '@site/static/images/migrations/postgres-replacingmergetree.png';
+import Image from '@theme/IdealImage';
 
 While transactional databases are optimized for transactional update and delete workloads, OLAP databases offer reduced guarantees for such operations. Instead, they optimize for immutable data inserted in batches for the benefit of significantly faster analytical queries. While ClickHouse offers update operations through mutations, as well as a lightweight means of deleting rows, its column-orientated structure means these operations should be scheduled with care, as described above. These operations are handled asynchronously, processed with a single thread, and require (in the case of updates) data to be rewritten on disk. They should thus not be used for high numbers of small changes.
 In order to process a stream of update and delete rows while avoiding the above usage patterns, we can use the ClickHouse table engine ReplacingMergeTree.
@@ -28,7 +29,7 @@ As a result of this merge process, we have four rows representing the final stat
 
 <br />
 
-<img src={postgres_replacingmergetree} class="image" alt="ReplacingMergeTree process" style={{width: '800px', background: 'none'}} />
+<Image img={postgres_replacingmergetree} size="md" alt="ReplacingMergeTree process"/>
 
 <br />
 

src/theme/IdealImage/index.tsx

@@ -181,7 +181,7 @@ export default function IdealImage(
       <ControlledZoom
         isZoomed={isZoomed}
         onZoomChange={handleZoomChange}
-        classDialog={`${styles.customZoom} ${styles.customWhiteZoom}`}
+        classDialog={`${styles.customZoom} ${background == "white" ? styles.customWhiteZoom : ""}`}
       >
         {isLoaded && (
           <img