DOCAPI-7991: Update of Log engines docs (#6516)

* Link fix.

* Fixed ZH docs build.

* DOCAPI-7991: Upate of *Log engines docs.

* DOCAPI-7991: Typo fix.

docs/en/operations/table_engines/log_family.md

@@ -1,6 +1,6 @@
 # Log Engine Family
 
-These engines were developed for scenarios when you need to write many tables with the small amount of data (less than 1 million rows).
+These engines were developed for scenarios when you need to quickly write many small tables (up to about 1 million rows) and read them later as a whole.
 
 Engines of the family:
 
@@ -14,6 +14,10 @@ Engines:
 
 - Store data on a disk.
 - Append data to the end of file when writing.
+- Support locks for concurrent data access.
+    
+    During `INSERT` query the table is locked, and other queries for reading and writing data both wait for unlocking. If there are no writing data queries, any number of reading data queries can be performed concurrently.
+
 - Do not support [mutation](../../query_language/alter.md#alter-mutations) operations.
 - Do not support indexes.
 
@@ -23,20 +27,12 @@ Engines:
 
     You can get a table with corrupted data if something breaks the write operation, for example, abnormal server shutdown.
 
+
 ## Differences
 
-The `Log` and `StripeLog` engines support:
+The `TinyLog` engine is the simplest in the family and provides the poorest functionality and lowest efficiency. The `TinyLog` engine does not support a parallel reading of data. It reads the data slower than other engines of the family that have parallel reading, and it uses almost as many descriptors as the `Log` engine because it stores each column in a separate file. Use it in simple low-load scenarios.
 
-- Locks for concurrent data access.
+The `Log` and `StripeLog` engines support parallel reading of data. When reading data ClickHouse uses multiple threads. Each thread processes separated data block. The `Log` engine uses the separate file for each column of the table. The `StripeLog` stores all the data in one file. Thus the `StripeLog` engine uses fewer descriptors in the operating system, but the `Log` engine provides a more efficient reading of the data.
 
-    During `INSERT` query the table is locked, and other queries for reading and writing data both wait for unlocking. If there are no writing data queries, any number of reading data queries can be performed concurrently.
-
-- Parallel reading of data.
-
-    When reading data ClickHouse uses multiple threads. Each thread processes separated data block.
-
-The `Log` engine uses the separate file for each column of the table. The `StripeLog` stores all the data in one file. Thus the `StripeLog` engine uses fewer descriptors in the operating system, but the `Log` engine provides a more efficient reading of the data.
-
-The `TinyLog` engine is the simplest in the family and provides the poorest functionality and lowest efficiency. The `TinyLog` engine does not support a parallel reading and concurrent access and stores each column in a separate file. It reads the data slower than both other engines with parallel reading, and it uses almost as many descriptors as the `Log` engine. You can use it in simple low-load scenarios.
 
 [Original article](https://clickhouse.yandex/docs/en/operations/table_engines/log_family/) <!--hide-->

docs/en/operations/table_engines/tinylog.md

@@ -1,22 +1,12 @@
 # TinyLog
 
-Engine belongs to the family of log engines. See the common properties of log engines and their differences in the [Log Engine Family](log_family.md) article.
+Engine belongs to the family of log engines. See [Log Engine Family](log_family.md) for common properties of log engines and for their differences.
 
-The simplest table engine, which stores data on a disk.
+The typical way using this table engine is write-once method: firstly write the data one time, then read it as many times as needed. For example, you can use `TinyLog`-type tables for intermediary data that is processed in small batches.
-Each column is stored in a separate compressed file.
-When writing, data is appended to the end of files.
 
-Concurrent data access is not restricted in any way:
+Queries are executed in a single stream. In other words, this engine is intended for relatively small tables (recommended up to about 1,000,000 rows). It makes sense to use this table engine if you have many small tables, since it is simpler than the [Log](log.md) engine (fewer files need to be opened).
 
-- If you are simultaneously reading from a table and writing to it in a different query, the read operation will complete with an error.
+The situation when you have a large number of small tables guarantees poor productivity, but may already be used when working with another DBMS, and you may find it easier to switch to using `TinyLog`-type tables.
-- If you are writing to a table in multiple queries simultaneously, the data will be broken.
 
-The typical way to use this table is write-once: first just write the data one time, then read it as many times as needed.
-Queries are executed in a single stream. In other words, this engine is intended for relatively small tables (recommended up to 1,000,000 rows).
-It makes sense to use this table engine if you have many small tables, since it is simpler than the Log engine (fewer files need to be opened).
-The situation when you have a large number of small tables guarantees poor productivity, but may already be used when working with another DBMS, and you may find it easier to switch to using TinyLog types of tables.
-**Indexes are not supported.**
-
-In Yandex.Metrica, TinyLog tables are used for intermediary data that is processed in small batches.
 
 [Original article](https://clickhouse.yandex/docs/en/operations/table_engines/tinylog/) <!--hide-->