Merge pull request #3139 from ClickHouse/on-the-fly-mutations

Remove cloud badge from lightweight updates

Author: rfraposa

docs/en/guides/developer/lightweight-update.md

@@ -5,12 +5,8 @@ title: Lightweight Update
 keywords: [lightweight update]
 ---
 
-import CloudAvailableBadge from '@theme/badges/CloudAvailableBadge';
-
 ## Lightweight Update
 
-<CloudAvailableBadge/>
-
 When lightweight updates are enabled, updated rows are marked as updated immediately and subsequent `SELECT` queries will automatically return with the changed values. When lightweight updates are not enabled, you may have to wait for your mutations to be applied via a background process to see the changed values.
 
 Lightweight updates can be enabled for `MergeTree`-family tables by enabling the query-level setting `apply_mutations_on_fly`.
@@ -23,7 +19,7 @@ SET apply_mutations_on_fly = 1;
 
 Let's create a table and run some mutations:
 ```sql
-CREATE TABLE test_on_fly_mutations (id UInt64, v String) 
+CREATE TABLE test_on_fly_mutations (id UInt64, v String)
 ENGINE = MergeTree ORDER BY id;
 
 -- Disable background materialization of mutations to showcase
@@ -93,4 +89,4 @@ These behaviours are controlled by the following settings:
 - `mutations_execute_nondeterministic_on_initiator` - if true, non-deterministic functions are executed on the initiator replica and are replaced as literals in `UPDATE` and `DELETE` queries. Default value: `false`.
 - `mutations_execute_subqueries_on_initiator` - if true, scalar subqueries are executed on the initiator replica and are replaced as literals in `UPDATE` and `DELETE` queries. Default value: `false`.
  - `mutations_max_literal_size_to_replace` - The maximum size of serialized literals in bytes to replace in `UPDATE` and `DELETE` queries. Default value: `16384` (16 KiB).
- 
+

docs/en/managing-data/updating-data/overview.md

@@ -5,11 +5,9 @@ description: How to update data in ClickHouse
 keywords: [update, updating data]
 ---
 
-import CloudAvailableBadge from '@theme/badges/CloudAvailableBadge';
-
 ## Differences between updating data in ClickHouse and OLTP databases
 
-When it comes to handling updates, ClickHouse and OLTP databases diverge significantly due to their underlying design philosophies and target use cases. For example, PostgreSQL, a row-oriented, ACID-compliant relational database, supports robust and transactional update and delete operations, ensuring data consistency and integrity through mechanisms like Multi-Version Concurrency Control (MVCC). This allows for safe and reliable modifications even in high-concurrency environments. 
+When it comes to handling updates, ClickHouse and OLTP databases diverge significantly due to their underlying design philosophies and target use cases. For example, PostgreSQL, a row-oriented, ACID-compliant relational database, supports robust and transactional update and delete operations, ensuring data consistency and integrity through mechanisms like Multi-Version Concurrency Control (MVCC). This allows for safe and reliable modifications even in high-concurrency environments.
 
 Conversely, ClickHouse is a column-oriented database optimized for read-heavy analytics and high throughput append-only operations. While it does natively support in-place updates and delete, they must be used carefully to avoid high I/O. Alternatively, tables can be restructured to convert delete and update into appended operations where they are processed asynchronously and/or at read time, thus reflecting the focus on high-throughput data ingestion and efficient query performance over real-time data manipulation.
 
@@ -24,15 +22,15 @@ In summary, update operations should be issued carefully, and the mutations queu
 | Method                                                                                | Syntax                               | When to use                                                                                                                                                                                                                              |
 |---------------------------------------------------------------------------------------|--------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | [Update mutation](/en/sql-reference/statements/alter/update)                          | `ALTER TABLE [table] UPDATE`         | Use when data must be updated to disk immediately (e.g. for compliance). Negatively affects `SELECT` performance.                                                                                                                        |
-| [Lightweight update](/en/guides/developer/lightweight-update) (ClickHouse Cloud)      | `ALTER TABLE [table] UPDATE`         | Enable using `SET apply_mutations_on_fly = 1;`. Use when updating small amounts of data. Rows are immediately returned with updated data in all subsequent `SELECT` queries but are initially only internally marked as updated on disk. |
+| [Lightweight update](/en/guides/developer/lightweight-update)                         | `ALTER TABLE [table] UPDATE`         | Enable using `SET apply_mutations_on_fly = 1;`. Use when updating small amounts of data. Rows are immediately returned with updated data in all subsequent `SELECT` queries but are initially only internally marked as updated on disk. |
 | [ReplacingMergeTree](/en/engines/table-engines/mergetree-family/replacingmergetree)   | `ENGINE = ReplacingMergeTree`        | Use when updating large amounts of data. This table engine is optimized for data deduplication on merges.                                                                                                                                |
 | [CollapsingMergeTree](/en/engines/table-engines/mergetree-family/collapsingmergetree) | `ENGINE = CollapsingMergeTree(Sign)` | Use when updating individual rows frequently, or for scenarios where you need to maintain the latest state of objects that change over time. For example, tracking user activity or article stats.                                       |
 
 Here is a summary of the different ways to update data in ClickHouse:
 
 ## Update Mutations
 
-Update mutations can be issued through a `ALTER TABLE … UPDATE` command e.g. 
+Update mutations can be issued through a `ALTER TABLE … UPDATE` command e.g.
 
 ```sql
 ALTER TABLE posts_temp
