This is an automated email from the ASF dual-hosted git repository.
czweng pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-paimon.git
The following commit(s) were added to refs/heads/master by this push:
new 1638fccc [docs] Move document pages from content/docs to content/
(#627)
1638fccc is described below
commit 1638fccc0c4f6b485ae8d3593a9e9f942be2aeb8
Author: tsreaper <[email protected]>
AuthorDate: Fri Mar 17 20:37:02 2023 +0800
[docs] Move document pages from content/docs to content/ (#627)
---
docs/config.toml | 2 ++
docs/content/_index.md | 2 +-
docs/content/{docs => }/concepts/_index.md | 0
docs/content/{docs => }/concepts/append-only-table.md | 2 +-
docs/content/{docs => }/concepts/basic-concepts.md | 8 ++++----
docs/content/{docs => }/concepts/external-log-systems.md | 2 +-
docs/content/{docs => }/concepts/file-layouts.md | 8 ++++----
docs/content/{docs => }/concepts/overview.md | 0
docs/content/{docs => }/concepts/primary-key-table.md | 12 ++++++------
docs/content/{docs => }/engines/_index.md | 0
docs/content/{docs => }/engines/flink.md | 0
docs/content/{docs => }/engines/hive.md | 2 +-
docs/content/{docs => }/engines/overview.md | 0
docs/content/{docs => }/engines/spark2.md | 2 +-
docs/content/{docs => }/engines/spark3.md | 0
docs/content/{docs => }/engines/trino.md | 0
docs/content/{docs => }/filesystems/_index.md | 0
docs/content/{docs => }/filesystems/oss.md | 2 +-
docs/content/{docs => }/filesystems/overview.md | 0
docs/content/{docs => }/filesystems/s3.md | 2 +-
docs/content/{docs => }/how-to/_index.md | 0
docs/content/{docs => }/how-to/altering-tables.md | 0
docs/content/{docs => }/how-to/creating-catalogs.md | 2 +-
docs/content/{docs => }/how-to/creating-tables.md | 6 +++---
docs/content/{docs => }/how-to/lookup-joins.md | 0
docs/content/{docs => }/how-to/querying-tables.md | 4 ++--
docs/content/{docs => }/how-to/writing-tables.md | 2 +-
docs/content/{docs => }/maintenance/_index.md | 0
docs/content/{docs => }/maintenance/configurations.md | 0
docs/content/{docs => }/maintenance/expiring-snapshots.md | 2 +-
docs/content/{docs => }/maintenance/manage-partition.md | 0
docs/content/{docs => }/maintenance/rescale-bucket.md | 0
docs/content/{docs => }/maintenance/write-performance.md | 6 +++---
docs/content/versions.md | 1 +
34 files changed, 35 insertions(+), 32 deletions(-)
diff --git a/docs/config.toml b/docs/config.toml
index 61a177d1..3928cadf 100644
--- a/docs/config.toml
+++ b/docs/config.toml
@@ -66,6 +66,8 @@ pygmentsUseClasses = true
["0.3",
"https://nightlies.apache.org/flink/flink-table-store-docs-release-0.3";],
]
+ BookSection = '/'
+
[markup]
[markup.goldmark.renderer]
unsafe = true
diff --git a/docs/content/_index.md b/docs/content/_index.md
index f4afc7f7..d1c142c7 100644
--- a/docs/content/_index.md
+++ b/docs/content/_index.md
@@ -36,7 +36,7 @@ Table Store offers the following core capabilities:
## Try Table Store
If you’re interested in playing around with Flink Table Store, check out our
-quick start guide with [Flink]({{< ref "docs/engines/flink" >}}), [Spark]({{<
ref "docs/engines/spark3" >}}) or [Hive]({{< ref "docs/engines/hive" >}}). It
provides a step by
+quick start guide with [Flink]({{< ref "engines/flink" >}}), [Spark]({{< ref
"engines/spark3" >}}) or [Hive]({{< ref "engines/hive" >}}). It provides a step
by
step introduction to the APIs and guides you through real applications.
<--->
diff --git a/docs/content/docs/concepts/_index.md
b/docs/content/concepts/_index.md
similarity index 100%
rename from docs/content/docs/concepts/_index.md
rename to docs/content/concepts/_index.md
diff --git a/docs/content/docs/concepts/append-only-table.md
b/docs/content/concepts/append-only-table.md
similarity index 98%
rename from docs/content/docs/concepts/append-only-table.md
rename to docs/content/concepts/append-only-table.md
index 5be416e6..502593ce 100644
--- a/docs/content/docs/concepts/append-only-table.md
+++ b/docs/content/concepts/append-only-table.md
@@ -33,7 +33,7 @@ This type of table is suitable for use cases that do not
require updates (such a
## Bucketing
-You can also define bucket number for Append-only table, see [Bucket]({{< ref
"docs/concepts/basic-concepts#bucket" >}}).
+You can also define bucket number for Append-only table, see [Bucket]({{< ref
"concepts/basic-concepts#bucket" >}}).
It is recommended that you set the `bucket-key` field. Otherwise, the data
will be hashed according to the whole row,
and the performance will be poor.
diff --git a/docs/content/docs/concepts/basic-concepts.md
b/docs/content/concepts/basic-concepts.md
similarity index 79%
rename from docs/content/docs/concepts/basic-concepts.md
rename to docs/content/concepts/basic-concepts.md
index 1a25e9c5..4c980106 100644
--- a/docs/content/docs/concepts/basic-concepts.md
+++ b/docs/content/concepts/basic-concepts.md
@@ -36,7 +36,7 @@ Table Store adopts the same partitioning concept as Apache
Hive to separate data
Partitioning is an optional way of dividing a table into related parts based
on the values of particular columns like date, city, and department. Each table
can have one or more partition keys to identify a particular partition.
-By partitioning, users can efficiently operate on a slice of records in the
table. See [file layouts]({{< ref "docs/concepts/file-layouts" >}}) for how
files are divided into multiple partitions.
+By partitioning, users can efficiently operate on a slice of records in the
table. See [file layouts]({{< ref "concepts/file-layouts" >}}) for how files
are divided into multiple partitions.
{{< hint info >}}
@@ -48,14 +48,14 @@ Partition keys must be a subset of primary keys if primary
keys are defined.
Unpartitioned tables, or partitions in partitioned tables, are sub-divided
into buckets, to provide extra structure to the data that may be used for more
efficient querying.
-The range for a bucket is determined by the hash value of one or more columns
in the records. Users can specify bucketing columns by providing the
[`bucket-key` option]({{< ref "docs/maintenance/configurations#coreoptions"
>}}). If no `bucket-key` option is specified, the primary key (if defined) or
the complete record will be used as the bucket key.
+The range for a bucket is determined by the hash value of one or more columns
in the records. Users can specify bucketing columns by providing the
[`bucket-key` option]({{< ref "maintenance/configurations#coreoptions" >}}). If
no `bucket-key` option is specified, the primary key (if defined) or the
complete record will be used as the bucket key.
A bucket is the smallest storage unit for reads and writes, so the number of
buckets limits the maximum processing parallelism. This number should not be
too big, though, as it will result in lots of small files and low read
performance. In general, the recommended data size in each bucket is about 1GB.
-See [file layouts]({{< ref "docs/concepts/file-layouts" >}}) for how files are
divided into buckets. Also, see [rescale bucket]({{< ref
"docs/maintenance/rescale-bucket" >}}) if you want to adjust the number of
buckets after a table is created.
+See [file layouts]({{< ref "concepts/file-layouts" >}}) for how files are
divided into buckets. Also, see [rescale bucket]({{< ref
"maintenance/rescale-bucket" >}}) if you want to adjust the number of buckets
after a table is created.
## Consistency Guarantees
-Table Store writers uses two-phase commit protocol to atomically commit a
batch of records to the table. Each commit produces at most two [snapshots]({{<
ref "docs/concepts/basic-concepts#snapshot" >}}) at commit time.
+Table Store writers uses two-phase commit protocol to atomically commit a
batch of records to the table. Each commit produces at most two [snapshots]({{<
ref "concepts/basic-concepts#snapshot" >}}) at commit time.
For any two writers modifying a table at the same time, as long as they do not
modify the same bucket, their commits are serializable. If they modify the same
bucket, only snapshot isolation is guaranteed. That is, the final table state
may be a mix of the two commits, but no changes are lost.
diff --git a/docs/content/docs/concepts/external-log-systems.md
b/docs/content/concepts/external-log-systems.md
similarity index 89%
rename from docs/content/docs/concepts/external-log-systems.md
rename to docs/content/concepts/external-log-systems.md
index 56bb6130..345b76f5 100644
--- a/docs/content/docs/concepts/external-log-systems.md
+++ b/docs/content/concepts/external-log-systems.md
@@ -26,7 +26,7 @@ under the License.
# External Log Systems
-Aside from [underlying table files]({{< ref
"docs/concepts/primary-key-table#changelog-producers" >}}), changelog of Table
Store can also be stored into or consumed from an external log system, such as
Kafka. By specifying `log.system` table property, users can choose which
external log system to use.
+Aside from [underlying table files]({{< ref
"concepts/primary-key-table#changelog-producers" >}}), changelog of Table Store
can also be stored into or consumed from an external log system, such as Kafka.
By specifying `log.system` table property, users can choose which external log
system to use.
If an external log system is used, all records written into table files will
also be written into the log system. Changes produced by the streaming queries
will thus come from the log system instead of table files.
diff --git a/docs/content/docs/concepts/file-layouts.md
b/docs/content/concepts/file-layouts.md
similarity index 86%
rename from docs/content/docs/concepts/file-layouts.md
rename to docs/content/concepts/file-layouts.md
index a532f6df..b5b081d9 100644
--- a/docs/content/docs/concepts/file-layouts.md
+++ b/docs/content/concepts/file-layouts.md
@@ -49,7 +49,7 @@ A manifest file is a file containing changes about LSM data
files and changelog
## Data Files
-Data files are grouped by partitions and buckets. Each bucket directory
contains an [LSM tree]({{< ref "docs/concepts/file-layouts#lsm-trees" >}}) and
its [changelog files]({{< ref
"docs/concepts/primary-key-table#changelog-producers" >}}).
+Data files are grouped by partitions and buckets. Each bucket directory
contains an [LSM tree]({{< ref "concepts/file-layouts#lsm-trees" >}}) and its
[changelog files]({{< ref "concepts/primary-key-table#changelog-producers" >}}).
## LSM Trees
@@ -57,13 +57,13 @@ Table Store adapts the LSM tree (log-structured merge-tree)
as the data structur
### Sorted Runs
-LSM tree organizes files into several sorted runs. A sorted run consists of
one or multiple [data files]({{< ref "docs/concepts/file-layouts#data-files"
>}}) and each data file belongs to exactly one sorted run.
+LSM tree organizes files into several sorted runs. A sorted run consists of
one or multiple [data files]({{< ref "concepts/file-layouts#data-files" >}})
and each data file belongs to exactly one sorted run.
Records within a data file are sorted by their primary keys. Within a sorted
run, ranges of primary keys of data files never overlap.
{{< img src="/img/sorted-runs.png">}}
-As you can see, different sorted runs may have overlapping primary key ranges,
and may even contain the same primary key. When querying the LSM tree, all
sorted runs must be combined and all records with the same primary key must be
merged according to the user-specified [merge engine]({{< ref
"docs/concepts/primary-key-table#merge-engines" >}}) and the timestamp of each
record.
+As you can see, different sorted runs may have overlapping primary key ranges,
and may even contain the same primary key. When querying the LSM tree, all
sorted runs must be combined and all records with the same primary key must be
merged according to the user-specified [merge engine]({{< ref
"concepts/primary-key-table#merge-engines" >}}) and the timestamp of each
record.
New records written into the LSM tree will be first buffered in memory. When
the memory buffer is full, all records in memory will be sorted and flushed to
disk. A new sorted run is now created.
@@ -75,4 +75,4 @@ To limit the number of sorted runs, we have to merge several
sorted runs into on
However, compaction is a resource intensive procedure which consumes a certain
amount of CPU time and disk IO, so too frequent compaction may in turn result
in slower writes. It is a trade-off between query and write performance. Table
Store currently adapts a compaction strategy similar to Rocksdb's [universal
compaction](https://github.com/facebook/rocksdb/wiki/Universal-Compaction).
-By default, when Table Store writers append records to the LSM tree, they'll
also perform compactions as needed. Users can also choose to perform all
compactions in a dedicated compaction job. See [dedicated compaction job]({{<
ref "docs/maintenance/write-performance#dedicated-compaction-job" >}}) for more
info.
+By default, when Table Store writers append records to the LSM tree, they'll
also perform compactions as needed. Users can also choose to perform all
compactions in a dedicated compaction job. See [dedicated compaction job]({{<
ref "maintenance/write-performance#dedicated-compaction-job" >}}) for more info.
diff --git a/docs/content/docs/concepts/overview.md
b/docs/content/concepts/overview.md
similarity index 100%
rename from docs/content/docs/concepts/overview.md
rename to docs/content/concepts/overview.md
diff --git a/docs/content/docs/concepts/primary-key-table.md
b/docs/content/concepts/primary-key-table.md
similarity index 93%
rename from docs/content/docs/concepts/primary-key-table.md
rename to docs/content/concepts/primary-key-table.md
index c7a88200..1ae10cb4 100644
--- a/docs/content/docs/concepts/primary-key-table.md
+++ b/docs/content/concepts/primary-key-table.md
@@ -30,7 +30,7 @@ Changelog table is the default table type when creating a
table. Users can inser
Primary keys are a set of columns that are unique for each record. Table Store
imposes an ordering of data, which means the system will sort the primary key
within each bucket. Using this feature, users can achieve high performance by
adding filter conditions on the primary key.
-By [defining primary keys]({{< ref
"docs/how-to/creating-tables#tables-with-primary-keys" >}}) on a changelog
table, users can access the following features.
+By [defining primary keys]({{< ref
"how-to/creating-tables#tables-with-primary-keys" >}}) on a changelog table,
users can access the following features.
## Merge Engines
@@ -39,7 +39,7 @@ When Table Store sink receives two or more records with the
same primary keys, i
{{< hint info >}}
Set `table.exec.sink.upsert-materialize` to `NONE` always in Flink SQL
TableConfig, sink upsert-materialize may
result in strange behavior. When the input is out of order, we recommend that
you use
-[Sequence Field]({{< ref "docs/concepts/primary-key-table#sequence-field" >}})
to correct disorder.
+[Sequence Field]({{< ref "concepts/primary-key-table#sequence-field" >}}) to
correct disorder.
{{< /hint >}}
### Deduplicate
@@ -60,7 +60,7 @@ For example, let's say Table Store receives three records:
If the first column is the primary key. The final result will be `<1, 25.2,
10, 'This is a book'>`.
{{< hint info >}}
-For streaming queries, `partial-update` merge engine must be used together
with `lookup` or `full-compaction` [changelog producer]({{< ref
"docs/concepts/primary-key-table#changelog-producers" >}}).
+For streaming queries, `partial-update` merge engine must be used together
with `lookup` or `full-compaction` [changelog producer]({{< ref
"concepts/primary-key-table#changelog-producers" >}}).
{{< /hint >}}
{{< hint info >}}
@@ -109,12 +109,12 @@ If you allow some functions to ignore retraction
messages, you can configure:
`'fields.${field_name}.ignore-retract'='true'`.
{{< hint info >}}
-For streaming queries, `aggregation` merge engine must be used together with
`lookup` or `full-compaction` [changelog producer]({{< ref
"docs/concepts/primary-key-table#changelog-producers" >}}).
+For streaming queries, `aggregation` merge engine must be used together with
`lookup` or `full-compaction` [changelog producer]({{< ref
"concepts/primary-key-table#changelog-producers" >}}).
{{< /hint >}}
## Changelog Producers
-Streaming queries will continuously produce latest changes. These changes can
come from the underlying table files or from an [external log system]({{< ref
"docs/concepts/external-log-systems" >}}) like Kafka. Compared to the external
log system, changes from table files have lower cost but higher latency
(depending on how often snapshots are created).
+Streaming queries will continuously produce latest changes. These changes can
come from the underlying table files or from an [external log system]({{< ref
"concepts/external-log-systems" >}}) like Kafka. Compared to the external log
system, changes from table files have lower cost but higher latency (depending
on how often snapshots are created).
By specifying the `changelog-producer` table property when creating the table,
users can choose the pattern of changes produced from files.
@@ -138,7 +138,7 @@ To conclude, `none` changelog producers are best suited for
consumers such as a
### Input
-By specifying `'changelog-producer' = 'input'`, Table Store writers rely on
their inputs as a source of complete changelog. All input records will be saved
in separated [changelog files]({{< ref "docs/concepts/file-layouts" >}}) and
will be given to the consumers by Table Store sources.
+By specifying `'changelog-producer' = 'input'`, Table Store writers rely on
their inputs as a source of complete changelog. All input records will be saved
in separated [changelog files]({{< ref "concepts/file-layouts" >}}) and will be
given to the consumers by Table Store sources.
`input` changelog producer can be used when Table Store writers' inputs are
complete changelog, such as from a database CDC, or generated by Flink stateful
computation.
diff --git a/docs/content/docs/engines/_index.md
b/docs/content/engines/_index.md
similarity index 100%
rename from docs/content/docs/engines/_index.md
rename to docs/content/engines/_index.md
diff --git a/docs/content/docs/engines/flink.md b/docs/content/engines/flink.md
similarity index 100%
rename from docs/content/docs/engines/flink.md
rename to docs/content/engines/flink.md
diff --git a/docs/content/docs/engines/hive.md b/docs/content/engines/hive.md
similarity index 98%
rename from docs/content/docs/engines/hive.md
rename to docs/content/engines/hive.md
index 740f485f..84ddfb3e 100644
--- a/docs/content/docs/engines/hive.md
+++ b/docs/content/engines/hive.md
@@ -80,7 +80,7 @@ By using table store Hive catalog, you can create, drop and
insert into table st
**Step 1: Prepare Table Store Hive Catalog Jar File for Flink**
-See [creating a catalog with Hive metastore]({{< ref
"docs/how-to/creating-catalogs#creating-a-catalog-with-hive-metastore" >}}).
+See [creating a catalog with Hive metastore]({{< ref
"how-to/creating-catalogs#creating-a-catalog-with-hive-metastore" >}}).
**Step 2: Create Test Data with Flink SQL**
diff --git a/docs/content/docs/engines/overview.md
b/docs/content/engines/overview.md
similarity index 100%
rename from docs/content/docs/engines/overview.md
rename to docs/content/engines/overview.md
diff --git a/docs/content/docs/engines/spark2.md
b/docs/content/engines/spark2.md
similarity index 97%
rename from docs/content/docs/engines/spark2.md
rename to docs/content/engines/spark2.md
index b6decd64..4ab5a739 100644
--- a/docs/content/docs/engines/spark2.md
+++ b/docs/content/engines/spark2.md
@@ -68,7 +68,7 @@ If you are using HDFS, make sure that the environment
variable `HADOOP_HOME` or
**Step 1: Prepare Test Data**
-Table Store currently only supports reading tables through Spark2. To create a
Table Store table with records, please follow our [Flink quick start guide]({{<
ref "docs/engines/flink#quick-start" >}}).
+Table Store currently only supports reading tables through Spark2. To create a
Table Store table with records, please follow our [Flink quick start guide]({{<
ref "engines/flink#quick-start" >}}).
After the guide, all table files should be stored under the path
`/tmp/table_store`, or the warehouse path you've specified.
diff --git a/docs/content/docs/engines/spark3.md
b/docs/content/engines/spark3.md
similarity index 100%
rename from docs/content/docs/engines/spark3.md
rename to docs/content/engines/spark3.md
diff --git a/docs/content/docs/engines/trino.md b/docs/content/engines/trino.md
similarity index 100%
rename from docs/content/docs/engines/trino.md
rename to docs/content/engines/trino.md
diff --git a/docs/content/docs/filesystems/_index.md
b/docs/content/filesystems/_index.md
similarity index 100%
rename from docs/content/docs/filesystems/_index.md
rename to docs/content/filesystems/_index.md
diff --git a/docs/content/docs/filesystems/oss.md
b/docs/content/filesystems/oss.md
similarity index 97%
rename from docs/content/docs/filesystems/oss.md
rename to docs/content/filesystems/oss.md
index 74a931b9..8bc14889 100644
--- a/docs/content/docs/filesystems/oss.md
+++ b/docs/content/filesystems/oss.md
@@ -99,7 +99,7 @@ SET tablestore.fs.oss.accessKeyId=xxx;
SET tablestore.fs.oss.accessKeySecret=yyy;
```
-And read table from hive metastore, table can be created by Flink or Spark,
see [Catalog with Hive Metastore]({{< ref "docs/how-to/creating-catalogs" >}})
+And read table from hive metastore, table can be created by Flink or Spark,
see [Catalog with Hive Metastore]({{< ref "how-to/creating-catalogs" >}})
```sql
SELECT * FROM test_table;
SELECT COUNT(1) FROM test_table;
diff --git a/docs/content/docs/filesystems/overview.md
b/docs/content/filesystems/overview.md
similarity index 100%
rename from docs/content/docs/filesystems/overview.md
rename to docs/content/filesystems/overview.md
diff --git a/docs/content/docs/filesystems/s3.md
b/docs/content/filesystems/s3.md
similarity index 97%
rename from docs/content/docs/filesystems/s3.md
rename to docs/content/filesystems/s3.md
index 274fb797..f0618fad 100644
--- a/docs/content/docs/filesystems/s3.md
+++ b/docs/content/filesystems/s3.md
@@ -99,7 +99,7 @@ SET tablestore.s3.access-key=xxx;
SET tablestore.s3.secret-key=yyy;
```
-And read table from hive metastore, table can be created by Flink or Spark,
see [Catalog with Hive Metastore]({{< ref "docs/how-to/creating-catalogs" >}})
+And read table from hive metastore, table can be created by Flink or Spark,
see [Catalog with Hive Metastore]({{< ref "how-to/creating-catalogs" >}})
```sql
SELECT * FROM test_table;
SELECT COUNT(1) FROM test_table;
diff --git a/docs/content/docs/how-to/_index.md b/docs/content/how-to/_index.md
similarity index 100%
rename from docs/content/docs/how-to/_index.md
rename to docs/content/how-to/_index.md
diff --git a/docs/content/docs/how-to/altering-tables.md
b/docs/content/how-to/altering-tables.md
similarity index 100%
rename from docs/content/docs/how-to/altering-tables.md
rename to docs/content/how-to/altering-tables.md
diff --git a/docs/content/docs/how-to/creating-catalogs.md
b/docs/content/how-to/creating-catalogs.md
similarity index 97%
rename from docs/content/docs/how-to/creating-catalogs.md
rename to docs/content/how-to/creating-catalogs.md
index 5213681d..6a9c6a09 100644
--- a/docs/content/docs/how-to/creating-catalogs.md
+++ b/docs/content/how-to/creating-catalogs.md
@@ -31,7 +31,7 @@ Table Store catalogs currently support two types of
metastores:
* `filesystem` metastore (default), which stores both metadata and table files
in filesystems.
* `hive` metastore, which additionally stores metadata in Hive metastore.
Users can directly access the tables from Hive.
-See [CatalogOptions]({{< ref "docs/maintenance/configurations#catalogoptions"
>}}) for detailed options when creating a catalog.
+See [CatalogOptions]({{< ref "maintenance/configurations#catalogoptions" >}})
for detailed options when creating a catalog.
## Creating a Catalog with Filesystem Metastore
diff --git a/docs/content/docs/how-to/creating-tables.md
b/docs/content/how-to/creating-tables.md
similarity index 96%
rename from docs/content/docs/how-to/creating-tables.md
rename to docs/content/how-to/creating-tables.md
index 695e8f06..a83ea6e4 100644
--- a/docs/content/docs/how-to/creating-tables.md
+++ b/docs/content/how-to/creating-tables.md
@@ -28,7 +28,7 @@ under the License.
## Creating Catalog Managed Tables
-Tables created in Table Store [catalogs]({{< ref
"docs/how-to/creating-catalogs" >}}) are managed by the catalog. When the table
is dropped from catalog, its table files will also be deleted.
+Tables created in Table Store [catalogs]({{< ref "how-to/creating-catalogs"
>}}) are managed by the catalog. When the table is dropped from catalog, its
table files will also be deleted.
The following SQL assumes that you have registered and are using a Table Store
catalog. It creates a managed table named `MyTable` with five columns in the
catalog's `default` database, where `dt`, `hh` and `user_id` are the primary
keys.
@@ -111,7 +111,7 @@ Partition keys must be a subset of primary keys if primary
keys are defined.
{{< /hint >}}
{{< hint info >}}
-By configuring [partition.expiration-time]({{< ref
"docs/maintenance/manage-partition" >}}), expired partitions can be
automatically deleted.
+By configuring [partition.expiration-time]({{< ref
"maintenance/manage-partition" >}}), expired partitions can be automatically
deleted.
{{< /hint >}}
## Create Table As
@@ -263,7 +263,7 @@ CREATE TABLE MyTableLike LIKE MyTable;
### Table Properties
-Users can specify table properties to enable features or improve performance
of Table Store. For a complete list of such properties, see
[configurations]({{< ref "docs/maintenance/configurations" >}}).
+Users can specify table properties to enable features or improve performance
of Table Store. For a complete list of such properties, see
[configurations]({{< ref "maintenance/configurations" >}}).
The following SQL creates a table named `MyTable` with five columns
partitioned by `dt` and `hh`, where `dt`, `hh` and `user_id` are the primary
keys. This table has two properties: `'bucket' = '2'` and `'bucket-key' =
'user_id'`.
diff --git a/docs/content/docs/how-to/lookup-joins.md
b/docs/content/how-to/lookup-joins.md
similarity index 100%
rename from docs/content/docs/how-to/lookup-joins.md
rename to docs/content/how-to/lookup-joins.md
diff --git a/docs/content/docs/how-to/querying-tables.md
b/docs/content/how-to/querying-tables.md
similarity index 98%
rename from docs/content/docs/how-to/querying-tables.md
rename to docs/content/how-to/querying-tables.md
index 4884db2f..47106e94 100644
--- a/docs/content/docs/how-to/querying-tables.md
+++ b/docs/content/how-to/querying-tables.md
@@ -59,7 +59,7 @@ Produces the latest snapshot on the table upon first startup,
and continues to r
<tr>
<td>compacted-full</td>
<td>
-Produces the snapshot after the latest <a href="{{< ref
"docs/concepts/file-layouts#lsm-trees#compactions" >}}">compaction</a>.
+Produces the snapshot after the latest <a href="{{< ref
"concepts/file-layouts#lsm-trees#compactions" >}}">compaction</a>.
</td>
<td>
Produces the snapshot after the latest compaction on the table upon first
startup, and continues to read the following changes.
@@ -83,7 +83,7 @@ Produces the snapshot after the latest compaction on the
table upon first startu
</tbody>
</table>
-Users can also adjust `changelog-producer` table property to specify the
pattern of produced changes. See [changelog producer]({{< ref
"docs/concepts/primary-key-table#changelog-producers" >}}) for details.
+Users can also adjust `changelog-producer` table property to specify the
pattern of produced changes. See [changelog producer]({{< ref
"concepts/primary-key-table#changelog-producers" >}}) for details.
{{< img src="/img/scan-mode.png">}}
diff --git a/docs/content/docs/how-to/writing-tables.md
b/docs/content/how-to/writing-tables.md
similarity index 99%
rename from docs/content/docs/how-to/writing-tables.md
rename to docs/content/how-to/writing-tables.md
index 15762108..13e785c1 100644
--- a/docs/content/docs/how-to/writing-tables.md
+++ b/docs/content/how-to/writing-tables.md
@@ -275,7 +275,7 @@ Table Store supports "MERGE INTO" via submitting the
'merge-into' job through `f
{{< hint info >}}
Important table properties setting:
-1. Only [primary key table]({{< ref "docs/concepts/primary-key-table" >}})
supports this feature.
+1. Only [primary key table]({{< ref "concepts/primary-key-table" >}}) supports
this feature.
2. The action won't produce UPDATE_BEFORE, so it's not recommended to set
'changelog-producer' = 'input'.
{{< /hint >}}
diff --git a/docs/content/docs/maintenance/_index.md
b/docs/content/maintenance/_index.md
similarity index 100%
rename from docs/content/docs/maintenance/_index.md
rename to docs/content/maintenance/_index.md
diff --git a/docs/content/docs/maintenance/configurations.md
b/docs/content/maintenance/configurations.md
similarity index 100%
rename from docs/content/docs/maintenance/configurations.md
rename to docs/content/maintenance/configurations.md
diff --git a/docs/content/docs/maintenance/expiring-snapshots.md
b/docs/content/maintenance/expiring-snapshots.md
similarity index 88%
rename from docs/content/docs/maintenance/expiring-snapshots.md
rename to docs/content/maintenance/expiring-snapshots.md
index 00824856..44938af1 100644
--- a/docs/content/docs/maintenance/expiring-snapshots.md
+++ b/docs/content/maintenance/expiring-snapshots.md
@@ -26,7 +26,7 @@ under the License.
# Expiring Snapshots
-Table Store writers generates one or two [snapshots]({{< ref
"docs/concepts/basic-concepts#snapshots" >}}) per commit. Each snapshot may add
some new data files or mark some old data files as deleted. However, the marked
data files are not truly deleted because Table Store also supports time
traveling to an earlier snapshot. They are only deleted when the snapshot
expires.
+Table Store writers generates one or two [snapshots]({{< ref
"concepts/basic-concepts#snapshots" >}}) per commit. Each snapshot may add some
new data files or mark some old data files as deleted. However, the marked data
files are not truly deleted because Table Store also supports time traveling to
an earlier snapshot. They are only deleted when the snapshot expires.
Currently, expiration is automatically performed by Table Store writers when
committing new changes. By expiring old snapshots, old data files and metadata
files that are no longer used can be deleted to release disk space.
diff --git a/docs/content/docs/maintenance/manage-partition.md
b/docs/content/maintenance/manage-partition.md
similarity index 100%
rename from docs/content/docs/maintenance/manage-partition.md
rename to docs/content/maintenance/manage-partition.md
diff --git a/docs/content/docs/maintenance/rescale-bucket.md
b/docs/content/maintenance/rescale-bucket.md
similarity index 100%
rename from docs/content/docs/maintenance/rescale-bucket.md
rename to docs/content/maintenance/rescale-bucket.md
diff --git a/docs/content/docs/maintenance/write-performance.md
b/docs/content/maintenance/write-performance.md
similarity index 90%
rename from docs/content/docs/maintenance/write-performance.md
rename to docs/content/maintenance/write-performance.md
index 70f527b2..f753af73 100644
--- a/docs/content/docs/maintenance/write-performance.md
+++ b/docs/content/maintenance/write-performance.md
@@ -57,9 +57,9 @@ It is recommended that the parallelism of sink should be less
than or equal to t
### Number of Sorted Runs to Trigger Compaction
-Table Store uses [LSM tree]({{< ref "docs/concepts/file-layouts#lsm-trees"
>}}) which supports a large number of updates. LSM organizes files in several
[sorted runs]({{< ref "docs/concepts/file-layouts#lsm-trees#sorted-runs" >}}).
When querying records from an LSM tree, all sorted runs must be combined to
produce a complete view of all records.
+Table Store uses [LSM tree]({{< ref "concepts/file-layouts#lsm-trees" >}})
which supports a large number of updates. LSM organizes files in several
[sorted runs]({{< ref "concepts/file-layouts#lsm-trees#sorted-runs" >}}). When
querying records from an LSM tree, all sorted runs must be combined to produce
a complete view of all records.
-One can easily see that too many sorted runs will result in poor query
performance. To keep the number of sorted runs in a reasonable range, Table
Store writers will automatically perform [compactions]({{< ref
"docs/concepts/file-layouts#lsm-trees#compactions" >}}). The following table
property determines the minimum number of sorted runs to trigger a compaction.
+One can easily see that too many sorted runs will result in poor query
performance. To keep the number of sorted runs in a reasonable range, Table
Store writers will automatically perform [compactions]({{< ref
"concepts/file-layouts#lsm-trees#compactions" >}}). The following table
property determines the minimum number of sorted runs to trigger a compaction.
<table class="table table-bordered">
<thead>
@@ -116,7 +116,7 @@ Write stalls will become less frequent when
`num-sorted-run.stop-trigger` become
By default, Table Store writers will perform compaction as needed when writing
records. This is sufficient for most use cases, but there are two downsides:
* This may result in unstable write throughput because throughput might
temporarily drop when performing a compaction.
-* Compaction will mark some data files as "deleted" (not really deleted, see
[expiring snapshots]({{< ref "docs/maintenance/expiring-snapshots" >}}) for
more info). If multiple writers mark the same file a conflict will occur when
committing the changes. Table Store will automatically resolve the conflict,
but this may result in job restarts.
+* Compaction will mark some data files as "deleted" (not really deleted, see
[expiring snapshots]({{< ref "maintenance/expiring-snapshots" >}}) for more
info). If multiple writers mark the same file a conflict will occur when
committing the changes. Table Store will automatically resolve the conflict,
but this may result in job restarts.
To avoid these downsides, users can also choose to skip compactions in
writers, and run a dedicated job only for compaction. As compactions are
performed only by the dedicated job, writers can continuously write records
without pausing and no conflicts will ever occur.
diff --git a/docs/content/versions.md b/docs/content/versions.md
index ee89ff05..0fa4dbbd 100644
--- a/docs/content/versions.md
+++ b/docs/content/versions.md
@@ -2,6 +2,7 @@
title: Versions
type: docs
bookToc: false
+bookHidden: true
---
<!--
Licensed to the Apache Software Foundation (ASF) under one
