[docs] title case and fixes in en/concepts/ (#16703)

Author: blinkov

ydb/docs/en/core/concepts/_includes/datamodel/blockdevice.md

@@ -1,22 +1,22 @@
-## How it works?
+## How It Works?
 
-Fully explaining how YDB works in detail takes quite a while. Below you can review several key highlights and then continue exploring documentation to learn more.
+Fully explaining how YDB works in detail takes quite a while. Below you can review several key highlights and then continue exploring the documentation to learn more.
 
-### {{ ydb-short-name }} architecture {#ydb-architecture}
+### {{ ydb-short-name }} Architecture {#ydb-architecture}
 
 ![YDB architecture](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/grps.png)
 
-{{ ydb-short-name }} clusters typically run on commodity hardware with shared-nothing architecture. If you look at {{ ydb-short-name }} from a bird's eye view, you'll see a layered architecture. The compute and storage layers are disaggregated, they can either run on separate sets of nodes or be co-located.
+{{ ydb-short-name }} clusters typically run on commodity hardware with a shared-nothing architecture. From a bird's eye view, {{ ydb-short-name }} exhibits a layered architecture. The compute and storage layers are disaggregated; they can either run on separate sets of nodes or be co-located.
 
-One of the key building blocks of {{ ydb-short-name }}'s compute layer is called a *tablet*. They are stateful logical components implementing various aspects of {{ ydb-short-name }}.
+One of the key building blocks of {{ ydb-short-name }}'s compute layer is called a *tablet*. Tablets are stateful logical components implementing various aspects of {{ ydb-short-name }}.
 
-The next level of detail of overall {{ ydb-short-name }} architecture is explained in the [{#T}](../../../contributor/general-schema.md) article.
+The next level of detail of the overall {{ ydb-short-name }} architecture is explained in the [{#T}](../../../contributor/general-schema.md) article.
 
 ### Hierarchy {#ydb-hierarchy}
 
 ![Hierarchy](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/organization.png)
 
-From the user's perspective, everything inside {{ ydb-short-name }} is organized in a hierarchical structure using directories. It can have arbitrary depth depending on how you choose to organize your data and projects. Even though {{ ydb-short-name }} does not have a fixed hierarchy depth like in other SQL implementations, it will still feel familiar as this is exactly how any virtual filesystem looks like.
+From the user's perspective, everything inside {{ ydb-short-name }} is organized in a hierarchical structure using directories. It can have arbitrary depth depending on how you choose to organize your data and projects. Even though {{ ydb-short-name }} does not have a fixed hierarchy depth like in other SQL implementations, it will still feel familiar as this is exactly how any virtual filesystem looks.
 
 ### Table {#table}
 
@@ -27,7 +27,7 @@ From the user's perspective, everything inside {{ ydb-short-name }} is organized
 * [Row-oriented tables](../../datamodel/table.md#row-tables) are designed for OLTP workloads.
 * [Column-oriented tables](../../datamodel/table.md#column-tables) are designed for OLAP workloads.
 
-Logically, from the user’s perspective, both types of tables look the same. The main difference between row-oriented and column-oriented tables lies in how the data is physically stored. In row-oriented tables, the values of all columns in each row are stored together. In contrast, in column-oriented tables, each column is stored separately, meaning that cells from different rows are stored next to each other within the same column.
+Logically, from the user's perspective, both types of tables look the same. The main difference between row-oriented and column-oriented tables lies in how the data is physically stored. In row-oriented tables, the values of all columns in each row are stored together. In contrast, in column-oriented tables, each column is stored separately, meaning that cells from different rows are stored next to each other within the same column.
 
 Regardless of the type, each table must have a primary key. Column-oriented tables can only have `NOT NULL` columns in primary keys. Table data is physically sorted by the primary key.
 
@@ -38,32 +38,32 @@ Partitioning works differently in row-oriented and column-oriented tables:
 
 Each partition of a table is processed by a specific [tablet](../../glossary.md#tablets), called a [data shard](../../glossary.md#datashard) for row-oriented tables and a [column shard](../../glossary.md#columnshard) for column-oriented tables.
 
-#### Split by load {#split-by-load}
+#### Split by Load {#split-by-load}
 
 ![Split by load](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/nagruz%201.5.png)
 
-Data shards will automatically split into more ones as the load increases. They automatically merge back to the appropriate number when the peak load goes away.
+Data shards will automatically split into more as the load increases. They automatically merge back to the appropriate number when the peak load subsides.
 
-#### Split by size {#split-by-size}
+#### Split by Size {#split-by-size}
 
 ![Split by size](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/size%201.5%20(1).png)
 
-Data shards also will automatically split when the data size increases. They automatically merge back if enough data will be deleted.
+Data shards will also automatically split when the data size increases. They automatically merge back if enough data is deleted.
 
-### Automatic balancing {#automatic-balancing}
+### Automatic Balancing {#automatic-balancing}
 
 ![Automatic balancing](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/pills%201.5.png)
 
-{{ ydb-short-name }} evenly distributes tablets among available nodes. It moves heavily loaded tablets from overloaded nodes. CPU, Memory, and Network metrics are tracked to facilitate this.
+{{ ydb-short-name }} evenly distributes tablets among available nodes. It moves heavily loaded tablets from overloaded nodes. CPU, memory, and network metrics are tracked to facilitate this.
 
-### Distributed Storage internals {#ds-internals}
+### Distributed Storage Internals {#ds-internals}
 
 ![Distributed Storage internals](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/distributed.png)
 
 {{ ydb-short-name }} doesn't rely on any third-party filesystem. It stores data by directly working with disk drives as block devices. All major disk kinds are supported: NVMe, SSD, or HDD. The PDisk component is responsible for working with a specific block device. The abstraction layer above PDisk is called VDisk. There is a special component called DSProxy between a tablet and VDisk. DSProxy analyzes disk availability and characteristics and chooses which disks will handle a request and which won't.
 
-### Distributed Storage proxy (DSProxy) {#ds-proxy}
+### Distributed Storage Proxy (DSProxy) {#ds-proxy}
 
 ![DSProxy](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/proxy%202.png)
 
-A common fault-tolerant setup of {{ ydb-short-name }} spans 3 datacenters or availability zones (AZ). When {{ ydb-short-name }} writes data to 3 AZ, it doesn’t send requests to obviously bad disks and continues to operate without interruption even if one AZ and a disk in another AZ are lost.
+A common fault-tolerant setup of {{ ydb-short-name }} spans three datacenters or availability zones (AZ). When {{ ydb-short-name }} writes data to three AZs, it doesn't send requests to obviously bad disks and continues to operate without interruption even if one AZ and a disk in another AZ are lost.

ydb/docs/en/core/concepts/_includes/datamodel/dir.md

@@ -1,23 +1,23 @@
-# {{ ydb-short-name }} overview
+# {{ ydb-short-name }} Overview
 
-*{{ ydb-short-name }}* is a horizontally scalable distributed fault-tolerant DBMS. {{ ydb-short-name }} is designed for high performance with a typical server being capable of handling tens of thousands of queries per second. The system is designed to handle hundreds of petabytes of data. {{ ydb-short-name }} can operate in single data center and geo-distributed (cross data center) modes on a cluster of thousands of servers.
+*{{ ydb-short-name }}* is a horizontally scalable, distributed, fault-tolerant DBMS. It is designed for high performance, with a typical server capable of handling tens of thousands of queries per second. The system is designed to handle hundreds of petabytes of data. {{ ydb-short-name }} can operate in both single data center and geo-distributed (cross data center) modes on a cluster of thousands of servers.
 
 {{ ydb-short-name }} provides:
 
-* [Strict consistency](https://en.wikipedia.org/wiki/Consistency_model#Strict_Consistency) which can be relaxed to increase performance.
-* Support for queries written in [YQL](../../../yql/reference/index.md) (an SQL dialect for working with big data).
+* [Strict consistency](https://en.wikipedia.org/wiki/Consistency_model#Strict_Consistency), which can be relaxed to increase performance.
+* Support for queries written in [YQL](../../../yql/reference/index.md), an SQL dialect for working with big data.
 * Automatic data replication.
-* High availability with automatic failover in case a server, rack, or availability zone goes offline.
+* High availability with automatic failover if a server, rack, or availability zone goes offline.
 * Automatic data partitioning as data or load grows.
 
-To interact with {{ ydb-short-name }}, you can use the [{{ ydb-short-name }} CLI](../../../reference/ydb-cli/index.md) and [SDK](../../../reference/ydb-sdk/index.md) fo C++, C#, Go, Java, Node.js, PHP, Python, and Rust.
+To interact with {{ ydb-short-name }}, you can use the [{{ ydb-short-name }} CLI](../../../reference/ydb-cli/index.md) and [SDK](../../../reference/ydb-sdk/index.md) for C++, C#, Go, Java, Node.js, PHP, Python, and Rust.
 
-{{ ydb-short-name }} supports a relational [data model](../../../concepts/datamodel/table.md) and manages [row-oriented](../../datamodel/table.md#row-oriented-tables) and [column-oriented](../../datamodel/table.md#column-oriented-tables) tables with a predefined schema. To make it easier to organize tables, directories can be created like in the file system. In addition to tables, {{ ydb-short-name }} supports [topics](../../topic.md) as an entity for storing unstructured messages and delivering them to multiple subscribers.
+{{ ydb-short-name }} supports a relational [data model](../../../concepts/datamodel/table.md) and manages [row-oriented](../../datamodel/table.md#row-oriented-tables) and [column-oriented](../../datamodel/table.md#column-oriented-tables) tables with a predefined schema. Directories can be created like in a file system to organize tables. In addition to tables, {{ ydb-short-name }} supports [topics](../../topic.md) for storing unstructured messages and delivering them to multiple subscribers.
 
-Database commands are mainly written in YQL, an SQL dialect. This gives the user a powerful and already familiar way to interact with the database.
+Database commands are mainly written in YQL, an SQL dialect, providing a powerful and familiar way to interact with the database.
 
-{{ ydb-short-name }} supports high-performance distributed [ACID](https://en.wikipedia.org/wiki/ACID_(computer_science)) transactions that may affect multiple records in different tables. It provides the serializable isolation level, which is the strictest transaction isolation. You can also reduce the level of isolation to raise performance.
+{{ ydb-short-name }} supports high-performance distributed [ACID](https://en.wikipedia.org/wiki/ACID_(computer_science)) transactions that may affect multiple records in different tables. It provides the serializable isolation level, the strictest transaction isolation, with the option to reduce the isolation level to enhance performance.
 
-{{ ydb-short-name }} natively supports different processing options, such as [OLTP](https://en.wikipedia.org/wiki/Online_transaction_processing) and [OLAP](https://en.wikipedia.org/wiki/Online_analytical_processing). The current version offers limited analytical query support. This is why we can say that {{ ydb-short-name }} is currently an OLTP database.
+{{ ydb-short-name }} natively supports different processing options, such as [OLTP](https://en.wikipedia.org/wiki/Online_transaction_processing) and [OLAP](https://en.wikipedia.org/wiki/Online_analytical_processing). The current version offers limited analytical query support, which is why {{ ydb-short-name }} is currently considered an OLTP database.
 
-{{ ydb-short-name }} is an open-source system. The {{ ydb-short-name }} source code is available under [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0). Client applications interact with {{ ydb-short-name }} based on [gRPC](https://grpc.io/) that has an open specification. It allows implementing an SDK for any programming language.
+{{ ydb-short-name }} is an open-source system. The source code is available under the [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0). Client applications interact with {{ ydb-short-name }} based on [gRPC](https://grpc.io/), which has an open specification, allowing for SDK implementation in any programming language.

ydb/docs/en/core/concepts/_includes/datamodel/intro.md

@@ -1,4 +1,4 @@
-## Use cases {#use-cases}
+## Use Cases {#use-cases}
 
 {{ ydb-short-name }} can be used as an alternative solution in the following cases: