borders

Author: gingerwizard

docs/cloud/bestpractices/asyncinserts.md

@@ -18,7 +18,7 @@ By default, ClickHouse is writing data synchronously.
 Each insert sent to ClickHouse causes ClickHouse to immediately create a part containing the data from the insert.
 This is the default behavior when the async_insert setting is set to its default value of 0:
 
-<Image img={asyncInsert01} size="lg" alt="Asynchronous insert process - default synchronous inserts" background="white"/>
+<Image img={asyncInsert01} size="md" alt="Asynchronous insert process - default synchronous inserts" background="white"/>
 
 By setting async_insert to 1, ClickHouse first stores the incoming inserts into an in-memory buffer before flushing them regularly to disk.
 
@@ -36,9 +36,9 @@ With the [wait_for_async_insert](/operations/settings/settings.md/#wait_for_asyn
 
 The following two diagrams illustrate the two settings for async_insert and wait_for_async_insert:
 
-<Image img={asyncInsert02} size="lg" alt="Asynchronous insert process - async_insert=1, wait_for_async_insert=1" background="white"/>
+<Image img={asyncInsert02} size="md" alt="Asynchronous insert process - async_insert=1, wait_for_async_insert=1" background="white"/>
 
-<Image img={asyncInsert03} size="lg" alt="Asynchronous insert process - async_insert=1, wait_for_async_insert=0" background="white"/>
+<Image img={asyncInsert03} size="md" alt="Asynchronous insert process - async_insert=1, wait_for_async_insert=0" background="white"/>
 
 ### Enabling asynchronous inserts {#enabling-asynchronous-inserts}
 

docs/cloud/bestpractices/partitioningkey.md

@@ -9,18 +9,16 @@ import Image from '@theme/IdealImage';
 import partitioning01 from '@site/static/images/cloud/bestpractices/partitioning-01.png';
 import partitioning02 from '@site/static/images/cloud/bestpractices/partitioning-02.png';
 
-# Choose a Low Cardinality Partitioning Key
-
 When you send an insert statement (that should contain many rows - see [section above](/optimize/bulk-inserts)) to a table in ClickHouse Cloud, and that
 table is not using a [partitioning key](/engines/table-engines/mergetree-family/custom-partitioning-key.md) then all row data from that insert is written into a new part on storage:
 
-<Image img={partitioning01} size="lg" alt="Insert without partitioning key - one part created" background="white"/>
+<Image img={partitioning01} size="md" alt="Insert without partitioning key - one part created" background="white"/>
 
 However, when you send an insert statement to a table in ClickHouse Cloud, and that table has a partitioning key, then ClickHouse:
 - checks the partitioning key values of the rows contained in the insert
 - creates one new part on storage per distinct partitioning key value
 - places the rows in the corresponding parts by partitioning key value
 
-<Image img={partitioning02} size="lg" alt="Insert with partitioning key - multiple parts created based on partitioning key values" background="white"/>
+<Image img={partitioning02} size="md" alt="Insert with partitioning key - multiple parts created based on partitioning key values" background="white"/>
 
 Therefore, to minimize the number of write requests to the ClickHouse Cloud object storage, use a low cardinality partitioning key or avoid using any partitioning key for your table.

docs/guides/best-practices/skipping-indexes.md

@@ -99,7 +99,7 @@ Instead of processing 100 million rows of 800 megabytes, ClickHouse has only rea
 In a more visual form, this is how the 4096 rows with a `my_value` of 125 were read and selected, and how the following rows
 were skipped without reading from disk:
 
-<Image img={simple_skip} size="lg" alt="Simple Skip"/>
+<Image img={simple_skip} size="md" alt="Simple Skip"/>
 
 Users can access detailed information about skip index usage by enabling the trace when executing queries.  From
 clickhouse-client, set the `send_logs_level`:
@@ -176,7 +176,7 @@ Skip indexes are not intuitive, especially for users accustomed to secondary row
 
 Consider the following data distribution:
 
-<Image img={bad_skip} size="lg" alt="Bad Skip"/>
+<Image img={bad_skip} size="md" alt="Bad Skip"/>
 
 Assume the primary/order by key is `timestamp`, and there is an index on `visitor_id`.  Consider the following query:
 

docs/guides/developer/cascading-materialized-views.md

@@ -9,17 +9,7 @@ keywords: ['materialized view', 'aggregation']
 
 This example demonstrates how to create a Materialized View, and then how to cascade a second Materialized View on to the first. In this page, you will see how to do it, many of the possibilities, and the limitations. Different use cases can be answered by creating a Materialized view using a second Materialized view as the source.
 
-<div style={{width:'640px', height: '360px'}}>
-  <iframe src="//www.youtube.com/embed/QDAJTKZT8y4"
-    width="640"
-    height="360"
-    frameborder="0"
-    allow="autoplay;
-    fullscreen;
-    picture-in-picture"
-    allowfullscreen>
-  </iframe>
-</div>
+<iframe width="1024" height="576" src="https://www.youtube.com/embed/QDAJTKZT8y4?si=1KqPNHHfaKfxtPat" 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>
 
 <br />
 
@@ -301,13 +291,13 @@ Create two materialized views pointing to the same `Target` table. You don't nee
 ```sql
 CREATE MATERIALIZED VIEW analytics.daily_impressions_mv
 TO analytics.daily_overview
-AS                                                
+AS
 SELECT
     toDate(event_time) AS on_date,
     domain_name,
     count() AS impressions,
     0 clicks         ---<<<--- if you omit this, it will be the same 0
-FROM                                              
+FROM
     analytics.impressions
 GROUP BY
     toDate(event_time) AS on_date,

docs/integrations/data-ingestion/dbms/dynamodb/index.md

@@ -32,14 +32,14 @@ Data will be ingested into a `ReplacingMergeTree`. This table engine is commonly
 First, you will want to enable a Kinesis stream on your DynamoDB table to capture changes in real-time. We want to do this before we create the snapshot to avoid missing any data.
 Find the AWS guide located [here](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/kds.html).
 
-<Image img={dynamodb_kinesis_stream} size="lg" alt="DynamoDB Kinesis Stream" />
+<Image img={dynamodb_kinesis_stream} size="lg" alt="DynamoDB Kinesis Stream" border/>
 
 ## 2. Create the snapshot {#2-create-the-snapshot}
 
 Next, we will create a snapshot of the DynamoDB table. This can be achieved through an AWS export to S3. Find the AWS guide located [here](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/S3DataExport.HowItWorks.html).
 **You will want to do a "Full export" in the DynamoDB JSON format.**
 
-<Image img={dynamodb_s3_export} size="lg" alt="DynamoDB S3 Export"/>
+<Image img={dynamodb_s3_export} size="md" alt="DynamoDB S3 Export" border/>
 
 ## 3. Load the snapshot into ClickHouse {#3-load-the-snapshot-into-clickhouse}
 
@@ -129,7 +129,7 @@ Now we can set up the Kinesis ClickPipe to capture real-time changes from the Ki
   - `ApproximateCreationDateTime`: `version`
   - Map other fields to the appropriate destination columns as shown below
 
-<Image img={dynamodb_map_columns} size="lg" alt="DynamoDB Map Columns"/>
+<Image img={dynamodb_map_columns} size="md" alt="DynamoDB Map Columns" border/>
 
 ## 5. Cleanup (optional) {#5-cleanup-optional}
 

docs/managing-data/core-concepts/academic_overview.mdx

@@ -29,7 +29,7 @@ export function Anchor(props) {
 
 This is the web version of our [VLDB 2024 scientific paper](https://www.vldb.org/pvldb/vol17/p3731-schulze.pdf). We also [blogged](https://clickhouse.com/blog/first-clickhouse-research-paper-vldb-lightning-fast-analytics-for-everyone) about its background and journey, and recommend watching the VLDB 2024 presentation by ClickHouse CTO and creator, Alexey Milovidov:
 
-<iframe width="768" height="432" src="https://www.youtube.com/embed/7QXKBKDOkJE?si=5uFerjqPSXQWqDkF" 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/7QXKBKDOkJE?si=5uFerjqPSXQWqDkF" 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>
 
 ## ABSTRACT {#abstract}
 

docs/managing-data/core-concepts/shards.md

@@ -114,4 +114,4 @@ For more details beyond this high-level introduction to table shards and replica
 
 We also highly recommend this tutorial video for a deeper dive into ClickHouse shards and replicas:
 
-<iframe width="768" height="432" src="https://www.youtube.com/embed/vBjCJtw_Ei0?si=WqopTrnti6usCMRs" 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/vBjCJtw_Ei0?si=WqopTrnti6usCMRs" 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>