Высоконагруженные системы *

Меня зовут Максим Копосов, я руководитель компании «Промобит». 16 лет назад мы начали разрабатывать российские системы хранения данных и другую вычислительную технику. Сегодня делаем СХД на отечественных и зарубежных процессорах, создаем оригинальное ПО для них. Наши инженеры находятся в постоянном поиске, и поэтому появляются собственные исследования, одним из которых сегодня хочу поделиться с вами. Это отчёт о тепловом моделировании систем хранения данных в области массива накопителей. В нем были оценены температурные режимы ключевых компонентов системы, таких как накопители (HDD формата 3.5 дюйма и SSD формата 2.5 дюйма) и PCIe-свитчи, при различных условиях эксплуатации. Измерения проводились на нашей СХД серии 4100.

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

Привет, Хабр! В этом месяце мы запустили акцию с GPU за рубль, предложили кешбэк до 1 000 000 бонусов для стартапов, добавили посуточную аренду видеокарт для ML и не только.  В тексте делимся подробностями, а еще — приглашаем 27 июля на Selectel Day Off.

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

Это статья в формате вольного пересказа более чем сорокалетнего периода работы с разными ОС, главным образом с ОС мейнфрейм, и размышлениями об их сходстве и различиях (в большей степени о различиях, конечно).

Многие популярные ОС выполняются на серверах (речь в статье пойдет исключительно про серверные ОС) х86 (Intel, AMD). Это Линукс разных мастей и названий, и Windows. В силу уклона российского образования в сторону инфраструктур на основе х86 у многих айтишников есть твердое убеждение, что то, как написаны известные ОС, это единственный вариант, как ОС и могут быть написаны. Попытки писать свою, российскую, ОС сводятся к написанию очередного Линукса.

Но есть и другие, современные ОС, выполняющиеся не на х86 платформе. Это одна из ОС IBM мейнфрейм (МФ), называемая z/OS. IBM МФ — тоже весьма современная техническая платформа. В апреле этого года IBM анонсировали новое поколение z17, т. е. семнадцатое поколение, начавшее свою историю в далеком 1964 году.

Как был переработан подход к полиморфизму в C++‑фреймворке Flox: замена virtual на статически сгенерированные vtable с концептами. В статье описана архитектура, проблемы, решение и метрики прироста производительности.

Представьте, что вы создаёте умный поиск, который понимает не просто слова, а смысл текста. Или рекомендательную систему, способную угадывать желания пользователя на основе его действий и предпочтений. Для таких задач недостаточно обычных баз данных — нужны инструменты, способные оперировать векторами — числовыми представлениями смысла, визуальных образов или поведения. Здесь и появляется Qdrant.

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

Индекс — это как указатель в толстенном справочнике. Без него, чтобы найти нужный термин, вы обречены листать страницу за страницей. С ним — вы мгновенно открываете нужный раздел. Но что, если указатель сам размером с полкниги? Или ведет не туда? Такой помощник только вредит. С индексами в БД всё то же самое. Грамотная стратегия индексирования — это полет. Ошибочная — это бег в мешках по болоту.

Новый релиз СУБД Tantor Postgres 17.5 насыщен обновлениями во всех основных аспектах: усиление безопасности, повышение общей производительности, новые расширения, а также инфраструктурные улучшения. Сегодня мы проведем обзор изменений, касающихся работы с высоконагруженными системами 1С. Релиз предлагает не просто несколько точечных исправлений, а целый арсенал специализированных функций, призванных существенно ускорить выполнение типичных для 1С операций, снизить нагрузку на инфраструктуру и упростить администрирование. Спектр улучшений распространился на многие ключевые узлы производительности от оптимизации работы с временными таблицами и сложными запросами RLS (row-level security) до ускорения критически важных процессов наподобие «Закрытия месяца». Обо всем этом и пойдет речь в статье.

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

Меня зовут Алина Шестакова. Я разработчик в команде разработки DataPlatform единой облачной платформы One-сloud. В этой статье расскажу о том, как устроен стриминг данных в ОК, а также обо всех патчах и челленджах, возникших в процессе обновления стримингового фреймворка.

Это первая статья из цикла, рассказывающая о практике развёртывания небольшого кластера Cassandra: от дефолтного деплоя «из коробки» до готовности к производственной эксплуатации.

Apache Cassandra — это распределенная высокомасштабируемая NoSQL СУБД, предназначенная для надежного хранения огромных массивов данных. Cassandra используют такие гиганты как Netflix, Apple, Instagram*, Twitter* (*Запрещены в РФ), Spotify и множество других известных компаний и брендов.

