Как стать автором
Поиск
Написать публикацию
Обновить

Как мы повышали производительность очереди сообщений

Время на прочтение14 мин
Количество просмотров12K
Всего голосов 30: ↑30 и ↓0+37
Комментарии15

Комментарии 15

это основное конкурентное преимущество по сравнению с Kafka, так как выделенный слой хранения существенно упрощает масштабирование и отказоустойчивость

Нет никакой связи между выделенностью и упрощением

Когда SDK обращается к прокси, оно спрашивает, где находится интересующая её партиция. А SDK отвечает,что партиция находится на таком‑то узле

Наверное, хотели написать "А прокси отвечает". И вообще оно тут уже не прокси, ибо перестаёт пропускать трафик сквозь себя, это редиректор.

По стеку вызовов видно, что внутри функции TBatch::Serialize много времени тратится на лишнее копирование строки

по стеку не видно, что оно лишнее

Выделенный слой хранения дает возможным независимо изменять число брокеров Pulsar и узлов хранения Bookeeper. Если повышенная вычислительная нагрузка на брокеры, то можно увеличить число узлов Pulsar. Если не хватает места на диске для требуемых гарантий времени хранения (retention), то можно увеличить число узлов Bookeeper. В Kafka такой гибкости не хватает, так как хранение данных производится непосредственно на брокерах. Добавил в тексте.

Действительно, "прокси отвечает", поправил, спасибо.

В результатах профайлера видно функцию TBatch::Serialize, внутри которой есть std::copy и memmove. Именно на это мы обратили внимание и пошли смотреть исходный код. А там уже нашли и убрали лишние склеивания строк.

Наверное, из моего предыдущего комментария не очень понятно, что моя основная претензия к статье - её излишняя краткость, из-за чего она изобилует громкими утверждениями, которым не хватает обоснований.

По комментарию: не могли бы вы, пожалуйста, рассказать, какого рода вычислительная нагрузка на брокерах, что она может быть "повышенной"? Я бы предположил (в случае с Kafka), что они пишут байты на диск и отсылают байты на другие узлы кластера, то есть упираются в диск и сеть. При этом чем принципиально отличается добавление узлов Bookeeper от добавления узла Kafka? И там, и там нужна железка и процесс.

И ещё, если у вас есть возможность дополнять статью, не могли бы вы развернуть самый важный, и при этом самый короткий пункт "Почему именно YDB Platform". Нифига не понятно, зачем KeyValue. Вот для файла-журнала есть отличная и простая модель: непрерывный файл, сообщение адресуется смещением в этом файле, при последовательном чтении сообщений мы автоматически получаем смещение каждого следующего сообщения и возвращаем его. Про ваше KeyValue ничего не понятно: что является ключом, что является значением, хранится в памяти или на диске и в каком виде.

какого рода вычислительная нагрузка на брокерах, что она может быть "повышенной"

Брокер сообщений выполняет множество вычислительно сложных операций: общение с писателями/читателями (терминация SSL, аутентификация, прием/отправка сообщений, подтверждение сообщений, буферизация, дедупликация), общение с другими брокерами (репликация), и на конец - запись на диск.

чем принципиально отличается добавление узлов Bookeeper от добавления узла Kafka

Добавление брокера в Kafka сильно сложнее, чем в Pulsar. Основная причина: данные партиций лежат прямо на брокерах и при увеличении числа брокеров данные нужно перебалансировать. Процесс переноса партиций между брокерами в Kafka называется partition reassignment и требует полного копирования данных затрагиваемых партиций.

что является ключом, что является значением, хранится в памяти или на диске и в каком виде.


В статье есть:
Ключом является уникальный номер пачки, а значением множество сообщений.
При записи свежие сообщения объединяются в пачку, на базе смещения формируется ключ, и эта пара отправляется в Key‑Value хранилище. При чтении, наоборот.

Ряд дополнительных подробностей про YBD Topics можно найти тут https://ydb.tech/docs/ru/concepts/topic

Давно слежу за этим продуктом, выглядит очень вкусно.
Но!
Когда вы сделаете справку в ydb cli (консольном)? О.о
Банально попробовал "быстрый старт" и не смог через cli даже посмотреть список баз и таблиц, точно через web-ui... o.O

У нас есть команда CLI для просмотра списка объектов: https://ydb.tech/docs/ru/reference/ydb-cli/commands/scheme-ls
А также есть команда для получения информации об объекте схемы: https://ydb.tech/docs/ru/reference/ydb-cli/commands/scheme-describe

Т.е. чтобы найти нужную команду в интерактивном cli, вы предлагаете сходить в доку на сайте?

Есть несколько способов найти нужную команду в CLI. Если есть какая-то ключевая фраза, проще всего найти команду в документации.

В самом CLI удобно пользоваться опцией --help, которая есть у каждой команды. Структура команд CLI древовидная. Можно выполнить ydb --help и посмотреть список её подкоманд. Полное дерево команд из этого вывода мы убрали, т.к. оно было слишком громоздким. Но по текущему списку с описанием каждой подкоманды можно быстро найти подходящий раздел и посмотреть справку по нему. Например, ydb scheme --help покажет уже такое дерево:

scheme                      Scheme service operations

├─ describe                 Show information about object at given object

├─ ls                       Show information about objects inside given directory

├─ mkdir                    Make directory

├─ permissions              Modify permissions

└─ rmdir                    Remove directory

И так далее по дереву.

Указание --help по конечной команде покажет описание самой команды и все доступные опции с их описанием.

Думаем также также про auto-complete, но в ближайших планах его пока нет. Это уже скорее дополнительное удобство при использовании, когда примерно знаешь, что ищешь.

Для ознакомления с функционалом я бы все-таки рекомендовал смотреть --help команд

bash-completion нет?

Сейчас нет. Есть планы на автокомплит, причём тут можно выделить 3 задачи:

  • Подстановка дочерних подкоманд

  • Подстановка в конечных командах. Тут у каждой команды свой сценарий. Пути схемы, имя профиля и т.д.

  • Автокомплит в интерактивном CLI. Это вообще отдельная история, основная на YQL грамматике.

    Все пункты надеемся реализовать, сроков пока нет.

Статья занимательная, спасибо автору! Приятно видеть, что приводятся данные тестирования:)
Инструмент на рынке "очередей сообщений" новый и интересно узнать про проблемы и подводные камни, которые зафиксировала команда разработки или пользователи продукта. Спасибо!

В топиках поддерживается сжатие. А когда оно будет доступно в YDB CDC?

Мы думали об этом, но это требует отдельных экспериментов по влиянию сжатия на производительность YDB CDC. Надеемся в какой-то момент реализовать.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий