Комментарии 24
В рамках одной транзакции можно записать сообщение и в таблицу и в топик?
Мы туда идем. Сделали транзакционное чтение из топиков и запись в таблицы (сценарий процессинга данных из топиков), сейчас пишем код по транзакционной записи в топики (сценарий стриминга изменений наружу).
А у вас в каком сценарии нужно писать и в таблицу и в топик в одной транзакции?
Смотрю в сторону упрощения паттерна Transactional outbox.
Изменили сущность в БД, гарантировано отправили доменное событие в шину
Насколько я понял эти же топики используются для репликации, соответственно можно ваше приложение как реплику подключить и гарантировано получить доменное событие. Подключаться можно как по пропиетарному протоколу, так и используя kafka-клиент.
CDC не рассматривали как вариант? Вроде бы делает то что вы ожидаете
2 HDD (система, логи);
4 NVME (данные).
А из каких соображений система находится на HDD, а не на NVME?
Имха, система и софт грузятся один раз в память, потом это условно работает несколько миллиардов лет, пока не помрет или не перезагрузится. Зачем там НВМЕ? Для логов 100Мб/с (если это бюджетные диски, но что-то сомневаюсь) потоковой записи вполне должно хватить. Не?
В настоящее время скорость физических операций на дисках HDD достигает 200–300 МБ/с, а на дисках SSD — 600–700 МБ/с. Интерфейс имеет более высокую пропускную способность, что позволяет контроллеру кэшировать и буферизировать обрабатываемые данные. (гугл нарисовал на вопрос)
А рандом там особо не нужен...
У меня есть сомнения, что линукс (если это он) грузится один раз в память. Если только они не разворачивают виртуальный ram-диск. Но вроде бы как память сервера можно использовать более производительно.
Там нужно по сути ядро + один процесс. Уверен, что процесс лочится в памяти с помощью mlock и больше не выгружается на диск.
Если ограничиться одним монолитным процессом, что трудно представимо для сложной системы. Скрипты, в частности, не использовать.
Скрипты в Яндексе тоже любят собирать в монобинарь(по крайней мере Питон).
Линукс не дурак и отлично мапит в память все файлы, к которым обращался. И на самом деле система действительно грузится один раз, дальше могут какие-то вспомогательные скрипты или команды загружаться, но нет ничего страшного если они будут аж 100 мс грузиться. Самое главное, что HDD надёжнее NVME в таких сценариях, реже требует замены и сильно дешевле. В масштабах Яндекса должно прямо заметно выходить.
Да, все так. Плюс технически не во все сервера возможна установка 6 NVME, а хочется работать плюс-минус на commodity серверах
Я с посылом не спорю, но отмечу что 600-700МБ/сек для SSD это устаревшая информация. Диски для PCIe 5.0 умеют больше 13000МБ/сек.
Del
А™зачем® так™ много® трейдмарок™? Вы же их не продаёте тут.
У меня на прошлой работе, тоже гигантские обьемы были и я предлагал на митапе тоже самое - отдельную шину данных на аппаратном уровне, но меня никто не поддержал. Аргумент против - что не истратили полностью ресурсы оптимизации. И вот Яндекс это реализовал. А могли бы мы сами сделать и с Яндексом поделиться (уже готовой технологией). Почему никто не смотрит в будущее?
Если выпивать 50 грамм каждый раз, когда в тексте встречается
Kafka®
, то можно неплохо надраться.
Зачастую в этой роли используется система типа Apache ZooKeeper™, которая отвечает за выбор лидера, а затем поступившие данные переносятся на узел хранения с помощью внутренних механизмов репликации.
ZooKeeper еще в версии 2.8 заменили на Metadata Quorum
20 петабайт на нвме? Богато живете
Как Яндекс создал свою шину данных, чтобы передавать сотни гигабайт в секунду