Спасибо за вопросы! 1. Workload Manager не про тюнинг настроек, поэтому "удачная конфигурация" не совсем применимо в этом случае. Здесь именно настройка со стороны пользователя, которая позволяет распределять ресурсы между разными задачами. Похожие решения существуют в других базах данных Greenplum, Teradata, Synapse Analytics и другие 2. YDB относится к shared nothing архитектуре, подробнее про архитектуру YDB можно почитать в документации https://ydb.tech/docs/ru/concepts/
Да, действительно такой подход будет лучше работать, но он сложнее в реализации. Некоторые compute акторы накапливают состояние, например Join, TopSort, Aggregation и если такой актор упадет, то при переподнятии ему нужно будет как-то получить обратно это состояние, в этом случае можно либо прогнать часть вычислений заново или же персистить некоторые шаги. Это важно делать в случае транзакционных баз данных, иначе можно получить не корректные результаты в транзакциях. Но мы будем двигаться в эту сторону.
Если перезагрузился сервер на котором жили только специальные акторы, которые называются таблетками (они фактически отвечают за хранение и чтение некоторой части таблицы). В этом случае произойдет переезд таблеток на другие сервера и запрос продолжит свое выполнение (случай "YDB их пересоздаст и продолжит выполение запроса")
Если же перезагрузится сервер на котором были compute акторы, то в этом случае SDK получит ошибку и поретраит запрос (случай YDB ответит SDK что запрос прерван "по техническим причинам" и SDK перезапустит запрос). Но если такое будет происходить часто, то в SDK после некоторого числа срабатываний будет отправлена ошибка пользователю (случай "что-то пошло не так, не смогли выполнить запрос"). Подробнее про error handling можно посмотреть в документации https://ydb.tech/docs/ru/reference/ydb-sdk/error_handling
Спасибо за вопрос. Сейчас используется алгоритм который пересчитывает лимиты в зависимости от того используют конкретный Resource Pool или нет. Соответственно он выступает как некоторый лимитер из-за чего может не достигаться 100% утилизация cpu, если один пул перегружен, а второй недогружен, то перераспределения ресурсов между Resource Pool'ами не произойдет, при этом такой подход обладает минимальными накладными расходами. После перехода на HDRF будет честное распределение ресурсов между пулами в соответствии с весами, что позволит достигать 100% утилизации cpu, также это позволит строить иерархически пулы ресурсов и по предварительным результатам накладные расходы незначительно больше чем у подхода через лимитер.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Спасибо за вопросы!
1. Workload Manager не про тюнинг настроек, поэтому "удачная конфигурация" не совсем применимо в этом случае. Здесь именно настройка со стороны пользователя, которая позволяет распределять ресурсы между разными задачами. Похожие решения существуют в других базах данных Greenplum, Teradata, Synapse Analytics и другие
2. YDB относится к shared nothing архитектуре, подробнее про архитектуру YDB можно почитать в документации https://ydb.tech/docs/ru/concepts/
На самых крупных кластерах YDB больше 10k хостов на которых проверяется это свойство. Также в статье https://habr.com/ru/companies/ydb/articles/801587/ можно найти результаты экспериментов
Да, действительно такой подход будет лучше работать, но он сложнее в реализации. Некоторые compute акторы накапливают состояние, например Join, TopSort, Aggregation и если такой актор упадет, то при переподнятии ему нужно будет как-то получить обратно это состояние, в этом случае можно либо прогнать часть вычислений заново или же персистить некоторые шаги. Это важно делать в случае транзакционных баз данных, иначе можно получить не корректные результаты в транзакциях. Но мы будем двигаться в эту сторону.
Для решения этой задачи существует механизм трансфера. Находимся на финишной прямой к его включению. Ознакомиться с draft документации можно по этой ссылке https://ydb-platform--ydb.viewer.diplodoc.com/ru/concepts/transfer?revision=pr-20816-8de83c1f4a9db380281f6a05a7fefbe904fd738b
Здесь может быть две глобальных ситуации:
Если перезагрузился сервер на котором жили только специальные акторы, которые называются таблетками (они фактически отвечают за хранение и чтение некоторой части таблицы). В этом случае произойдет переезд таблеток на другие сервера и запрос продолжит свое выполнение (случай "YDB их пересоздаст и продолжит выполение запроса")
Если же перезагрузится сервер на котором были compute акторы, то в этом случае SDK получит ошибку и поретраит запрос (случай YDB ответит SDK что запрос прерван "по техническим причинам" и SDK перезапустит запрос). Но если такое будет происходить часто, то в SDK после некоторого числа срабатываний будет отправлена ошибка пользователю (случай "что-то пошло не так, не смогли выполнить запрос"). Подробнее про error handling можно посмотреть в документации https://ydb.tech/docs/ru/reference/ydb-sdk/error_handling
Получается что все три варианта возможны
Спасибо за вопрос. Сейчас используется алгоритм который пересчитывает лимиты в зависимости от того используют конкретный Resource Pool или нет. Соответственно он выступает как некоторый лимитер из-за чего может не достигаться 100% утилизация cpu, если один пул перегружен, а второй недогружен, то перераспределения ресурсов между Resource Pool'ами не произойдет, при этом такой подход обладает минимальными накладными расходами. После перехода на HDRF будет честное распределение ресурсов между пулами в соответствии с весами, что позволит достигать 100% утилизации cpu, также это позволит строить иерархически пулы ресурсов и по предварительным результатам накладные расходы незначительно больше чем у подхода через лимитер.