Методы получения высокой производительности систем
Привет! Меня зовут Антон Головенко и я backend-разработчик команды Search-Quality в Авито. Вот уже полтора года я ускоряю производительность поиска и повышаю его надежность, а также участвую в интеграции новых продуктов. В статье расскажу о том, как мы тестировали Redis под нагрузкой, с какими проблемами столкнулись, как их решали и какие выводы сделали. Заголовок звучит кликбейтно — но вы скоро поймёте, что он полностью оправдан.
Вполне логично предположить, что сократитель ссылок — довольно простой сервис как с точки зрения пользователя, так и под капотом. Но что, если, взяв за основу такую простую задачу, построить целую распределенную систему?
Мой шортенер начинался как простая практика с Go и gRPC после всех ОГЭ:), где должно было быть 3 сервиса: тг бот, API gateway и ядро. Но с каждым днем идей все больше, энтузиазм растёт, я стал делать упор на высокие нагрузки, и постепенно мини‑практика начала становиться боевой event-driven машиной. В этой статье я хотел бы подметить интересную мысль: даже самая простая вещь может быть реализована сложно.
О паттернах отказоустойчивой архитектуры написано уже немало. Но когда дело доходит до реальных кейсов, особенно в специфических отраслях вроде лотерейной — информации почти нет. А ведь здесь, как и в любой высоконагруженной системе, отказоустойчивость — не просто галочка в ТЗ, а вопрос пользовательского доверия и бизнес-репутации.
В этой статье расскажем, как мы в «Столото» подошли к проектированию Lottery Payment System. Это полностью вымышленный сервис для выплат выигрышей, построенный на опыте реальных вызовов и ограничений для того, чтобы на его примере описать, как работают ключевые паттерны отказоустойчивой архитектуры: Retry, Idempotency Key, Deadlines, Rate Limit и Circuit Breaker. Также покажем, как они применяются в контексте распределённой системы, которая должна стабильно работать, даже когда вокруг всё пошло не по плану.
В нашем вымышленном сценарии мы представили, что компания прошла через архитектурную трансформацию и решила переосмыслить доменные области. Слишком громоздкий и хрупкий процессинг тормозил развитие. В какой-то момент он стал похож на башню из кубиков, которую боишься задеть. Поэтому мы выбрали путь здорового прагматизма — выплаты вынесли в отдельный сервис, чтобы дать этому направлению и стабильность, и простор для развития. В зоне его ответственности — всё, что связано с переводами пользователям, которые хотят получать выигрыши по лотерейным билетам и исполнять свои мечты.
Будет немного архитектуры, чуть-чуть лирики и много практики. Это не скучный туториал — это живая история гипотетического продукта, в котором отказоустойчивость стала краеугольным камнем. Если вы работаете с высоконагруженными системами, и вам важно, чтобы ваши системы не падали — добро пожаловать.
В 2024 году компания xAI, основанная Илоном Маском, запустила суперкомпьютерный кластер Colossus в Мемфисе. Его построили всего за 122 дня, что не много для такой мощной системы. С тех пор Colossus несколько раз наращивали, и теперь его ждет следующий, еще более масштабный апгрейд. Сегодня поговорим о том, как устроен Colossus, что за технологии в нем используются и какие задачи он должен решать. Поехали!
Control plane Kubernetes — как сейф с главными ключами. Он управляет кластером, хранит sensitive-информацию и зачастую представляет собой лакомую цель для злоумышленников.
В этой статье — разбор того, как спрятать control plane в сервисе Managed Kubernetes, предоставляемом в облаке: зачем это нужно, какие варианты существуют и с какими проблемами мы столкнулись на практике. Рассмотрим несколько open source решений, которые протестировали у себя в поисках надёжного способа изолировать control plane-ноды от пользователя и сделать их недоступными для какого-либо внешнего взаимодействия.
Меня зовут Каиржан, я DevOps/Software-инженер в команде разработки MWS Cloud Platform, пишу на Go под Kubernetes и ClusterAPI. Наша команда разрабатывает сервис Managed Kubernetes для публичного облака — от инфраструктуры до собственных провайдеров для ClusterAPI. Поэтому вопрос безопасности control plane (CP) для нас стоит особенно остро.
Будучи разработчиками, мы постоянно стремимся создавать системы, которые не просто работают, но и отличаются эффективностью и масштабируемостью. В мире, где пользователи ожидают всё более быстрые и точные результаты, оптимизация производительности поиска становится ключевым приоритетом в современной разработке приложений.
Эта статья основана на нашем выступлении на конференции QCon San Francisco 2024, где мы рассмотрели эволюцию подходов к индексированию данных, их извлечению и ранжированию. Для платформ вроде Uber Eats, обрабатывающих сложные запросы на больших объёмах данных, оптимизация поиска — это серьёзный вызов, требующий продвинутых стратегий: индексирования, шардинга и параллельной обработки запросов.
Сложность поисковых систем продолжает расти, и необходимость соблюдения баланса между скоростью, релевантностью и масштабируемостью становится как никогда актуальной. В этой статье мы рассматриваем ключевые техники таких оптимизаций и их влияние на пользовательский опыт и производительность системы.
Когда имеется несколько индексов с одинаковыми ведущими столбцами, иногда выбирается не лучший индекс, и время выполнения запроса увеличивается на порядки. Такие ситуации встречаются в сложных приложениях, но чаще всего в 1С:ERP, поскольку это приложение наиболее распространено. Как это обычно бывает: после миграции приложения на СУБД PostgreSQL часть запросов начинает выполняться медленнее. Планировщик выбирает индекс, созданный по меньшему числу столбцов, время выполнения увеличивается, потому что при использовании такого индекса индексные записи указывают на строки таблицы, которые не соответствуют условиям соединения. При выборе же индекса по большему числу задействованных в запросе столбцов время выполнения становится существенно ниже и практически не зависит от размера таблиц.
В статье детализируется часть доклада Максима Старкова на конференции PG BootCamp, которая прошла в апреле в Екатеринбурге. Описываются признаки таблиц и индексов, при работе с которыми может возникнуть проблема выбора худшего индекса, а также рассматривается пример, демонстрирующий, что строка "Buffers" характерна для определения эффективности выполнения запроса (в 18 версии PostgreSQL "Buffers" будет показываться в планах по умолчанию).
ScyllaDB — это высокопроизводительная NoSQL база данных, созданная как улучшенная версия Apache Cassandra на C++. Она способна обрабатывать миллионы операций в секунду, что делает ее лидером среди распределенных баз данных. Такая производительность достигается благодаря особой архитектуре хранения данных, в центре которой находится процесс компактизации данных. Правильный выбор стратегии компактизации данных и ее оптимизация - это ключ к высокой производительности и отказоустойчивости распределенной базы данных ScyllaDB.
В этой статье рассмотрены все стратегии компактизации, их преимущества и недостатки, а также приведен детальный алгоритм выбора стратегии компактизации под конкретные use cases.
Все говорили о микросервисах. Гибкость. Масштабируемость. Независимые команды. Звучало как мечта. Многие компании бросились распиливать свои монолиты. Разработка действительно ускорилась. Отдельные компоненты стало проще обновлять и разворачивать.
А потом сервисам понадобилось общаться. И мечта превратилась в сложную, многомерную головоломку.
Всех постоянно интересует, как сделать Postgres быстрее, эффективнее и всё такое, но никто не задумывался, как её замедлить. Да, большинству этих людей платят за то, чтобы они повышали скорость, но ко мне это не относится. Недавно я писал более полезное руководство, и мне вдруг пришла мысль, что кто-то должен попробовать создать такую конфигурацию Postgres, которая будет настроена на максимально медленную обработку запросов. Зачем? Сложно сказать, но вот такая возникла мысль.
Предлагается к рассмотрению метод динамического определения форматов хранения и типов индексации в таблицах аналитической базы данных Dimension DB. На основе метаданных из источников данных (SQL-запросов, таблиц или представлений) определяется формат хранения или представления данных, а по текущему распределению данных, автоматически определяется тип индексирования.
Даже сложная и продуманная технологическая система не застрахована от инцидентов — это касается любых инфраструктур, от железнодорожных и коммунальных до IT. Поэтому инженерам, которые обеспечивают надёжность систем, важно не только предотвращать проблемы, но и минимизировать их влияние за счёт хорошего антикризисного (или DR) плана.
Меня зовут Костя Крамлих, я отвечаю за сетевую виртуализацию и сетевые сервисы в Yandex Cloud. К написанию этой статьи меня подтолкнула наша работа по предотвращению крупных инцидентов, наподобие тех, что произошли в конце 2024 года. Разрешить их удалось благодаря слаженной работе всей команды, и по итогам мы сделали выводы, которые не ограничиваются только устранением сетевых аварий.
Сегодня по материалам реальных событий расскажу о сетевой части:
— что важно знать о том, как ломаются большие системы, на наших примерах;
— как мы проанализировали все наши инциденты за последний год и что сделали, чтобы предотвратить появление проблем на инфраструктуре;
— как подошли к внедрению этих улучшений небольшими шагами, чтобы они не стали источником новых инцидентов.
Для чего используют кластеризацию серверов СУБД? Вопрос не совсем праздный, особенно для крупных компаний. Если с кластеризацией/масштабированием серверов приложений, терминалов, web-серверов и т. д. все понятно и прозрачно, то вот с СУБД не всё так просто. Особенно для 1С систем.
Всем привет! Кажется, настало время поговорить о том, как внедрялись ограничители частоты запросов на бэкенд в Wildberries. В статье — о том, с какими трудностями мы столкнулись на этом благородном пути и как прошли через четыре схемы реализации — от простейшей in-memory до собственных gRPC-сервисов. Не обойдём вниманием и парочку лайфхаков ;) Например, с помощью рейтлимитов мы неожиданно решили проблему плавного отключения старых версий API.
Меня зовут Дмитрий Виноградов, и я лид команды публичного API Wildberries. До этого почти 18 лет занимался промышленной автоматизацией в Schneider Electric — от программирования контроллеров и embedded-устройств до собственных SCADA-систем. Хочешь не хочешь, а научишься делать красивые интерфейсы :)
Привет, Хабр! В этой статье я расскажу про наш LLM инференс-кластер YADRO: зачем он нужен, что у него под капотом и как в такой конфигурации показывают себя популярные модели. Кроме того, я немного порассуждаю об альтернативных реализациях кластера и поделюсь планами по развитию реализации нашей.
Привет, Хабр. Меня зовут Роман Ескин, я один из C разработчиков проекта Greengage DB. В этой статье я расскажу, как мы реализовали и протестировали lock-free подход в рамках масштабной работы по внедрению функции удаления брошенных файлов. Приглашаю вас заглянуть во внутреннюю кухню работы нашей команды при оценке этой функциональности.
Введение
Позвольте начать с краткой исторической справки: Greengage DB был запущен в 2024 году как open-source форк Greenplum — Massively Parallel Processing (MPP) аналитической системы управления базами данных, основанной на PostgreSQL. Мы начали этот проект, чтобы поддержать open-source сообщество Greenplum, который неожиданно стал проприетарным продуктом в мае 2024 года. Мы гарантируем дальнейшее развитие Greengage DB, следуя принципам открытости и прозрачности.
Так как Greengage DB основан на PostgreSQL, он унаследовал некоторые его известные особенности и проблемы. Одна из таких проблем, особенно актуальная в распределенных средах — это проблема "брошенных файлов" (orphaned files).
Эта проблема возникает, когда таблица создается и данные загружаются в рамках активной транзакции. Если происходит критический сбой до того, как транзакция будет закоммичена или отменена (например, внезапное отключение питания или неожиданное завершение работы узла базы данных), система проходит процесс восстановления после падения (crash recovery). При этом логическая таблица откатится, но физические файлы данных, связанные с этой незакоммиченной таблицей, могут остаться в файловой системе. Со временем такие брошенные файлы могут накапливаться, занимая место и приводя к ненужному расходу ресурсов. В настоящее время их удаление происходит вручную.
Недавно мы представили новый функционал, который позволяет автоматически удалять такие брошенные файлы. Полная информация об этой возможности доступна в статье Удаление брошенных файлов в Greengage DB.
Привет, Хабр! За то время, пока существует Онтико, мы подготовили вместе со спикерами тысячи докладов. И точно знаем, что спикер тоже человек и как любой человек он может сомневаться.
Мы поговорили с психологами и опытными докладчиками, чтобы разобрать страхи, знакомые каждому начинающему спикеру. В этой статье — пошаговый разбор, как выбрать тему, которую точно примут, как перестать бояться недостатка опыта и подготовить доклад без выгорания.
При создании временных таблиц в PostgreSQL изменяются до 13 таблиц системного каталога, при этом особенно сильно разрастаются pg_attribute, pg_class, pg_depend и pg_type. Массовое создание и усечение временных таблиц активно применяется, в том числе в 1C:ERP. В статье рассматриваются особенности работы с временными таблицами и описано решение проблемы раздувания таблиц системного каталога, реализованное в СУБД Tantor Postgres.
Сегодня использование HTTPS стало практически обязательным для большинства веб‑приложений. Angie позволяет эффективно обрабатывать HTTPS‑трафик, обеспечивая при этом высокий уровень безопасности. В новых протоколах HTTP/2 и HTTP/3 использование защищённого соединения обязательно. Однако, как обычно, есть много деталей в конфигурации, которые мы последовательно разберём в этой статье.
Уже несколько лет компания AMD предлагает совершенно атомные, а точнее ядерные, а ещё точнее суперМНОГОЯДЕРНЫЕ процессоры Epyc. В этой статье мы рассмотрим основные «бутылочные горлышки», настройки биос и другие вещи, которые мешают раскрыть потенциал этих процессоров.