[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 <[email protected]>
apache · Oct 25, 2023 · 7193661 · 7193661
1 parent fd70713
commit 7193661
Showing 1 changed file with 7 additions and 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
@@ -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   |