Merge branch 'master' of github.com:yandex/ClickHouse

dbms/programs/copier/ClusterCopier.cpp

@@ -481,7 +481,7 @@ String DB::TaskShard::getHostNameExample() const
 }
 
 
-static bool isExtedndedDefinitionStorage(const ASTPtr & storage_ast)
+static bool isExtendedDefinitionStorage(const ASTPtr & storage_ast)
 {
     const ASTStorage & storage = typeid_cast<const ASTStorage &>(*storage_ast);
     return storage.partition_by || storage.order_by || storage.sample_by;
@@ -503,7 +503,7 @@ static ASTPtr extractPartitionKey(const ASTPtr & storage_ast)
     ASTPtr arguments_ast = engine.arguments->clone();
     ASTs & arguments = typeid_cast<ASTExpressionList &>(*arguments_ast).children;
 
-    if (isExtedndedDefinitionStorage(storage_ast))
+    if (isExtendedDefinitionStorage(storage_ast))
     {
         if (storage.partition_by)
             return storage.partition_by->clone();

docs/en/development/architecture.md

@@ -4,7 +4,7 @@ ClickHouse is a true column-oriented DBMS. Data is stored by columns, and during
 
 > This idea is nothing new. It dates back to the `APL` programming language and its descendants: `A +`, `J`, `K`, and `Q`. Array programming is used in scientific data processing. Neither is this idea something new in relational databases: for example, it is used in the `Vectorwise` system.
 
-There are two different approaches for speeding up the query processing: vectorized query execution and runtime code generation. In the latter, the code is generated for every kind of query on the fly, removing all indirection and dynamic dispatch. Neither of these approaches is strictly better than the other. Runtime code generation can be better when it's fuses many operations together, thus fully utilizing CPU execution units and the pipeline. Vectorized query execution can be less practical, because it involves the temporary vectors that must be written to the cache and read back. If the temporary data does not fit in the L2 cache, this becomes an issue. But vectorized query execution more easily utilizes the SIMD capabilities of the CPU. A [research paper](http://15721.courses.cs.cmu.edu/spring2016/papers/p5-sompolski.pdf) written by our friends shows that it is better to combine both approaches. ClickHouse uses vectorized query execution and has limited initial support for runtime code.
+There are two different approaches for speeding up the query processing: vectorized query execution and runtime code generation. In the latter, the code is generated for every kind of query on the fly, removing all indirection and dynamic dispatch. Neither of these approaches is strictly better than the other. Runtime code generation can be better when it fuses many operations together, thus fully utilizing CPU execution units and the pipeline. Vectorized query execution can be less practical, because it involves temporary vectors that must be written to the cache and read back. If the temporary data does not fit in the L2 cache, this becomes an issue. But vectorized query execution more easily utilizes the SIMD capabilities of the CPU. A [research paper](http://15721.courses.cs.cmu.edu/spring2016/papers/p5-sompolski.pdf) written by our friends shows that it is better to combine both approaches. ClickHouse uses vectorized query execution and has limited initial support for runtime code generation.
 
 ## Columns
 
@@ -67,7 +67,7 @@ There are also row streams: `IRowInputStream` and `IRowOutputStream`. They allow
 
 ## I/O
 
-For byte-oriented input/output, there are `ReadBuffer` and `WriteBuffer` abstract classes. They are used instead of C++ `iostream`'s. Don't worry: every mature C++ project is using something other than `iostream`'s for good reasons.
+For byte-oriented input/output, there are `ReadBuffer` and `WriteBuffer` abstract classes. They are used instead of C++ `iostream`s. Don't worry: every mature C++ project is using something other than `iostream`s for good reasons.
 
 `ReadBuffer` and `WriteBuffer` are just a contiguous buffer and a cursor pointing to the position in that buffer. Implementations may own or not own the memory for the buffer. There is a virtual method to fill the buffer with the following data (for `ReadBuffer`) or to flush the buffer somewhere (for `WriteBuffer`). The virtual methods are rarely called.
 

docs/zh/operations/table_engines/null.md

@@ -1,8 +1,8 @@
 # Null
 
-When writing to a Null table, data is ignored. When reading from a Null table, the response is empty.
+当写入 Null 类型的表时，将忽略数据。从 Null 类型的表中读取时，返回空。
 
-However, you can create a materialized view on a Null table. So the data written to the table will end up in the view.
+但是，可以在 Null 类型的表上创建物化视图。写入表的数据将转发到视图中。
 
 
 [Original article](https://clickhouse.yandex/docs/en/operations/table_engines/null/) <!--hide-->

docs/zh/operations/table_engines/set.md

@@ -1,13 +1,12 @@
 # Set
 
-A data set that is always in RAM. It is intended for use on the right side of the IN operator (see the section "IN operators").
+始终存在于 RAM 中的数据集。它适用于IN运算符的右侧（请参见 "IN运算符" 部分）。
 
-You can use INSERT to insert data in the table. New elements will be added to the data set, while duplicates will be ignored.
-But you can't perform SELECT from the table. The only way to retrieve data is by using it in the right half of the IN operator.
+可以使用 INSERT 向表中插入数据。新元素将添加到数据集中，而重复项将被忽略。但是不能对此类型表执行 SELECT 语句。检索数据的唯一方法是在 IN 运算符的右半部分使用它。
 
-Data is always located in RAM. For INSERT, the blocks of inserted data are also written to the directory of tables on the disk. When starting the server, this data is loaded to RAM. In other words, after restarting, the data remains in place.
+数据始终存在于 RAM 中。对于 INSERT，插入数据块也会写入磁盘上的表目录。启动服务器时，此数据将加载到 RAM。也就是说，重新启动后，数据仍然存在。
 
-For a rough server restart, the block of data on the disk might be lost or damaged. In the latter case, you may need to manually delete the file with damaged data.
+对于强制服务器重启，磁盘上的数据块可能会丢失或损坏。在数据块损坏的情况下，可能需要手动删除包含损坏数据的文件。
 
 
 [Original article](https://clickhouse.yandex/docs/en/operations/table_engines/set/) <!--hide-->

docs/zh/operations/table_engines/view.md

@@ -1,6 +1,6 @@
 # View
 
-Used for implementing views (for more information, see the `CREATE VIEW query`). It does not store data, but only stores the specified `SELECT` query. When reading from a table, it runs this query (and deletes all unnecessary columns from the query).
+用于构建视图（有关更多信息，请参阅 `CREATE VIEW 查询`）。 它不存储数据，仅存储指定的 `SELECT` 查询。 从表中读取时，它会运行此查询（并从查询中删除所有不必要的列）。
 
 
 [Original article](https://clickhouse.yandex/docs/en/operations/table_engines/view/) <!--hide-->