Table section revamped: introduction written, string table description modified, column table section added.

Add introduction on tables, enhance string and column table descriptions, provide SQL and YQL creation examples, and integrate content from the column table section.

1 files changed, 92 insertions, 12 deletions

diff --git a/ydb/docs/ru/core/concepts/datamodel/_includes/table.md b/ydb/docs/ru/core/concepts/datamodel/_includes/table.md
index da53894b90..114bf5f20f 100644
--- a/ydb/docs/ru/core/concepts/datamodel/_includes/table.md
+++ b/ydb/docs/ru/core/concepts/datamodel/_includes/table.md
@@ -1,18 +1,34 @@
 # Таблица
 
-Таблица в {{ ydb-short-name }} — это [реляционная таблица](https://en.wikipedia.org/wiki/Table_(database)), содержащая набор связанных данных, состоящий из строк и столбцов. Каждая из строк представляет собой набор ячеек, предназначенных для хранения значений определенных типов в соответствии со схемой данных. Схема данных определяет имена (names) и типы (types) столбцов таблицы. Пример схемы данных показан на рисунке ниже. Таблица `Series` состоит из четырех столбцов c именами `SeriesId`, `ReleaseDate`, `SeriesInfo` и `Title` и типами данных `Uint64?` для первых двух и `String?` для последних. Первичным ключом объявлен столбец `SeriesId`.
+Таблица — это реляционная [таблица](https://ru.wikipedia.org/wiki/Таблица_(база_данных)), содержащая набор связанных данных, состоящий из строк и столбцов. Таблицы описывают сущности. Например, статья в блоге может быть представлена таблицей `article` со столбцами: `id`, `date_create`, `title`, `author` и т.д. Строки содержат данные, а столбцы определяют типы данных. Например, столбец id не может быть пустым (`NOT NULL`) и должен содержать только уникальные целочисленные значения. Запись в YQL может выглядеть так:
 
-![Datamodel_of_a_relational_table](../../_assets/datamodel_rtable.png)
+```sql
+CREATE TABLE article (
+    id Int64 NOT NULL,
+    date_create Date,
+    author String,
+    title String,
+    PRIMARY KEY (id)
+)
+```
+Обратите внимание, что на текущий момент ограничение `NOT NULL` можно указать только для колонок, входящих в первичный ключ.
 
-{{ ydb-short-name }} использует типы данных [YQL](../../datatypes.md), в качестве типов столбцов могут использоваться [простые типы данных YQL](../../../yql/reference/types/primitive.md). По умолчанию все столбцы [опциональные](../../../yql/reference/types/optional.md) и могут иметь значение `NULL`. При создании для столбцов, входящих в первичный ключ, можно указать ограничение `NOT NULL`, тогда им нельзя будет присвоить пустое значение. 
+YDB поддерживает создание строковых и колоночных таблиц. Основное их отличие — в области применения и формате хранения данных на жестком диске. Для строковых таблиц данные хранятся последовательно в виде строк, а для колоночных — в виде столбцов. У каждого типа таблиц свое предназначение.
 
-Таблица {{ ydb-short-name }} всегда имеет один или несколько столбцов, составляющих ключ ([primary key](https://en.wikipedia.org/wiki/Unique_key)). Строки таблицы уникальны по ключу, то есть для одного значения ключа может быть не больше одной строки. Таблица {{ ydb-short-name }} всегда упорядочена по ключу. Это означает, что точечное чтение по ключу, а также диапазонные запросы по ключу или префиксу ключа выполняются эффективно (фактически используя индекс). В примере выше ключевые столбцы выделены серым цветом и отмечены специальным знаком. Допускаются таблицы, состоящие только из ключевых столбцов. Таблицы без первичного ключа создавать нельзя.
+## Строковые таблицы
+Строковые таблицы хорошо подходят для транзакционных запросов, которые генерируют Online Transaction Processing (OLTP) системы, например, бекэнды сервисов погоды или интернет-магазинов. Строковые таблицы предоставляют эффективный доступ к большому количеству столбцов одновременно. Поиск по строковым таблицам работает очень быстро, за счет использования индексов.
 
-Часто при проектировании схемы таблицы имеется набор полей, естественным образом подходящий для использования в качестве первичного ключа. Тем не менее, к выбору ключа нужно подходить аккуратно, чтобы не создать хотспоты. Например, если вы вставляете в таблицу данные с монотонно возрастающим ключом, то вы будете писать в конец таблицы. А так как {{ ydb-short-name }} разбивает данные таблицы по диапазонам ключей, это означает, что ваши вставки будут обрабатываться одним конкретным сервером, и перестанут использоваться основные преимущества распределенной БД. Для того, чтобы нагрузка равномерно распределялась по различным серверам и при обработке больших таблиц не было хотспотов, рекомендуется применять: хеширование естественного ключа и использование хеша в качестве первой компоненты первичного ключа, изменение порядка следования компонент первичного ключа.
+[Индекс](https://ru.wikipedia.org/wiki/Индекс_(базы_данных)) — это структура данных, которая увеличивает скорость операций извлечения данных на основе одного или нескольких столбцов. Это аналог индекса в книге: вместо того чтобы просматривать каждую страницу книги, чтобы найти нужный раздел, вы можете обратиться к индексу в конце книги и быстро перейти к нужной странице.
 
-## Партиционирование {#partitioning}
+Когда выполняется запрос на основе столбца (или столбцов), по которому (которым) создан индекс, СУБД может использовать этот индекс, чтобы быстро найти соответствующие строки, минуя полный перебор всех данных. Например, если у вас есть индекс на столбце "author", и вы ищете все статьи, написанные автором "Gray", СУБД использует индекс для быстрого нахождения всех строк с этой фамилией.
 
-Таблица в БД может быть шардирована по диапазонам значений первичного ключа. Каждый шард таблицы отвечает за свой диапазон первичных ключей. Диапазоны ключей, обслуживаемых разными шардами, не пересекаются. Различные шарды таблицы могут обслуживаться разными серверами распределенной БД (в том числе расположенными в разных локациях), а также могут независимо друг от друга перемещаться между серверами для перебалансировки или поддержания работоспособности шарда при отказах серверов или сетевого оборудования.
+Создать строковую таблицу можно через web-интерфейс YDB, с помощью CLI или SDK. Вне зависимости от способа взаимодействия с YDB стоит помнить об общем правиле создания строковой таблицы: таблица должна иметь минимум одну ключевую колонку, при этом допускается создание таблицы, состоящий только из ключевых колонок. 
+
+По умолчанию при создании строковой таблицы все столбцы опциональны и могут иметь значения `NULL`, такое поведение можно изменить и задать условия `NOT NULL` для ключевых колонок, которые входят в состав первичного ключа. Первичные ключи уникальны, и строковые таблицы всегда упорядочена по ключу. Это означает, что точечное чтение по ключу, а также диапазонные запросы по ключу или префиксу ключа выполняются эффективно (фактически используя индекс). Допускается создание таблицы, состоящей только из ключевых столбцов. К выбору ключа нужно подходить аккуратно, поэтому рекомендуем ознакомиться со статьей: ["Выбор первичного ключа для максимальной производительности"](../../../best_practices/pk_scalability.md).
+
+### Партиционирование строковой таблицы {#partitioning_row_table}
+
+Строковая таблица в БД может быть шардирована по диапазонам значений первичного ключа. Каждый шард таблицы отвечает за свой диапазон первичных ключей. Диапазоны ключей, обслуживаемых разными шардами, не пересекаются. Различные шарды таблицы могут обслуживаться разными серверами распределенной БД (в том числе расположенными в разных локациях), а также могут независимо друг от друга перемещаться между серверами для перебалансировки или поддержания работоспособности шарда при отказах серверов или сетевого оборудования.
 
 При малом объеме данных или небольшой нагрузке таблица может состоять из одного шарда. При росте объема данных, обслуживаемых шардом, или нагрузки на шард, {{ ydb-short-name }} автоматически разбивает его на два. Разбиение происходит по медианному значению первичного ключа, если размер шарда превышает порог. В случае разбиения по нагрузке шард сначала собирает сэмпл запрашиваемых ключей (читаемых, записываемых и удаляемых), и на основании этого сэмпла выбирает для разбиения такой ключ, чтоб нагрузка распределилась поровну между новыми шардами. Таким образом в случае разбиения по нагрузке новые шарды могут иметь существенно отличающийся размер.
 
@@ -83,7 +99,7 @@
 
 При включенном автоматическом партиционировании необходимо также не забыть установить корректное значение параметра [AUTO_PARTITIONING_MIN_PARTITIONS_COUNT](#auto_partitioning_min_partitions_count), чтобы все партиции не объединились в одну сразу после создания таблицы.
 
-## Чтение с реплик {#read_only_replicas}
+### Чтение с реплик {#read_only_replicas}
 
 При выполнении запросов в {{ ydb-short-name }} фактическое выполнение запроса к каждому шарду осуществляется в единой точке, обслуживающей протокол распределенных транзакций. Но благодаря хранению данных на разделяемом хранилище возможен запуск одного или нескольких фолловеров шарда, без выделения дополнительного места на сторадже — данные уже хранятся реплицированно и возможно обслуживание более одного читателя (но писатель при этом все еще в каждый момент строго один).
 
@@ -106,7 +122,7 @@
 
 Если фолловеров несколько, то отставание их от лидера может различаться, т.е. хотя каждый фолловер каждого из шардов сохраняет внутреннюю консистентность, между разными шардами могут наблюдаться артефакты. Код приложения должен быть к этому готов. По этой же причине на данный момент невозможно и выполнение с фолловеров кроссшардовых транзакций.
 
-## Автоматическое удаление устаревших данных (TTL) {#ttl}
+### Автоматическое удаление устаревших данных (TTL) {#ttl}
 
 {{ ydb-short-name }} поддерживает функцию автоматического фонового удаления устаревших данных. В схеме данных таблицы может быть определена колонка [подходящего типа](../../../concepts/ttl.md#restrictions), значение которой у всех строк будет сравниваться в фоновом режиме с текущим временем. Строки, для которых текущее время стало больше, чем значение в колонке с учетом заданной задержки, будут удалены.
 
@@ -122,7 +138,7 @@
 
 Подробнее об удалении устаревших данных читайте в разделе [Time to Live (TTL)](../../../concepts/ttl.md).
 
-## Переименование {#rename}
+### Переименование {#rename}
 
 {{ ydb-short-name }} позволяет переименовать существующую таблицу, переместить ее в другую директорию этой же базы данных, а также заменить одну таблицу другой, при этом данные заменяемой таблицы будут удалены. При выполнении операций изменяются только метаданные таблицы, например ее путь и имя. Данные таблицы не переносятся и не перезаписываются.
 
@@ -141,7 +157,7 @@
 | ------------- | --- | ------------------- | --------------------- | ------------------ |
 | `KEY_BLOOM_FILTER` | Enum | `ENABLED`, `DISABLED` | Да | Нет |
 
-## Группы колонок {#column-groups}
+### Группы колонок {#column-groups}
 
 {{ ydb-short-name }} позволяет группировать колонки в таблице для оптимизации их хранения и использования. Механизм групп колонок позволяет увеличить производительность операций неполного чтения строк путем разделения хранения колонок таблицы на насколько групп. Наиболее часто используемый сценарий — организация хранения редко используемых атрибутов в отдельной группе колонок (и, возможно, с использованием сжатия и на более медленных устройствах хранения данных).
 
@@ -162,7 +178,7 @@
 
 Таким образом, вынос части колонок таблицы в отдельную группу колонок позволяет ускорить чтение наиболее важных и часто используемых колонок (входящих в состав основной группы колонок) ценой некоторого замедления доступа к остальным колонкам. Кроме того, на уровне групп колонок осуществляется управление параметрами хранения данных — выбор типа устройств хранения и режима сжатия.
 
-## Пользовательские атрибуты {#users-attr}
+### Пользовательские атрибуты {#users-attr}
 
 Пользовательские атрибуты позволяют добавлять произвольную информацию к метаданным таблицы. Эта информация не интерпретируется сервером, однако может быть интерпретирована клиентом БД (человеком или, чаще, программой).
 
@@ -176,3 +192,67 @@
 
 О том, как добавить, изменить, получить текущие значения или удалить атрибуты читайте в статье [{#T}](../../../operations/manage-users-attr.md).
 
+
+
+## Колоночные таблицы
+
+{% note warning %}
+
+Колоночные таблицы {{ ydb-short-name }} доступны в режиме Preview.
+
+{% endnote %}
+
+Колоночные таблицы YDB хранят данные каждого столбца отдельно (независимо) от других столбцов. Такой принцип хранения данных оптимизирован для работы с Online Analytical Processing-нагрузками (OLAP), так как при выполнении запроса считываются только те столбцы, которые непосредственно участвуют в запросе. Еще один плюс такого подхода — высокая степень сжатия данных, так как в столбцах зачастую хранятся повторяющиеся или близкие данные. Минусом является то, что выполнение операций над строками становится более затратным.
+
+На данный момент основной сценарий использования колоночных таблиц YDB — запись данных с возрастающим первичным ключом (например, время события), анализ этих данных и удаление устаревших данных по TTL. Оптимальным способом добавления данных в колоночные таблицы YDB является [пакетная запись](../../../best_practices/batch_upload.md), выполняемая блоками в единицы МБ. Вставка пакетов данных производится атомарно: данные будут записаны или во все партиции, или ни в одну. 
+
+В большинстве случаев работа с колоночными таблицами YDB аналогична работе со строковыми, но есть и отличия:
+
+* В качестве первичного ключа можно использовать только `NOT NULL` колонки.
+* Данные партицируются не по первичному ключу, а по Hash от колонок партицирования.
+* В колоночных таблицах поддерживается ограниченный набор типов данных:
+    + Доступно и в первичном ключе и в остальных колонках: `Date`, `Datetime`, `Timestamp`, `Int32`, `Int64`, `Uint8`, `Uint16`, `Uint32`, `Uint64`, `Utf8`, `String`;
+    + Доступно только в колонках, не входящих в первичный ключ: `Bool`, `Decimal`, `Double`, `Float`, `Int8`, `Int16`, `Interval`, `JsonDocument`, `Json`, `Uuid`, `Yson`.
+
+    
+Повторим создание таблицы article на этот раз в колоночной форме с помощью следующей YQL-команды:
+```sql
+CREATE TABLE article_column_table (
+    id Int64 NOT NULL,
+    author String,
+    title String,
+    PRIMARY KEY (id)
+)
+WITH (STORE = COLUMN);
+```
+
+В настоящий момент реализована не вся функциональность колоночных таблиц. Сейчас не поддерживается:
+
+* Чтение с реплик.
+* Вторичные индексы.
+* Фильтры Блума.
+* Change Data Capture.
+* Переименование таблиц.
+* Пользовательские атрибуты таблиц.
+* Изменение списка колонок данных.
+* Добавление данных в колоночные таблицы с помощью SQL-оператора INSERT.
+* Удаление данных из колоночных таблиц с помощью SQL-оператора DELETE. Фактически, удаление возможно только по истечению TTL времени хранения данных.
+
+
+### Партицирование колоночной таблицы
+
+В отличие от строковых таблиц YDB, колоночные таблицы партицируют данные не по первичным ключам, а по специально выделенным ключам — ключам партицирования. Ключи партицирования являются подмножеством первичных ключей таблицы.
+
+В отличие от партицирования данных в строковых таблицах YDB, партицирование данных для колоночных таблиц выполняется не по значениям ключей, а по hash-значениям от ключей, что позволяет равномерно распределить данные во все существующие партиции. Такое партицирование позволяет избежать хотспотов при вставке и ускоряет аналитические запросы, обрабатывающие (считывающие) большие объемы данных.
+
+Выбор ключей партицирования существенно влияет на производительность колоночных таблиц. Подробнее смотрите: ["Выбор первичного ключа для максимальной производительности колоночных таблиц"](../../../best_practices/pk-olap-scalability.md).
+
+Для управления партицированием данных используется дополнительный параметр партиционирования: AUTO_PARTITIONING_MIN_PARTITIONS_COUNT. Остальные параметры партицирования для колоночных таблиц игнорируются.
+
+AUTO_PARTITIONING_MIN_PARTITIONS_COUNT определяет минимальное физическое количество партиций для хранения данных.
+
+Тип: `Uint64`.
+
+Значение по умолчанию: 64.
+
+С учетом, что остальные параметры партицирования игнорируются, это же значение определяет и верхнее число партиций.
\ No newline at end of file