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

Прошло почти 15 лет с запуска сети Bitcoin, предложившей миру новый способ передачи ценности, альтернативный традиционным валютам. Всё это время технологии не стояли на месте: к 2023 на основе блокчейна вовсю развиваются проекты в различных сферах экономики — особенно финансовой — а государства всерьез занимаются запуском собственной «крипты», ЦВЦБ. Такой прорыв стал возможен во многом благодаря смарт-контрактам. В этом посте мы расскажем, что такое смарт-контракты, как они эволюционировали и, наконец, как работают на нашей платформе «Конфидент».

В нашем предыдущем посте о производительности YDB, посвященном Yahoo! Cloud Serving Benchmark (YCSB), мы упоминали, что готовим к публикации результаты других бенчмарков. Мы придерживаемся плана и сегодня рады представить вашему вниманию наши первые результаты бенчмарка TPC-C*, который является индустриальным стандартом оценки производительности онлайн транзакций (OLTP). Согласно этим результатам есть сценарии, в которых YDB немного превосходит CockroachDB, другую хорошо известную распределенную SQL СУБД.

Порой простое и очевидное решение может потянуть за собой хвост проблем в будущем. Например, добавление ретраев.

Меня зовут Денис Исаев, и я работаю в Яндекс Go. Сегодня я поделюсь опытом решения проблем с отказоустойчивостью из-за ретраев. Основано на реальных инцидентах в системе из 800 микросервисов.

Этот пост — продолжение вымышленных историй о разработчике Васе, который несколько лет назад разбирался с идемпотентностью в распределённых системах. Теперь перед ним новые задачи — получится ли справиться с ними в этот раз? Давайте узнаем.

Привет, Habr! С вами Антон, руководитель Архитектурного комитета компании SimbirSoft. Мы продолжаем цикл статей, посвященных практическому внедрению подхода Design API First в разработку наших проектов. Настало время поделиться практическим опытом использования спецификаций OpenAPI для кодогенерации контрактов backend.

Дисклеймер: Материал публикации в первую очередь передает практический опыт работы системных аналитиков и практикующих архитекторов при интеграции Design API First с непосредственным процессом разработки. Некоторые технические детали реализации будут описаны не полностью.

NAT - механизм, создающий множество проблем для P2P коммуникации, в силу того, что нередко адрес пира может не иметь доступного из любой точки мира, "белого" адреса. Существует ряд способов обхода NAT, но их документация, равно как и данные об их надежности, достоинствах и недостатках оставляет желать лучшего, а потому мы рассмотрим наиболее простой, и в то же время надежный метод - "hole punching".

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

Приветствую, Хабр! В очередной раз возникло желание обсудить блокчейн‑технологии, хотя им и было посвящено уже немало публикаций на Хабре (да и, несомненно, их еще будет много в дальнейшем).

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

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

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

В этой статье мы рассмотрим достоинства и недостатки блокчейн‑технологий и попытаемся классифицировать сферы их применения, после чего дадим обзор формализованных методов выбора: «блокчейн или не блокчейн».

Наша команда продолжает развивать Platform V DataGrid — распределенную базу данных в оперативной памяти для высокопроизводительных вычислений. В последнем релизе мы реализовали инкрементальные снапшоты, которые быстро снимаются, сохраняют транзакционную целостность и почти не влияют на общую производительность системы.

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

Вряд ли можно поспорить сегодня с аргументом, что скорость и эффективность обработки информации стали ключевыми факторами успеха любого цифрового проекта. При этом традиционные подходы к хранению и обработке данных уже не могут удовлетворить растущие потребности бизнеса и пользователей. Именно в этот момент на сцену выходит Apache Ignite — высокопроизводительная, распределенная платформа для вычислений в памяти. Рассказывает Александр Столяров, ведущий программист компании Comindware.

По мере расширения функциональности сервиса и роста его аудитории мы неизбежно сталкиваемся с узкими местами в производительности. Прежде чем масштабировать ресурсы для эксплуатации, следует понять, насколько эффективно эксплуатируется текущая конфигурация.

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

