Распределённые системы *

Привет, Хабр! С вами команда разработки платформы Russ Online Группы компаний Russ (входит в объединенную компанию Wildberries & Russ). Мы хотим поделиться историей о том, как от монолитной системы мы перешли к микросервисной архитектуре и облачным решениям на базе Kubernetes и S3. Эта трансформация создала фундамент для дальнейшего развития платформы и внедрения новых сервисов.

В быстро меняющемся мире веб-разработки постоянно появляются новые технологии и подходы к созданию системы обмена данными между приложением или сервисом. Одной из таких технологий, позволяющей запрашивать только необходимые данные, является GraphQL. Меня зовут Дмитрий и я python-разработчик. В этом материале я дам сравнительный обзор на REST и GraphQL.

Один из наиболее популярных примеров использования GraphQL — это применение в социальных сетях, где множество пользователей связаны между собой определёнными отношениями. К GraphQL мы прибегаем, когда нам требуется избирательно получить много данных о них. Такая организация пользователей имеет сетевую модель и представляется в виде графа, отсюда и связь с названием GraphQL (Graph — граф, QL — язык запросов).

Итак, почему компании, однажды выбравшие GraphQL, решают изменить свой курс и вернуться к стандартному способу реализации систем? Ответ на этот вопрос лежит на пересечении технических возможностей, бизнес-потребностей и экономических соображений. Давайте разберёмся в этом подробнее.

Привет, хабр!

Меня зовут Кирилл, и на протяжении последних двух лет я мечтал научиться проходить System Design интервью. Но только недавно взялся за дело всерьёз.

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

Всем привет, 

Команда devhands.io сделала с Владимиром Перепелицей интервью, посвященное сравнению наиболее популярных решений в области очередей и брокеров сообщений — Kafka, RabbitMQ, NATS.

Владимир — эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload. А мы, R&D-центр devhands.io, разрабатываем образовательные программы по хайлоаду, перформансу, архитектуре, базам данных и другим направлениям.

Под катом – расшифровка интервью.

Как структурировать диалоги с LLM: шаблоны, интенты, статусы и архитектура ai-dialog-system, превращающая хаос в управляемую систему. Подход подходит для аналитики, CI и командной разработки.

Примерно в 2012-2013 году в сообществе сисадминов стали много говорить о технологии под названием «Borg». Складывалось впечатление, что это какая-то система управления контейнерами, основанная на Linux и применяемая в Google — с её помощью они эксплуатируют свои внутренние ресурсы. Терминология по этой системе немного озадачивала; внутри кластеров, состоящих из «ячеек» (cells), в ней находились какие-то «борглеты», но суть уже на данном этапе начинала ускользать. В системе существовали концепции «сервисов» (services) и «заданий» (jobs), так, что приложения могли при помощи сервисов откликаться на пользовательские запросы, после чего система собирала задания в пакеты, и эти пакетные задания уже выполнялись достаточно долго.

Затем 7-го июня 2014 года состоялся первый коммит в Kubernetes. Это греческое слово означает «кормчий», и в течение первых трёх лет существования этой технологии решительно никто не понимал, как его правильно произносить. Поэтому пришлось сдаться и позволить простым смертным обозначать его как k8s.

В этой статье рассказываем о том, как мы решили проблему удаления брошенных файлов — файлов данных, которые не ассоциированы ни с одной из имеющихся в базе данных таблиц, но могут оставаться на файловой системе после аварийного завершения процессов.

Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.

Изучая System Design, вы часто видите только теоретические материалы. В этой статье я постарался показать в том числе практическую реализацию многих вещей, чтобы вы не просто готовились к собеседованиям, но и знали, как эти вещи используются в реальном мире.

Иногда появляется необходимость обращения к брокерам Kafka из другой сети через NAT. Но, даже если NAT настроен корректно, то при попытках подключения, обратно возвращается ошибка о том, что брокер недоступен. Хотя ping и telnet по нужному порту проходят. В статье мы подробно разберем, как необходимо настроить Kafka для того, чтобы к системе можно было обращаться через NAT.

Greengage DB — это массивно-параллельная реляционная СУБД на базе Greenplum OSS, которая подходит для хранения и обработки данных. Позволяет выполнять сложные аналитические запросы над большими объёмами данных, предоставляя к ним гетерогенный доступ за счёт различного рода коннекторов и средств интеграции.

Но помимо функциональных возможностей, есть и ряд других необходимых вещей, таких как мониторинг, аудит, резервирование и пр. Они требуются для обеспечения полноценной и надёжной работы системы, особенно если речь идёт о промышленной эксплуатации. В рамках данной статьи как раз хочется обсудить подход к резервированию кластера Greengage: какие тут есть возможности, каковы подводные камни и многое другое.

Компании часто сталкиваются с необходимостью переливать данные между системами. Но нередко это превращается в настоящий квест: форматы данных могут различаться, для интеграции инструментов может не быть готовых коннекторов, самостоятельно гарантировать консистентность данных в целевой системе может быть сложно или невозможно. Поэтому подобные задачи редко обходятся без применения CDC (Change Data Capture).

