Update index.md (#11544)

docs/zh/index.md

@@ -4,7 +4,7 @@ ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)
 
 在传统的行式数据库系统中，数据按如下顺序存储：
 
-| 行  | 小心点      | JavaEnable | 标题       | GoodEvent | 活动时间            |
+| row  | watchID      | JavaEnable | title      | GoodEvent | EventTime            |
 |-----|-------------|------------|------------|-----------|---------------------|
 | \#0 | 89354350662 | 1          | 投资者关系 | 1         | 2016-05-18 05:19:20 |
 | \#1 | 90329509958 | 0          | 联系我们   | 1         | 2016-05-18 08:10:20 |
@@ -18,23 +18,23 @@ ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)
 
 在列式数据库系统中，数据按如下的顺序存储：
 
-| 行:         | \#0                 | \#1                 | \#2                 | \#N |
+| row:         | \#0                 | \#1                 | \#2                 | \#N |
 |-------------|---------------------|---------------------|---------------------|-----|
-| 小心点:     | 89354350662         | 90329509958         | 89953706054         | …   |
+| watchID:     | 89354350662         | 90329509958         | 89953706054         | …   |
 | JavaEnable: | 1                   | 0                   | 1                   | …   |
-| 标题:       | 投资者关系          | 联系我们            | 任务                | …   |
+| title:       | 投资者关系          | 联系我们            | 任务                | …   |
 | GoodEvent:  | 1                   | 1                   | 1                   | …   |
-| 活动时间:   | 2016-05-18 05:19:20 | 2016-05-18 08:10:20 | 2016-05-18 07:38:00 | …   |
+| EventTime:   | 2016-05-18 05:19:20 | 2016-05-18 08:10:20 | 2016-05-18 07:38:00 | …   |
 
-该示例中只展示了数据在列式数据库中数据的排列顺序。
+该示例中只展示了数据在列式数据库中数据的排列方式。
 对于存储而言，列式数据库总是将同一列的数据存储在一起，不同列的数据也总是分开存储。
 
 常见的列式数据库有： Vertica、 Paraccel (Actian Matrix，Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 MonetDB (VectorWise， Actian Vector)、 LucidDB、 SAP HANA、 Google Dremel、 Google PowerDrill、 Druid、 kdb+。
 {: .灰色 }
 
-不同的存储方式适合不同的场景，这里的查询场景包括： 进行了哪些查询，多久查询一次以及各类查询的比例； 每种查询读取多少数据————行、列和字节；读取数据和写入数据之间的关系；使用的数据集大小以及如何使用本地的数据集；是否使用事务,以及它们是如何进行隔离的；数据的复制机制与数据的完整性要求；每种类型的查询要求的延迟与吞吐量等等。
+不同的数据存储方式适用不同的业务场景，数据访问的场景包括：进行了何种查询、多久查询一次以及各类查询的比例； 每种查询读取多少数据————行、列和字节；读取数据和写入数据之间的关系；使用的数据集大小以及如何使用本地的数据集；是否使用事务,以及它们是如何进行隔离的；数据的复制机制与数据的完整性要求；每种类型的查询要求的延迟与吞吐量等等。
 
-系统负载越高，根据使用场景进行定制化就越重要，并且定制将会变的越精细。没有一个系统同样适用于明显不同的场景。如果系统适用于广泛的场景，在负载高的情况下，所有的场景可以会被公平但低效处理，或者高效处理一小部分场景。
+系统负载越高，依据使用场景进行定制化就越重要，并且定制将会变的越精细。没有一个系统能够同时适用所有明显不同的业务场景。如果系统适用于广泛的场景，在负载高的情况下，要兼顾所有的场景，那么将不得不做出选择。是要平衡还是要效率？
 
 ## OLAP场景的关键特征 {#olapchang-jing-de-guan-jian-te-zheng}
 
@@ -52,7 +52,7 @@ ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)
 -   每一个查询除了一个大表外都很小
 -   查询结果明显小于源数据，换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中
 
-很容易可以看出，OLAP场景与其他流行场景(例如,OLTP或K/V)有很大的不同， 因此想要使用OLTP或Key-Value数据库去高效的处理分析查询是没有意义的，例如，使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求。
+很容易可以看出，OLAP场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同， 因此想要使用OLTP或Key-Value数据库去高效的处理分析查询场景，并不是非常完美的适用方案。例如，使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求。
 
 ## 列式数据库更适合OLAP场景的原因 {#lie-shi-shu-ju-ku-geng-gua-he-olapchang-jing-de-yuan-yin}