Как определить, что утилизация ресурсов кэширования происходит оптимально? Что если довольно большая часть нагрузки не приносит реальной пользы, и от нее с легкостью можно избавиться, тем самым разгрузив хранилище? В рамках этой статьи мы оценим эффективность кэширования бэкeнда ЛК МегаФон и расскажем о результатах проведенных мероприятий для оптимизации.

Привет, Хабр

Однажды команда LogDoc, которая тогда ещё была просто дружеской компанией суровых разработчиков, после бурного обсуждения очередного напряжённого рабочего дня вынесла однозначный вердикт — в мире нет и не предвидится нормального, человеческого продукта для работы в распределённой среде с логами, трейсами, сигналами и прочим подобным. Нас это опечалило (по очевидным причинам) и воодушевило — мы увидели возможность создать полезный продукт. Подумали, собрались с духом и выложились полностью в попытке реализовать задуманное. Именно результат наших усилий мы представляем вам в этой вводной статье.

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

Как подтвердит любой, кому когда-либо доводилось проходить собеседование по программированию, при наличии арифметической и геометрической прогрессии геометрическая всегда возобладает. При горизонтальном масштабировании расходы растут линейно (арифметически). Но по закону Мура вычислительные мощности со временем растут экспоненциально (геометрически). Это означает, что можно несколько лет ничего не делать, а затем масштабировать систему вертикально и получать улучшение на порядки. За двадцать лет плотность транзисторов возросла в  1000 раз. Это значит, что такая задача, для решения которой в 2002 году потребовались бы тысячи машин, сегодня выполнима всего на одной.

Статья является продолжением предыдущей статьи в рамках цикла статей, посвященных обработке больших и очень больших графов. В статье реализованы распределенные версии четырех классических алгоритмов: "Связные компоненты", "Кратчайшее расстояние", "Топологическая сортировка" и PageRank на Apache Spark DataFrame API. Алгоритмы составлены в соответствии с идеями популярного фреймворка распределенной обработки графов Pregel.

Дата-контракты - это мощный инструмент, который уже широко используется в сфере сервисов данных Web2 благодаря своим многочисленным преимуществам для пользователей и разработчиков. Они представляют собой относительно простые JSON-схемы, определяющие структуру данных, которые может хранить dapp.

Привет, Хабр. Вашему вниманию предлагается сокращённый перевод эпичного поста под авторством Энди Уорфилда, вице-президента и заслуженного инженера в компании Amazon, занятого разработкой S3. Пост основан на его пленарном выступлении с конференции USENIX FAST ‘23 и затрагивает три различных аспекта, касающихся выстраивания и эксплуатации такого огромного хранилища данных как S3. Если пост окажется интересным - рассмотрим вариант перевести и вторую часть

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

В качестве инструмента для запуска задач рассматриваются torchrun и MPI.

Однажды ко мне обратилась одна крупная фруктовая телефонная компания с просьбой подготовить для них курс по Apache Spark продвинутого уровня, и в нем обязательно должен быть раздел про обработку графов (Neo4j не предлагать). На тот момент я знал про классические алгоритмы обработки графов на базе DFS (поиск в глубину) и BFS (поиск в ширину). При этом неотъемлемым условием применения того или иного подхода является локальная поддержка стека (DFS) или очереди (BFS). Следовательно, классические алгоритмы можно применять для обработки графов, которые умещаются в память одной машины.

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

Рассказываем, для чего в Авито проводят интервью по System Design, чего от него ожидать и что нужно знать, чтобы его успешно пройти.

Сегодня начинает набирать обороты концепция "экономики вещей" (Economy of Things - EoT). Евангелисты данной конфессии концепции прогнозируют массовый переход подключенных устройств на этот способ взаимодействия и, соответственно, колоссальный рынок.

Давайте посмотрим, что нам готовит новый дивный мир как с точки зрения пользователя (способы использования), так и с точки зрения разработчика (технологический стек). Особое место в этой концепции могут занять Device Twins.