Как стать автором
Обновить

Как Яндекс создал свою шину данных, чтобы передавать сотни гигабайт в секунду

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров40K
Всего голосов 52: ↑51 и ↓1+70
Комментарии24

Комментарии 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МБ/сек.

Ну в этой цитате гугла смысл был больше в том, что ХДД тоже не так уж и плохи при последовательном доступе. Они сильно проигрывают по IOPS, что для логов - текстовый поток данных - малоактуально.

Я именно потому и написал, что с посылом не спорю, просто уточняю некоторые фактические неточности в самой цитате.

А™зачем® так™ много® трейдмарок™? Вы же их не продаёте тут.

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

А могли бы мы сами сделать и с Яндексом поделиться (уже готовой технологией)

Оно ему зачем? Или вы б сделали нечто, что 100500 звезд и форков на гитлабе имело бы? А, если нет, то, зачем брать чужой код, где ещё хз, сколько багов и сколько под себя допиливать?

Если выпивать 50 грамм каждый раз, когда в тексте встречается

Kafka®

, то можно неплохо надраться.

750 грамм в одно лицо как никак.

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

ZooKeeper еще в версии 2.8 заменили на Metadata Quorum

20 петабайт на нвме? Богато живете

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