Comments 16
Спасибо за статью! В чём именно вы видите основную пользу от внедрения HDRF в контексте YDB и насколько ощутимый буст это может дать в общем?
Спасибо за вопрос. Сейчас используется алгоритм который пересчитывает лимиты в зависимости от того используют конкретный Resource Pool или нет. Соответственно он выступает как некоторый лимитер из-за чего может не достигаться 100% утилизация cpu, если один пул перегружен, а второй недогружен, то перераспределения ресурсов между Resource Pool'ами не произойдет, при этом такой подход обладает минимальными накладными расходами. После перехода на HDRF будет честное распределение ресурсов между пулами в соответствии с весами, что позволит достигать 100% утилизации cpu, также это позволит строить иерархически пулы ресурсов и по предварительным результатам накладные расходы незначительно больше чем у подхода через лимитер.
@dorooleg Ты пишешь, что для обработки каждого запроса от пользователя используется много акторов, которые выполняются на разных серверах.
А что будет, если один из серверов перезагрузится и те акторы, которые на нем выполнялись, перестанут существовать? YDB их пересоздаст и продолжит выполенние запроса? Или YDB ответит SDK что запрос прерван "по техническим причинам" и SDK перезапустит запрос? Или пользователь получит ошибку "что-то пошло не так, не смогли выполнить запрос"?
Здесь может быть две глобальных ситуации:
Если перезагрузился сервер на котором жили только специальные акторы, которые называются таблетками (они фактически отвечают за хранение и чтение некоторой части таблицы). В этом случае произойдет переезд таблеток на другие сервера и запрос продолжит свое выполнение (случай "YDB их пересоздаст и продолжит выполение запроса")
Если же перезагрузится сервер на котором были compute акторы, то в этом случае SDK получит ошибку и поретраит запрос (случай YDB ответит SDK что запрос прерван "по техническим причинам" и SDK перезапустит запрос). Но если такое будет происходить часто, то в SDK после некоторого числа срабатываний будет отправлена ошибка пользователю (случай "что-то пошло не так, не смогли выполнить запрос"). Подробнее про error handling можно посмотреть в документации https://ydb.tech/docs/ru/reference/ydb-sdk/error_handling
Получается что все три варианта возможны
А разве не лучше было бы ретрай делать на уровне базы данных, а не на уровне клентсого SDK? У тебя тысяча акторов 10 минут выполняли аналитический запрос, почти закончили. И тут один из акторов прекратил свое существование, потому что сервер перезагрузился. Разве не лучше пересоздать этот один актор и продолжить выполнение запроса?
Да, действительно такой подход будет лучше работать, но он сложнее в реализации. Некоторые compute акторы накапливают состояние, например Join, TopSort, Aggregation и если такой актор упадет, то при переподнятии ему нужно будет как-то получить обратно это состояние, в этом случае можно либо прогнать часть вычислений заново или же персистить некоторые шаги. Это важно делать в случае транзакционных баз данных, иначе можно получить не корректные результаты в транзакциях. Но мы будем двигаться в эту сторону.
Интересная статья, спасибо!
Я работаю только со строковыми таблицами, колоночные нужны для быстрой аналитики по тем же данным. Как эти колоночные таблицы правильно создавать и синхронизировать в YDB? База данных сама их может поддерживать?
Для решения этой задачи существует механизм трансфера. Находимся на финишной прямой к его включению. Ознакомиться с draft документации можно по этой ссылке https://ydb-platform--ydb.viewer.diplodoc.com/ru/concepts/transfer?revision=pr-20816-8de83c1f4a9db380281f6a05a7fefbe904fd738b
Одно из основных требований к YDB — бесконечная линейная горизонтальная масштабируемость. ..... Линейная — значит прирост производительности пропорционален числу добавленных машин.
Ну и как удалось достичь линейности? Вы это как то измеряете и видите что линейность имеет место быть?
На самых крупных кластерах YDB больше 10k хостов на которых проверяется это свойство. Также в статье https://habr.com/ru/companies/ydb/articles/801587/ можно найти результаты экспериментов
Шрафик "Масштабируемость YDB, tpmC" показывает что на трех машинах на каждую машину пришлось 67606 tpmC, на 9 - 56120, на 18 - 48532, и на 36 - 40201.
Если бы рост производительности был бы линейным то на 36 машинах должно было быть как минимум 2433816. Т.е. получается что 36 машин обеспечивают рост как минимум на 41% меньше линейной зависимости. Как минимум потому что не известно сколько было бы на одной машине в этом тесте.
Ну а вообще то график выглядит как бы линейным. Но это лишь "как бы".
Даже на уровне здравого смысла в таких архитектурах не может быть линейной зависимости производительности от количества машин. Издержки на координацию машин растут и ресурс на обслуживание координации растет, причем тоже не линейно, а с неким ускорением.
Чудес не быват. К счастью.
Статья называется:
Как YDB изолирует OLTP и OLAP
Вот все что можно было бы отнести к раскрытию этой тему:
Менеджер смешанной нагрузки — один из механизмов высокого уровня, позволяющих распределять нагрузку так, как нужно пользователям YDB. Если этого не делать, то даже одного OLAP запроса может быть достаточно, чтобы нагрузить любой кластер и заметно снизить его способность к обработке большого потока OLTP-запросов.
......
Особенно опасна для кластера аналитическая нагрузка. OLAP-запросы часто выполняются над огромными таблицами и содержат десятки JOIN. Для их выполнения YDB создаёт много акторов-тасок, которые обмениваются сообщениями с акторами-таблетками. И чем больше данных нужно обработать — тем больше таких сообщений. Если никак не управлять нагрузкой на кластер, то запущенный аналитический запрос способен понизить RPS для всей остальной OLTP-нагрузки.
......
Для каждого актора замеряется время выполнения кода обработки сообщений и занимаемая ими память. Основываясь на заданных пользователем ограничениях, YDB может вызывать код актора чаще или реже. Или вообще перестать создавать новые акторы, если превышена квота по использованию памяти.
.....
Настройки балансировки задаются для пулов ресурсов, и YDB автоматически выбирает один из пулов для каждого запроса. Пул выбирается по пользователю, который сделал запрос. А если пользователь находится в списках разных пулов, YDB выбирает тот из них, ранг которого минимален (чем меньше числовое значение ранга — тем выше его приоритет).
....
Менеджер смешанной нагрузки по алгоритму Max-min Fairness определяет, может ли актор выполняться. И если не может — то актор отправляет сам себе сообщение, чтобы движок через нужное время снова вызвал обработчик и актор мог повторить попытку.
Так, синхронизируя ключевую информацию между узлами слоя вычисления и ставя на паузу акторы-таски, YDB управляет OLAP и OLTP-нагрузкой кластера.
Более менее понятно что менеджер смешанной нагрузки в состоянии "сдерживать" тех илил иных акторов используя статискику выполнения и ограничения.
Это интересно, но складывается впечатление что ответственность за правильную конфигурацию пулов и ограничений несет пользователь. Иначе говоря разделение нагрузкаи OLAP и OLTP это не функция YD, это задача пользователя и от того насколько пользователь удачно смог сконфигурировать YDB будет определяться успех "изоляции" одного от другого.
Или я не понял Вас?
Вопрос: В теории БД есть два варианта (architecture) кластеризации БД: 1. Shared-nothing architecture и 2. Shared-disk (everything) architecture. К какову из этих двух вариантов относится распределенная БД YDB?
Спасибо.
Спасибо за вопросы!
1. Workload Manager не про тюнинг настроек, поэтому "удачная конфигурация" не совсем применимо в этом случае. Здесь именно настройка со стороны пользователя, которая позволяет распределять ресурсы между разными задачами. Похожие решения существуют в других базах данных Greenplum, Teradata, Synapse Analytics и другие
2. YDB относится к shared nothing архитектуре, подробнее про архитектуру YDB можно почитать в документации https://ydb.tech/docs/ru/concepts/
Cпасибо за ответы.
Здесь именно настройка со стороны пользователя, которая позволяет распределять ресурсы между разными задачами.
Вот именно это я и имел в виду. Все зависит от того чему и сколько пользователь дал ресурсов.
Причем по достижению назначенного ресурса актор-таска уходит за печку. В z/OS Workload Manager 'то называется Discretionary (по усмотрению), и является самым низшим типм цели в Service Class. А еще в Service Class есть другие типы, есть периоды с продолжительностью, выражаемой количеством ресурсов потребленным просессом.
Это я описывал в моей статье "Чем различаются ОС IBM мейнфрейм и ОС х86" https://habr.com/ru/articles/926352/ ближе к концу.
Есть масса информации на интернете про z/OS WLM в том чмсле о том как этот WLM используется для управления ресурсами как самой базы данных DB2 for z/OS так и процессами в ней.
Конечно Вы не будете использовать ни z/OS WLM ни DB2 for z/OS, но их концепсии и принципы работы наверняка помогут Вам лучше понять как это должно делаться на самом деле. Я имею в виду общую тему Workload Manager. Не уверен что на платформе х86 Вам удастся реализовать что-то подобное, но вот для DB2 for LUW ИБМ что-то такое реализовал (наверняка имея в виду z/OS WLM):
https://www.ibm.com/docs/en/db2/11.1.0?topic=administration-db2-workload-manager
Как YDB изолирует OLTP и OLAP