@@ -44,9 +42,7 @@ Read more about [update mutations](/en/sql-reference/statements/alter/update).
 
 ## Lightweight Updates
 
-<CloudAvailableBadge />
-
-Lightweight updates provide a mechanism to update rows such that they are updated immediately, and subsequent `SELECT` queries will automatically return with the changed values (this incurs an overhead and will slow queries). This effectively addresses the atomicity limitation of normal mutations. We show an example below: 
+Lightweight updates provide a mechanism to update rows such that they are updated immediately, and subsequent `SELECT` queries will automatically return with the changed values (this incurs an overhead and will slow queries). This effectively addresses the atomicity limitation of normal mutations. We show an example below:
 
 ```sql
 SET apply_mutations_on_fly = 1;
@@ -62,7 +58,7 @@ WHERE Id = 404346
 1 row in set. Elapsed: 0.115 sec. Processed 59.55 million rows, 238.25 MB (517.83 million rows/s., 2.07 GB/s.)
 Peak memory usage: 113.65 MiB.
 
--increment count 
+-increment count
 ALTER TABLE posts
 	(UPDATE ViewCount = ViewCount + 1 WHERE Id = 404346)
 
@@ -84,11 +80,11 @@ Read more about [lightweight updates](/en/guides/developer/lightweight-update).
 ## Collapsing Merge Tree
 
 Stemming from the idea that updates are expensive but inserts can be leveraged to perform updates,
-the [`CollapsingMergeTree`](/en/engines/table-engines/mergetree-family/collapsingmergetree) table engine 
+the [`CollapsingMergeTree`](/en/engines/table-engines/mergetree-family/collapsingmergetree) table engine
 can be used together with a `sign` column as a way to tell ClickHouse to update a specific row by collapsing (deleting)
-a pair of rows with sign `1` and `-1`. 
-If `-1` is inserted for the `sign` column, the whole row will be deleted. 
-If `1` is inserted for the `sign` column, ClickHouse will keep the row. 
+a pair of rows with sign `1` and `-1`.
+If `-1` is inserted for the `sign` column, the whole row will be deleted.
+If `1` is inserted for the `sign` column, ClickHouse will keep the row.
 Rows to update are identified based on the sorting key used in the `ORDER BY ()` statement when creating the table.
 
 ```sql
@@ -120,7 +116,7 @@ HAVING sum(Sign) > 0
 ```
 
 :::note
-The approach above for updating requires users to maintain state client side. 
+The approach above for updating requires users to maintain state client side.
 While this is most efficient from ClickHouse's perspective, it can be complex to work with at scale.
 
 We recommend reading the documentation