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

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

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

Хэширование — простой и надёжный способ проверить целостность данных. Но как быть, если нужно удостовериться, что часть данных принадлежит определённому набору? Например, проверить отдельную транзакцию в блоке Bitcoin или чанк файла в BitTorrent? Для этого используется уникальная структура данных — Merkle-tree. В этой статье вы узнаете, как с её помощью решать задачи проверки данных без доступа к их полному объёму.

Привет, Хабр! На связи Александр Бобряков, техлид команды МТС Аналитика. Это мой одиннадцатый пост про Apache Flink. В предыдущей части мы рассмотрели сериализацию данных во Flink, написали сериализатор, поддерживающий эволюцию схемы для Flink-состояния в операторе на основе Jackson.

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

Весь разбираемый исходный код можно найти в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии. Этот материал соответствует релизной ветке с названием release/10_test_JacksonStateSerializer.

Продолжаем серию статей о CAP-теореме и языке Coq. В предыдущей части мы детально проанализировали определения CAP-теоремы, готовясь к её формализации на языке Coq, и нашли там серьёзную ошибку (теперь будет о чём поговорить при случае на system design interview).

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

No subject appears to be more controversial to distributed systems engineers than the oft-quoted, oft-misunderstood CAP theorem. The CAP FAQ

— Сейчас я тебе объясню... — Объяснить я и сам могу, ты расскажи, что на самом деле происходит! (Из разговора политологов, но для CAP-теоремы подходит тоже)

— Давайте уже запишем CAP-теорему на языке Coq и посмотрим, что там на самом деле. (Я)

Привет, Хабр! Меня зовут Максим, я Go-разработчик из Wildberries. Свою дебютную статью я хочу посвятить довольно популярной теме, когда на проекте приходится уходить с одной технологии на другую. Данная статья будет полезна разработчикам, кто активно использует асинхронный способ передачи данных в своих проектах.

Массовая трансляция видео и аудио генерирует огромное количество трафика. А трафик это деньги. Иногда – большие деньги. И тогда бизнес начинает задумываться – как бы сделать так, чтобы эти деньги не платить. А желания бизнеса – плодотворная почва для интересных решений. Об одном из них мы и поговорим.

Всем привет, меня зовут Вадим Макеров, я работаю в iSpring бэкенд-разработчиком.
Однажды у нас в продукте был инцидент, который привел к даунтайму LMS и происходил несколько раз, в течении нескольких дней. Причина оказалась нетривиальной и находилась на уровне сетевых настроек подключений между сервисами.

Часто в распределенных ИТ-ландшафтах компании используют несколько хранилищ данных под разные задачи. Это делает их важным компонентом любой системы Change Data Capture (CDC) — они помогают отслеживать изменения данных и связывать используемые хранилища. Но далеко не все CDC-инструменты способны ответить на актуальные запросы бизнеса.

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

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

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

Казалось бы, между ресурсоемким по своей природе блокчейном и Интернетом вещей, построенном на использовании устройств с ограниченными ресурсами, лежит огромная пропасть. Однако многие из свойств блокчейна оказались настолько востребованными в Интернете вещей, что появилось целое направление блокчейн-технологий – низкоресурсный блокчейн (Lightweight Blockchain, LWB), в рамках которого было предложено множество подходов к созданию блокчейнов с пониженными требованиями к ресурсам и, следовательно, к их адаптации для реализации в системах Интернета вещей и, в частности, в устройствах с низкими вычислительными ресурсами.

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

YTsaurus — платформа для распределённого хранения и обработки данных. С помощью неё пользователи могут производить вычисления с данными, которые хранятся на кластере. За запуск этих вычислений отвечает один из центральных компонентов системы — планировщик. Зачастую ресурсов кластера не хватает, чтобы одновременно запустить все желаемые вычислительные задачи. Поэтому одна из важных задач планировщика — умение грамотно распределять вычислительные ресурсы между пользователями.

