From 719366105ddaeaf4c32ff07fc56de8a4dd644c2c Mon Sep 17 00:00:00 2001 From: qqqttt123 <148952220+qqqttt123@users.noreply.github.com> Date: Wed, 25 Oct 2023 17:31:09 +0800 Subject: [PATCH] [MINOR] docs: Fix some spelling errors in the rfc doc (#590) ### What changes were proposed in this pull request? Fix some spelling errors in the rfc doc. ### Why are the changes needed? Improve the quality of the document ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? No need. --------- Co-authored-by: RoryQi <1242949407@qq.com> --- rfc/rfc-2/Entity-key-encoding-for-kv-store.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/rfc/rfc-2/Entity-key-encoding-for-kv-store.md b/rfc/rfc-2/Entity-key-encoding-for-kv-store.md index bd0f9ddb6f..30e4605ffb 100644 --- a/rfc/rfc-2/Entity-key-encoding-for-kv-store.md +++ b/rfc/rfc-2/Entity-key-encoding-for-kv-store.md @@ -3,7 +3,7 @@ This software is licensed under the Apache License version 2. --> -# RFC-1: Enity Key Encoding design for KV store +# RFC-1: Entity Key Encoding design for KV store | Revision | Owner | Date | | :------- |-------| ------| @@ -12,7 +12,7 @@ ## Background Currently, there will be many data to storage, for example, -User information. Such as username, passward, user property, this data is structure data +User information. Such as username, password, user property, this data is structure data Metadata. Metadata is the key point of our product. Metadata is Heterogeneous and data may be very large Other information, such as query history, query log and so on @@ -24,7 +24,7 @@ Others like MongoDB, ES After we refer to snowflake schema and others (Hashdata and so on), KV storage is better than other kinds of storage compared to relational databases. -According to our previous design, Matadata in gravitino will be originzed as the following structure +According to our previous design, Metadata in gravitino will be organized as the following structure ![mc](../rfc-1/schema-overview.png) According to the picture above, Metadata in gravitino can be divided into multiple layers which is a little bit like a file directory structure. To implement this hierarchy, we can choose the following options to encode keys. @@ -42,8 +42,8 @@ We should design a key encoding method to encode the key of KV store that should ### Design -Firstly, we introduce a global auto-increment ID (or simply a UUID) that reprents the name of namespace. This ID is unique in the whole system. -For example, if there exists a catalog named `catalog1` with namepace name `metalake1`, and a schema name `schema3` under `catalog2`, then we will add the following key-value pair to KV store +Firstly, we introduce a global auto-increment ID (or simply a UUID) that represents the name of namespace. This ID is unique in the whole system. +For example, if there exists a catalog named `catalog1` with namespace name `metalake1`, and a schema name `schema3` under `catalog2`, then we will add the following key-value pair to KV store | Key | Value | Description | |:------------|-------------|----------------------------------------------| @@ -67,8 +67,8 @@ Then, The whole key of entity can be encoded as the following format | Key | Value | Description | |:-----------------------------------------------|---------------|---------------------------------| -| ml/{ml_id} | matalake info | ml is a short name for metalake | -| ml/{ml_id} | matalake info | ml is a short name for metalake | +| ml/{ml_id} | metalake info | ml is a short name for metalake | +| ml/{ml_id} | metalake info | ml is a short name for metalake | | ca/{ml_id}/{ca_id} | catalog_info | ca is a short name for catalog | | ca/{ml_id}/{ca_id} | catalog_info | ca is a short name for catalog | | sc/{ml_id}/{ca_id}/{sc_id} | schema_info | sc is a short name for schema |