diff options
| author | bazeltsev <bazeltsev@yandex-team.ru> | 2022-03-06 12:05:49 +0300 |
|---|---|---|
| committer | bazeltsev <bazeltsev@yandex-team.ru> | 2022-03-06 12:05:49 +0300 |
| commit | b53fb5d9edf7d9b2ce86d83f75c5d99801b2a6d2 (patch) | |
| tree | 7b333596943d2a8b695c1fe06f8a6e497180aaca | |
| parent | 4956097cce302e71664bd2b768cdf09c587f6975 (diff) | |
| download | ydb-b53fb5d9edf7d9b2ce86d83f75c5d99801b2a6d2.tar.gz | |
Вычитать core ru - concepts
copy to kikimr
updated presets
updated
ref:495a1769a6455bbee8884db49e81e8a5ae5ed22d
39 files changed, 248 insertions, 223 deletions
diff --git a/ydb/docs/en/presets.yaml b/ydb/docs/en/presets.yaml new file mode 100644 index 0000000000..508b7dc6f3 --- /dev/null +++ b/ydb/docs/en/presets.yaml @@ -0,0 +1,3 @@ +default: + lang: en + link-console-main: https://console.cloud.yandex.com diff --git a/ydb/docs/presets.yaml b/ydb/docs/presets.yaml index 3448703313..14e00ec51b 100644 --- a/ydb/docs/presets.yaml +++ b/ydb/docs/presets.yaml @@ -15,13 +15,14 @@ default: ydb-short-name: YDB yandex-cloud: Yandex.Cloud ydb-name: YDB + objstorage-full-name: Yandex Object Storage + sf-name: Cloud Functions concept_secondary_index: ../../../../concepts/secondary_indexes concept_table: ../../../../concepts/datamodel#table ydb_local_docker_image: cr.yandex/yc/yandex-docker-local-ydb ydb_local_docker_image_tag: latest managed-k8s-full-name: Yandex Managed Service for Kubernetes managed-k8s-name: Managed Service for Kubernetes - link-console-main: https://console.cloud.yandex.ru s3-storage-host: s3.mds.yandex.net objstorage-name: Object Storage diff --git a/ydb/docs/ru/core/concepts/_includes/connect.md b/ydb/docs/ru/core/concepts/_includes/connect.md index 532b62d27f..ea4f9709e8 100644 --- a/ydb/docs/ru/core/concepts/_includes/connect.md +++ b/ydb/docs/ru/core/concepts/_includes/connect.md @@ -4,26 +4,27 @@ Для соединения с БД {{ ydb-short-name }} из {{ ydb-short-name }} CLI или приложения, использующего {{ ydb-short-name }} SDK, вам потребуется предоставить следующие данные: -1. Эндпоинт -3. Аутентификационная информация -2. Размещение базы данных +1. Эндпоинт. +1. Аутентификационная информация. +1. Размещение базы данных. ## Эндпоинт {#endpoint} -Эндпоинт (`endpoint`) - строка в формате `protocol://host:port`, предоставляемая владельцем кластера {{ ydb-short-name }} для корректной маршрутизации запросов клиента к его базам данных через сетевую инфраструктуру, и установки сетевого соединения. Для облачных баз данных `endpoint` показывается в консоли управления на странице требуемой БД, а также обычно может быть получено через CLI облачного поставщика. В корпоративных окружениях имена эндпоинтов {{ ydb-short-name }} предоставляются командой администраторов или также могут быть получены в консоли управления внутренним облаком. +Эндпоинт (endpoint) - строка в формате `protocol://host:port`, предоставляемая владельцем кластера {{ ydb-short-name }} для корректной маршрутизации запросов клиента к его базам данных через сетевую инфраструктуру и установки сетевого соединения. Для облачных баз данных endpoint показывается в консоли управления на странице требуемой БД, а также обычно может быть получен через CLI облачного поставщика. В корпоративных окружениях имена эндпоинтов {{ ydb-short-name }} предоставляются командой администраторов или также могут быть получены в консоли управления внутренним облаком. {% include [overlay/endpoint.md](connect_overlay/endpoint.md) %} Примеры: -- `grpc://localhost:7135` - протокол обмена данными без шифрования (gRPC), сервер запущен на том же хосте что и клиент, принимает соединения на порту 7135 -- `grpcs://ydb.somecorp-int.ru` - протокол обмена данными с шифрованием (gRPCs), сервер запущен на хосте ydb.somecorp-int.ru в изолированной корпоративной интрасети компании "SomeCorp", принимает соединения на порту YDB по умолчанию 2135 -- `grpcs://ydb.serverless.yandexcloud.net:2135` - протокол обмена данными с шифрованием (gRPCs), публичный сервер Serverless YDB Yandex.Cloud ydb.serverless.yandexcloud.net, порт 2135 + +* `grpc://localhost:7135` — протокол обмена данными без шифрования (gRPC), сервер запущен на том же хосте что и клиент, принимает соединения на порту 7135. +* `grpcs://ydb.somecorp-int.ru` — протокол обмена данными с шифрованием (gRPCs), сервер запущен на хосте ydb.somecorp-int.ru в изолированной корпоративной интрасети компании «SomeCorp», принимает соединения на порту YDB по умолчанию 2135. +* `grpcs://ydb.serverless.yandexcloud.net:2135` — протокол обмена данными с шифрованием (gRPCs), публичный сервер Serverless YDB {{ yandex-cloud }} ydb.serverless.yandexcloud.net, порт 2135. {% include [overlay/endpoint_example.md](connect_overlay/endpoint_example.md) %} ## Аутентификационная информация {#auth} -После успешной установки сетевого соединения сервер принимает к обработке запросы от клиента, в которых передается аутентификационная информация. На её основании сервер определяет учетную запись (аккаунт) клиента и проверяет доступ на выполнение запроса. +После успешной установки сетевого соединения сервер принимает к обработке запросы от клиента, в которых передается аутентификационная информация. На ее основании сервер определяет учетную запись (аккаунт) клиента и проверяет доступ на выполнение запроса. Основная схема работы предполагает наличие отдельной системы управления учетными данными и доступами - [IAM (Identity and Access Management)](https://en.wikipedia.org/wiki/Identity_management). IAM выдает привязанный к учетной записи токен, который передается клиентом {{ ydb-short-name }} на сервер вместе с запросом. Сервер {{ ydb-short-name }} обращается к IAM для проверки токена и доступа на выполнение запрошенной операции и кеширует результат. @@ -33,13 +34,13 @@ Клиент {{ ydb-short-name }} (CLI или SDK) поддерживают следующие режимы выбора токена для передачи в запросах: -- **Anonymous** - в запросах передается пустой токен -- **Access Token** - параметром для клиента (SDK или CLI) задается фиксированный токен, который передается в запросы -- **Refresh Token** - параметром для клиента (SDK или CLI) задается [OAuth токен](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/) персональной учетной записи, на основании которого клиент периодически в фоновом режиме обращается к IAM API для ротации (получения следующего) токена, передаваемого в запросы. -- **Service Account Key** - параметром для клиента (SDK или CLI) задаются атрибуты сервисной учетной записи и ключ для подписи, на основании которых клиент периодически в фоновом режиме обращается к IAM API для ротации (получения следующего) токена, передаваемого в запросы -- **Metadata** - клиент (SDK или CLI) периодически обращается к локальному сервису для ротации (получения следующего) токена, передаваемого в запросы +* **Anonymous** — в запросах передается пустой токен. +* **Access Token** — параметром для клиента (SDK или CLI) задается фиксированный токен, который передается в запросы. +* **Refresh Token** — параметром для клиента (SDK или CLI) задается [OAuth токен](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/) персональной учетной записи, на основании которого клиент периодически в фоновом режиме обращается к IAM API для ротации (получения следующего) токена, передаваемого в запросы. +* **Service Account Key** — параметром для клиента (SDK или CLI) задаются атрибуты сервисной учетной записи и ключ для подписи, на основании которых клиент периодически в фоновом режиме обращается к IAM API для ротации (получения следующего) токена, передаваемого в запросы. +* **Metadata** — клиент (SDK или CLI) периодически обращается к локальному сервису для ротации (получения следующего) токена, передаваемого в запросы. -Любой обладатель валидного токена может получить доступ на выполнение операций, поэтому главная задача системы безопасности -- обеспечение секретности токена и предотвращение его компрометации. +Любой обладатель валидного токена может получить доступ на выполнение операций, поэтому главная задача системы безопасности — обеспечение секретности токена и предотвращение его компрометации. Режимы аутентификации с ротацией токена **Refresh Token** и **Service Account Key** обеспечивают больший уровень безопасности по сравнению с режимом с фиксированным токеном **Access Token**, так как на сервер {{ ydb-short-name }} по сети передаются только короткоживущие секреты. @@ -47,17 +48,17 @@ При выборе режима аутентификации среди поддерживаемых сервером и окружением, следует руководствоваться следующими рекомендациями: -- **Anonymous** обычно применяется на самостоятельно разворачиваемых локальных кластерах {{ ydb-short-name }}, недоступных по сети -- **Access Token** применяется при отсутствии поддержки других режимов на стороне сервера или в настроечных/отладочных целях. Он не требует взаимодействий клиента с IAM. Однако, если IAM поддерживает API для ротации токенов, то обычно выдываемые таким IAM фиксированные токены имеют короткий срок жизни, что вынуждает регулярно обновлять их в IAM вручную заново. -- **Refresh Token** может применяться при выполнении разовых ручных операций под персональной учетной записью, например, связанных с обслуживанием данных в БД, выполнением ad-hoc операций в CLI, или запусками приложений с рабочей станции. Такой токен можно получить вручную в IAM один раз на долгий срок, и сохранить в переменной окружения на личной рабочей станции для автоматического применения при запуске CLI без дополнительных параметров аутентификации. -- **Service Account Key** применяется в первую очередь для приложений, рассчитанных на эксплуатацию в окружениях, где поддерживается режим **Metadata**, при их тестировании вне таких окружений (например, на рабочей станции). Также он может применяться для приложений вне таких окружений, работая как аналог **Refresh Token** для сервисных учетных записей. В отличие от персональной учетной записи, объекты доступа и роли сервисной учетной записи могут быть ограничены. -- **Metadata** применяется при разворачивании приложений в облаках. В настоящее время этот режим поддерживается на виртуальных машинах и в Cloud Functions Yandex.Cloud. +* **Anonymous** обычно применяется на самостоятельно разворачиваемых локальных кластерах {{ ydb-short-name }}, недоступных по сети. +* **Access Token** применяется при отсутствии поддержки других режимов на стороне сервера или в настроечных/отладочных целях. Он не требует взаимодействий клиента с IAM. Однако, если IAM поддерживает API для ротации токенов, то обычно выдаваемые таким IAM фиксированные токены имеют короткий срок жизни, что вынуждает регулярно обновлять их в IAM вручную заново. +* **Refresh Token** может применяться при выполнении разовых ручных операций под персональной учетной записью, например, связанных с обслуживанием данных в БД, выполнением ad-hoc операций в CLI, или запусками приложений с рабочей станции. Такой токен можно получить вручную в IAM один раз на долгий срок и сохранить в переменной окружения на личной рабочей станции для автоматического применения при запуске CLI без дополнительных параметров аутентификации. +* **Service Account Key** применяется в первую очередь для приложений, рассчитанных на эксплуатацию в окружениях, где поддерживается режим **Metadata**, при их тестировании вне таких окружений (например, на рабочей станции). Также он может применяться для приложений вне таких окружений, работая как аналог **Refresh Token** для сервисных учетных записей. В отличие от персональной учетной записи, объекты доступа и роли сервисной учетной записи могут быть ограничены. +* **Metadata** применяется при разворачивании приложений в облаках. В настоящее время этот режим поддерживается на виртуальных машинах и в {{ sf-name }} {{ yandex-cloud }}. -Токен для указания в параметрах может быть получен в системе IAM, с которой связана конкретная установка {{ ydb-short-name }}. В частности, для сервиса {{ ydb-short-name }} в Yandex.Cloud применяется Yandex.Passport OAuth и севисные аккаунты Yandex.Cloud. При использовании {{ ydb-short-name }} в корпоративных контекстах могут применяться стандартные для данной организации системы централизованной аутентификации. +Токен для указания в параметрах может быть получен в системе IAM, с которой связана конкретная установка {{ ydb-short-name }}. В частности, для сервиса {{ ydb-short-name }} в {{ yandex-cloud }} применяется Yandex.Passport OAuth и сервисные аккаунты {{ yandex-cloud }}. При использовании {{ ydb-short-name }} в корпоративных контекстах могут применяться стандартные для данной организации системы централизованной аутентификации. {% include [overlay/auth_choose.md](connect_overlay/auth_choose.md) %} -При использовании режимов, предусматривающих обращение клиента {{ ydb-short-name }} к IAM, дополнительно может быть задан URL IAM, предоставляющий API выдачи токенов. По умолчанию в существующих SDK и CLI производится попытка обращения к API IAM Yandex.Cloud, размещенному на `iam.api.cloud.yandex.net:443`. +При использовании режимов, предусматривающих обращение клиента {{ ydb-short-name }} к IAM, дополнительно может быть задан URL IAM, предоставляющий API выдачи токенов. По умолчанию в существующих SDK и CLI производится попытка обращения к API IAM {{ yandex-cloud }}, размещенному на `iam.api.cloud.yandex.net:443`. ## Размещение базы данных {#database} @@ -71,13 +72,14 @@ {% note warning %} -Приложения не должны как-либо интерпретировать количество и значение каталогов в `database`, так как они определяются конфигурацией кластера {{ ydb-short-name }}. Например, при работе с сервисом {{ ydb-short-name }} в Yandex.Cloud `database` сейчас имеет структуру `region_name/cloud_id/database_id`, однако этот формат может быть изменен в будущем для новых БД. +Приложения не должны как-либо интерпретировать количество и значение каталогов в `database`, так как они определяются конфигурацией кластера {{ ydb-short-name }}. Например, при работе с сервисом {{ ydb-short-name }} в {{ yandex-cloud }} `database` сейчас имеет структуру `region_name/cloud_id/database_id`, однако этот формат может быть изменен в будущем для новых БД. {% endnote %} Примеры: -- `/ru-central1/b1g8skpblkos03malf3s/etn01q5ko6sh271beftr` -- база данных Yandex.Cloud с идентификатором `etn01q3ko8sh271beftr` в облаке `b1g8skpbljhs03malf3s`, развернутая в регионе `ru-central1` -- `/local` -- база данных по умолчанию при самостоятельном развертывании [с использованием Docker](../../getting_started/ydb_docker.md) + +* `/ru-central1/b1g8skpblkos03malf3s/etn01q5ko6sh271beftr` — база данных {{ yandex-cloud }} с идентификатором `etn01q3ko8sh271beftr` в облаке `b1g8skpbljhs03malf3s`, развернутая в регионе `ru-central1`. +* `/local` — база данных по умолчанию при самостоятельном развертывании [с использованием Docker](../../getting_started/ydb_docker.md). {% include [overlay/database_example.md](connect_overlay/database_example.md) %} @@ -94,10 +96,10 @@ При использовании протокола с шифрованием ([gRPC over TLS](https://grpc.io/docs/guides/auth/), или grpcs) продолжение сетевого соединения возможно только в том случае, если клиент уверен в том, что ему действительно отвечает подлинный сервер, с которым он пытается установить соединение, а не кто-то посередине, перехвативший запрос в сети. Это обеспечивается проверкой через [цепочки доверия]{% if lang == "en" %}(https://en.wikipedia.org/wiki/Chain_of_trust){% endif %}{% if lang == "ru" %}(https://ru.wikipedia.org/wiki/Цепочка_доверия){% endif %}, для работы которой на клиенте должен быть установлен т.н. корневой сертификат. -В состав операционных систем, на которых запускается клиент, уже входит набор корневых сертификатов от основных мировых центров сертификации. Однако, владелец кластера {{ ydb-short-name }} может использовать свой центр сертификации, не связанный ни с одним из мировых, что часто встречается в корпоративных окружениях, и почти всегда применяется при самостоятельном развертывании кластеров с поддержкой шифрования на соединениях. В этом случае владелец кластера должен каким-либо образом передать свой корневой сертификат для использования на стороне клиента. Такой сертификат может быть установлен в хранилище сертификатов операционной системы, где запускается клиент (вручную пользователем или корпоративной командой администраторов ОС), или встроен в состав самого клиента (как это сделано для Yandex.Cloud в {{ ydb-short-name }} CLI и SDK). +В состав операционных систем, на которых запускается клиент, уже входит набор корневых сертификатов от основных мировых центров сертификации. Однако, владелец кластера {{ ydb-short-name }} может использовать свой центр сертификации, не связанный ни с одним из мировых, что часто встречается в корпоративных окружениях, и почти всегда применяется при самостоятельном развертывании кластеров с поддержкой шифрования на соединениях. В этом случае владелец кластера должен каким-либо образом передать свой корневой сертификат для использования на стороне клиента. Такой сертификат может быть установлен в хранилище сертификатов операционной системы, где запускается клиент (вручную пользователем или корпоративной командой администраторов ОС), или встроен в состав самого клиента (как это сделано для {{ yandex-cloud }} в {{ ydb-short-name }} CLI и SDK). ### API получения токенов IAM {#token-refresh-api} -Для ротации токенов {{ ydb-short-name }} SDK и CLI используют gRPC-запрос к Yandex.Cloud IAM API [IamToken - create]{% if lang == "en" %}(https://cloud.yandex.com/en/docs/iam/api-ref/grpc/iam_token_service#Create){% endif %}{% if lang == "ru" %}(https://cloud.yandex.ru/docs/iam/api-ref/grpc/iam_token_service#Create){% endif %}. В режиме **Refresh Token** заданный параметром OAuth токен передается в атрибуте `yandex_passport_oauth_token`. В режиме **Service Account Key** на основании заданных атрибутов сервисной учетной записи и ключа шифрования формируется короткоживущий JWT-токен и передается в атрибуте `jwt`. Исходный код формирования JWT-токена доступен в составе SDK (например, метод `get_jwt()` в [коде на Python](https://github.com/ydb-platform/ydb-python-sdk/blob/main/ydb/iam/auth.py)). +Для ротации токенов {{ ydb-short-name }} SDK и CLI используют gRPC-запрос к {{ yandex-cloud }} IAM API [IamToken - create]{% if lang == "en" %}(https://cloud.yandex.com/en/docs/iam/api-ref/grpc/iam_token_service#Create){% endif %}{% if lang == "ru" %}(https://cloud.yandex.ru/docs/iam/api-ref/grpc/iam_token_service#Create){% endif %}. В режиме **Refresh Token** заданный параметром OAuth токен передается в атрибуте `yandex_passport_oauth_token`. В режиме **Service Account Key** на основании заданных атрибутов сервисной учетной записи и ключа шифрования формируется короткоживущий JWT-токен и передается в атрибуте `jwt`. Исходный код формирования JWT-токена доступен в составе SDK (например, метод `get_jwt()` в [коде на Python](https://github.com/ydb-platform/ydb-python-sdk/blob/main/ydb/iam/auth.py)). -{{ ydb-short-name }} SDK и CLI позволяют подменить хост для обращения к API получения токенов, что дает возможность реализовать аналогичный API в корпоративных контекстах.
\ No newline at end of file +{{ ydb-short-name }} SDK и CLI позволяют подменить хост для обращения к API получения токенов, что дает возможность реализовать аналогичный API в корпоративных контекстах. diff --git a/ydb/docs/ru/core/concepts/_includes/databases/base_hierarchy.md b/ydb/docs/ru/core/concepts/_includes/databases/base_hierarchy.md index 91cfc1da58..4c67b90ddd 100644 --- a/ydb/docs/ru/core/concepts/_includes/databases/base_hierarchy.md +++ b/ydb/docs/ru/core/concepts/_includes/databases/base_hierarchy.md @@ -1,13 +1,12 @@ ## Иерархия сущностей на кластере {#hierarchy} {#domain} {#account} {#directory} {#dir} -Для размещения БД в {{ ydb-short-name }} принято использовать следующую структуру директорий: ```/domain/account/directory/database```, где: +Для размещения БД в {{ ydb-short-name }} принято использовать следующую структуру директорий: `/domain/account/directory/database`, где: -- *Домен* (domain) — элемент первого уровня, в котором располагаются все ресурсы кластера. На одном кластере может быть только один домен. -- *Аккаунт* (account) — элемент второго уровня, определяющий владельца группы БД. -- *Директория* (directory) -- элемент третьего уровня, определяемый владельцем аккаунта для групировки его БД. -- *База данных* (database) -- элемент четвертого уровня, соответствующий БД. +* _Домен_ (domain) — элемент первого уровня, в котором располагаются все ресурсы кластера. На одном кластере может быть только один домен. +* _Аккаунт_ (account) — элемент второго уровня, определяющий владельца группы БД. +* _Директория_ (directory) — элемент третьего уровня, определяемый владельцем аккаунта для группировки его БД. +* _База данных_ (database) — элемент четвертого уровня, соответствующий БД. На верхнем уровне уровне иерархии в кластере расположен один домен, в нем располагаются один или несколько аккаунтов, в аккаунте — одна или несколько директорий, в которых в свою очередь располагаются базы данных. Иерархия сущностей позволяет назначать права доступа, а также получать агрегированные или отфильтрованные показатели мониторинга, по элементам любого уровня иерархии. - diff --git a/ydb/docs/ru/core/concepts/_includes/databases/cluster.md b/ydb/docs/ru/core/concepts/_includes/databases/cluster.md index 871292d10d..3341af5408 100644 --- a/ydb/docs/ru/core/concepts/_includes/databases/cluster.md +++ b/ydb/docs/ru/core/concepts/_includes/databases/cluster.md @@ -1,5 +1,5 @@ ## Кластер {#cluster} -_Кластер {{ ydb-short-name }}_ - множество узлов {{ ydb-short-name }}, между которыми распределяется нагрузка, и коммуницирующих друг с другом через сеть. На одном кластере может обслуживаться множество баз данных, под каждую БД выделяются определенные узлы кластера. Одна БД целиком располагается на одном кластере. +_Кластер {{ ydb-short-name }}_ — множество узлов {{ ydb-short-name }}, между которыми распределяется нагрузка, коммуницирующих друг с другом через сеть. На одном кластере может обслуживаться множество баз данных, под каждую БД выделяются определенные узлы кластера. Одна БД целиком располагается на одном кластере. Кластер {{ ydb-short-name }} может быть однодатацентровым или геораспределенным. Минимальный однадатацентровый кластер состоит из одного узла. diff --git a/ydb/docs/ru/core/concepts/_includes/databases/compute.md b/ydb/docs/ru/core/concepts/_includes/databases/compute.md index 3d15471e1d..83eabadd20 100644 --- a/ydb/docs/ru/core/concepts/_includes/databases/compute.md +++ b/ydb/docs/ru/core/concepts/_includes/databases/compute.md @@ -1,3 +1,3 @@ ## Вычислительные ресурсы {#compute-resources} -Кластер {{ ydb-short-name }} может быть развернут на bare metal, виртуальных машинах, или в среде контейнерной виртуализации.
\ No newline at end of file +Кластер {{ ydb-short-name }} может быть развернут на bare metal, виртуальных машинах, или в среде контейнерной виртуализации. diff --git a/ydb/docs/ru/core/concepts/_includes/databases/intro.md b/ydb/docs/ru/core/concepts/_includes/databases/intro.md index c72615e3c6..08b81bd39c 100644 --- a/ydb/docs/ru/core/concepts/_includes/databases/intro.md +++ b/ydb/docs/ru/core/concepts/_includes/databases/intro.md @@ -1,6 +1,6 @@ --- -title: "Термины и определения {{ ydb-short-name }}" -description: "База данных (БД) {{ ydb-short-name }} — это изолированное согласованное множество данных, доступ к которому осуществляется через сервис {{ ydb-short-name }}, обеспечивающий масштабируемость, отказоустойчивость, и автоматическую репликацию данных." +title: "Термины и определения YDB" +description: "База данных (БД) YDB — это изолированное согласованное множество данных, доступ к которому осуществляется через сервис YDB, обеспечивающий масштабируемость, отказоустойчивость, и автоматическую репликацию данных." --- # Термины и определения diff --git a/ydb/docs/ru/core/concepts/_includes/databases/regions.md b/ydb/docs/ru/core/concepts/_includes/databases/regions.md index ae766f3e79..b7b0e8c384 100644 --- a/ydb/docs/ru/core/concepts/_includes/databases/regions.md +++ b/ydb/docs/ru/core/concepts/_includes/databases/regions.md @@ -1,7 +1,7 @@ ## Регионы и зоны доступности {#regions-az} -_Зона доступности_ -- центр обработки данных, или его изолированный сегмент, в пределах которого обеспечивается минимальное физическое расстояние между узлами, и минимизируются возможности сбоев одновременно с другими зонами доступности. -_Широкий географический регион_ -- территория, расстояние между зонами доступности в которой не превышает 500 км. +_Зона доступности_ — центр обработки данных, или его изолированный сегмент, в пределах которого обеспечивается минимальное физическое расстояние между узлами, и минимизируются возможности сбоев одновременно с другими зонами доступности. +_Широкий географический регион_ — территория, расстояние между зонами доступности в которой не превышает 500 км. Геораспределенный кластер {{ ydb-short-name }} содержит узлы, находящиеся в разных зонах доступности в пределах широкого географического региона. {{ ydb-short-name }} осуществляет синхронную запись в каждую из зон доступности, обеспечивая полноценное продолжение работы при потере любой одной зоны доступности. diff --git a/ydb/docs/ru/core/concepts/_includes/databases/slots.md b/ydb/docs/ru/core/concepts/_includes/databases/slots.md index a29b0ec2d1..3f9e99c00f 100644 --- a/ydb/docs/ru/core/concepts/_includes/databases/slots.md +++ b/ydb/docs/ru/core/concepts/_includes/databases/slots.md @@ -1,5 +1,5 @@ ## Слоты {#slots} -_Слот_ -- часть ресурсов сервера, выделенная под запуск одного узла кластера {{ ydb-short-name }}, фиксированного размера 10CPU/50GB RAM. Слоты применяются в случае, если кластер {{ ydb-short-name }} разворачивается на bare metal машинах, ресурсы которых достаточны для обслуживания нескольких слотов. В случае использования виртуальных машин для развертывания кластера мощность этих машин выбирается таким образом, чтобы применение слотов не требовалось: один узел обслуживает одну БД, одна БД использует множество выделенных ей узлов. +_Слот_ — часть ресурсов сервера, выделенная под запуск одного узла кластера {{ ydb-short-name }}, фиксированного размера 10 CPU/50 ГБ RAM. Слоты применяются в случае, если кластер {{ ydb-short-name }} разворачивается на bare metal машинах, ресурсы которых достаточны для обслуживания нескольких слотов. В случае использования виртуальных машин для развертывания кластера мощность этих машин выбирается таким образом, чтобы применение слотов не требовалось: один узел обслуживает одну БД, одна БД использует множество выделенных ей узлов. Список слотов, выделенных базе, можно увидеть в результатах выполнения команды `discovery list` консольного клиента {{ ydb-short-name }}. diff --git a/ydb/docs/ru/core/concepts/_includes/databases/storage_groups.md b/ydb/docs/ru/core/concepts/_includes/databases/storage_groups.md index f3b2d2b4e4..8147e92fc0 100644 --- a/ydb/docs/ru/core/concepts/_includes/databases/storage_groups.md +++ b/ydb/docs/ru/core/concepts/_includes/databases/storage_groups.md @@ -2,6 +2,6 @@ Группа хранения — избыточный массив независимых дисковых накопителей, объединенных по сети в единый логический элемент. Применение групп хранения позволяет повысить отказоустойчивость за счет избыточности и увеличить производительность. -Каждой группе хранения соответствует определенная схема хранения, влияющая на количество используемых дисков, модель отказа и коэффициент избыточности. Для однодатацентровых кластеров обычно используется схема ``block4-2``, при которой группа хранения расположена на 8 дисках в 8 стойках, переживает отказ любых двух дисков и дает избыточность с коэффициентом 1.5. В мультидатацентровых кластерах используется схема ``mirror3dc``, где в группе хранения задействовано 9 дисков, расположенных по 3 в трех датацентрах, выдерживает отказ датацентра и диска в любом другом датацентре, дает избыточность с коэффициентом 3. +Каждой группе хранения соответствует определенная схема хранения, влияющая на количество используемых дисков, модель отказа и коэффициент избыточности. Для однодатацентровых кластеров обычно используется схема `block4-2`, при которой группа хранения расположена на 8 дисках в 8 стойках, переживает отказ любых 2 дисков и дает избыточность с коэффициентом 1,5. В мультидатацентровых кластерах используется схема `mirror3dc`, где в группе хранения задействовано 9 дисков, расположенных по 3 в 3 датацентрах, выдерживает отказ датацентра и диска в любом другом датацентре, дает избыточность с коэффициентом 3. Сервис {{ ydb-short-name }} позволяет выделять дополнительные группы хранения для имеющихся БД по мере роста объема хранимых данных. diff --git a/ydb/docs/ru/core/concepts/_includes/datamodel/blockdevice.md b/ydb/docs/ru/core/concepts/_includes/datamodel/blockdevice.md index 1d7a5ded89..11267c07cd 100644 --- a/ydb/docs/ru/core/concepts/_includes/datamodel/blockdevice.md +++ b/ydb/docs/ru/core/concepts/_includes/datamodel/blockdevice.md @@ -1,2 +1,3 @@ -## Том сетевого блочного устройства +## Том сетевого блочного устройства {#volume} + Одним из примеров применения {{ ydb-short-name }} в качестве платформы для создания широкого спектра систем хранения и обработки данных является реализация [сетевого блочного устройства](https://en.wikipedia.org/wiki/Network_block_device) на базе {{ ydb-short-name }}. Сетевые блочные устройства реализуют интерфейс локального блочного устройства, при этом являются отказоустойчивыми (за счет избыточности) и хорошо масштабируются как по размеру тома, так и по количеству операций ввода-вывода в единицу времени. К недостаткам сетевого блочного устройства можно отнести то, что любая операция ввода-вывода на таком устройстве требует сетевого взаимодействия, что может увеличить latency сетевого устройства по сравнению с локальным. На сетевом блочном устройстве можно развернуть обычную файловую систему и/или запустить приложение, напрямую работающее с блочным устройством, например СУБД. diff --git a/ydb/docs/ru/core/concepts/_includes/datamodel/dir.md b/ydb/docs/ru/core/concepts/_includes/datamodel/dir.md index 1ff3ad54f3..92d60b6f64 100644 --- a/ydb/docs/ru/core/concepts/_includes/datamodel/dir.md +++ b/ydb/docs/ru/core/concepts/_includes/datamodel/dir.md @@ -1,2 +1,3 @@ ## Директории {#dir} + Для удобства организации поддерживается создание директорий по аналогии с файловой системой, то есть вся база состоит из дерева директорий, а таблицы и другие сущности находятся в листах этого дерева (аналогично файлам файловой системы). В одной директории могут быть несколько поддиректорий и несколько таблиц. Имена у сущностей внутри одной директории уникальны. diff --git a/ydb/docs/ru/core/concepts/_includes/datamodel/intro.md b/ydb/docs/ru/core/concepts/_includes/datamodel/intro.md index 1a7c762827..a5caeb6666 100644 --- a/ydb/docs/ru/core/concepts/_includes/datamodel/intro.md +++ b/ydb/docs/ru/core/concepts/_includes/datamodel/intro.md @@ -1,5 +1,3 @@ # Модель данных и схема -В разделе собраны описания сущностей, которыми оперирует {{ ydb-short-name }} в рамках БД. -Ядро {{ ydb-short-name }} позволяет гибко реализовывать различные примитивы хранения, поэтому возможно появление в будущем новых сущностей. - +В разделе собраны описания сущностей, которыми оперирует {{ ydb-short-name }} в рамках БД. Ядро {{ ydb-short-name }} позволяет гибко реализовывать различные примитивы хранения, поэтому возможно появление в будущем новых сущностей. diff --git a/ydb/docs/ru/core/concepts/_includes/datamodel/pq.md b/ydb/docs/ru/core/concepts/_includes/datamodel/pq.md index b45c176ff1..a2949765d5 100644 --- a/ydb/docs/ru/core/concepts/_includes/datamodel/pq.md +++ b/ydb/docs/ru/core/concepts/_includes/datamodel/pq.md @@ -1,2 +1,3 @@ -## Персистентная очередь -Персистентная очередь состоит из одной или более партиций, каждая партиция представляет собой [FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)) [очередь сообщений](https://en.wikipedia.org/wiki/Message_queue), обеспечивающую надежную доставку между несколькими участниками. Сообщения данных нетипизированы и представляют собой blob данных. Партиция является инструментом параллельности и позволяет обеспечить высокую пропускную способность очереди. Предусмотрены механизмы для реализации at least once и exactly once гарантий работы с персистетной очередью. Персистентная очередь {{ ydb-short-name }} похожа на концепцию topic в [Apache Kafka](https://en.wikipedia.org/wiki/Apache_Kafka). +## Персистентная очередь {#persistent-queue} + +Персистентная очередь состоит из одной или более партиций, каждая партиция представляет собой [FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)) [очередь сообщений](https://en.wikipedia.org/wiki/Message_queue), обеспечивающую надежную доставку между несколькими участниками. Сообщения данных не типизированы и представляют собой blob данных. Партиция является инструментом параллельности и позволяет обеспечить высокую пропускную способность очереди. Предусмотрены механизмы для реализации at least once и exactly once гарантий работы с персистентной очередью. Персистентная очередь {{ ydb-short-name }} похожа на концепцию topic в [Apache Kafka](https://en.wikipedia.org/wiki/Apache_Kafka). diff --git a/ydb/docs/ru/core/concepts/_includes/datamodel/table.md b/ydb/docs/ru/core/concepts/_includes/datamodel/table.md index affd298716..257e9bb744 100644 --- a/ydb/docs/ru/core/concepts/_includes/datamodel/table.md +++ b/ydb/docs/ru/core/concepts/_includes/datamodel/table.md @@ -1,122 +1,120 @@ ## Таблица {#table} -Таблица в {{ ydb-short-name }} — это [реляционная таблица](https://en.wikipedia.org/wiki/Table_(database)), содержащая набор связанных данных, состоящий из строк и столбцов. каждая из строк представляет собой набор ячеек, предназначенных для хранения значений определенных типов в соответствии со схемой данных. Схема данных определяет имена (names) и типы (types) столбцов таблицы. Пример схемы данных показан на рисунке ниже. - - -<small>Рисунок 1 — пример схемы таблицы</small> +Таблица в {{ ydb-short-name }} — это [реляционная таблица](https://en.wikipedia.org/wiki/Table_(database)), содержащая набор связанных данных, состоящий из строк и столбцов. Каждая из строк представляет собой набор ячеек, предназначенных для хранения значений определенных типов в соответствии со схемой данных. Схема данных определяет имена (names) и типы (types) столбцов таблицы. Пример схемы данных показан на рисунке ниже. Таблица `Series` состоит из четырех столбцов c именами `SeriesId`, `ReleaseDate`, `SeriesInfo` и `Title` и типами данных `Uint64?` для первых двух и `String?` для последних. Первичным ключом объявлен столбец `SeriesId`. -На рисунке 1 приведена схема таблицы ```Series``` из четырех столбцов c именами ```SeriesId```, ```ReleaseDate```, ```SeriesInfo``` и ```Title``` и типами данных ```Uint64?``` для первых двух и ```String?``` для последних. Первичным ключом объявлен столбец ```SeriesId```. + -{{ ydb-short-name }} использует типы данных [YQL](../../datatypes.md), в качестве типов столбцов могут использоваться [простые типы данных YQL](../../../yql/reference/types/primitive.md). Все столбцы могут содержать специальное значение NULL, используемое для обозначения отсутствия значения. +{{ ydb-short-name }} использует типы данных [YQL](../../datatypes.md), в качестве типов столбцов могут использоваться [простые типы данных YQL](../../../yql/reference/types/primitive.md). Все столбцы могут содержать специальное значение `NULL`, используемое для обозначения отсутствия значения. Таблица {{ ydb-short-name }} всегда имеет один или несколько столбцов, составляющих ключ ([primary key](https://en.wikipedia.org/wiki/Unique_key)). Строки таблицы уникальны по ключу, то есть для одного значения ключа может быть не больше одной строки. Таблица {{ ydb-short-name }} всегда упорядочена по ключу. Это означает, что точечное чтение по ключу, а также диапазонные запросы по ключу или префиксу ключа выполняются эффективно (фактически используя индекс). В примере выше ключевые столбцы выделены серым цветом и отмечены специальным знаком. Допускаются таблицы, состоящие только из ключевых столбцов. Таблицы без первичного ключа создавать нельзя. -Часто при проектировании схемы таблицы имеется набор полей, естественным образом подходящий для использования в качестве первичного ключа. Тем не менее, к выбору ключа нужно подходить аккуратно, чтобы не создать хотспоты. -Например, если вы вставляете в таблицу данные с монотонно возрастающим ключом, то вы будете писать в конец таблицы. А так как {{ ydb-short-name }} разбивает данные таблицы по диапазонам ключей, это означает, что ваши вставки будут обрабатываться одним конкретным сервером, и перестанут использоваться основные преимущества распределенной БД. -Для того, чтобы нагрузка равномерно распределялась по различным серверам и при обработке больших таблиц не было хотспотов, рекомендуется применять: хэширование естественного ключа и использование хеша в качестве первой компоненты первичного ключа, изменение порядка следования компонент первичного ключа. +Часто при проектировании схемы таблицы имеется набор полей, естественным образом подходящий для использования в качестве первичного ключа. Тем не менее, к выбору ключа нужно подходить аккуратно, чтобы не создать хотспоты. Например, если вы вставляете в таблицу данные с монотонно возрастающим ключом, то вы будете писать в конец таблицы. А так как {{ ydb-short-name }} разбивает данные таблицы по диапазонам ключей, это означает, что ваши вставки будут обрабатываться одним конкретным сервером, и перестанут использоваться основные преимущества распределенной БД. Для того, чтобы нагрузка равномерно распределялась по различным серверам и при обработке больших таблиц не было хотспотов, рекомендуется применять: хеширование естественного ключа и использование хеша в качестве первой компоненты первичного ключа, изменение порядка следования компонент первичного ключа. ### Партиционирование таблиц {#partitioning} + Таблица в БД может быть шардирована по диапазонам значений первичного ключа. Каждый шард таблицы отвечает за свой диапазон первичных ключей. Диапазоны ключей, обслуживаемых разными шардами, не пересекаются. Различные шарды таблицы могут обслуживаться разными серверами распределенной БД (в том числе расположенными в разных локациях), а также могут независимо друг от друга перемещаться между серверами для перебалансировки или поддержания работоспособности шарда при отказах серверов или сетевого оборудования. При малом объеме данных или небольшой нагрузке таблица может состоять из одного шарда. При росте объема данных, обслуживаемых шардом, или нагрузки на шард, {{ ydb-short-name }} автоматически разбивает его на два. Разбиение происходит по медианному значению первичного ключа, если размер шарда превышает порог. В случае разбиения по нагрузке шард сначала собирает сэмпл запрашиваемых ключей (читаемых, записываемых и удаляемых), и на основании этого сэмпла выбирает для разбиения такой ключ, чтоб нагрузка распределилась поровну между новыми шардами. Таким образом в случае разбиения по нагрузке новые шарды могут иметь существенно отличающийся размер. Порог разделения шарда по размеру и включение/выключение автоматического разделения могут быть настроены индивидуально для каждой таблицы базы данных. -Помимо автоматического разделения предоставляется возможность создать пустую таблицу с предопределённым количеством шардов. При этом можно вручную задать точные границы разделения ключей по шардам или указать равномерное разделение на предопределённое количество шардов. В этом случае границы создадутся по первой компоненте первичного ключа. Равномерное распределение можно указать для таблиц, у которых первая компонента первичного ключа — целое число Uint64 или Uint32. +Помимо автоматического разделения предоставляется возможность создать пустую таблицу с предопределенным количеством шардов. При этом можно вручную задать точные границы разделения ключей по шардам или указать равномерное разделение на предопределенное количество шардов. В этом случае границы создадутся по первой компоненте первичного ключа. Равномерное распределение можно указать для таблиц, у которых первая компонента первичного ключа — целое число Uint64 или Uint32. -Параметры партиционирования относятся к самой таблице, но не к построенным на её данных вторичным индексам. Каждый индекс обслуживается своим набором шардов, и решения о разделении или объединении его партиций принимаются независимо на основании настроек по умолчанию. В будущем эти настройки могут быть сделаны доступными пользователям, аналогично настройкам основной таблицы. +Параметры партиционирования относятся к самой таблице, но не к построенным на ее данных вторичным индексам. Каждый индекс обслуживается своим набором шардов, и решения о разделении или объединении его партиций принимаются независимо на основании настроек по умолчанию. В будущем эти настройки могут быть сделаны доступными пользователям, аналогично настройкам основной таблицы. -Характерное время операции разделения или объединения - порядка 500 милисекунд. На это время вовлеченные в операцию данные становятся кратковременно недоступны для чтения и записи. Специализированные методы-обертки в {{ ydb-short-name }} SDK автоматически выполняют повторные попытки при получении информации о том, что шард находится в состоянии разделения или объединения, не поднимая её до уровня приложения. Стоит отметить, что если система по каким-то причинам перегружена (например, из-за общей нехватки CPU или пропускной способности выделенных базе дисковых ресурсов) то операции разделения и объединения могут длиться дольше. +Характерное время операции разделения или объединения — порядка 500 мс. На это время вовлеченные в операцию данные становятся кратковременно недоступны для чтения и записи. Специализированные методы-обертки в {{ ydb-short-name }} SDK автоматически выполняют повторные попытки при получении информации о том, что шард находится в состоянии разделения или объединения, не поднимая ее до уровня приложения. Стоит отметить, что если система по каким-то причинам перегружена (например, из-за общей нехватки CPU или пропускной способности выделенных базе дисковых ресурсов) то операции разделения и объединения могут длиться дольше. В схеме данных определяются следующие параметры партиционирования таблицы: #### AUTO_PARTITIONING_BY_SIZE -* Тип: Enum (`ENABLED`, `DISABLED`) -* Значение по умолчанию: `ENABLED` +* Тип: `Enum` (`ENABLED`, `DISABLED`). +* Значение по умолчанию: `ENABLED`. -Режим автоматического партиционирования по размеру партиции. Если размер партиции превысил значение, заданное параметром [`AUTO_PARTITIONING_PARTITION_SIZE_MB`](#auto_partitioning_partition_size_mb), то она встает в очередь на разделение (split). Если суммарный размер двух или более соседних партиции меньше 50% от значения параметра [`AUTO_PARTITIONING_PARTITION_SIZE_MB`](#auto_partitioning_partition_size_mb), то они встают в очередь на объединение (merge). +Режим автоматического партиционирования по размеру партиции. Если размер партиции превысил значение, заданное параметром [AUTO_PARTITIONING_PARTITION_SIZE_MB](#auto_partitioning_partition_size_mb), то она встает в очередь на разделение (split). Если суммарный размер двух или более соседних партиции меньше 50% от значения параметра [AUTO_PARTITIONING_PARTITION_SIZE_MB](#auto_partitioning_partition_size_mb), то они встают в очередь на объединение (merge). #### AUTO_PARTITIONING_BY_LOAD -* Тип: Enum (`ENABLED`, `DISABLED`) -* Значение по умолчанию: `DISABLED` +* Тип: `Enum` (`ENABLED`, `DISABLED`). +* Значение по умолчанию: `DISABLED`. Режим автоматического партиционирования по нагрузке. Если в течение нескольких десятков секунд шард потребляет более 50% CPU, то он ставится в очередь на разделение (split). Если в течение часа суммарная нагрузка на два или более соседних шарда утилизировала менее 35% одного ядра CPU, то они ставятся в очередь на объединение (merge). -Выполнение операций разделения или объединения само по себе утилизирует CPU, и занимает время. Поэтому, при работе с плавающей нагрузкой рекомендуется вместе с включением данного режима устанавливать отличное от 1 значение параметра минимального количество партиций [`AUTO_PARTITIONING_MIN_PARTITIONS_COUNT`](#auto_partitioning_min_partitions_count), чтобы спады нагрузки не приводили к снижению количества партиций ниже необходимого, и не было потребности их заново делить при появлении нагрузки. +Выполнение операций разделения или объединения само по себе утилизирует CPU, и занимает время. Поэтому, при работе с плавающей нагрузкой рекомендуется вместе с включением данного режима устанавливать отличное от 1 значение параметра минимального количество партиций [AUTO_PARTITIONING_MIN_PARTITIONS_COUNT](#auto_partitioning_min_partitions_count), чтобы спады нагрузки не приводили к снижению количества партиций ниже необходимого, и не было потребности их заново делить при появлении нагрузки. При выборе минимального количества партиций имеет смысл руководствоваться соображениями, что одна партиция таблицы может находиться только на одном сервере и использовать не более 1 ядра CPU для операций изменения данных. Исходя из этого, для таблицы на которой может ожидаться высокая нагрузка, можно указывать минимальное количество партиций не менее количества узлов (серверов), а лучше порядка количества ядер CPU, выделенных базе. #### AUTO_PARTITIONING_PARTITION_SIZE_MB -* Тип: Uint64 -* Значение по умолчанию: 2000 MB ( 2ГБ ) +* Тип: `Uint64`. +* Значение по умолчанию: `2000 MB` ( `2 ГБ` ). -Порог размера партиции в мегабайтах, при превышении которого шард будет разделён, имеет значение при включенном режиме [`AUTO_PARTITIONING_BY_SIZE`](#auto_partitioning_by_size). +Порог размера партиции в мегабайтах, при превышении которого шард будет разделен, имеет значение при включенном режиме [AUTO_PARTITIONING_BY_SIZE](#auto_partitioning_by_size). #### AUTO_PARTITIONING_MIN_PARTITIONS_COUNT -* Тип: Uint64 -* Значение по умолчанию: 1 +* Тип: `Uint64`. +* Значение по умолчанию: `1`. Объединение партиций (merge) производится только в том случае, если их фактическое количество превышает заданное этим параметром значение. При использовании режима автоматического партиционирования по нагрузке рекомендуется устанавливать отличное от 1 значение данного параметра, чтобы периодический спад нагрузки не приводил к снижению количества партиций ниже необходимого. #### AUTO_PARTITIONING_MAX_PARTITIONS_COUNT -* Тип: Uint64 -* Значение по умолчанию: 50 +* Тип: `Uint64`. +* Значение по умолчанию: `50`. Разделение партиций (split) производится только в том случае, если их количество не превышает заданное этим параметром значение. При любых включенных режимах автоматического партиционирования рекомендуется устанавливать осмысленное значение этого параметра, а также отслеживать приближение фактического количества партиций к нему, иначе рано или поздно партиции перестанут разделяться при росте данных или нагрузке, что приведет к сбою. #### UNIFORM_PARTITIONS -* Тип: Uint64 -* Значение по умолчанию: Не применимо +* Тип: `Uint64`. +* Значение по умолчанию: не применимо. -Количество партиций для равномерного начального разделения таблицы. Первая колонка первичного ключа должна иметь тип Uint64 или Uint32. Созданная таблица сразу будет разделена на указанное количество партиций. +Количество партиций для равномерного начального разделения таблицы. Первая колонка первичного ключа должна иметь тип `Uint64` или `Uint32`. Созданная таблица сразу будет разделена на указанное количество партиций. -При включенном автоматическом партиционировании необходимо также не забыть установить корректное значение параметра [`AUTO_PARTITIONING_MIN_PARTITIONS_COUNT`](#auto_partitioning_min_partitions_count), чтобы все партиции не объединились в одну сразу после создания таблицы. +При включенном автоматическом партиционировании необходимо также не забыть установить корректное значение параметра [AUTO_PARTITIONING_MIN_PARTITIONS_COUNT](#auto_partitioning_min_partitions_count), чтобы все партиции не объединились в одну сразу после создания таблицы. #### PARTITION_AT_KEYS -* Тип: Expression -* Значение по умолчанию: Не применимо +* Тип: `Expression`. +* Значение по умолчанию: не применимо. -Граничные значения ключей для начального разделения на партиции. Представляется списком граничных значений, разделенных запятыми и обрамленными в скобки. Каждое граничное значение может быть либо набором значений ключевых колонок (также разделенных запятыми и обрамленными в скобки), либо единичным значением, если указываются только значения первой ключевой колонки. Примеры: ```(100, 1000)```, ```((100, "abc"), (1000, "cde"))```. +Граничные значения ключей для начального разделения на партиции. Представляется списком граничных значений, разделенных запятыми и обрамленными в скобки. Каждое граничное значение может быть либо набором значений ключевых колонок (также разделенных запятыми и обрамленными в скобки), либо единичным значением, если указываются только значения первой ключевой колонки. Примеры: `(100, 1000)`, `((100, "abc"), (1000, "cde"))`. -При включенном автоматическом партиционировании необходимо также не забыть установить корректное значение параметра [`AUTO_PARTITIONING_MIN_PARTITIONS_COUNT`](#auto_partitioning_min_partitions_count), чтобы все партиции не объединились в одну сразу после создания таблицы. +При включенном автоматическом партиционировании необходимо также не забыть установить корректное значение параметра [AUTO_PARTITIONING_MIN_PARTITIONS_COUNT](#auto_partitioning_min_partitions_count), чтобы все партиции не объединились в одну сразу после создания таблицы. ### Чтение с реплик {#read_only_replicas} -При выполнении запросов в {{ ydb-short-name }} фактическое выполнение запроса к каждому шарду осуществляется в единой точке, обслуживающей протокол распределенных транзакций. Но благодаря хранению данных на разделяемом хранилище возможен запуск одного или нескольких фолловеров шарда, без выделения дополнительного места на сторадже - данные уже хранятся реплицированного и возможно обслуживание более одного читателя (но писатель при этом всё еще в каждый момент строго один). + +При выполнении запросов в {{ ydb-short-name }} фактическое выполнение запроса к каждому шарду осуществляется в единой точке, обслуживающей протокол распределенных транзакций. Но благодаря хранению данных на разделяемом хранилище возможен запуск одного или нескольких фолловеров шарда, без выделения дополнительного места на сторадже — данные уже хранятся реплицированно и возможно обслуживание более одного читателя (но писатель при этом все еще в каждый момент строго один). Применение чтения с фолловеров дает следующие возможности: -* обслуживать клиентов, критичных к минимальным задержкам, недостижимым иными способами в мульти-ДЦ кластере. Достигается за счёт приближения точки выполнения запроса к точке задания запроса, что отсекает задержку на меж-ДЦ пересылки. В результате, сохраняя все гарантии мульти-ДЦ кластера по надёжности хранения, отвечать на точечные читающие запросы за единицы миллисекунд. -* обслуживать читающие запросов с фолловеров без влияния на модифицирующие запросы, выполняющиеся на шарде. Это может быть полезно как для изоляции разных сценариев, так и для увеличения пропускной способности партиции. -* продолжать обслуживание при переездах лидера партиции (как штатной при балансировке, так и при сбоях). Позволяет переживать процессы в кластере без влияния на читающих клиентов. -* в целом повышать предел проиводительности чтения шард, если множество читающих запросов попадают на одни и те же ключи + +* Обслуживать клиентов, критичных к минимальным задержкам, недостижимым иными способами в мульти-ДЦ кластере. Достигается за счет приближения точки выполнения запроса к точке задания запроса, что отсекает задержку на меж-ДЦ пересылки. В результате, сохраняя все гарантии мульти-ДЦ кластера по надежности хранения, отвечать на точечные читающие запросы за единицы миллисекунд. +* Обслуживать читающие запросов с фолловеров без влияния на модифицирующие запросы, выполняющиеся на шарде. Это может быть полезно как для изоляции разных сценариев, так и для увеличения пропускной способности партиции. +* Продолжать обслуживание при переездах лидера партиции (как штатной при балансировке, так и при сбоях). Позволяет переживать процессы в кластере без влияния на читающих клиентов. +* В целом повышать предел производительности чтения шардов, если множество читающих запросов попадают на одни и те же ключи. В схеме данных таблицы можно указать необходимость запуска реплик для чтения для каждого шарда таблицы. Обращения к репликам для чтения (фолловерам) типично происходят не покидая сети датацентра, что позволяет обеспечить время ответа в единицы миллисекунд: | Имя параметра | Описание | Тип | Допустимые значения | Возможность изменения | Возможность сброса | | ------------- | --------- | --- | ------------------- | --------------------- | ------------------ | -| ```READ_REPLICAS_SETTINGS``` | ```PER_AZ``` означает использование указанного количества реплик в каждом AZ, ```ANY_AZ``` — во всех AZ суммарно. | String | ```"PER_AZ:<count>"```, ```"ANY_AZ:<count>"``` где ```<count>``` — число реплик | Да | Нет | +| `READ_REPLICAS_SETTINGS` | `PER_AZ` означает использование указанного количества реплик в каждом AZ, `ANY_AZ` — во всех AZ суммарно. | String | `"PER_AZ:<count>"`, `"ANY_AZ:<count>"` где `<count>` — число реплик | Да | Нет | Внутреннее состояние каждого из фолловеров восстанавливается в точности по состоянию лидера и полностью консистентно. Кроме состояния данных в сторадже на фолловеров отправляется и поток обновлений с лидера. Обновления отправляются в реальном времени, сразу после коммита в лог. Но отправляются асинхронно, что приводит к некоторой задержке применения обновлений на фолловерах относительно их коммита на лидере (типично в десятки миллисекунд, но может увеличиваться в случае проблем связности в кластере). В связи с этим, чтение с фолловеров обеспечивается только в [режиме транзакций](../transactions#modes) `StaleReadOnly()`. -Если фолловеров несколько - то отставание их от лидера может различаться, т.е. хотя каждый фолловер каждого из шардов сохраняет внутреннюю консистентность, между разными шардами могут наблюдаться артефакты. Код приложения должен быть к этому готов. По этой же причине на данный момент невозможно и выполнение с фолловеров кроссшардовых транзакций. +Если фолловеров несколько, то отставание их от лидера может различаться, т.е. хотя каждый фолловер каждого из шардов сохраняет внутреннюю консистентность, между разными шардами могут наблюдаться артефакты. Код приложения должен быть к этому готов. По этой же причине на данный момент невозможно и выполнение с фолловеров кроссшардовых транзакций. ### Автоматическое удаление устаревших данных (TTL) {#ttl} -{{ ydb-short-name }} поддерживат функцию автоматического фонового удаления устаревших данных. В схеме данных таблицы может быть определена колонка, содержащая значение типа Datetime или Timestamp, значение которой у всех строк будет сравниваться в фоновом режиме с текущим временем. Строки, для которых текущее время стало больше чем значение в колонке с учетом заданной задержки, будут удалены. +{{ ydb-short-name }} поддерживает функцию автоматического фонового удаления устаревших данных. В схеме данных таблицы может быть определена колонка, содержащая значение типа `Datetime` или `Timestamp`, значение которой у всех строк будет сравниваться в фоновом режиме с текущим временем. Строки, для которых текущее время стало больше чем значение в колонке с учетом заданной задержки, будут удалены. | Имя параметра | Тип | Допустимые значения | Возможность изменения | Возможность сброса | | ------------- | --- | ------------------- | --------------------- | ------------------ | -| ```TTL``` | Expression | ```Interval("<literal>") ON <column>``` | Да | Да | +| `TTL` | Expression | `Interval("<literal>") ON <column>` | Да | Да | -Подробнее об удалении устаревших данных читайте в разделе [Time to Live (TTL)](../../../concepts/ttl.md) +Подробнее об удалении устаревших данных читайте в разделе [Time to Live (TTL)](../../../concepts/ttl.md). ### Переименование таблицы {#rename} @@ -126,8 +124,8 @@ Скорость выполнения переименования определяется типом дата-транзакций, которые выполняются в данный момент на таблице, и не зависит от количества данных в таблице. -- [Переименование таблицы в YQL](../../../yql/reference/syntax/alter_table.md#rename) -- [Переименование таблицы через CLI](../../../reference/ydb-cli/commands/tools/rename.md) +* [Переименование таблицы в YQL](../../../yql/reference/syntax/alter_table.md#rename) +* [Переименование таблицы через CLI](../../../reference/ydb-cli/commands/tools/rename.md) ### Фильтр Блума {#bloom-filter} @@ -135,5 +133,4 @@ | Имя параметра | Тип | Допустимые значения | Возможность изменения | Возможность сброса | | ------------- | --- | ------------------- | --------------------- | ------------------ | -| ```KEY_BLOOM_FILTER``` | Enum | ```ENABLED```, ```DISABLED``` | Да | Нет | - +| `KEY_BLOOM_FILTER` | Enum | `ENABLED`, `DISABLED` | Да | Нет | diff --git a/ydb/docs/ru/core/concepts/_includes/index/intro.md b/ydb/docs/ru/core/concepts/_includes/index/intro.md index 3b47b7d27b..5bd6a9d697 100644 --- a/ydb/docs/ru/core/concepts/_includes/index/intro.md +++ b/ydb/docs/ru/core/concepts/_includes/index/intro.md @@ -5,7 +5,7 @@ description: 'YDB — это горизонтально масштабируем # Обзор {{ ydb-short-name }} -*{{ ydb-short-name }}* ({{ ydb-short-name }}) — это горизонтально масштабируемая распределённая отказоустойчивая СУБД. {{ ydb-short-name }} спроектирована с учетом требований высокой производительности — например, обычный сервер может обрабатывать десятки тысяч запросов в секунду. В дизайн системы заложена работа с объемами данных в сотни петабайт. {{ ydb-short-name }} может эксплуатироваться в однодатацентровом и геораспределенном (кросс-датацентровый) режимах на кластере из тысяч серверов. +*{{ ydb-short-name }}* — это горизонтально масштабируемая распределённая отказоустойчивая СУБД. {{ ydb-short-name }} спроектирована с учетом требований высокой производительности — например, обычный сервер может обрабатывать десятки тысяч запросов в секунду. В дизайн системы заложена работа с объемами данных в сотни петабайт. {{ ydb-short-name }} может эксплуатироваться в однодатацентровом и геораспределенном (кросс-датацентровый) режимах на кластере из тысяч серверов. {{ ydb-short-name }} обеспечивает: @@ -25,4 +25,4 @@ description: 'YDB — это горизонтально масштабируем В дизайн {{ 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-short-name }} используется в сервисах Яндекса в качестве высокопроизводительной [OLTP](https://en.wikipedia.org/wiki/Online_transaction_processing) СУБД. В частности, сервисы {{ yandex-cloud }} Yandex Object Storage и Yandex Block Storage используют {{ ydb-short-name }} для хранения данных и базируются на её компонентах. +{{ ydb-short-name }} используется в сервисах Яндекса в качестве высокопроизводительной [OLTP](https://en.wikipedia.org/wiki/Online_transaction_processing) СУБД. В частности, сервисы {{ yandex-cloud }} {{ objstorage-full-name}} использует {{ ydb-short-name }} для хранения данных и базируется на её компонентах. diff --git a/ydb/docs/ru/core/concepts/_includes/index/when_use.md b/ydb/docs/ru/core/concepts/_includes/index/when_use.md index 9011747909..c39ce247a1 100644 --- a/ydb/docs/ru/core/concepts/_includes/index/when_use.md +++ b/ydb/docs/ru/core/concepts/_includes/index/when_use.md @@ -1,11 +1,11 @@ -## Сценарии применения +## Сценарии применения {#use-cases} -{{ ydb-short-name }} является альтернативой имеющимся решениям в следующих случаях: -* При использовании NoSQL систем, когда требуется строгая консистентность данных -* При использовании NoSQL систем, когда требуется транзакционное изменение данных, хранящихся в разных строках одной или нескольких таблиц -* В системах, требующих обработки и хранения большого объема данных, с возможностью практически неограниченного горизонтального масштабирования (в эксплуатации находятся промышленные кластера из 5000+ узлов, обрабатывающие нагрузку в миллионы RPS, и хранящие петабайты данных) -* В системах с незначительной нагрузкой, когда поддержка отдельного инстанса базы данных будет расточительна с материальной точки зрения (предлагается использовать {{ ydb-short-name }} в режиме бессерверных вычислений) -* В системах с плохо предсказуемой или сезонно меняющейся нагрузкой (используя возможность добавления/уменьшения вычислительных ресурсов по запросу и/или в -режиме бессерверных вычислений) -* В высоконагруженных системах, которые шардируют нагрузку между инстансами реляционной базы данных -* При разработке нового продукта, для которого нет надежного прогноза будущей нагрузки, или ожидается большая нагрузка, превышающая возможности традиционных реляционных баз данных
\ No newline at end of file +{{ ydb-short-name }} является альтернативой имеющимся решениям в следующих случаях: + +* При использовании NoSQL систем, когда требуется строгая консистентность данных. +* При использовании NoSQL систем, когда требуется транзакционное изменение данных, хранящихся в разных строках одной или нескольких таблиц. +* В системах, требующих обработки и хранения большого объема данных, с возможностью практически неограниченного горизонтального масштабирования (в эксплуатации находятся промышленные кластера из 5000+ узлов, обрабатывающие нагрузку в миллионы RPS, и хранящие петабайты данных). +* В системах с незначительной нагрузкой, когда поддержка отдельного инстанса базы данных будет расточительна с материальной точки зрения (предлагается использовать {{ ydb-short-name }} в режиме бессерверных вычислений). +* В системах с плохо предсказуемой или сезонно меняющейся нагрузкой (используя возможность добавления/уменьшения вычислительных ресурсов по запросу и/или в режиме бессерверных вычислений). +* В высоконагруженных системах, которые шардируют нагрузку между инстансами реляционной базы данных. +* При разработке нового продукта, для которого нет надежного прогноза будущей нагрузки, или ожидается большая нагрузка, превышающая возможности традиционных реляционных баз данных. diff --git a/ydb/docs/ru/core/concepts/_includes/limits-ydb.md b/ydb/docs/ru/core/concepts/_includes/limits-ydb.md index 1a8dca52a7..b7d7a8f07f 100644 --- a/ydb/docs/ru/core/concepts/_includes/limits-ydb.md +++ b/ydb/docs/ru/core/concepts/_includes/limits-ydb.md @@ -9,19 +9,19 @@ | Объект | Ограничение | Значение | Пояснение | Внутреннее<br>название | Тип<br>ошибки | | :--- | :--- | :--- | :--- | :---: | :---: | -| База данных | Максимальная глубина пути | 32 | Максимальное количество вложенных элементов пути (директорий, таблиц) | MaxDepth | SCHEME_ERROR | -| База данных | Максимальное количество путей (объектов в схеме) | 200 000 | Максимальное количество элементов пути (директорий, таблиц) в базе данных| MaxPaths | GENERIC_ERROR | -| База данных | Максимальное количество таблеток | 200 000 | Максимальное количество таблеток (шардов таблиц и системных таблеток), которое может работать в базе данных. На запрос создания, копирования или изменения таблицы, в результате выполнения которого данное ограничение может быть превышено, будет возвращена ошибка. При достижении максимального количества таблеток в базе автоматическое шардирование таблиц не происходит | MaxShards | GENERIC_ERROR | -| База данных | Максимальная длина имени объекта | 255 | Ограничивает количество символов в имени объекта схемы, например директории или таблицы | MaxPathElementLength | SCHEME_ERROR | -| База данных | Максимальный размер ACL | 10 Кб | Максимальный суммарный размер всех правил контроля доступа, которые можно сохранить для одного объекта схемы | MaxAclBytesSize | GENERIC_ERROR | -| Директория | Максимальное количество объектов | 100 000 | Максимальное количество таблиц, директорий, созданных в директории| MaxChildrenInDir | SCHEME_ERROR | -| Таблица | Максимальное количество шардов таблицы | 35 000 | Максимальное количество шардов таблицы | MaxShardsInPath | GENERIC_ERROR | -| Таблица | Максимальное количество столбцов | 200 | Ограничивает общее количество столбцов в таблице| MaxTableColumns | GENERIC_ERROR | -| Таблица | Максимальная длина имени столбца | 255 | Ограничивает количество символов в имени столбца | MaxTableColumnNameLength | GENERIC_ERROR | -| Таблица | Максимальное количество столбцов в первичном ключе | 20 | Каждая таблица должна иметь первичный ключ. Количество столбцов, входящих в состав первичного ключа, не может превышать это ограничение | MaxTableKeyColumns | GENERIC_ERROR | -| Таблица | Максимальное количество индексов | 20 | Максимальное количество индексов помимо индекса первичного ключа, которые могут быть созданы на таблице| MaxTableIndices | GENERIC_ERROR | -| Таблица | Максимальное количество фолловеров | 3 | Максимальное количество read-only реплик, которое можно указать при создании таблицы с фолловерами| MaxFollowersCount | GENERIC_ERROR | -| Таблица | Максимальное количество копируемых таблиц | 1000 | Ограничение на размер списка таблиц для операций консистентного копирования таблиц| MaxConsistentCopyTargets | GENERIC_ERROR | +| База данных | Максимальная глубина пути | 32 | Максимальное количество вложенных элементов пути (директорий, таблиц). | MaxDepth | SCHEME_ERROR | +| База данных | Максимальное количество путей (объектов в схеме) | 200 000 | Максимальное количество элементов пути (директорий, таблиц) в базе данных. | MaxPaths | GENERIC_ERROR | +| База данных | Максимальное количество таблеток | 200 000 | Максимальное количество таблеток (шардов таблиц и системных таблеток), которое может работать в базе данных. На запрос создания, копирования или изменения таблицы, в результате выполнения которого данное ограничение может быть превышено, будет возвращена ошибка. При достижении максимального количества таблеток в базе автоматическое шардирование таблиц не происходит. | MaxShards | GENERIC_ERROR | +| База данных | Максимальная длина имени объекта | 255 | Ограничивает количество символов в имени объекта схемы, например директории или таблицы. | MaxPathElementLength | SCHEME_ERROR | +| База данных | Максимальный размер ACL | 10 Кб | Максимальный суммарный размер всех правил контроля доступа, которые можно сохранить для одного объекта схемы. | MaxAclBytesSize | GENERIC_ERROR | +| Директория | Максимальное количество объектов | 100 000 | Максимальное количество таблиц, директорий, созданных в директории. | MaxChildrenInDir | SCHEME_ERROR | +| Таблица | Максимальное количество шардов таблицы | 35 000 | Максимальное количество шардов таблицы. | MaxShardsInPath | GENERIC_ERROR | +| Таблица | Максимальное количество столбцов | 200 | Ограничивает общее количество столбцов в таблице. | MaxTableColumns | GENERIC_ERROR | +| Таблица | Максимальная длина имени столбца | 255 | Ограничивает количество символов в имени столбца. | MaxTableColumnNameLength | GENERIC_ERROR | +| Таблица | Максимальное количество столбцов в первичном ключе | 20 | Каждая таблица должна иметь первичный ключ. Количество столбцов, входящих в состав первичного ключа, не может превышать это ограничение. | MaxTableKeyColumns | GENERIC_ERROR | +| Таблица | Максимальное количество индексов | 20 | Максимальное количество индексов помимо индекса первичного ключа, которые могут быть созданы на таблице. | MaxTableIndices | GENERIC_ERROR | +| Таблица | Максимальное количество фолловеров | 3 | Максимальное количество read-only реплик, которое можно указать при создании таблицы с фолловерами. | MaxFollowersCount | GENERIC_ERROR | +| Таблица | Максимальное количество копируемых таблиц | 1000 | Ограничение на размер списка таблиц для операций консистентного копирования таблиц. | MaxConsistentCopyTargets | GENERIC_ERROR | ## Ограничения размеров хранимых данных @@ -36,8 +36,8 @@ | Параметр | Значение | Вызов | Пояснение | Статус<br>в случае<br>нарушения<br>ограничения | | :--- | :--- | :--- | :--- | :---: | -| Максимальное количество строк в результате запроса | 1000 | ExecuteDataQuery | Полные результаты некоторых запросов, выполненных через метод `ExecuteDataQuery`, могут содержать больше строк, чем допустимо. В этом случае в ответ на запрос вернётся максимально допустимое число строк, а у результата будет установлен флаг `truncated` | SUCCESS | -| Максимальный размер результата запроса | 50 Мб | ExecuteDataQuery | Полный результат некоторых запросов может превышать установленное ограничение. В этом случае запрос завершится ошибкой, данные не будут возвращены | PRECONDITION_FAILED | -| Максимальное количество сессий на ноду кластера | 1000 | CreateSession | Используя библиотеку для работы с {{ ydb-short-name }}, приложение может создавать сессии в рамках соединения. Сессии привязаны к ноде. С одной нодой можно создать ограниченное количество сессий | OVERLOADED | -| Максимальная длина текста запроса | 10 Кб | ExecuteDataQuery | Ограничение на длину текста YQL-запроса | BAD_REQUEST | -| Максимальный размер значений параметров | 50 Мб | ExecuteDataQuery | Ограничение на суммарный размер параметров, передаваемых при выполнении ранее подготовленного запроса | BAD_REQUEST | +| Максимальное количество строк в результате запроса | 1000 | ExecuteDataQuery | Полные результаты некоторых запросов, выполненных через метод `ExecuteDataQuery`, могут содержать больше строк, чем допустимо. В этом случае в ответ на запрос вернется максимально допустимое число строк, а у результата будет установлен флаг `truncated`. | SUCCESS | +| Максимальный размер результата запроса | 50 Мб | ExecuteDataQuery | Полный результат некоторых запросов может превышать установленное ограничение. В этом случае запрос завершится ошибкой, данные не будут возвращены. | PRECONDITION_FAILED | +| Максимальное количество сессий на ноду кластера | 1000 | CreateSession | Используя библиотеку для работы с {{ ydb-short-name }}, приложение может создавать сессии в рамках соединения. Сессии привязаны к ноде. С одной нодой можно создать ограниченное количество сессий. | OVERLOADED | +| Максимальная длина текста запроса | 10 Кб | ExecuteDataQuery | Ограничение на длину текста YQL-запроса. | BAD_REQUEST | +| Максимальный размер значений параметров | 50 Мб | ExecuteDataQuery | Ограничение на суммарный размер параметров, передаваемых при выполнении ранее подготовленного запроса. | BAD_REQUEST | diff --git a/ydb/docs/ru/core/concepts/_includes/scan_query.md b/ydb/docs/ru/core/concepts/_includes/scan_query.md index fa2ee180b7..d066b47ccb 100644 --- a/ydb/docs/ru/core/concepts/_includes/scan_query.md +++ b/ydb/docs/ru/core/concepts/_includes/scan_query.md @@ -1,27 +1,25 @@ # Скан запросы (Scan Query) в {{ ydb-short-name }} -Скан запросы (*Scan Queries*) - это отдельный интерфейс доступа к данным, предназначенный в первую очередь для выполнения аналитических ad-hoc запросов над базой данных. +Скан запросы (Scan Queries) — это отдельный интерфейс доступа к данным, предназначенный в первую очередь для выполнения аналитических ad-hoc запросов над базой данных. Данный способ исполнения запросов обладает следующими отличительными свойствами: * Это только *Read-Only* запросы. * В режиме *SERIALIZABLE_RW* берется snapshot данных, над которым в дальнейшем и происходит вся работа. В результате влияние на поток OLTP-транзакций минимальное (только снятие снапшота). -* Результат запроса - это стрим данных ([grpc stream](https://grpc.io/docs/what-is-grpc/core-concepts/)). Таким образом, у скан запросов нет лимита на количество строк в результате. +* Результат запроса — это стрим данных ([grpc stream](https://grpc.io/docs/what-is-grpc/core-concepts/)). Таким образом, у скан запросов нет лимита на количество строк в результате. * Из-за высоких накладных расходов подходит только для ad-hoc запросов. - {% node info %} Через интерфейс *Scan Queries* можно выполнять запросы к [системным таблицам](../../troubleshooting/system_views.md). {% endnote %} - На текущий момент скан запросы не могут считаться полноценным способом выполнения OLAP-запросов, поскольку они обладают рядом технических ограничений (которые со временем будут сняты): * Длительность запроса ограничена 5 минутами. * Многие операции (включая сортировку) выполняются целиком в памяти, поэтому на сложных запросах можно получить ошибку нехватки ресурсов. -* Для джойнов на текущий момент используется только одна стратегия - *MapJoin* (aka *Broadcast Join*), где "правая" таблица конвертируется в карту, поэтому она должна быть не более единиц гигабайт. +* Для джойнов на текущий момент используется только одна стратегия — *MapJoin* (aka *Broadcast Join*), где «правая» таблица конвертируется в карту, поэтому она должна быть не более единиц гигабайт. * Не поддерживается prepared-форма, т.е. на каждый вызов происходит компиляция запроса. * Нет оптимизаций под точечные чтения и чтения небольших диапазонов данных. * В SDK не поддерживается автоматический retry. @@ -32,13 +30,16 @@ {% endnote %} -## Как воспользоваться +## Как воспользоваться {#how-use} -Как и другие виды запросов, *Scan Queries* доступны через [консоль управления]({{ link-console-main }})(В запросе требуется указать прагму `PRAGMA Kikimr.ScanQuery = "true";`), [CLI](../../reference/ydb-cli/commands/scan-query.md) и [SDK](../../reference/ydb-sdk/index.md). +Как и другие виды запросов, *Scan Queries* доступны через [консоль управления]({{ link-console-main }})(в запросе требуется указать прагму `PRAGMA Kikimr.ScanQuery = "true";`), [CLI](../../reference/ydb-cli/commands/scan-query.md) и [SDK](../../reference/ydb-sdk/index.md). {% if oss %} -### C++ SDK -Для запуска запроса через механизм *Scan Queries* предназначены 2 метода в классе `Ydb::TTableClient` + +### C++ SDK {#cpp} + +Для запуска запроса через механизм *Scan Queries* предназначены 2 метода в классе `Ydb::TTableClient`: + ```cpp class TTableClient { ... @@ -51,4 +52,4 @@ class TTableClient { }; ``` -{% endif %}
\ No newline at end of file +{% endif %} diff --git a/ydb/docs/ru/core/concepts/_includes/secondary_indexes.md b/ydb/docs/ru/core/concepts/_includes/secondary_indexes.md index 946e7fcb52..d583b62884 100644 --- a/ydb/docs/ru/core/concepts/_includes/secondary_indexes.md +++ b/ydb/docs/ru/core/concepts/_includes/secondary_indexes.md @@ -3,6 +3,7 @@ В {{ ydb-short-name }} автоматически создается индекс по первичному ключу, поэтому выборки с условием по первичному ключу всегда выполняются эффективно, затрагивая только требуемые строки. Выборка с условием, наложенным на одну или несколько неключевых колонок, как правило, приводит к полному сканированию таблицы. Для того чтобы такие выборки были эффективными, нужно использовать _вторичные индексы_. В текущей версии {{ ydb-short-name }} реализованы _синхронные_ и _асинхронные_ глобальные вторичные индексы. Каждый индекс представляет собой скрытую таблицу, которая обновляется: + * для синхронных индексов — транзакционно при изменении основной таблицы; * для асинхронных индексов — в фоне, получая необходимые изменения из основной таблицы. diff --git a/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/01_intro.md b/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/01_intro.md index 3ca78baf0b..8fff85f17e 100644 --- a/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/01_intro.md +++ b/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/01_intro.md @@ -14,4 +14,4 @@ editable: false * _Serverless_ — база данных, не требующая от вас какого-либо конфигурирования, администрирования, отслеживания загрузки и управления ресурсами. Для ее создания достаточно указать имя, и вы получите URL для соединения. Оплата берется за исполнение запросов и фактический объем хранимых данных. -* _Dedicated_ — вы определяете вычислительные ресурсы, которые будут зарезервированы под базу данных: CPU и RAM на узлах, количество узлов и объем хранилища данных. Вам необходимо отслеживать достаточность ресурсов для успешной обработки нагрузки и добавлять новые по мере необходимости. Оплата берется за выделенные ресурсы по часам, вне зависимости от их фактического использования.
\ No newline at end of file +* _Dedicated_ — вы определяете вычислительные ресурсы, которые будут зарезервированы под базу данных: CPU и RAM на узлах, количество узлов и объем хранилища данных. Вам необходимо отслеживать достаточность ресурсов для успешной обработки нагрузки и добавлять новые по мере необходимости. Оплата берется за выделенные ресурсы по часам, вне зависимости от их фактического использования. diff --git a/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md b/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md index b8ffd6519d..47e59195de 100644 --- a/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md +++ b/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md @@ -3,7 +3,7 @@ ### Ограничения — пропускная способность, RU/с {#capacity} -При исполнении запроса к Serverless базе данных вычисляется показатель, отражающий величину ресурсов разного вида, затраченных на исполнение этого запроса. Данный показатель измеряется в специальных единицах — Request Units (RU). От суммарного потребления RU зависит стоимость использования Serverless базы данных. +При исполнении запроса к Serverless базе данных вычисляется показатель, отражающий величину ресурсов разного вида, затраченных на исполнение этого запроса. Данный показатель измеряется в специальных единицах — Request Units (RU). От суммарного потребления RU зависит стоимость использования Serverless базы данных. Так как ресурсы Serverless базы данных неопределенно большие, то и максимальное потребление Request Units за промежуток времени также может составить любое значение, приведя к нежелательным начислениям. Например, такое может произойти в результате ошибки в коде, приводящей к запросам в бесконечном цикле. diff --git a/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md b/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md index fdf2a9d930..6c3ba7cec0 100644 --- a/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md +++ b/ydb/docs/ru/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md @@ -1,5 +1,5 @@ -## Архитектура {{ ydb-short-name }} в разных режимах работы +## Архитектура {{ ydb-short-name }} в разных режимах работы {#arch-diff} ### Разделение compute и storage слоев {#separate-layers} @@ -11,10 +11,10 @@ ### Dedicated режим работы {{ ydb-short-name }} {#dedicated} -Режим работы Dedicated предполагает, что ресурсы на инстансы Таблеток и на выполнение YQL-запросов выбираются из явно выделенных для базы данных compute ресурсов. Под compute ресурсами понимаются виртуальные машины, обладаемые определенным количеством vCPU и памяти. Задача выбора оптимального количества ресурсов для базы данных в настоящий момент лежит на пользователе. Если ресурсов будет недостаточно для обслуживания подаваемой нагрузки, то latency запросов начнет увеличиваться, а в пределе будет отказ в обслуживании запросов, например с кодом возврата ```OVERLOADED```. Пользователь может добавить compute ресурсы (ВМ) в базу данных в UI или CLI для того, чтобы обеспечить базу данных необходимым количеством вычислительных ресурсов. Добавление compute ресурсов в базу данных происходит относительно быстро и сопоставимо со временем запуска ВМ. Далее {{ ydb-short-name }} автоматически отбалансирует Таблетки по кластеру с учетом добавленных ресурсов. +Режим работы Dedicated предполагает, что ресурсы на инстансы Таблеток и на выполнение YQL-запросов выбираются из явно выделенных для базы данных compute ресурсов. Под compute ресурсами понимаются виртуальные машины, обладающие определенным количеством vCPU и памяти. Задача выбора оптимального количества ресурсов для базы данных в настоящий момент лежит на пользователе. Если ресурсов будет недостаточно для обслуживания подаваемой нагрузки, то latency запросов начнет увеличиваться, а в пределе будет отказ в обслуживании запросов, например с кодом возврата `OVERLOADED`. Пользователь может добавить compute ресурсы (ВМ) в базу данных в UI или CLI для того, чтобы обеспечить базу данных необходимым количеством вычислительных ресурсов. Добавление compute ресурсов в базу данных происходит относительно быстро и сопоставимо со временем запуска ВМ. Далее {{ ydb-short-name }} автоматически сбалансирует Таблетки по кластеру с учетом добавленных ресурсов. ### Serverless режим работы {{ ydb-short-name }} {#serverless} -В Serverless режиме работы инфраструктура {{ ydb-short-name }} определяет сколько вычислительных ресурсов необходимо выделить для обслуживания пользовательской базы. Количество выделенных ресурсов может быть как очень большим (произвольное количество ядер), так и очень маленьким (значительно менее одного ядра). Если пользователь создал базу данных из одной таблицы с одной записью в ней, при этом выполняет запросы к базе крайне редко, то {{ ydb-short-name }} по сути тратит незначительный объем памяти на инстансы Таблеток, которые входят в состав пользовательской базы. Это возможно за счет того, что компоненты пользовательской базы представляют собой объекты, а не процессы. Если нагрузка возрастает, то компоненты базы начинают потреблять больше процессорного времени и памяти. Если нагрузка возрастает до пределов, когда ресурсов ВМ не хватает, инфраструктура {{ ydb-short-name }} имеет возможность гранулированно балансировать систему, порождая инстансы Таблеток на других ВМ. +В Serverless режиме работы инфраструктура {{ ydb-short-name }} определяет, сколько вычислительных ресурсов необходимо выделить для обслуживания пользовательской базы. Количество выделенных ресурсов может быть как очень большим (произвольное количество ядер), так и очень маленьким (значительно менее одного ядра). Если пользователь создал базу данных из одной таблицы с одной записью в ней, при этом выполняет запросы к базе крайне редко, то {{ ydb-short-name }}, по сути, тратит незначительный объем памяти на инстансы Таблеток, которые входят в состав пользовательской базы. Это возможно за счет того, что компоненты пользовательской базы представляют собой объекты, а не процессы. Если нагрузка возрастает, то компоненты базы начинают потреблять больше процессорного времени и памяти. Если нагрузка возрастает до пределов, когда ресурсов ВМ не хватает, инфраструктура {{ ydb-short-name }} имеет возможность гранулированно балансировать систему, порождая инстансы Таблеток на других ВМ. -Подобная технология позволяет очень плотно упаковывать виртуальные сущности (инстансы Таблеток) в физические ресурсы на основе реального потребления, что дает возможность выставлять счет пользователю за выполненные операции, а не за выделенные ресурсы.
\ No newline at end of file +Подобная технология позволяет очень плотно упаковывать виртуальные сущности (инстансы Таблеток) в физические ресурсы на основе реального потребления, что дает возможность выставлять счет пользователю за выполненные операции, а не за выделенные ресурсы. diff --git a/ydb/docs/ru/core/concepts/_includes/transactions.md b/ydb/docs/ru/core/concepts/_includes/transactions.md index 8e6b06591a..4ebf65da1c 100644 --- a/ydb/docs/ru/core/concepts/_includes/transactions.md +++ b/ydb/docs/ru/core/concepts/_includes/transactions.md @@ -2,16 +2,19 @@ Этот раздел описывает особенности реализации YQL для {{ ydb-short-name }} транзакций. -## Язык запросов +## Язык запросов {#query-language} + Основным средством создания, модификации и управления данными в {{ ydb-short-name }} является декларативный язык запросов YQL. YQL — это диалект SQL, который может считаться стандартом для общения с базами данных. Кроме того, {{ ydb-short-name }} поддерживает набор специальных RPC, например, для работы с древовидной схемой или для управления кластером. ## Режимы транзакций {#modes} + По умолчанию транзакции в {{ ydb-short-name }} выполняются в режиме *Serializable*, который предоставляет самый строгий [уровень изоляции](https://en.wikipedia.org/wiki/Isolation_(database_systems)#Serializable) для пользовательских транзакций. В этом режиме гарантируется, что результат успешно выполненных параллельных транзакций эквивалентен определенному последовательному порядку их выполнения, при этом для успешных транзакций отсутствуют [аномалии чтений](https://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_phenomena). -В случае когда требования консистентности или свежести читаемых транзакцией данных могут быть ослаблены, пользователь имеет возможность использовать режимы выполнения с пониженными гарантиями: -* *Online Read-Only*. Каждое из чтений в транзакции читает последние на момент своего выполнения данные. Консистентость полученных данных определяется настройкой *allow_inconsistent_reads*: - * *false* (consistent reads). В данном режиме каждое из чтений по отдельности возвращает консистентные данные, но консистентность данных между разными чтениями не гарантируется. Дважды выполненное чтение одного и того же диапазона таблицы может вернуть разные результаты. - * *true* (inconsistent reads). В данном режиме данные даже для отдельно взятого чтения могут содержать неконсистентные результаты. +В случае, когда требования консистентности или свежести читаемых транзакцией данных могут быть ослаблены, пользователь имеет возможность использовать режимы выполнения с пониженными гарантиями: + +* *Online Read-Only*. Каждое из чтений в транзакции читает последние на момент своего выполнения данные. Консистентность полученных данных определяется настройкой *allow_inconsistent_reads*: + * *false* (consistent reads). В данном режиме каждое из чтений по отдельности возвращает консистентные данные, но консистентность данных между разными чтениями не гарантируется. Дважды выполненное чтение одного и того же диапазона таблицы может вернуть разные результаты. + * *true* (inconsistent reads). В данном режиме данные даже для отдельно взятого чтения могут содержать неконсистентные результаты. * *Stale Read Only*. Чтения данных в транзакции возвращают результаты с возможным отставанием от актуальных (доли секунды). Данные в каждом отдельно взятом чтении консистентны, между разными чтениями консистентность данных не гарантируется. Режим выполнения транзакции задается в настройках транзакции при ее создании. @@ -22,12 +25,12 @@ Подробнее о поддерживаемых конструкциях YQL можно почитать в [документации YQL](../../yql/reference/index.md). -Ниже перечислены возможности и ограничения поддержки YQL в {{ ydb-short-name }}, которые могут быть неочевидны на первый взгляд и на которые стоит обратить внимание. +Ниже перечислены возможности и ограничения поддержки YQL в {{ ydb-short-name }}, которые могут быть неочевидны на первый взгляд и на которые стоит обратить внимание: - * Допускаются multistatement transactions, то есть транзакции, состоящие из последовательности выражений YQL. При выполнении транзакции допускается взаимодействие с клиентской программой, иначе говоря, взаимодействие клиента с базой может выглядеть следующим образом: `BEGIN; выполнить SELECT; проанализировать результаты SELECT на клиенте; ...; выполнить UPDATE; COMMIT`. Стоит отметить, что если тело транзакции полностью сформировано до обращения к базе данных, то транзакция может обрабатываться эффективнее. - * В {{ ydb-short-name }} не поддерживается возможность смешивать DDL и DML запросы в одной транзакции. Традиционное понятие [ACID]{% if lang == "en" %}(https://en.wikipedia.org/wiki/ACID){% endif %}{% if lang == "ru" %}(https://ru.wikipedia.org/wiki/ACID){% endif %} транзакции применимо именно к DML запросам, то есть к запросам, которые меняют данные. DDL запросы должны быть идемпотентными, то есть повторяемы в случае ошибки. Если необходимо выполнить действие со схемой, то каждое из действий будет транзакционно, а набор действий - нет. - * Реализация YQL в {{ ydb-short-name }} использует механизм [Optimistic Concurrency Control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control). На затронутые в ходе транзакции сущности ставятся оптимистичные блокировки, при завершении транзакции проверяется, что блокировки не были инвалидированы. Оптимистичность блокировок выливается в важное для пользователя свойство — в случае конфликта выигрывает транзакция, которая завершается первой. Конкурирующие транзакции завершатся с ошибкой ```Transaction locks invalidated```. - * Все изменения, производимые в рамках транзакции, накапливаются в памяти сервера базы данных и применяются в момент завершения транзакции. Если взятые блокировки не были инвалидированы, то все накопленные изменения применяются атомарно, если хотя бы одна блокировка была инвалидирована, то ни одно из изменений не будет применено. Описанная схема накладывает некоторые ограничения: объем изменений осуществляемых в рамках одной транзакции должен умещаться в память и транзакция "не видит" своих изменений. +* Допускаются multistatement transactions, то есть транзакции, состоящие из последовательности выражений YQL. При выполнении транзакции допускается взаимодействие с клиентской программой, иначе говоря, взаимодействие клиента с базой может выглядеть следующим образом: `BEGIN; выполнить SELECT; проанализировать результаты SELECT на клиенте; ...; выполнить UPDATE; COMMIT`. Стоит отметить, что если тело транзакции полностью сформировано до обращения к базе данных, то транзакция может обрабатываться эффективнее. +* В {{ ydb-short-name }} не поддерживается возможность смешивать DDL и DML запросы в одной транзакции. Традиционное понятие [ACID]{% if lang == "en" %}(https://en.wikipedia.org/wiki/ACID){% endif %}{% if lang == "ru" %}(https://ru.wikipedia.org/wiki/ACID){% endif %} транзакции применимо именно к DML запросам, то есть к запросам, которые меняют данные. DDL запросы должны быть идемпотентными, то есть повторяемы в случае ошибки. Если необходимо выполнить действие со схемой, то каждое из действий будет транзакционно, а набор действий — нет. +* Реализация YQL в {{ ydb-short-name }} использует механизм [Optimistic Concurrency Control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control). На затронутые в ходе транзакции сущности ставятся оптимистичные блокировки, при завершении транзакции проверяется, что блокировки не были инвалидированы. Оптимистичность блокировок выливается в важное для пользователя свойство — в случае конфликта выигрывает транзакция, которая завершается первой. Конкурирующие транзакции завершатся с ошибкой `Transaction locks invalidated`. +* Все изменения, производимые в рамках транзакции, накапливаются в памяти сервера базы данных и применяются в момент завершения транзакции. Если взятые блокировки не были инвалидированы, то все накопленные изменения применяются атомарно, если хотя бы одна блокировка была инвалидирована, то ни одно из изменений не будет применено. Описанная схема накладывает некоторые ограничения: объем изменений осуществляемых в рамках одной транзакции должен умещаться в память и транзакция «не видит» своих изменений. Следует формировать транзакцию таким образом, чтобы в первой части транзакции выполнялись только чтения, а во второй части транзакции только модификации. Структура запроса тогда выглядит следующим образом: diff --git a/ydb/docs/ru/core/concepts/_includes/ttl.md b/ydb/docs/ru/core/concepts/_includes/ttl.md index c2828bef1f..65590c1261 100644 --- a/ydb/docs/ru/core/concepts/_includes/ttl.md +++ b/ydb/docs/ru/core/concepts/_includes/ttl.md @@ -14,21 +14,23 @@ Момент времени, когда строка таблицы может быть удалена, определяется по следующей формуле: -``` +```text expiration_time = valueof(ttl_column) + expire_after_seconds ``` {% note info %} -Не гарантируется, что удаление произойдет именно в `expiration_time` — оно может случиться позже. Если важно исключить из выборки логически устаревшие, но пока еще физически неудаленные строки, нужно использовать фильтрацию уровня запроса. +Не гарантируется, что удаление произойдет именно в `expiration_time` — оно может случиться позже. Если важно исключить из выборки логически устаревшие, но пока еще физически не удаленные строки, нужно использовать фильтрацию уровня запроса. {% endnote %} Непосредственно удалением данных занимается фоновая операция удаления — *Background Removal Operation* (*BRO*), состоящая из 2 стадий: + 1. Проверка значений в TTL-колонке. -2. Удаление устаревших данных. +1. Удаление устаревших данных. *BRO* обладает следующими свойствами: + * Единицей параллельности является [партиция таблицы](../datamodel.md#partitioning). * Для таблиц со [вторичными индексами](../secondary_indexes.md) стадия удаления является [распределенной транзакцией](../transactions.md#distributed-tx). @@ -41,17 +43,17 @@ expiration_time = valueof(ttl_column) + expire_after_seconds ## Ограничения {#restrictions} * TTL-колонка должна быть одного из следующих типов: - - `Date`; - - `Datetime`; - - `Timestamp`; - - `Uint32`; - - `Uint64`; - - `DyNumber`. + * `Date`; + * `Datetime`; + * `Timestamp`; + * `Uint32`; + * `Uint64`; + * `DyNumber`. * Значение TTL-колонки с числовым типом (`Uint32`, `Uint64`, `DyNumber`) интерпретируется как величина от [Unix-эпохи]{% if lang == "en" %}(https://en.wikipedia.org/wiki/Unix_time){% endif %}{% if lang == "ru" %}(https://ru.wikipedia.org/wiki/Unix-время){% endif %} заданная в: - - секундах; - - миллисекундах; - - микросекундах; - - наносекундах. + * секундах; + * миллисекундах; + * микросекундах; + * наносекундах. * Нельзя указать несколько TTL-колонок. * Нельзя удалить TTL-колонку. Если это все же требуется, сначала нужно [выключить TTL](#disable) на таблице. @@ -59,9 +61,9 @@ expiration_time = valueof(ttl_column) + expire_after_seconds Управление настройками TTL в настоящий момент возможно с использованием: -* [YQL](../../yql/reference/index.md) +* [YQL](../../yql/reference/index.md). * [Консольного клиента {{ ydb-short-name }}](../../reference/ydb-cli/index.md). -* {{ ydb-short-name }} {% if oss %}C++ и{% endif %} Python [SDK](../../reference/ydb-sdk/index.md) +* {{ ydb-short-name }} {% if oss %}C++ и{% endif %} Python [SDK](../../reference/ydb-sdk/index.md). {% note info %} @@ -76,17 +78,21 @@ expiration_time = valueof(ttl_column) + expire_after_seconds {% list tabs %} - YQL + ```yql ALTER TABLE `mytable` SET (TTL = Interval("PT1H") ON created_at); ``` - CLI + ```bash $ {{ ydb-cli }} -e <endpoint> -d <database> table ttl set --column created_at --expire-after 3600 mytable ``` {% if oss == true %} + - C++ + ```c++ session.AlterTable( "mytable", @@ -96,9 +102,11 @@ expiration_time = valueof(ttl_column) + expire_after_seconds .EndAlterTtlSettings() ); ``` + {% endif %} - Python + ```python session.alter_table('mytable', set_ttl_settings=ydb.TtlSettings().with_date_type_column('created_at', 3600)) ``` @@ -118,6 +126,7 @@ expiration_time = valueof(ttl_column) + expire_after_seconds {% list tabs %} - YQL + ```yql CREATE TABLE `mytable` ( id Uint64, @@ -129,7 +138,9 @@ expiration_time = valueof(ttl_column) + expire_after_seconds ``` {% if oss == true %} + - C++ + ```c++ session.CreateTable( "mytable", @@ -141,9 +152,11 @@ expiration_time = valueof(ttl_column) + expire_after_seconds .Build() ); ``` + {% endif %} - Python + ```python session.create_table( 'mytable', @@ -162,17 +175,21 @@ expiration_time = valueof(ttl_column) + expire_after_seconds {% list tabs %} - YQL + ```yql ALTER TABLE `mytable` RESET (TTL); ``` - CLI + ```bash $ {{ ydb-cli }} -e <endpoint> -d <database> table ttl drop mytable ``` {% if oss == true %} + - C++ + ```c++ session.AlterTable( "mytable", @@ -182,9 +199,11 @@ expiration_time = valueof(ttl_column) + expire_after_seconds .EndAlterTtlSettings() ); ``` + {% endif %} - Python + ```python session.alter_table('mytable', drop_ttl_settings=True) ``` @@ -198,19 +217,24 @@ expiration_time = valueof(ttl_column) + expire_after_seconds {% list tabs %} - CLI + ```bash $ {{ ydb-cli }} -e <endpoint> -d <database> scheme describe mytable ``` {% if oss == true %} + - C++ + ```c++ auto desc = session.DescribeTable("mytable").GetValueSync().GetTableDescription(); auto ttl = desc.GetTtlSettings(); ``` + {% endif %} - Python + ```python desc = session.describe_table('mytable') ttl = desc.ttl_settings diff --git a/ydb/docs/ru/core/concepts/cluster/_includes/common_scheme_ydb/nodes.md b/ydb/docs/ru/core/concepts/cluster/_includes/common_scheme_ydb/nodes.md index dc5e52f6fd..d3ba3dcc2d 100644 --- a/ydb/docs/ru/core/concepts/cluster/_includes/common_scheme_ydb/nodes.md +++ b/ydb/docs/ru/core/concepts/cluster/_includes/common_scheme_ydb/nodes.md @@ -1,11 +1,11 @@ -## Узлы +## Узлы {#nodes} -Одна инсталляция {{ ydb-short-name }} состоит из *кластера*, который разбит на *узлы*. Узел -- это один процесс в системе, как правило kikimr. Это узел входит в кластер и может обмениваться данными с другими узлами в этом кластере через *Interconnect*. Каждый *узел* имеет свой идентификатор, который обычно называется NodeId. NodeId -- целое число от 1, состоит из 20 бит. NodeId 0 зарезервирован для внутренних нужд и как правило обозначает текущий узел, либо отсутствие узла. +Одна инсталляция {{ ydb-short-name }} состоит из *кластера*, который разбит на *узлы*. Узел — это один процесс в системе, как правило kikimr. Это узел входит в кластер и может обмениваться данными с другими узлами в этом кластере через *Interconnect*. Каждый *узел* имеет свой идентификатор, который обычно называется NodeId. NodeId — целое число от 1, состоит из 20 бит. NodeId 0 зарезервирован для внутренних нужд и как правило обозначает текущий узел, либо отсутствие узла. На каждом узле выполняется ряд сервисов, реализованных через *акторы*. Узлы могут быть статическими и динамическими. -Конфигурация статических узлов, то есть их полный перечень с указанием адреса для подключения по Interconnect, хранится в конфигурационном файле и вычитывается единожды при запуске процесса. Набор статических узлов меняется очень редко. Как правило, это происходит при расширении кластеров или при переезде узлов с одних физических машин на другие. Для того, чтобы изменить набор статических узлов, нужно разложить на **всех** узлах обновлённую конфигурацию, после чего выполнить rolling restart всего кластера. +Конфигурация статических узлов, то есть их полный перечень с указанием адреса для подключения по Interconnect, хранится в конфигурационном файле и вычитывается единожды при запуске процесса. Набор статических узлов меняется очень редко. Как правило, это происходит при расширении кластеров или при переезде узлов с одних физических машин на другие. Для того, чтобы изменить набор статических узлов, нужно разложить на **всех** узлах обновленную конфигурацию, после чего выполнить rolling restart всего кластера. -Динамические узлы заранее неизвестны и добавляются в систему по мере запуска новых процессов. Это может быть связано, например, с созданием новых тенантов в инсталляциях {{ ydb-short-name }} как БД. При регистрации динамического узла его процесс сначала подключается к одному из статических узлов через gRPC и через специальный сервис, который называется Node Broker, передаёт информацию о себе, получая в ответ NodeId, под которым ему можно будет войти в систему. Механизм назначения узлов во многом похож на DHCP в контексте раздачи IP-адресов. +Динамические узлы заранее неизвестны и добавляются в систему по мере запуска новых процессов. Это может быть связано, например, с созданием новых тенантов в инсталляциях {{ ydb-short-name }} как БД. При регистрации динамического узла его процесс сначала подключается к одному из статических узлов через gRPC и через специальный сервис, который называется Node Broker, передает информацию о себе, получая в ответ NodeId, под которым ему можно будет войти в систему. Механизм назначения узлов во многом похож на DHCP в контексте раздачи IP-адресов. diff --git a/ydb/docs/ru/core/concepts/cluster/_includes/common_scheme_ydb/tablets.md b/ydb/docs/ru/core/concepts/cluster/_includes/common_scheme_ydb/tablets.md index 4de586d864..ae42e4f79f 100644 --- a/ydb/docs/ru/core/concepts/cluster/_includes/common_scheme_ydb/tablets.md +++ b/ydb/docs/ru/core/concepts/cluster/_includes/common_scheme_ydb/tablets.md @@ -1,7 +1,7 @@ -## Таблетки +## Таблетки {#tablets} -На каждом узле выполняются специальные микросервисы, которые называются *таблетками*. Каждая таблетка имеет определённый тип и идентификатор и является singleton'ом, что означает, что в каждый момент времени во всём кластере может работать только одна таблетка с конкретным идентификатором. Таблетка может запускаться на любом из подходящих для неё узлов. Важной характеристикой таблетки является её поколение -- *Generation* -- которое увеличивается при каждом следующем запуске. Стоит отметить, что в силу распределённости системы и наличии различного рода проблем, например, сетевого партиционирования, может сложиться ситуация, когда одна и та же таблетка будет фактически выполняться на двух разных узлах одновременно. Но BlobStorage гарантирует, что только одна из них сможет успешно завершить операции, изменяющие её состояние, и при этом поколение, в котором выполнена каждая успешная операция, не будет убывать со временем. +На каждом узле выполняются специальные микросервисы, которые называются *таблетками*. Каждая таблетка имеет определенный тип и идентификатор и является singleton'ом, что означает, что в каждый момент времени во всем кластере может работать только одна таблетка с конкретным идентификатором. Таблетка может запускаться на любом из подходящих для нее узлов. Важной характеристикой таблетки является ее поколение — *Generation* — которое увеличивается при каждом следующем запуске. Стоит отметить, что в силу распределенности системы и наличии различного рода проблем, например, сетевого партиционирования, может сложиться ситуация, когда одна и та же таблетка будет фактически выполняться на двух разных узлах одновременно. Но BlobStorage гарантирует, что только одна из них сможет успешно завершить операции, изменяющие ее состояние, и при этом поколение, в котором выполнена каждая успешная операция, не будет убывать со временем. Узнать, на каком узле выполняется таблетка в актуальном поколении, можно через сервис *StateStorage*. Для отправки сообщений в таблетку существует специальный набор библиотек, который называется *tablet pipe*. При помощи него, зная идентификатор целевой таблетки, можно легко послать ей нужное сообщение. @@ -9,30 +9,30 @@ Базовая таблетка представляет собой набор таблиц, каждая из которых может состоять из одной или нескольких колонок ключа произвольного типа, а также произвольного набора колонок данных. Каждая таблица может иметь свою схему, кроме того, таблицы можно создавать и удалять в ходе работы таблетки. Интерфейс базовой таблетки позволяет выполнять операции чтения и изменения этих таблиц. -Пользовательская логика находится между базовой таблеткой и пользователем и позволяет обрабатывать специфические запросы для данного типа таблеток, надёжно сохраняя изменения в BlobStorage. Часто используемый шаблон работы таблетки -- хранение всех данных в памяти, вычитка их только на старте и синхронное изменение данных в памяти и в хранилище после успешного коммита. +Пользовательская логика находится между базовой таблеткой и пользователем и позволяет обрабатывать специфические запросы для данного типа таблеток, надежно сохраняя изменения в BlobStorage. Часто используемый шаблон работы таблетки — хранение всех данных в памяти, вычитка их только на старте и синхронное изменение данных в памяти и в хранилище после успешного коммита. -### Как таблетка хранит данные и какие они? +### Как таблетка хранит данные и какие они {#storage} -Базовая таблетка представляет собой LSM-дерево, в котором находятся все данные её таблиц. Уровнем ниже базовой таблетки находится BlobStorage, который, грубо говоря, является KeyValue-хранилищем, в котором лежат блобы. *Блоб* -- это бинарный фрагмент размером от 1 байта до 10 мегабайт, который имеет идентификатор фиксированной структуры (обычно он называется *BlobId* и имеет тип TLogoBlobID) и связанные с ним данные. Хранилище иммутабельное, то есть каждому идентификатору соответствует только одно значение, которое не может меняться со временем. Блоб можно записать, прочитать и затем удалить, когда он станет не нужен. +Базовая таблетка представляет собой LSM-дерево, в котором находятся все данные ее таблиц. Уровнем ниже базовой таблетки находится BlobStorage, который, грубо говоря, является KeyValue-хранилищем, в котором лежат блобы. *Блоб* -- это бинарный фрагмент размером от 1 байта до 10 мегабайт, который имеет идентификатор фиксированной структуры (обычно он называется *BlobId* и имеет тип TLogoBlobID) и связанные с ним данные. Хранилище иммутабельное, то есть каждому идентификатору соответствует только одно значение, которое не может меняться со временем. Блоб можно записать, прочитать и затем удалить, когда он станет не нужен. Подробнее о блобах и распределенном хранилище можно прочитать [здесь](../../distributed_storage.md). -Для BlobStorage блобы являются непрозрачной сущностью. Таблетка может хранить несколько типов блобов. Наиболее часто записываемый блоб -- блоб лога (имеется в виду recovery log, журнал восстановления). Лог таблетки устроен в списка блобов, в каждом из которых содержится информация о вносимом изменении в таблицы. При запуске таблетка находит последний блоб лога, и затем рекурсивно по ссылкам вычитывает все связанные с ним блобы. В логе могут также упоминаться блобы снимков (snapshot) -- это разновидность блобов, которые содержат данные нескольких блобов лога после слияния (операция merge в LSM-дереве). +Для BlobStorage блобы являются непрозрачной сущностью. Таблетка может хранить несколько типов блобов. Наиболее часто записываемый блоб — блоб лога (имеется в виду recovery log, журнал восстановления). Лог таблетки устроен в списка блобов, в каждом из которых содержится информация о вносимом изменении в таблицы. При запуске таблетка находит последний блоб лога, и затем рекурсивно по ссылкам вычитывает все связанные с ним блобы. В логе могут также упоминаться блобы снимков (snapshot) — это разновидность блобов, которые содержат данные нескольких блобов лога после слияния (операция merge в LSM-дереве). Блобы разных типов таблетка пишет в разные *каналы*. Канал указывает ветвь хранилища, в которой следует хранить блобы, и выполняет несколько функций, а именно: -1. Выбор типа хранилища (разные каналы могут быть привязаны к разным типам устройств -- SSD, HDD, NVME). -2. Балансировка нагрузки, т.к. каждый канал имеет лимит от IOPS, доступному месту и пропускной способности. -3. Указание типа данных. При восстановлении лога читаются только блобы из нулевого канала, что позволяет отделить их от прочих блобов. +1. Выбор типа хранилища (разные каналы могут быть привязаны к разным типам устройств — SSD, HDD, NVME). +1. Балансировка нагрузки, т.к. каждый канал имеет лимит от IOPS, доступному месту и пропускной способности. +1. Указание типа данных. При восстановлении лога читаются только блобы из нулевого канала, что позволяет отделить их от прочих блобов. -### История каналов в таблетке +### История каналов в таблетке {#history} -Как уже говорилось, каждая группа имеет фиксированный объём данных, которые в неё могут помещаться, а также делит полосу по пропускной способности и числу операций в секунду между всеми потребителями. Нагрузка на таблетки может меняться, в результате может сложиться так, что группа станет перегруженной. Для этого вводится понятие истории, которое позволяет для каждой таблетки, зная Channel и Generation блоба, определить, в какую группу записан данный блоб. +Как уже говорилось, каждая группа имеет фиксированный объем данных, которые в нее могут помещаться, а также делит полосу по пропускной способности и числу операций в секунду между всеми потребителями. Нагрузка на таблетки может меняться, в результате может сложиться так, что группа станет перегруженной. Для этого вводится понятие истории, которое позволяет для каждой таблетки, зная Channel и Generation блоба, определить, в какую группу записан данный блоб. Иллюстрация работы этого механизма ниже:  -Для каждого канала в структуре TTabletStorageInfo содержится подструктура TTabletChannelInfo, которая содержит диапазоны поколений и номер группы, соответствующий каждому диапазону. Диапазоны строго примыкают друг к другу, последний диапазон открыт. Номера групп могут пересекаться в разных диапазонах и даже между разными каналами -- это не запрещено и достаточно часто встречается. +Для каждого канала в структуре TTabletStorageInfo содержится подструктура TTabletChannelInfo, которая содержит диапазоны поколений и номер группы, соответствующий каждому диапазону. Диапазоны строго примыкают друг к другу, последний диапазон открыт. Номера групп могут пересекаться в разных диапазонах и даже между разными каналами — это не запрещено и достаточно часто встречается. -При выполнении записи блоба таблетка выбирает самый последний диапазон для соответствующего канала, т.к. запись всегда идёт от имени текущего поколения таблетки. При выполнении чтения номер группы извлекается исходя из BlobId.Generation читаемого блоба. +При выполнении записи блоба таблетка выбирает самый последний диапазон для соответствующего канала, т.к. запись всегда идет от имени текущего поколения таблетки. При выполнении чтения номер группы извлекается исходя из BlobId.Generation читаемого блоба. diff --git a/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/detailed_distributed_storage.md b/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/detailed_distributed_storage.md index c344ecc47a..a08f9a4a1a 100644 --- a/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/detailed_distributed_storage.md +++ b/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/detailed_distributed_storage.md @@ -37,12 +37,12 @@ Всю информацию, которая хранится в BS_CONTROLLER можно условно разбить на несколько частей: 1. Настройки BS_CONTROLLER. -2. Конфигурация нижнего уровня (PDisk'и, VDisk'и, группы). -3. Конфигурация верхнего уровня (Box'ы и StoragePool'ы). -4. Runtime-информация (персистентные метрики дисков и групп, состояние скраббинга отдельных VDisk'ов, информация о серийных номерах накопителей на узлах). -5. Логи операций (OperationLog). +1. Конфигурация нижнего уровня (PDisk'и, VDisk'и, группы). +1. Конфигурация верхнего уровня (Box'ы и StoragePool'ы). +1. Runtime-информация (персистентные метрики дисков и групп, состояние скраббинга отдельных VDisk'ов, информация о серийных номерах накопителей на узлах). +1. Логи операций (OperationLog). -Логика работы построена таким образом, что вся информация из таблиц на запуске таблетки BS_CONTROLLER'а загружается в память и хранится там всё время его работы (за исключением OperationLog). При выполнении транзакций информация обновляется в таблицах и в памяти. +Логика работы построена таким образом, что вся информация из таблиц на запуске таблетки BS_CONTROLLER'а загружается в память и хранится там все время его работы (за исключением OperationLog). При выполнении транзакций информация обновляется в таблицах и в памяти. Более подробно таблицы рассматриваются ниже. diff --git a/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/distributed_storage_interface.md b/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/distributed_storage_interface.md index 09ae021e06..305da56bab 100644 --- a/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/distributed_storage_interface.md +++ b/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/distributed_storage_interface.md @@ -4,28 +4,28 @@ Каждый блоб имеет 192-битный идентификатор, состоящий из следующих полей (в порядке, используемом для сортировки): -1. TabletId (64 бита) -- идентификатор таблетки-владельца блоба. -2. Channel (8 бит) -- порядковый номер канала. -3. Generation (32 бита) -- номер поколения, в котором была запущена таблетка, записавшая данный блоб. -4. Step (32 бита) -- внутренний номер группы блобов в рамках Generation. -5. Cookie (24 бита) -- идентификатор, который можно использовать, если Step не хватает. -6. CrcMode (2 бита) -- выбирает режим для избыточного контроля целостности блоба на уровне BlobStorage. -7. BlobSize (26 бит) -- размер данных блоба. -8. PartId (4 бита) -- номер фрагмента при erasure-кодировании блоба; на уровне взаимодействия "BlobStorage <-> таблетка" этот параметр всегда 0, что означает целый блоб. +1. TabletId (64 бита) — идентификатор таблетки-владельца блоба. +2. Channel (8 бит) — порядковый номер канала. +3. Generation (32 бита) — номер поколения, в котором была запущена таблетка, записавшая данный блоб. +4. Step (32 бита) — внутренний номер группы блобов в рамках Generation. +5. Cookie (24 бита) — идентификатор, который можно использовать, если Step не хватает. +6. CrcMode (2 бита) — выбирает режим для избыточного контроля целостности блоба на уровне BlobStorage. +7. BlobSize (26 бит) — размер данных блоба. +8. PartId (4 бита) — номер фрагмента при erasure-кодировании блоба; на уровне взаимодействия «BlobStorage <-> таблетка» этот параметр всегда 0, что означает целый блоб. Два блоба считаются различными, если у их идентификаторов отличается хотя бы один из первых пяти параметров (TabletId, Channel, Generation, Step, Cookie). Таким образом, нельзя записать два блоба, которые различаются только BlobSize и/или CrcMode. Для целей отладки существует строковое форматирование идентификатора блоба, которое имеет взаимодействия `[TabletId:Generation:Step:Channel:Cookie:BlobSize:PartId]`, например, `[12345:1:1:0:0:1000:0]`. -При выполнении записи блоба таблетка выбирает параметры Channel, Step и Cookie. TabletId фиксирован и должен указывать на ту таблетку, которая выполняет запись, а Generation -- на поколение, в котором запущена таблетка, выполняющая операцию. +При выполнении записи блоба таблетка выбирает параметры Channel, Step и Cookie. TabletId фиксирован и должен указывать на ту таблетку, которая выполняет запись, а Generation — на поколение, в котором запущена таблетка, выполняющая операцию. При чтении указывается идентификатор блоба, который может быть произвольным, но желательно ранее записанным. ### Группы -Запись блобов производится в логическую сущность, называемую *группой*. На каждом узле для каждой группы, в которую осуществляется запись, создаётся специальный актор, который называется DS proxy. Этот актор отвечает за выполнение всех операций, связанных с группой. Создание этого актора производится автоматически через сервис NodeWarden, о котором речь пойдёт ниже. +Запись блобов производится в логическую сущность, называемую *группой*. На каждом узле для каждой группы, в которую осуществляется запись, создается специальный актор, который называется DS proxy. Этот актор отвечает за выполнение всех операций, связанных с группой. Создание этого актора производится автоматически через сервис NodeWarden, о котором речь пойдет ниже. -Физически группа представляет собой набор из нескольких физических устройств (блочные устройства в ОС), которые расположены на разных узлах таким образом, чтобы выход из строя одного устройства как можно меньше коррелировал с выходом из строя другого устройства; как правило, эти устройства располагаются в разных стойках или в разных ДЦ. На каждом из этих устройств для группы выделено место, которое управляется специальным сервисом, который называется *VDisk*. Каждый VDisk работает поверх блочного устройства, от которого он отделён другим сервисом -- *PDisk*. Блобы разбиваются на фрагменты в соответствии с *erasure-кодированием*, на VDisk'и пишутся строго фрагменты. Перед разбиванием на фрагменты может выполняться опциональное шифрование данные в группе. +Физически группа представляет собой набор из нескольких физических устройств (блочные устройства в ОС), которые расположены на разных узлах таким образом, чтобы выход из строя одного устройства как можно меньше коррелировал с выходом из строя другого устройства; как правило, эти устройства располагаются в разных стойках или в разных ДЦ. На каждом из этих устройств для группы выделено место, которое управляется специальным сервисом, который называется *VDisk*. Каждый VDisk работает поверх блочного устройства, от которого он отделен другим сервисом — *PDisk*. Блобы разбиваются на фрагменты в соответствии с *erasure-кодированием*, на VDisk'и пишутся строго фрагменты. Перед разбиванием на фрагменты может выполняться опциональное шифрование данные в группе. Схематично это показано на рисунке ниже. @@ -37,25 +37,25 @@  -Каждый VDisk внутри группы имеет порядковый номер, диски нумеруются от 0 и до N-1, где N -- число дисков в группе. +Каждый VDisk внутри группы имеет порядковый номер, диски нумеруются от 0 и до N-1, где N — число дисков в группе. -Кроме того, диски в группе объединены в fail domain'ы, а fail domain'ы объединяются в fail realm'ы. Как правило, каждый fail domain имеет ровно один диск внутри (хотя теоретически возможно и больше, но это не нашло применения в пратике), а несколько fail realm'ов используется только для групп, которые размещают свои данные сразу в трёх ДЦ. Так, каждый VDisk получает помимо порядкового номера в группе идентификатор, который состоит из индекса fail realm'а, индекса fail domain'а внутри fail realm'а и индекса VDisk'а внутри fail domain'а. Этот идентификатор в строковом виде записывается как `VDISK[GroupId:GroupGeneration:FailRealm:FailDomain:VDisk]`. +Кроме того, диски в группе объединены в fail domain'ы, а fail domain'ы объединяются в fail realm'ы. Как правило, каждый fail domain имеет ровно один диск внутри (хотя теоретически возможно и больше, но это не нашло применения в практике), а несколько fail realm'ов используется только для групп, которые размещают свои данные сразу в трех ДЦ. Так, каждый VDisk получает, помимо порядкового номера в группе, идентификатор, который состоит из индекса fail realm'а, индекса fail domain'а внутри fail realm'а и индекса VDisk'а внутри fail domain'а. Этот идентификатор в строковом виде записывается как `VDISK[GroupId:GroupGeneration:FailRealm:FailDomain:VDisk]`. -Все fail realm'ы имеют одинаковое число fail domain'ов, а все fail domain'ы -- одинаковое число дисков внутри. Количество fail realm'ов, количество fail domain'ов внутри fail realm'а и количество дисков внутри fail domain'а образует геометрию группы. Геометрия зависит от способа кодирования данных в группе. Например, для block-4-2 numFailRealms = 1, число numFailDomainsInFailRealm >= 8 (на практике используется только 8), numVDisksInFailDomain >= 1 (на практике строго 1); для mirror-3-dc numFailRealms >= 3, numFailDomainsInFailRealm >= 3, numVDisksInFailDomain >= 1 (используется 3x3x1). +Все fail realm'ы имеют одинаковое число fail domain'ов, а все fail domain'ы — одинаковое число дисков внутри. Количество fail realm'ов, количество fail domain'ов внутри fail realm'а и количество дисков внутри fail domain'а образует геометрию группы. Геометрия зависит от способа кодирования данных в группе. Например, для block-4-2 numFailRealms = 1, число numFailDomainsInFailRealm >= 8 (на практике используется только 8), numVDisksInFailDomain >= 1 (на практике строго 1); для mirror-3-dc numFailRealms >= 3, numFailDomainsInFailRealm >= 3, numVDisksInFailDomain >= 1 (используется 3x3x1). Каждый PDisk имеет идентификатор, который складывается из номера узла, на котором он запущен, а также внутреннего номера PDisk'а внутри этого узла. Как правило, этот идентификатор записывается в виде NodeId:PDiskId, например, 1:1000. Зная идентификатор PDisk'а, можно вычислить сервисный ActorId этого диска и отправить ему сообщение. -Каждый VDisk запущен поверх определённого PDisk'а и имеет *идентификатор слота*, который состоит из трёх полей -- NodeId:PDiskId:VSlotId, а также идентификатор VDisk'а, про который было сказано выше. Строго говоря, есть различные понятия: "слот" -- это место, зарезервированное на PDisk'е, которое занимает VDisk, а также VDisk -- это элемент группы, который занимает определённый слот и выполняет над ним операции. По аналогии с PDisk'ами, зная идентификатор слота, можно вычислить сервисный ActorId запущенного VDisk'а и отправить ему сообщение. Для отправки сообщений из DS proxy в VDisk используется промежуточный актор, который называется *BS_QUEUE*. +Каждый VDisk запущен поверх определенного PDisk'а и имеет *идентификатор слота*, который состоит из трех полей — NodeId:PDiskId:VSlotId, а также идентификатор VDisk'а, про который было сказано выше. Строго говоря, есть различные понятия: «слот» — это место, зарезервированное на PDisk'е, которое занимает VDisk, а также VDisk — это элемент группы, который занимает определенный слот и выполняет над ним операции. По аналогии с PDisk'ами, зная идентификатор слота, можно вычислить сервисный ActorId запущенного VDisk'а и отправить ему сообщение. Для отправки сообщений из DS proxy в VDisk используется промежуточный актор, который называется *BS_QUEUE*. -Состав каждой группы не является фиксированным -- он может меняться в процессе работы системы. Для этого вводится понятие "поколение группы". Каждой паре "GroupId:GroupGeneration" соответствует фиксированный набор слотов (вектор, состоящий из N идентификаторов слотов, где N -- размер группы), в которых расположены данные всей группы. *Не следует путать поколение группы и поколение таблетки -- они никак не связаны*. +Состав каждой группы не является фиксированным — он может меняться в процессе работы системы. Для этого вводится понятие «поколение группы». Каждой паре "GroupId:GroupGeneration" соответствует фиксированный набор слотов (вектор, состоящий из N идентификаторов слотов, где N — размер группы), в которых расположены данные всей группы. *Не следует путать поколение группы и поколение таблетки — они никак не связаны*. -Как правило, группы двух соседних поколений различаются не более, чем на один слот. +Как правило, группы двух соседних поколений различаются не более, чем на один слот. ### Подгруппы -Для каждого блоба вводится специальное понятие *подгруппы* -- это упорядоченное подмножество дисков группы, которое имеет строго фиксированное число элементов, зависящее от типа кодирования (в группе число элементов должно быть не меньше), на котором будут храниться данные этого блоба. Для однодатацентровых групп с обычным кодированием подмножество выбирается как первые N элементов циклической перестановки дисков в группе; перестановка зависит от хэша BlobId. +Для каждого блоба вводится специальное понятие *подгруппы* — это упорядоченное подмножество дисков группы, которое имеет строго фиксированное число элементов, зависящее от типа кодирования (в группе число элементов должно быть не меньше), на котором будут храниться данные этого блоба. Для однодатацентровых групп с обычным кодированием подмножество выбирается как первые N элементов циклической перестановки дисков в группе; перестановка зависит от хэша BlobId. -Каждый диск в подгруппе соответствует диску в группе, но ограничен по допустимым хранимым блобам. Например, для кодирования block-4-2 с с четырьями фрагментами данных и двумя фрагментами чётности (data part, parity part) функциональное назначение дисков в подгруппе следующее: +Каждый диск в подгруппе соответствует диску в группе, но ограничен по допустимым хранимым блобам. Например, для кодирования block-4-2 с с четырьмя фрагментами данных и двумя фрагментами четности (data part, parity part) функциональное назначение дисков в подгруппе следующее: | Номер в подгруппе | Допустимые PartId | |-------------------|-------------------| @@ -69,6 +69,6 @@ | 7 | 1,2,3,4,5,6 | -В данном случае PartId=1..4 соответствует фрагментам данных (которые получаются разрезанием исходного блоба на 4 равные части), а PartId=5..6 -- фрагменты чётности. Диски с номерами 6 и 7 в подгруппе называются *handoff-дисками*. На них могут быть записаны любые фрагменты, в т.ч. несколько штук. На диски 0..5 -- только соответствующие им фрагменты блоба. +В данном случае PartId=1..4 соответствует фрагментам данных (которые получаются разрезанием исходного блоба на 4 равные части), а PartId=5..6 — фрагменты четности. Диски с номерами 6 и 7 в подгруппе называются *handoff-дисками*. На них могут быть записаны любые фрагменты, в т.ч. несколько штук. На диски 0..5 — только соответствующие им фрагменты блоба. -На практике при выполнении записи система пытается положить 6 фрагментов на первые 6 дисков подгруппы и в подавляющем большинстве случаев это проходит успешно. Однако если один из этих дисков недоступен, то операция записи не может завершиться успешно, тогда в работу вступают handoff-диски -- на них отправляются парты тех дисков, которые не ответили вовремя. Может случиться так, что в результате хитрых тормозов и гонок на один handoff уйдёт несколько фрагментов одного блоба. Это допустимо, хотя с точки зрения хранения бессмысленно -- каждый фрагмент должен иметь свой уникальный диск. +На практике при выполнении записи система пытается положить 6 фрагментов на первые 6 дисков подгруппы и в подавляющем большинстве случаев это проходит успешно. Однако если один из этих дисков недоступен, то операция записи не может завершиться успешно, тогда в работу вступают handoff-диски — на них отправляются парты тех дисков, которые не ответили вовремя. Может случиться так, что в результате хитрых тормозов и гонок на один handoff уйдет несколько фрагментов одного блоба. Это допустимо, хотя с точки зрения хранения бессмысленно — каждый фрагмент должен иметь свой уникальный диск. diff --git a/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/intro.md b/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/intro.md index aee5247334..93da4bdf10 100644 --- a/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/intro.md +++ b/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/intro.md @@ -1,5 +1,5 @@ # Дисковая подсистема кластера aka {{ ydb-short-name }} BlobStorage -{{ ydb-short-name }} BlobStorage -- подсистема {{ ydb-short-name }}, которая отвечает за надёжное хранение данных. +{{ ydb-short-name }} BlobStorage — подсистема {{ ydb-short-name }}, которая отвечает за надежное хранение данных. Позволяет хранить *блобы* (бинарный фрагмент размером от 1 байта до 10 мегабайт) c уникальным идентификатором. diff --git a/ydb/docs/ru/core/concepts/cluster/index.md b/ydb/docs/ru/core/concepts/cluster/index.md index 561f540a32..0fdda42554 100644 --- a/ydb/docs/ru/core/concepts/cluster/index.md +++ b/ydb/docs/ru/core/concepts/cluster/index.md @@ -2,6 +2,6 @@ Информация в данном разделе в основном предназначена для администраторов и разработчиков {{ ydb-short-name }}. -В статье ["Общая схема {{ ydb-short-name }}"](common_scheme_ydb.md) представлена общая информация об узлах и таблетках. +В статье [Общая схема {{ ydb-short-name }}](common_scheme_ydb.md) представлена общая информация об узлах и таблетках. -В статье ["Дисковая подсистема кластера"](distributed_storage.md) можно подробнее ознакомиться с особенностями распределенной системы хранения {{ ydb-short-name }}. +В статье [Дисковая подсистема кластера](distributed_storage.md) можно подробнее ознакомиться с особенностями распределенной системы хранения {{ ydb-short-name }}. diff --git a/ydb/docs/ru/core/concepts/index.md b/ydb/docs/ru/core/concepts/index.md index 976f963f23..ae247fd15d 100644 --- a/ydb/docs/ru/core/concepts/index.md +++ b/ydb/docs/ru/core/concepts/index.md @@ -1,4 +1,3 @@ - {% include [concepts/index/intro.md](_includes/index/intro.md) %} {% include [concepts/index/when_use.md](_includes/index/when_use.md) %} diff --git a/ydb/docs/ru/core/concepts/limits-ydb.md b/ydb/docs/ru/core/concepts/limits-ydb.md index 268aa3cd3d..2d0d5adcbd 100644 --- a/ydb/docs/ru/core/concepts/limits-ydb.md +++ b/ydb/docs/ru/core/concepts/limits-ydb.md @@ -1,3 +1 @@ - {% include [limits-ydb.md](_includes/limits-ydb.md) %} - diff --git a/ydb/docs/ru/core/concepts/scan_query.md b/ydb/docs/ru/core/concepts/scan_query.md index eebd21983f..e7e42c4124 100644 --- a/ydb/docs/ru/core/concepts/scan_query.md +++ b/ydb/docs/ru/core/concepts/scan_query.md @@ -1,2 +1 @@ - {% include [scan_query.md](_includes/scan_query.md) %} diff --git a/ydb/docs/ru/core/concepts/secondary_indexes.md b/ydb/docs/ru/core/concepts/secondary_indexes.md index 7a4630af67..a55bcc8a5e 100644 --- a/ydb/docs/ru/core/concepts/secondary_indexes.md +++ b/ydb/docs/ru/core/concepts/secondary_indexes.md @@ -1,3 +1 @@ - {% include [secondary_indexes.md](_includes/secondary_indexes.md) %} - diff --git a/ydb/docs/ru/core/concepts/serverless_and_dedicated.md b/ydb/docs/ru/core/concepts/serverless_and_dedicated.md index 103bfc35cf..a80ceb2658 100644 --- a/ydb/docs/ru/core/concepts/serverless_and_dedicated.md +++ b/ydb/docs/ru/core/concepts/serverless_and_dedicated.md @@ -1,6 +1,5 @@ - {% include [intro.md](_includes/serverless_and_dedicated/01_intro.md) %} {% include [sls_pars.md](_includes/serverless_and_dedicated/02_sls_pars.md) %} -{% include [arch_diff.md](_includes/serverless_and_dedicated/10_arch_diff.md) %}
\ No newline at end of file +{% include [arch_diff.md](_includes/serverless_and_dedicated/10_arch_diff.md) %} diff --git a/ydb/docs/ru/core/concepts/transactions.md b/ydb/docs/ru/core/concepts/transactions.md index b2cf914638..01e3c32a82 100644 --- a/ydb/docs/ru/core/concepts/transactions.md +++ b/ydb/docs/ru/core/concepts/transactions.md @@ -1,3 +1 @@ - {% include [transactions.md](_includes/transactions.md) %} - diff --git a/ydb/docs/ru/core/concepts/ttl.md b/ydb/docs/ru/core/concepts/ttl.md index 11c1812deb..65436fe5e8 100644 --- a/ydb/docs/ru/core/concepts/ttl.md +++ b/ydb/docs/ru/core/concepts/ttl.md @@ -1,2 +1 @@ - {% include [ttl.md](_includes/ttl.md) %} diff --git a/ydb/docs/ru/presets.yaml b/ydb/docs/ru/presets.yaml new file mode 100644 index 0000000000..ea35f4b81b --- /dev/null +++ b/ydb/docs/ru/presets.yaml @@ -0,0 +1,3 @@ +default: + lang: ru + link-console-main: https://console.cloud.yandex.ru |