Skip to content

Commit e622904

Browse files
committed
docs(fix): try to fix img path
1 parent 1d3dbcf commit e622904

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

website/blog/2022-12-13-indexing.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -154,7 +154,7 @@ select avg(DepDelay) from ontime where Year='2003';
154154

155155
From the sample above, we can see that a segment file contains its own Min/Max index information. So does a block file. The Min/Max indexes are layered and distributed among snapshots, segments, and blocks like this:
156156

157-
![Alt text](../static/img/blog/index-1.png)
157+
![Alt text](/img/blog/index-1.png)
158158

159159
When retrieving data for a query, Databend starts from the snapshot indexes and locates the corresponding segment by matching the Min/Max interval. Then, it looks up the indexes in the segment file to find the block where the required data is stored and reads data from the block file with information about the start position from `col_metas`. So Databend literally processes a query by finding the right segments and blocks with the Min/Max Index.
160160

@@ -170,6 +170,6 @@ The Min/Max Index seems to work perfectly for Databend, but in fact, data is usu
170170

171171
For example, you need to access up to three parquet files for a query condition like `Age = 20 & Age = 35`. If Age is set as the cluster key, Databend will sort the data by the Age column and combine as many small parquet files as possible.
172172

173-
![Alt text](../static/img/blog/index-2.png)
173+
![Alt text](/img/blog/index-2.png)
174174

175175
For more information about the cluster key, see https://databend.rs/doc/sql-commands/ddl/clusterkey/.

0 commit comments

Comments
 (0)