Sysview is renamed in doc (#12357)

Co-authored-by: anton-bobkov <anton-bobkov@ydb.tech>

Author: azevaykin

ydb/docs/en/core/concepts/glossary.md

@@ -165,6 +165,20 @@ A **column family** or **column group** is a feature that allows storing a subse
 
 **Time to live** or **TTL** is a mechanism for automatically removing old rows from a table asynchronously in the background. It is explained in a separate article [{#T}](ttl.md).
 
+### View {#view}
+
+A **view** logically represents a table formed by a given query. The view itself contains no data. The content of a view is generated every time you SELECT from it. Thus, any changes in the underlying tables are reflected immediately in the view.
+
+There are user-defined and system-defined views.
+
+#### User-defined view {#user-view}
+
+A **user-defined view** is created by a user with the [{#T}](../yql/reference/syntax/create-view.md) statement.  For more information, see [{#T}](../concepts/datamodel/view.md).
+
+#### System view {#system-view}
+
+A **system view** is for monitoring the DB status. System views are located in the .sys directory in the root of the database tree. It is explained in a separate article [{#T}](../dev/system-views.md).
+
 ### Topic {#topic}
 
 A **topic** is a persistent queue that can be used for reliable asynchronous communications between various systems via message passing. {{ ydb-short-name }} provides the infrastructure to ensure "exactly once" semantics in such communications, which ensures that there are both no lost messages and no accidental duplicates.

ydb/docs/ru/core/changelog-server.md

@@ -335,4 +335,4 @@
   * Добавлена поддержка сжатия при экспорте данных в S3.
   * Добавлен audit log для DDL statements.
   * Поддержана аутентификация со статическими учетными данными.
-  * Добавлены системные таблицы для диагностики производительности запросов.
+  * Добавлены системные представления для диагностики производительности запросов.

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

@@ -11,7 +11,7 @@
 
 {% note info %}
 
-Через интерфейс *Scan Queries* можно выполнять запросы к [системным таблицам](../../dev/system-views.md).
+Через интерфейс *Scan Queries* можно выполнять запросы к [системным представлениям](../../dev/system-views.md).
 
 {% endnote %}
 

ydb/docs/ru/core/concepts/glossary.md

@@ -159,6 +159,20 @@
 
 **Время жизни**, **time to live** или **TTL** — это механизм для автоматического удаления старых строк из таблицы асинхронно в фоновом режиме. Он описан в отдельной статье [{#T}](ttl.md).
 
+### Представление {#view}
+
+**Представление** или **view** — это способ сохранить запрос и обращаться к его результатам как к настоящей таблице. Само представление не хранит данных, кроме текста запроса. Запрос, хранящийся в представлении, выполняется при каждом SELECT из него, генерируя возвращаемый результат. Любые изменения в таблицах, на которые ссылается представление, немедленно отражаются в результатах чтения из него.
+
+Представления бывают пользовательские и системные.
+
+#### Пользовательские представления {#user-view}
+
+**Пользовательские представления** создаются пользователем с помощью команды [{#T}](../yql/reference/syntax/create-view.md). Они описаны более подробно в [{#T}](../concepts/datamodel/view.md).
+
+#### Системные представления {#system-view}
+
+**Системные представления** предназначены для отслеживания состояния базы данных. Эти таблицы доступны из корня дерева базы данных и используют системный префикс пути `.sys`. Они описаны более подробно в [{#T}](../dev/system-views.md).
+
 ### Топик {#topic}
 
 **Очередь сообщений** используется для надёжной асинхронной связи между различными системами посредством передачи сообщений. {{ ydb-short-name }} предоставляет инфраструктуру, обеспечивающую семантику "exactly once" (ровно один раз) в таких коммуникациях. С её использованием можно добиться гарантии отсутствия потерянных сообщений и случайных дубликатов.
@@ -596,4 +610,4 @@ MiniKQL — это язык низкого уровня. Конечные пол
 
 ### KiKiMR {#kikimr}
 
-**KiKiMR** — это устаревшее название {{ ydb-short-name }}, использовавшееся до того, как он стал [продуктом с открытым исходным кодом](https://github.com/ydb-platform/ydb) (open source). Оно всё ещё может встречаться в исходном коде, старых статьях и видео и т.д.
+**KiKiMR** — это устаревшее название {{ ydb-short-name }}, использовавшееся до того, как он стал [продуктом с открытым исходным кодом](https://github.com/ydb-platform/ydb) (open source). Оно всё ещё может встречаться в исходном коде, старых статьях и видео и т.д.

ydb/docs/ru/core/dev/system-views.md

@@ -1,10 +1,10 @@
-# Системные таблицы базы данных
+# Системные представления базы данных
 
-Вы можете отправлять запросы в специальные служебные таблицы (system views), чтобы следить за состоянием базы данных. Эти таблицы доступны из корня дерева базы данных и используют системный префикс пути `.sys`.
+Вы можете отправлять запросы в специальные служебные представления (system views), чтобы следить за состоянием базы данных. Эти представления доступны из корня дерева базы данных и используют системный префикс пути `.sys`.
 
-Индекс поля первичного ключа соответствующей таблицы содержится в описаниях доступных полей далее по тексту.
+Индекс поля первичного ключа соответствующего представления содержится в описаниях доступных полей далее по тексту.
 
-Системные таблицы содержат:
+Системные представления содержат:
 
 * [Детальные данные об отдельных партициях таблиц БД](#partitions).
 * [Топы запросов по определенным характеристикам](#top-queries).
@@ -13,21 +13,21 @@
 
 {% note info %}
 
-Обращение к системным таблицам имеет скорее аналитический характер нагрузки. Частое обращение к ним в больших базах будет существенно расходовать системные ресурсы. Рекомендуемая нагрузка не более 1-2 RPS.
+Обращение к системным представлениям имеет скорее аналитический характер нагрузки. Частое обращение к ним в больших базах будет существенно расходовать системные ресурсы. Рекомендуемая нагрузка не более 1-2 RPS.
 
 {% endnote %}
 
 ## Партиции {#partitions}
 
-Следующая системная таблица хранит детализированную информацию об отдельных [партициях](../concepts/datamodel/table.md#partitioning) всех таблиц базы данных:
+Следующее системное представление хранит детализированную информацию об отдельных [партициях](../concepts/datamodel/table.md#partitioning) всех таблиц базы данных:
 
 * `partition_stats` — cодержит информацию о моментальных метриках и кумулятивные счетчики операций. К первым относятся, например, данные о нагрузке на CPU или количестве выполняемых [транзакций](../concepts/transactions.md). Ко вторым — общее количество прочитанных строк.
 
 Предназначена для выявления различных неравномерностей в нагрузке на партицию или отображения размера данных в ней.
 
 Кумулятивные поля (`RowReads`, `RowUpdates` и т.д.) хранят накопленные значения с момента последнего старта таблетки, обслуживающей партицию.
 
-Структура таблицы:
+Структура представления:
 
 Поле | Описание
 --- | ---
@@ -84,7 +84,7 @@ GROUP BY Path
 
 ## Топы запросов {#top-queries}
 
-Следующие системные таблицы хранят данные для анализа потока пользовательских запросов:
+Следующие системные представления хранят данные для анализа потока пользовательских запросов:
 
 * `top_queries_by_duration_one_minute` — данные разбиты на минутные интервалы, содержит топ-5 запросов с наибольшим полным временем исполнения за последние 6 часов;
 * `top_queries_by_duration_one_hour` — данные разбиты на часовые интервалы, содержит топ-5 запросов с наибольшим полным временем исполнения за последние 2 недели;
@@ -99,7 +99,7 @@ GROUP BY Path
 
 Текст запроса ограничен 4 килобайтами.
 
-Все таблицы содержат одинаковый набор полей:
+Все представления содержат одинаковый набор полей:
 
 Поле | Описание
 --- | ---
@@ -168,18 +168,18 @@ WHERE Rank = 1
 
 ## Подробная информация о запросах {#query-metrics}
 
-Следующая системная таблица хранит подробную информацию о запросах:
+Следующее системное представление содержит подробную информацию о запросах:
 
 * `query_metrics_one_minute` — данные разбиты по минутным интервалам, содержит до 256 запросов за последние 6 часов.
 
-Каждая строка таблицы содержит информацию о множестве случившихся за интервал запросов с одинаковым текстом. Поля таблицы предоставляют минимальное, максимальное и суммарное значение по каждой отслеживаемой характеристике запроса. В пределах интервала запросы отсортированы по убыванию суммарного потраченного процессорного времени.
+Каждая строка представления содержит информацию о множестве случившихся за интервал запросов с одинаковым текстом. Поля представления предоставляют минимальное, максимальное и суммарное значение по каждой отслеживаемой характеристике запроса. В пределах интервала запросы отсортированы по убыванию суммарного потраченного процессорного времени.
 
 Ограничения:
 
 * текст запроса ограничен 4 килобайтами;
 * статистика может быть неполной, если база испытывает сильную нагрузку.
 
-Структура таблицы:
+Структура представления:
 
 Поле | Описание
 ---|---
@@ -243,14 +243,14 @@ LIMIT 100
 
 ## История перегруженных партиций {#top-overload-partitions}
 
-Следующие системные таблицы хранят историю моментов высокой нагрузки на отдельные партиции таблиц БД:
+Следующие системные представления содержат историю моментов высокой нагрузки на отдельные партиции таблиц БД:
 
 * `top_partitions_one_minute` — данные разбиты на минутные интервалы, содержит историю за последние 6 часов;
 * `top_partitions_one_hour` — данные разбиты на часовые интервалы, содержит историю за последние 2 недели.
 
-В таблицы попадают партиции с пиковой нагрузкой более 70 % (`CPUCores` > 0,7). В пределах одного интервала партиции ранжированы по пиковому значению нагрузки.
+В представления попадают партиции с пиковой нагрузкой более 70 % (`CPUCores` > 0,7). В пределах одного интервала партиции ранжированы по пиковому значению нагрузки.
 
-Обе таблицы содержат одинаковый набор полей:
+Оба представления содержат одинаковый набор полей:
 
 Поле | Описание
 --- | ---
@@ -268,7 +268,7 @@ LIMIT 100
 
 ### Примеры запросов
 
-Следующий запрос выводит партиции с потреблением CPU более 70% в указанном интервале времени, с идентификаторами таблеток и их размерами на момент превышения. Запрос выполняется к таблице `.sys/top_partitions_one_minute`, которая содержит данные за последние 6 часов с разбиением по часовым интервалам:
+Следующий запрос выводит партиции с потреблением CPU более 70% в указанном интервале времени, с идентификаторами таблеток и их размерами на момент превышения. Запрос выполняется к представлению `.sys/top_partitions_one_minute`, которое содержит данные за последние 6 часов с разбиением по часовым интервалам:
 
 ```yql
 SELECT
@@ -285,7 +285,7 @@ ORDER BY IntervalEnd desc, CPUCores desc
 
 * `"YYYY-MM-DDTHH:MM:SS.UUUUUUZ"` — время в зоне UTC 0 (`YYYY` — год, `MM` — месяц, `DD` — число, `hh` — часы, `mm` — минуты, `ss` — секунды, `uuuuuu` — микросекунды). Например, `"2023-01-26T13:00:00.000000Z"`.
 
-Следующий запрос выводит партиции с потреблением CPU более 90% в указанном интервале времени, с идентификаторами таблеток и их размерами на момент превышения. Запрос выполняется к таблице `.sys/top_partitions_one_hour`, которая содержит данные за последние 2 недели с разбиением по минутным интервалам:
+Следующий запрос выводит партиции с потреблением CPU более 90% в указанном интервале времени, с идентификаторами таблеток и их размерами на момент превышения. Запрос выполняется к представлению `.sys/top_partitions_one_hour`, которое содержит данные за последние 2 недели с разбиением по минутным интервалам:
 
 ```yql
 SELECT

ydb/docs/ru/core/dev/toc_p.yaml

@@ -26,7 +26,7 @@ items:
   href: paging.md
 - name: Таймауты
   href: timeouts.md
-- name: Системные таблицы
+- name: Системные представления
   href: system-views.md
 - name: Change Data Capture
   href: cdc.md