Skip to content

Commit ed62abf

Browse files
BlargianBlargian
committed
fix typos
1 parent b88b460 commit ed62abf

File tree

1 file changed

+4
-7
lines changed

1 file changed

+4
-7
lines changed

‎docs/data-modeling/projections/2_materialized-views-versus-projections.md

Lines changed: 4 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -7,9 +7,7 @@ description: 'Article comparing materialized views and projections in ClickHouse
77
---
88

99
> A common question from users is when they should use materialized views versus
10-
projections, both of which are frequently used tools in ClickHouse. Given that
11-
both are used as query optimization tools, it can be confusing to know which to pick.
12-
In this article we will explore the key differences between the two and why you
10+
projections. In this article we will explore the key differences between the two and why you
1311
may want to pick one over the other in certain scenarios.
1412

1513
## Summary of key differences {#key-differences}
@@ -18,10 +16,10 @@ The table below summarizes the key differences between materialized views and pr
1816

1917
| Aspect | Materialized views | Projections |
2018
|------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
21-
| Data storage and location | Store their results in a **separate, explicit target table** on insert to a source table, acting as insert triggers. | Projections create optimized data layouts that are physically **stored alongside the main table data** and are invisible to the user. |
19+
| Data storage and location | Store their results in a **separate, explicit target table**, acting as insert triggers, on insert to a source table. | Projections create optimized data layouts that are physically **stored alongside the main table data** and are invisible to the user. |
2220
| Update mechanism | Operate **synchronously** on `INSERT` to the source table (for incremental materialized views). Note: they can also be **scheduled** using refreshable materialized views. | **Asynchronous** updates in the background upon `INSERT` to the main table. |
2321
| Query interaction | Working with Materialized Views requires querying the **target table directly**, meaning that users need to be aware of the existence of materialized views when writing queries. | Projections are **automatically selected** by ClickHouse's query optimizer, and are transparent in the sense that the user does not have to modify their queries to the table with the projection in order to utilise it. From version 25.6 it is also possible to filter by more than one projection. |
24-
| Handling `UPDATE` / `DELETE` | **Do not automatically react** to `UPDATE` or `DELETE` operations on the source table as materialized views have no knowledge of the source table, acting only as insert triggers _to_ a source table. This can lead to potential data staleness between source and target tables and requires workarounds or periodic full refresh. (via Refreshable materialized view). | By default, are **incompatible with `DELETED` rows** (especially lightweight deletes). `lightweight_mutation_projection_mode` (v24.7+) can enable compatibility. |
22+
| Handling `UPDATE` / `DELETE` | **Do not automatically react** to `UPDATE` or `DELETE` operations on the source table as materialized views have no knowledge of the source table, acting only as insert triggers _to_ a source table. This can lead to potential data staleness between source and target tables and requires workarounds or periodic full refresh. (via refreshable materialized view). | By default, are **incompatible with `DELETED` rows** (especially lightweight deletes). `lightweight_mutation_projection_mode` (v24.7+) can enable compatibility. |
2523
| `JOIN` support | Yes. Refreshable materialized views can be used for complex denormalization. Incremental materialized views only trigger on left-most table inserts. | No. `JOIN` operations are not supported within projection definitions for filtering the materialised data. |
2624
| `WHERE` clause in definition | Yes. `WHERE` clauses can be included to filter data before materialization. | No. `WHERE` clauses are not supported within projection definitions for filtering the materialized data. |
2725
| Chaining capabilities | Yes, the target table of one materialized view can be the source for another materialized view, enabling multi-stage pipelines. | No. Projections cannot be chained. |
@@ -41,7 +39,6 @@ You should consider using materialized views when:
4139
- You require **complex denormalization**: You need to pre-join data from several sources (tables, subqueries or dictionaries) into a single, query-optimized table, especially if periodic full refreshes with the use of refreshable materialized views are acceptable.
4240
- You want **explicit schema control**: You require a separate, distinct target table with its own schema and engine for the pre-computed results, offering greater flexibility for data modelling.
4341
- You want to **filter at ingestion**: You need to filter data _before_ it's materialized, reducing the volume of data written to the target table.
44-
- When working with large tables
4542

4643
### When to avoid materialized views {#avoid-materialized-views}
4744

@@ -59,7 +56,7 @@ You should consider using projections when:
5956

6057
### When to avoid projections {#avoid-projections}
6158

62-
You should consider avoiding use of projections when:
59+
You should consider avoiding the use of projections when:
6360

6461
- **Complex data transformation or multi-stage ETL are required**: Projections do not support `JOIN` operations within their definitions, cannot be changed to build multi-step pipelines and cannot handle some SQL features like window functions or complex `CASE` statements. As such they are not suited for complex data transformation.
6562
- **Explicit filtering of materialized data is needed**: Projections do not support `WHERE` clauses in their definition to filter the data that gets materialized into the projection itself.

0 commit comments

Comments
 (0)