Меня зовут Андрей Капустин. Я менеджер продукта Tarantool CDC в компании VK Tech. В этой статье я расскажу о Tarantool CDC и о том, как инструмент помогает консолидировать данные из разрозненных хранилищ, в том числе проприетарных СУБД, обеспечивая прозрачность, высокую консистентность и скорость.

И снова здравствуйте! Меня по-прежнему зовут Александр Попов, и я всё ещё TechLead команды разработки маркетплейса 05.ru.

Я рад представить вам продолжение статьи о распределённой архитектуре нашего продукта. Предыдущая статья вышла около года назад, и за это время мы практически полностью перешли на новую архитектуру. Естественно, по пути столкнулись с проблемами, но в то же время получили неплохие бонусы. Вот об этом я и хотел бы рассказать.

Перед прочтением рекомендую ознакомиться с первой частью моего рассказа о новой архитектуре нашего продукта. Потому что велика вероятность встретить непонятные термины и описания незнакомых процессов.

Всем привет! Меня зовут Александр, и я хочу поделиться опытом использования CIM-модели и моделирования её расширений при разработке интеллектуальной системы учета электроэнергии. На самом деле материалов по этой теме у нашей команды накопилось достаточно — хватит на целую серию статьей. Начну с основ. В чем особенности рынка электроэнергетики, почему важно обеспечить унифицированный обмен данными между его участниками и как в этом помогает CIM? Давайте разбираться.

Решил и я в рамках конкурса рассказать о своём вкладе в развитие open source. Речь про open source блокчейн Hyperledger Fabric. Блокчейн активно используется в разных сферах: цифровые валюты центробанков (Беларусии, Нигерии), операторами информационных систем цифровых финансовых активов, электронное голосование, энергетика, здравоохранение и др.

В этой статье я расскажу как я:

обнаружил проблему;
создал свой первый open source: смарт-контракт для решения этой проблемы;
повлиял на создание патча для блокчейна Hyperledger Fabric, устраняющего проблему.

Привет! С вами Олег, Рамиль и Андрей из Flocktory. Мы руководим машинным обучением и разработкой в компании, сейчас активно внедряем AI для лучшей персонализации. В прошлом году наши команды реализовали ML-сервисы, внедрили ML Feature Store и переработали жизненный цикл моделей (о чём мы подробно рассказывали на HighLoad++: https://highload.ru/moscow/2024/abstracts/12929). В этой статье поразмышляем над следующим шагом для среднего размера компании, которая внедряет AI – как масштабировать проекты машинного обучения. Обработка, анализ и обучение на данных влекут за собой применение ML систем, в том числе нейросетей. Это требует больших вычислительных ресурсов: сотни гигабайт ОЗУ, десятки ядер CPU, а также видеокарты и (или) специальные чипы для ускорения вычислений.

Рассмотрим основные варианты ресурсов, которые можно использовать, сложности, связанные с их эксплуатацией, целесообразность вложений и vendor lock. Но сначала поговорим о природе трудностей, возникающих при масштабировании.

Слово блокчейн звучит отовсюду: от новостей про криптовалюты до обсуждений будущего технологий. Но что это такое на самом деле? Многие представляют себе что-то невероятно сложное, доступное лишь криптографам и финансовым гуру. Спойлер, основная идея довольно проста и изящна. Давайте попробуем разобраться на пальцах буквально за пару минут.

Почему так сложно пройти первые System Design Интервью? Какие есть подводные камни? Оказывается, что не все понимают базовый алгоритм прохождения, а также нюансы движения по основным этапам.

Меня зовут Владимир и я senior backend в геораспределенной HighLoad системе. Которая выдерживает пиковые нагрузки в млн RPS. Моя страсть System Design. Я успешно прохожу интервью в BigTech компании, а также готовлю учеников. Выделил ТОП-5 ошибок у новичков и готов поделиться их разбором. Подробности под катом.

Заранее оговорюсь, всё что будет описано в данной статье, будет касаться runtime (децентрализованного) кеша и применимо не только к Gо приложениям.
Зачем нам нужен такой кеш? По нескольким причинам.

На собеседованиях часто задают знаменитый вопрос, узнаваемость которому по большей части дал facebook*: «Что происходит после того, как вы вводите URL сайта в адресную строку браузера и нажимаете Enter?». Несмотря на кажущуюся простоту, этот вопрос покрывает широкий спектр тем – DNS, TCP/IP, HTTP, и даже работу браузера. Разработчики разных уровней иногда теряются в деталях ответа. Понимание этого процесса важно для инженеров – оно показывает, как взаимодействуют между собой различные сетевые протоколы и уровни. Ниже мы шаг за шагом рассмотрим, как данные проходят через каждый слой сетевого стека, и проиллюстрируем это примерами.