Здесь не будет рассказа об архитектуре Cassandra — о ней опубликовано очень много статей и снято настолько же много видео. Особо отмечу суперский «Cassandra Day Russia» на Youtube на русском языке, записанный нашими соотечественниками из Datastax. Поэтому, если вы вообще ничего не знаете о Cassandra, то посмотрите, например, вебинар «Введение в фундаментальные принципы и основы Apache Cassandra», а уже затем добро пожаловать в подготовку боевого кластера.

Что касается самого кластера, который мы будем разворачивать, то мне достался раскатанный через Ansible деплой на 5 хост‑машин с единственным образом Cassandra 4.0 в docker‑compose и дефолтными настройками. Пятерка хост‑машин представляет собой Core i5 / 64 GB RAM / 2 x 512 GB NVMe SSD / 16 TB SATA c Debian 11.

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

Приступим?

Задача нахождения неточных дубликатов текстовых строк - удивительно часто встречается на практике.

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

Но приключения начинаются, когда список становится размером несколько миллионов строк. В статье разберем что с этим можно сделать.

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

Сегодня рассмотрим, как работает fillfactor в PostgreSQL — тот самый параметр, который никто не трогает, пока таблицы не начинают раздуваться как на дрожжах. Разберём, зачем он нужен, что происходит при UPDATE, когда стоит менять его вручную и как не наломать дров.

Построить Rate Limiter — легко. Сделать его быстрым, отказоустойчивым и работающим в нескольких дата-центрах — сложнее. Делюсь опытом реализации нашего облачного Rate Limiter в DDoS-Guard: принцип работы, анализ правил и реальные примеры из практики.

Мы в OpenYard внимательно следим за тем, как развивается инфраструктура для искусственного интеллекта — от железа до сетей и архитектуры дата-центров. Причём это не просто рабочая необходимость, а и то, что нам самим по-настоящему интересно. В эту статью попали материалы, которые мы собираем и анализируем в процессе исследований для наших новых продуктов. Здесь собраны ключевые тренды, которые уже начинают влиять на то, как мы будем строить свою инфраструктуру и запускать модели ИИ в ближайшие 5–7 лет.

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

Всем привет, 

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

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

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

Сегодня пользователи ожидают от веб-приложений мгновенного отклика. Оптимизация производительности становится критически важной задачей для разработчиков. Один из способов повысить эффективность работы серверов и уменьшить время отклика — «прилипание» HTTP-запросов. 

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

Меня зовут Ринат Фатхуллин, я владелец продукта Platform V SynGX — веб- и обратного прокси-сервера на основе Nginx. Наш продукт полностью заместил Nginx Plus в Сбере, в том числе благодаря расширенной поддержке «липких» сессий. 

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

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

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

Единственное, что меня беспокоило — это авторизация. В мире нет ничего более желанного для ИБ и ненавистного разработчиками, чем контроль доступа. И я знал, что довольно скоро мы доберёмся и до этого вопроса.

Если вам интересно распутать клубок асинхронного взаимодействия тысяч продюссеров и консьюмеров, узнать, где документация Kafka нас обманывает, а librdkafka и Confluent.Kafka не могут договориться, и как один потерянный пакет может привести к Permission denied, добро пожаловать под хабракат. Эта история для тех, кто догадался, что недостаточно было «просто включить флажок в конфиге».

Привет, Хабр! Меня зовут Виктор Корейша и я — руководитель направления Managed Services в Ozon. Я и моя команда, в том числе, отвечаем за всю инфраструктуру асинхронного взаимодействия между сервисами, которую строим на базе Kafka. А ещё я ведущий подкастов «Кода кода» и «Три тимлида заходят в бар».

Эта статья написана по мотивам моего доклада для DevOps Conf 2025. Расскажу нашу историю про внедрение авторизации и аутентификации в Kafka. Инженеры по эксплуатации найдут в ней обзор решений реализации SASL-сервера, разработчики — историю о конфликтах в production-ready клиентах, архитекторы — любопытные кейсы взаимодействия высоконагруженных систем, ну а менеджеры — эпос о внедрении технически сложных изменений в больших компаниях.

Я — Web разработчик в команде CodeX @e11sy

Я работал над переписыванием системы уведомлений open-source трекера ошибок Хоук. Он отлавливает ошибки в ПО и присылает уведомления разработчикам. Исходная реализация была простой и не масштабируемой, что приводило к задержкам получения уведомлений.

Это - вторая публикация в серии DDD и кодогенерация. (первая часть, вторая часть, третья часть) В этой части мы научимся получать данные через рефлексию и Roslyn в одинаковой форме.

А атрибуты из Roslyn - как объекты.