[Перевод] Как Uber масштабировал репликацию данных, чтобы ежедневно перемещать петабайты

Uber держит огромные объёмы данных сразу в своих дата-центрах и в облаке, поэтому их нужно постоянно и быстро копировать между регионами для аналитики и аварийного восстановления. Когда объём таких копирований вырос до петабайта в день, оказалось, что система тормозит не на самой передаче данных, а на подготовке задач и служебных накладных расходах. Команда переработала процесс так, чтобы тяжелая подготовительная рутина выполнялась ближе к месту запуска задач, а ключевые этапы шли параллельно. Для маленьких копирований они убрали лишние запуски отдельных процессов/контейнеров, чтобы не тратить время на старт пустой работы. В итоге пропускная способность репликации выросла примерно в 5 раз и стала стабильнее, а перенос данных в облако пошёл заметно быстрее

https://habr.com/ru/articles/996726/

#uber #system_design #it #data #data_analysis #high_performance #performance

Сравнительный обзор механизмов polling в Kafka и Pub/Sub в RabbitMQ: особенности и области применения

Друзья, привет! Меня зовут Андрей Комягин, я CTO компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей, включая налоговое администрирование, телеком, track & trace и многие другие. В своих проектах и архитектурах мы широко применяем open-source-решения, включая брокеры сообщений, такие как Kafka и RabbitMQ. Совсем недавно я выступил на конференции HighLoad++ Genesis 2025: рассказал про анатомию каждого из этих брокеров, сравнил их по набору критериев и оценил результаты их нагрузочного тестирования. А теперь решил выпустить этот материал в виде статьи в блоге, чтобы читатели Хабра тоже смогли изучить нюансы и понять, на какие задачи заточен каждый из брокеров. Итак, поехали! О брокере Apache Kafka я очень подробно рассказал в своей предыдущей статье . Повторяться и снова разбирать его сегодня я не буду — вы можете перейти по ссылке выше и ознакомиться с материалом, а затем вернуться сюда.

https://habr.com/ru/articles/989590/

#kafka #rabbitmq #messagebroker #highload #highload++ #high_performance #архитектура #высоконагруженные_системы

REDIS: такой простой и такой сложный

Меня зовут Андрей Комягин, я СТО компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей и в своей работе широко используем open-source решения, в том числе СУБД Redis. Недавно я подробно рассказывал об этой системе на конференции Saint HighLoad++, а теперь с удовольствием поделюсь основной информацией с читателями Хабра. Итак, поехали.

https://habr.com/ru/companies/stm_labs/articles/841792/

#redis #highload #highload++ #high_performance #high_availability #cache #caching #database_design #базы_данных #архитектура

OpenDJ: быстрый масштабируемый LDAP на базе Apache Cassandra

LDAP-совместимые службы каталогов — широко распространенный отраслевой стандарт и удобное решение для хранения идентификационных данных. В одном из популярных open-source LDAP каталогов OpenDJ , начиная с версии 4.6.1 появилась возможность использовать Apache Cassandra или ScyllaDB в качестве хранилища данных. Это позволяет использовать преимущества производительности и масштабируемости колоночных NoSQL БД по сравнению с классическими LDAP каталогами. В данной статье мы развернем инстанс OpenDJ на базе Apache Cassandra.

https://habr.com/ru/articles/820925/

#ldap #opendj #open_source #cassandra #apache_cassandra #scylladb #scylla #high_performance #highload #scalability