Меня зовут Егор Щербин, я работаю в Yandex Infrastructure, в команде планировщика YTsaurus. О нём и расскажу в этой статье. А также о запуске вычислений в кластере YTsaurus, распределении ресурсов между вычислениями и о том, как управлять распределением, чтобы все операции получали ровно столько, сколько требуется.

Здравствуйте, меня зовут Дмитрий Карловский и я.. обычно пишу статьи с ответами, но на этот раз я, наоборот, буду задавать много вопросов, о которых вы даже не задумывались.

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

Apache Kafka — популярный распределенный брокер сообщений, который собирает и сохраняет сообщения (данные) со всех источников, а после предоставляет их программам и сервисам-получателям. Благодаря своей производительности и архитектуре инструмент довольно активно используется в проектах, где нужно гонять большие объемы данных. Но даже возможностей Kafka не всегда достаточно — иногда системам нужен буст по скорости и надежности. И получить его можно с помощью кэширования данных в Tarantool.

Меня зовут Никита Молоствов. Я старший программист в команде разработки VK Tech. В этой статье я расскажу о том, как можно наладить взаимодействие Kafka и Tarantool, зачем может понадобиться кэширование потока из Kafka в Tarantool, и дам подробную пошаговую инструкцию, с которой каждый сможет применить мои наработки в собственной системе.

Математическая модель технологической схемы – система математических соотношений, описывающих с требуемой точностью имитируемый объект или процесс (реакцию системы на действия пользователя или инструктора).

Итак, что мы сделали.... технология автоматического синтеза математической модели объекта....

Продолжаем наш цикл статей о типах и методах работы сборщиков данных с конечных точек, или, как принято их называть – агентов. В первой статье мы познакомились с этой сущностью и изучили основные нюансы сбора данных с их помощью. Так как мы в рамках разработки своих продуктов занимаемся и лог-менеджментом, и сбором событий, то хочется поделиться продолжением нашей обширной аналитики в quickstart формате. Поэтому в этом выпуске подробнее разберем функционал и используемые инструменты источников на ОС Windows.

Привет! Я Антон, работаю в команде базовой инфраструктуры Контура и занимаюсь развитием распределенной системы хранения данных Kanso. Это наш форк GFS (Google File System). Мы развиваем Kanso уже более 15 лет, в статье я расскажу про это подробнее.

Всем привет! Меня зовут Максим, я QA в Максилекте.

Недавно коллеги попросили меня рассказать о базовых вещах в Kafka, которые могут быть полезны при тестировании общающихся между собой микросервисов или сервисов, взаимодействующих со сторонними ресурсами. В этой статье - основные идеи моего рассказа.

Привет, Хабр! Я Роман Щербаков, ведущий инженер в Sage — это платформа мониторинга в Т-Банке, которую мы разрабатываем с 2019 года. За пять лет нагрузка на платформу возросла многократно, и, чтобы ее выдерживать, мы постоянно докручиваем наше решение. 

В этой статье расшифровка моего доклада с Saint HighLoad++ 2024 о том, как мы строим нагруженные пайплайны записи. И о том, как было бы здорово заранее знать, что нам потребуется. Мы придумали много всего для надежной работы пайплайнов, а посмотрели ретроспективно, и оказалось, что это просто одни сплошные стандартные паттерны.

Предположим, что у нас есть Postgres, Kafka и Elastic. В Postgres живет сущность, например, item.

Иногда возникает необходимость создать поисковый индекс отдельно от основной базы.

Например, если мы не хотим обрушивать поисковый трафик на Postgres мы можем вынести данные из него в Elastic.

И все бы хорошо, если актуальность не требуется - просто запускать крон пересборки индекса в Elastic каждую ночь.

Но что если данные нам нужны актуальные, и ситуация, что через секунду после записи сущности в Postgres запрос на её чтение отдает Not Found - неприемлема?