Refactoring YDB concepts (#5580)

Co-authored-by: Ivan Blinkov <ivan@ydb.tech>

Author: Pseudolukian

ydb/docs/ru/core/concepts/_includes/index/how_it_works.md

@@ -1,28 +1,34 @@
 ## Как это работает?
 
-Полное объяснение того, как работает YDB, получилось бы слишком объемным. Ниже вы можете ознакомиться с несколькими основными моментами, а затем продолжить изучение документации, чтобы узнать больше.
+Полное объяснение того, как работает {{ ydb-short-name }}, получилось бы слишком объемным. Ниже вы можете ознакомиться с несколькими основными моментами, а затем продолжить изучение документации, чтобы узнать больше.
 
-### Архитектура YDB {#ydb-architecture}
+### Архитектура {{ ydb-short-name }} {#ydb-architecture}
 
 ![Архитектура YDB](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/grps.png)
 
-Кластеры YDB обычно работают с shared nothing архитектурой на обычном оборудовании. Уровни вычислений и хранения являются разнёсенными. Они могут работать как на отдельных наборах узлов, так и быть совмещёнными.
+Кластеры {{ ydb-short-name }} обычно работают с shared nothing архитектурой на обычном оборудовании. Уровни вычислений и хранения являются разнёсенными. Они могут работать как на отдельных наборах узлов, так и быть совмещёнными.
 
-Один из ключевых элементов вычислительного слоя YDB называется *таблеткой*. Они являются логическими компонентами с состоянием, реализующими различные аспекты YDB.
+Один из ключевых элементов вычислительного слоя {{ ydb-short-name }} называется *таблеткой*. Они являются логическими компонентами с состоянием, реализующими различные аспекты {{ ydb-short-name }}.
 
-Более подробная информация об общей архитектуре YDB объясняется в разделе [документации о кластерах YDB](../../cluster/index.md).
+Более подробная информация об общей архитектуре {{ ydb-short-name }} объясняется в разделе [документации о кластерах YDB](../../cluster/index.md).
 
 ### Иерархия {#ydb-hierarchy}
 
 ![Иерархия](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/organization.png)
 
-С точки зрения пользователя, всё внутри YDB организовано в иерархической структуре с использованием каталогов. Она может иметь произвольную глубину в зависимости от того, как вы решили организовать свои данные и проекты. Хотя YDB не имеет фиксированной глубины иерархии, как в других реализациях SQL, она все равно будет знакома, поскольку именно так выглядит любая виртуальная файловая система.
+С точки зрения пользователя, всё внутри {{ ydb-short-name }} организовано в иерархической структуре с использованием каталогов. Она может иметь произвольную глубину в зависимости от того, как вы решили организовать свои данные и проекты. Хотя YDB не имеет фиксированной глубины иерархии, как в других реализациях SQL, она все равно будет знакома, поскольку именно так выглядит любая виртуальная файловая система.
 
 ### Таблица
 
 ![Таблица](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/table.png)
 
-YDB предоставляет пользователям хорошо известную абстракцию: таблицы. В YDB таблицы должны содержать первичный ключ, данные физически сортируются по первичному ключу. Таблицы автоматически шардируются по диапазонам первичных ключей в зависимости от нагрузки и объема данных. Каждый диапазон первичных ключей таблицы обрабатывается определенной таблеткой, называемой *data shard*.
+{{ ydb-short-name}} предоставляет пользователям хорошо известную абстракцию — таблицы. В {{ ydb-short-name }} существует два основных типа таблиц:
+* [Строковые таблицы](../../datamodel/table.md#row-tables) предназначены для OLTP-нагрузок.
+* [Колоночные таблицы](../../datamodel/table.md#column-tables) предназначены для OLAP-нагрузок.
+
+Логически, с точки зрения пользователя, оба вида таблиц выглядят одинаково. Основное отличие между строковыми и колоночными таблицами заключается в способе хранения данных. В строковых таблицах значения всех колонок каждой строки располагаются рядом, а в колоночных таблицах — наоборот, каждая колонка хранится отдельно, и рядом оказываются ячейки, относящиеся к разным строкам.
+
+Независимо от типа таблицы, она должна содержать первичный ключ. В первичном ключе колоночных таблиц можно использовать только колонки с `NOT NULL`. Данные в таблицах физически сортируются по первичному ключу. Строковые таблицы автоматически партицируются по диапазонам первичных ключей в зависимости от объёма данных, а данные в колоночных таблицах партицируются не по первичному ключу, а по хешу от колонок партицирования. Каждый диапазон первичных ключей таблицы обрабатывается определённой [таблеткой](../../cluster/common_scheme_ydb.md#tablets), называемой *data shard* для строчных таблиц и *column shard* — для колоночных.
 
 #### Разделение по нагрузке
 
@@ -40,16 +46,16 @@ Data shard также автоматически разделяются при 
 
 ![Автоматическое балансирование](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/pills%201.5.png)
 
-YDB равномерно распределяет таблетки среди доступных узлов. Она перемещает тяжело загруженные таблетки с перегруженных узлов. Метрики CPU, памяти и сети отслеживаются для облегчения этого процесса.
+{{ ydb-short-name }} равномерно распределяет таблетки среди доступных узлов. Она перемещает тяжело загруженные таблетки с перегруженных узлов. Метрики CPU, памяти и сети отслеживаются для облегчения этого процесса.
 
 ### Внутреннее устройство распределенного хранилища
 
 ![Внутреннее устройство распределенного хранилища](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/distributed.png)
 
-YDB не полагается на сторонние файловые системы. Она хранит данные, работая непосредственно с дисковыми накопителями как блочными устройствами. Поддерживаются все основные типы дисков: NVMe, SSD или HDD. За работу с конкретным блочным устройством отвечает компонент PDisk. Уровень абстракции выше PDisk называется VDisk. Также есть специальный компонент, называемый DSProxy, между таблеткой и VDisk. DSProxy анализирует доступность и характеристики дисков и выбирает, какие диски будут обрабатывать запрос, а какие нет.
+{{ ydb-short-name }} не полагается на сторонние файловые системы. Она хранит данные, работая непосредственно с дисковыми накопителями как блочными устройствами. Поддерживаются все основные типы дисков: NVMe, SSD или HDD. За работу с конкретным блочным устройством отвечает компонент PDisk. Уровень абстракции выше PDisk называется VDisk. Также есть специальный компонент, называемый DSProxy, между таблеткой и VDisk. DSProxy анализирует доступность и характеристики дисков и выбирает, какие диски будут обрабатывать запрос, а какие нет.
 
 ### Прокси распределенного хранилища (DSProxy)
 
 ![DSProxy](https://storage.yandexcloud.net/ydb-www-prod-site-assets/howitworks/proxy%202.png)
 
-Геораспределенная и отказоустойчивая конфигурация YDB обычно охватывает 3 датацентра или зоны доступности (Availability Zone - AZ). Когда YDB записывает данные на 3 зоны доступности, он не отправляет запросы на явно некорректные диски и продолжает работать без прерываний даже если одна зона доступности и диск в другой зоне доступности потеряны.
+Геораспределенная и отказоустойчивая конфигурация {{ ydb-short-name }} обычно охватывает 3 датацентра или зоны доступности (Availability Zone - AZ). Когда {{ ydb-short-name }} записывает данные на 3 зоны доступности, он не отправляет запросы на явно некорректные диски и продолжает работать без прерываний даже если одна зона доступности и диск в другой зоне доступности потеряны.

ydb/docs/ru/core/concepts/_includes/index/intro.md

@@ -17,11 +17,11 @@ description: 'YDB — это горизонтально масштабируем
 
 Для взаимодействия с {{ ydb-short-name }} доступен [{{ ydb-short-name }} CLI](../../../reference/ydb-cli/index.md), а также [SDK](../../../reference/ydb-sdk/index.md) для C++, C#, Go, Java, Node.js, PHP, Python и Rust.
 
-{{ ydb-short-name }} поддерживает реляционную [модель данных](../../../concepts/datamodel/table.md) и оперирует [таблицами](../../datamodel/table.md) с предопределенной схемой. Для удобства организации таблиц поддерживается создание директорий по аналогии с файловой системой. Помимо таблиц {{ ydb-short-name }} поддерживает [топики](../../topic.md), которые представляют собой сущность для хранения неструктурированных сообщений и доставки их множеству подписчиков.
+{{ ydb-short-name }} поддерживает реляционную модель данных и оперирует [строковыми](../../datamodel/table.md#row-tables) и [колоночными](../../datamodel/table.md#column-tables) таблицами с предопределенной схемой. Для удобства организации таблиц поддерживается создание директорий по аналогии с файловой системой. Помимо таблиц {{ ydb-short-name }} поддерживает [топики](../../topic.md), которые представляют собой сущность для хранения неструктурированных сообщений и доставки их множеству подписчиков.
 
 В качестве основного способа формирования команд к базе данных используется язык YQL, являющийся диалектом SQL. Таким образом, пользователю предлагается мощный и, в то же время, привычный способ взаимодействия с БД.
 
-В {{ ydb-short-name }} поддерживаются высокопроизводительные распределенные [ACID](https://en.wikipedia.org/wiki/ACID_(computer_science))-транзакции, которые могут затрагивать несколько записей из разных таблиц. Обеспечивается самый строгий уровень изоляции транзакций — serializable. Также имеется возможность ослабления уровня изоляции для увеличения производительности.
+В {{ ydb-short-name }} поддерживаются высокопроизводительные распределенные [ACID](https://en.wikipedia.org/wiki/ACID_(computer_science))-транзакции, которые могут затрагивать несколько записей из разных таблиц одного типа. Обеспечивается самый строгий уровень изоляции транзакций — serializable. Также имеется возможность ослабления уровня изоляции для увеличения производительности.
 
 В дизайн {{ ydb-short-name }} заложена поддержка разных сценариев нагрузки, таких как [OLTP](https://en.wikipedia.org/wiki/Online_transaction_processing) и [OLAP](https://en.wikipedia.org/wiki/Online_analytical_processing). В текущей реализации поддержка аналитических запросов ограничена. Поэтому можно говорить, что в данный момент {{ ydb-short-name }} — это OLTP-база данных.
 

ydb/docs/ru/core/concepts/_includes/index/when_use.md

@@ -9,3 +9,4 @@
 * В системах с плохо предсказуемой или сезонно меняющейся нагрузкой (используя возможность добавления/уменьшения вычислительных ресурсов по запросу и/или в режиме бессерверных вычислений).
 * В высоконагруженных системах, которые шардируют нагрузку между инстансами реляционной базы данных.
 * При разработке нового продукта, для которого нет надежного прогноза будущей нагрузки, или ожидается большая нагрузка, превышающая возможности традиционных реляционных баз данных.
+* В проектах, где требуются одновременная работа с транзакционными и аналитическими нагрузками. 

ydb/docs/ru/core/concepts/_includes/scan_query.md

@@ -9,13 +9,13 @@
 * Результат запроса — это стрим данных ([grpc stream](https://grpc.io/docs/what-is-grpc/core-concepts/)). Таким образом, у скан запросов нет лимита на количество строк в результате.
 * Из-за высоких накладных расходов подходит только для ad-hoc запросов.
 
-{% node info %}
+{% note info %}
 
 Через интерфейс *Scan Queries* можно выполнять запросы к [системным таблицам](../../dev/system-views.md).
 
 {% endnote %}
 
-На текущий момент скан запросы не могут считаться полноценным способом выполнения OLAP-запросов, поскольку они обладают рядом технических ограничений (которые со временем будут сняты):
+Скан запросы не считаются полноценным способом выполнения OLAP-запросов, поскольку они обладают рядом технических ограничений (которые со временем будут сняты):
 
 * Длительность запроса ограничена 5 минутами.
 * Многие операции (включая сортировку) выполняются целиком в памяти, поэтому на сложных запросах можно получить ошибку нехватки ресурсов.
@@ -24,6 +24,8 @@
 * Нет оптимизаций под точечные чтения и чтения небольших диапазонов данных.
 * В SDK не поддерживается автоматический retry.
 
+Для работы с OLAP-нагрузками в {{ ydb-short-name }} существует специализированный тип таблиц — [колоночные](../datamodel/table.md#column-tables) таблицы. Они хранят данные каждого столбца отдельно от других столбцов. Благодаря этому при выполнении запроса считываются только те столбцы, которые непосредственно участвуют в запросе.
+
 {% note info %}
 
 Несмотря на то, что *Scan Queries* явно не мешают выполнению OLTP-транзакций, они все же используют общие ресурсы базы: СPU, память, диск, сеть. Поэтому выполнение тяжелых запросов **может привести к голоданию по ресурсам**, что скажется на производительности всей базы.
@@ -53,3 +55,5 @@ class TTableClient {
 ```
 
 {% endif %}
+
+