какого рода вычислительная нагрузка на брокерах, что она может быть "повышенной"
Брокер сообщений выполняет множество вычислительно сложных операций: общение с писателями/читателями (терминация SSL, аутентификация, прием/отправка сообщений, подтверждение сообщений, буферизация, дедупликация), общение с другими брокерами (репликация), и на конец - запись на диск.
чем принципиально отличается добавление узлов Bookeeper от добавления узла Kafka
Добавление брокера в Kafka сильно сложнее, чем в Pulsar. Основная причина: данные партиций лежат прямо на брокерах и при увеличении числа брокеров данные нужно перебалансировать. Процесс переноса партиций между брокерами в Kafka называется partition reassignment и требует полного копирования данных затрагиваемых партиций.
что является ключом, что является значением, хранится в памяти или на диске и в каком виде.
В статье есть: Ключом является уникальный номер пачки, а значением множество сообщений. При записи свежие сообщения объединяются в пачку, на базе смещения формируется ключ, и эта пара отправляется в Key‑Value хранилище. При чтении, наоборот.
Выделенный слой хранения дает возможным независимо изменять число брокеров Pulsar и узлов хранения Bookeeper. Если повышенная вычислительная нагрузка на брокеры, то можно увеличить число узлов Pulsar. Если не хватает места на диске для требуемых гарантий времени хранения (retention), то можно увеличить число узлов Bookeeper. В Kafka такой гибкости не хватает, так как хранение данных производится непосредственно на брокерах. Добавил в тексте.
В результатах профайлера видно функцию TBatch::Serialize, внутри которой есть std::copy и memmove. Именно на это мы обратили внимание и пошли смотреть исходный код. А там уже нашли и убрали лишние склеивания строк.
У нас есть команда CLI для просмотра списка объектов: https://ydb.tech/docs/ru/reference/ydb-cli/commands/scheme-ls
А также есть команда для получения информации об объекте схемы: https://ydb.tech/docs/ru/reference/ydb-cli/commands/scheme-describe
Брокер сообщений выполняет множество вычислительно сложных операций: общение с писателями/читателями (терминация SSL, аутентификация, прием/отправка сообщений, подтверждение сообщений, буферизация, дедупликация), общение с другими брокерами (репликация), и на конец - запись на диск.
Добавление брокера в Kafka сильно сложнее, чем в Pulsar. Основная причина: данные партиций лежат прямо на брокерах и при увеличении числа брокеров данные нужно перебалансировать. Процесс переноса партиций между брокерами в Kafka называется partition reassignment и требует полного копирования данных затрагиваемых партиций.
В статье есть:
Ключом является уникальный номер пачки, а значением множество сообщений.
При записи свежие сообщения объединяются в пачку, на базе смещения формируется ключ, и эта пара отправляется в Key‑Value хранилище. При чтении, наоборот.
Ряд дополнительных подробностей про YBD Topics можно найти тут https://ydb.tech/docs/ru/concepts/topic
Выделенный слой хранения дает возможным независимо изменять число брокеров Pulsar и узлов хранения Bookeeper. Если повышенная вычислительная нагрузка на брокеры, то можно увеличить число узлов Pulsar. Если не хватает места на диске для требуемых гарантий времени хранения (retention), то можно увеличить число узлов Bookeeper. В Kafka такой гибкости не хватает, так как хранение данных производится непосредственно на брокерах. Добавил в тексте.
Действительно, "прокси отвечает", поправил, спасибо.
В результатах профайлера видно функцию TBatch::Serialize, внутри которой есть std::copy и memmove. Именно на это мы обратили внимание и пошли смотреть исходный код. А там уже нашли и убрали лишние склеивания строк.