NAT - механизм, создающий множество проблем для P2P коммуникации, в силу того, что нередко адрес пира может не иметь доступного из любой точки мира, "белого" адреса. Существует ряд способов обхода NAT, но их документация, равно как и данные об их надежности, достоинствах и недостатках оставляет желать лучшего, а потому мы рассмотрим наиболее простой, и в то же время надежный метод - "hole punching".
Распределённые системы *
Нюансы проектирования распределенных систем
PKI, прикладная криптография и электронная подпись: о чем здесь речь и как это работает в нашей блокчейн-платформе
Криптография в целом — это большая область знаний. И хотя блокчейн всегда идет с ней рука об руку, в реальных проектах на базе распределенных реестров используется лишь некоторые из достижений криптографии. В этом посте я постараюсь рассказать простым языком, что они собой представляют и как работают в рамках нашей блокчейн-платформы.
Блокчейн или не блокчейн? Формализованные критерии выбора технологии хранения и обработки данных
Приветствую, Хабр! В очередной раз возникло желание обсудить блокчейн‑технологии, хотя им и было посвящено уже немало публикаций на Хабре (да и, несомненно, их еще будет много в дальнейшем).
Многие технологии делают нашу жизнь лучше и интереснее. Блокчейн, несомненно, относится к таковым. Но в очень многих случаях вокруг блокчейна возникает излишний информационный шум, который далеко не всегда способствует правильному восприятию блокчейна именно как одной из ряда существующих технологий хранения и обработки данных.
В результате этого выбор данной технологии как базовой в той или иной системе может быть продиктован не техническими требованиями к системе, а как результат выбора (возможно даже, что навязанного извне) в пользу модной и перспективной технологии, возможно при этом не совсем технически обоснованного.
В течение последнего десятилетия некоторые организации и отдельные эксперты озаботились подобной ситуацией, когда выбор блокчейн‑технологии может быть ошибочным именно из‑за наличия факторов нетехнического характера, в результате чего было опубликовано несколько рекомендаций, в той или иной степени формализующих ответ на вопрос, использовать ли блокчейн при разработке новой системы или предпочесть какую‑либо альтернативную технологию.
В этой статье мы рассмотрим достоинства и недостатки блокчейн‑технологий и попытаемся классифицировать сферы их применения, после чего дадим обзор формализованных методов выбора: «блокчейн или не блокчейн».
Распределённые снапшоты: определение глобального состояния распределённых систем
Наша команда продолжает развивать Platform V DataGrid — распределенную базу данных в оперативной памяти для высокопроизводительных вычислений. В последнем релизе мы реализовали инкрементальные снапшоты, которые быстро снимаются, сохраняют транзакционную целостность и почти не влияют на общую производительность системы.
В рамках работы над этой фичей мы изучили несколько классических статей по распределённым системам, перевода которых на русский кажется не существует. Всех, кому интересна тема распределённых систем, приглашаю под кат.
Истории
Apache Ignite: как эта технология изменила подход к большим данным в Comindware
Вряд ли можно поспорить сегодня с аргументом, что скорость и эффективность обработки информации стали ключевыми факторами успеха любого цифрового проекта. При этом традиционные подходы к хранению и обработке данных уже не могут удовлетворить растущие потребности бизнеса и пользователей. Именно в этот момент на сцену выходит Apache Ignite — высокопроизводительная, распределенная платформа для вычислений в памяти. Рассказывает Александр Столяров, ведущий программист компании Comindware.
Нужна ли вам Kafka? Разбираемся в технологии и собираем простое приложение на базе managed-решения
Kafka — стильная, модная, молодежная технология, которую разработала в 2011 году компания LinkedIn и значительно усовершенствовал Apache Software Foundation. Представляет собой надежный, масштабируемый и устойчивый инструмент для обработки и передачи данных в режиме реального времени — шину данных.
Но нужно ли внедрять технологию в угоду моде или амбициям вашего продуктового менеджера? Под катом расскажу про сильные стороны Kafka и задачи, в которых она раскрывается по максимуму. Также напишем быстрое приложение на базе Kafka-as-a-service, которую мы недавно релизнули в Selectel.
Анализ эффективности кэширования на бэкенде ЛК МегаФон
По мере расширения функциональности сервиса и роста его аудитории мы неизбежно сталкиваемся с узкими местами в производительности. Прежде чем масштабировать ресурсы для эксплуатации, следует понять, насколько эффективно эксплуатируется текущая конфигурация.
Одним из таких узких мест может стать ваше распределенное хранилище для кэша. Все мы привыкли к тому, что оно нас спасает от тяжелых запросов в БД или обращенийк внешним системам с большой задержкой. Но рано или поздно может возникнуть ситуация, когда конфигурация этого хранилища будет на грани своей оптимальной производительности и в случае высоких нагрузок (аварий, спровоцированных наплывом пользователей или рекламными кампаниями) хранилище может подвести нас.
Как определить, что утилизация ресурсов кэширования происходит оптимально? Что если довольно большая часть нагрузки не приносит реальной пользы, и от нее с легкостью можно избавиться, тем самым разгрузив хранилище? В рамках этой статьи мы оценим эффективность кэширования бэкeнда ЛК МегаФон и расскажем о результатах проведенных мероприятий для оптимизации.
LogDoc: логи здорового человека
Привет, Хабр
Однажды команда LogDoc, которая тогда ещё была просто дружеской компанией суровых разработчиков, после бурного обсуждения очередного напряжённого рабочего дня вынесла однозначный вердикт — в мире нет и не предвидится нормального, человеческого продукта для работы в распределённой среде с логами, трейсами, сигналами и прочим подобным. Нас это опечалило (по очевидным причинам) и воодушевило — мы увидели возможность создать полезный продукт. Подумали, собрались с духом и выложились полностью в попытке реализовать задуманное. Именно результат наших усилий мы представляем вам в этой вводной статье.
Простые радости вертикального масштабирования
В последние 20 лет архитекторы программных и аппаратных систем перепробовали различные стратегии, которые позволили бы решать проблемы, связанные с большими данными. Пока программисты усердно переписывали код, приспосабливая его для горизонтального масштабирования на множество машин, железячники впихивали на каждый чип всё больше и больше транзисторов и ядер, чтобы увеличить объём работы, осуществимый на каждой машине.
Как подтвердит любой, кому когда-либо доводилось проходить собеседование по программированию, при наличии арифметической и геометрической прогрессии геометрическая всегда возобладает. При горизонтальном масштабировании расходы растут линейно (арифметически). Но по закону Мура вычислительные мощности со временем растут экспоненциально (геометрически). Это означает, что можно несколько лет ничего не делать, а затем масштабировать систему вертикально и получать улучшение на порядки. За двадцать лет плотность транзисторов возросла в 1000 раз. Это значит, что такая задача, для решения которой в 2002 году потребовались бы тысячи машин, сегодня выполнима всего на одной.
Обработка больших и очень больших графов: Pregel
Статья является продолжением предыдущей статьи в рамках цикла статей, посвященных обработке больших и очень больших графов. В статье реализованы распределенные версии четырех классических алгоритмов: "Связные компоненты", "Кратчайшее расстояние", "Топологическая сортировка" и PageRank на Apache Spark DataFrame API. Алгоритмы составлены в соответствии с идеями популярного фреймворка распределенной обработки графов Pregel.
Dash Platform: Дата-контракты
Дата-контракты - это мощный инструмент, который уже широко используется в сфере сервисов данных Web2 благодаря своим многочисленным преимуществам для пользователей и разработчиков. Они представляют собой относительно простые JSON-схемы, определяющие структуру данных, которые может хранить dapp.
S3 не сразу строилось
Привет, Хабр. Вашему вниманию предлагается сокращённый перевод эпичного поста под авторством Энди Уорфилда, вице-президента и заслуженного инженера в компании Amazon, занятого разработкой S3. Пост основан на его пленарном выступлении с конференции USENIX FAST ‘23 и затрагивает три различных аспекта, касающихся выстраивания и эксплуатации такого огромного хранилища данных как S3. Если пост окажется интересным - рассмотрим вариант перевести и вторую часть
Распределённое обучение с PyTorch на кластере для тех, кто спешит
Глубокие модели становятся всё больше и всё реже помещаются на один компьютер. Это перевод поста в блоге Lambda Labs, компании, специализирующейса на инфраструктуре для глубого обучения. В этом посте нам расскажут как организовать распределенное обучение модели PyTorch на нескольких вычислительных узлах.
В качестве инструмента для запуска задач рассматриваются torchrun и MPI.
Ближайшие события
Обработка больших и очень больших графов
Однажды ко мне обратилась одна крупная фруктовая телефонная компания с просьбой подготовить для них курс по Apache Spark продвинутого уровня, и в нем обязательно должен быть раздел про обработку графов (Neo4j не предлагать). На тот момент я знал про классические алгоритмы обработки графов на базе DFS (поиск в глубину) и BFS (поиск в ширину). При этом неотъемлемым условием применения того или иного подхода является локальная поддержка стека (DFS) или очереди (BFS). Следовательно, классические алгоритмы можно применять для обработки графов, которые умещаются в память одной машины.
В современном мире данные накапливаются очень быстро, и классические подходы, ориентированные на обработку графов в рамках одной машины, перестают работать, а значит высока потребность в алгоритмах распределенной обработки графов. Интуитивно можно предположить, что необходимо разбивать граф на части, но каким образом и как потом их собирать вместе?
«Возьмите инициативу на себя»: готовимся к System Design Interview
Рассказываем, для чего в Авито проводят интервью по System Design, чего от него ожидать и что нужно знать, чтобы его успешно пройти.
Экономика вещей: устройства как экономические агенты. Роль Device Twins
Сегодня начинает набирать обороты концепция "экономики вещей" (Economy of Things - EoT). Евангелисты данной конфессии концепции прогнозируют массовый переход подключенных устройств на этот способ взаимодействия и, соответственно, колоссальный рынок.
Давайте посмотрим, что нам готовит новый дивный мир как с точки зрения пользователя (способы использования), так и с точки зрения разработчика (технологический стек). Особое место в этой концепции могут занять Device Twins.
Как генерировать модели интерфейсов на основе спецификации на стороне frontend-приложений
На связи снова Архитектурный комитет компании SimbirSoft, и мы продолжаем наш цикл статей, посвященных Design API First. Ранее мы уже писали о том, что представляет собой этот подход, приводили пример спецификации для сервиса аутентификации и рассказывали, как мы интегрируем этот паттерн в наш конвейер разработки.
Сегодня мы немного отвлечемся от бэкенда и разберем автоматизацию одной из рутинных задач на стороне frontend-разработки. А именно описание моделей интерфейсов для взаимодействия фронта с беком, а также написание API-сервисов, в которых фиксируются endpoints, методы запросов и формат передачи данных (query-параметры, заголовки, тело).
Три движка для одной Лавки: как эволюционировала система поиска в сервисе
Лавка — сервис быстрой доставки продуктов. Один из важнейших сценариев использования сервиса для покупателя — это поиск. Примерно 30% товаров добавляются в корзину именно из его результатов. А ещё, если в пользовательской сессии был успешный запрос в поиск, вероятность совершения заказа вырастает на 10–15%. То есть, если клиенту нужен конкретный продукт и он его быстро находит через поиск, вероятность совершения заказа становится выше.
Корректная и качественная организация поиска — нетривиальная задача, поэтому иногда приходится придумывать нестандартные решения, чтобы всё работало как нужно. В этой статье я расскажу историю развития поиска в Лавке от самого начала до текущего момента. Нам пришлось объединить всю силу и мощь целых трёх движков, чтобы пользователи получали точный и актуальный результат. Параллельно погрузимся в различные технические детали, проблемы и прочие нюансы.
Как построить систему, способную выдерживать нагрузку в 5 млн rps
Всем привет!
Меня зовут Владимир Олохтонов, я руковожу командой разработки в отделе Message Bus, который является частью платформы Ozon. Мы занимаемся разработкой самых разных систем вокруг Kafka, etcd и Vault. В этой статье я расскажу о том, как мы строили линейно масштабируемую gRPC-прокси перед Kafka, способную обслуживать миллионы запросов в секунду, используя Go.
Верификация распределённых систем с применением Isabelle/HOL
Мы ежедневно пользуемся распределёнными системами (в форме интернет-сервисов). Эти системы очень полезны, но и реализовывать их непросто, так как сети непредсказуемы. Всякий раз, когда вы передаёте сообщение по сети, предполагается, что оно прибудет очень быстро, но возможны и достаточно долгие задержки. Может случиться так, что сообщение не прибудет вообще, либо прибудет несколько раз. Когда вы отправляете запрос другому процессу и не получаете отклика, вы понятия не имеете, что произошло: потерялся ли запрос, либо тот другой процесс аварийно завершился, либо сам отклик потерялся? Или же на самом деле ничего не потерялось, сообщение просто задержалось и ещё может прибыть. Невозможно доподлинно узнать, что произошло, поскольку ненадёжный обмен сообщениями – единственный способ межпроцессной коммуникации.
Вклад авторов
olegchir 356.4kovalensky 173.0Bright_Translate 163.2andreyka26 159.0clubadm 159.0jirfag 152.0sergepetrenko 141.0ph_piter 130.6bitec 129.0gridem 125.0