Мы успешно обновили кластер PostgreSQL с версии 13 до 16, обеспечив минимальный простой и высокую производительность. Процесс включал в себя создание новой реплики через логическую репликацию, перенос роли мастера на обновлённую реплику и настройку потоковой репликации. Несмотря на некоторые сложности, такие как управление LSN и проблемы с подписками, нам удалось сохранить данные и обеспечить синхронизацию.
Подробности читайте в статье.
Netflix продолжает расширять бизнес и диверсифицироваться в различных направлениях, вроде доставки видео по запросу и гейминга. В результате всё важнее становятся технологии, обеспечивающие загрузку временных (темпоральных) данных в системы компании и их хранение. Речь идёт об огромных объёмах данных, измеряемых петабайтами. А задержки доступа к этим данным должны укладываться в миллисекунду. В предыдущих материалах мы рассказывали о нашем слое абстракции для хранения данных типа «ключ-значение», и о платформе, реализующий возможности шлюза данных. И то и другое — это неотъемлемые части подсистемы, отвечающей в Netflix за работу с данными. Система хранения данных типа «ключ-значение» — это гибкое и хорошо масштабируемое решение для работы со структурированными данными соответствующего формата. А шлюз данных — это платформа, которая даёт компании базовую инфраструктуру, обеспечивающую защиту, настройку, развёртывание компонентов, ориентированных на работу с данными.
В этой статье мы создадим учебный проект, демонстрирующий мощную связку FastAPI, Redis и Celery на примере системы временного хранения файлов. Наше приложение будет обладать функцией автоудаления файлов и удобным веб-интерфейсом, что позволит наглядно продемонстрировать возможности этого современного стека технологий.
Мы пошагово разберем процесс разработки, начиная с настройки FastAPI для обработки HTTP-запросов, интеграции Redis для эффективного хранения метаданных файлов, и заканчивая использованием Celery для асинхронного выполнения задач по удалению устаревших файлов.
Статья будет полезна разработчикам, желающим углубить свои знания в области современной веб-разработки на Python и получить опыт работы с передовыми инструментами и фреймворками.
Привет! Меня зовут Макс, я backend-разработчик в компании ИдаПроджект и автор YouTube-канала PyLounge.
Эта вторая часть большой статьи по Django-миграциям для начинающих. Если вы пропустили или потеряли первую часть — держите ссылку.
Что здесь будет? Разберем фиктивное применение, миграции данных, «сухую проверку» и основные проблемы, которые возникают у начинающих. Также поделюсь полезными советами и подсвечу детали работы. Примеры из практики — обязательно будут.
Дисклеймер (как и в первой части, чтобы не было недопониманий): все примеры специально упрощены, чтобы неокрепший ум выцепил концепции, а не детали реализации. Не бейте, или бейте там, где синяков не видно :)
В то время, как пользователи видят позитивные стороны технологий, мы, разработчики, обычно сталкиваемся с ограничениями/недоработками/багами и видим наш продукт с совсем другой стороны. Вот и в этот раз: после публикации результатов сравнительного тестирования где я прогонял запросы теста Join-Order-Benchmark на базе с партициями и без, меня не отпускало ощущение, что всё-таки что-то я не досмотрел и при наличии партиций постгрес должен строить план хуже, чем без них. И это должен быть не просто баг, а технологическое ограничение. И вот, методом разглядывания потолка удалось-таки найти тонкое место - запросы с лимитами.
Оптимизация Asymmetric Join (AJ) — это новый подход к объединению партицированных связей (partitioned relation, PR) и непартицированных связей (non-partitioned relation, NR). Она заключается в том, что каждая партиция присоединяется с помощью NR, а результаты объединяются путём APPEND. Всё это выглядит как эволюция техники partitionwise join (PWJ).
Наша компания — Netflix — способна организовывать бесперебойную, высококачественную потоковую передачу видео миллионам пользователей благодаря своей надёжной глобальной серверной инфраструктуре. В самом центре этой инфраструктуры лежит множество онлайновых распределённых баз данных. Среди них — Apache Cassandra — NoSQL-СУБД, известная высокой доступностью и хорошей масштабируемостью. Cassandra играет роль опорной технологии для множества самых разных возможностей Netflix: от механизма входа пользователя в систему — до хранения истории просмотренных материалов и до поддержки аналитики реального времени и прямых трансляций.
Со временем появлялись новые базы данных типа «ключ-значение» (Key-Value, KV), владельцы сервисов вводили в строй новый функционал. В результате мы столкнулись с массой сложностей, связанных с неправильным использованием хранилищ данных. Во-первых — разработчикам сложно оперировать такими понятиями, как производительность хранилищ данных, согласованность и устойчивость данных. Ведь речь идёт о взаимодействии со сложной системой глобальных масштабов, представленной множеством хранилищ. Во-вторых — разработчикам приходилось постоянно переучиваться, осваивая новые подходы к моделированию данных и распространённые, но очень важные паттерны доступа к данным. В перечень сложностей, встающих перед разработчиками, входят высокие задержки, которым подвержен небольшой процент запросов, находящихся в «хвосте» распределения задержек (tail latency) и идемпотентность операций. Тут же можно упомянуть и поддержку работы «широких» разделов хранилищ с множеством строк, и работу в условиях, когда для хранения данных применяется единственный «толстый» столбец, и медленную пагинацию ответов. Кроме того — наши системы были связаны с множеством собственных API разных баз данных — с API, которые постоянно развивались, и в которых иногда появлялись изменения, нарушающие обратную совместимость. Всё это привело к тому, что инженеры, в масштабах всей организации, тратили много времени на поддержку и оптимизацию механизмов доступа к данным наших микросервисов.
Как эффективно организовать процесс обмена знаниями в компании, минимизировать потерю времени и повысить продуктивность команды. В статье делимся проверенными инструментами и подходами из личного опыта техписов, которые сделали взаимодействие внутри команды удобным и результативным.
Зачем вообще "надёжно" стирать данные? Главное же, чтобы пользователь через интерфейс СУБД не мог их достать. Мало ли, что там за остатки данных в файлах болтаются, это же не проблема. Или нет?
Меня зовут Сергей Гребенюк, я лидер разработки Sidec (Росреестр). Расскажу, как решили задачу объединения двух топиков с соотношением один ко многим и почему не устроило решение на Kafka-streams (kafka docs) и RocksDB (github). А также о том, как, опираясь на гарантии доставки exactly-once (EOS) (confluent docs), смогли снизить требования к ресурсам в несколько раз.
На иллюстрации показаны два подхода к объединению топиков: с persistent cache и in-memory cache. Мы перейдём от первой схемы ко второй.
Apache Kafka — популярный распределенный брокер сообщений, который собирает и сохраняет сообщения (данные) со всех источников, а после предоставляет их программам и сервисам-получателям. Благодаря своей производительности и архитектуре инструмент довольно активно используется в проектах, где нужно гонять большие объемы данных. Но даже возможностей Kafka не всегда достаточно — иногда системам нужен буст по скорости и надежности. И получить его можно с помощью кэширования данных в Tarantool.
Меня зовут Никита Молоствов. Я старший программист в команде разработки VK Tech. В этой статье я расскажу о том, как можно наладить взаимодействие Kafka и Tarantool, зачем может понадобиться кэширование потока из Kafka в Tarantool, и дам подробную пошаговую инструкцию, с которой каждый сможет применить мои наработки в собственной системе.
Оу, таблица merchants2? Ну, у нас кончились столбцы в merchants, так что мы сделали merchants2.
Когда я начал заниматься программированием в детстве, я не знал, что людям за это платят. Даже когда я закончил высшую школу, я предполагал, что мир "профессиональной разработки" был устроен совершенно иначе, чем мой код, написанный в свободное время. Когда мне посчастливилось попасть на первую работу разработчиком, я быстро понял насколько я был прав и неправ. Моя первая работа была "испытанием огнём", и по сей день эта кодовая база является и худшей, и лучшей из тех, с которыми я работал. И пусть она навеки останется закрытой в стенах той конкретной компании, я всё же могу поделиться парой самый забавных и страшных историй.
В этой статье мы создадим полноценный мини-блог на FastAPI с нуля, используя современные технологии веб-разработки. Вы узнаете, как реализовать JWT-аутентификацию, работать с Markdown и создать привлекательный пользовательский интерфейс.
Мы рассмотрим асинхронную работу с SQLAlchemy 2, включая сложные запросы и связи ManyToMany, а также интеграцию фронтенда с использованием Jinja2.
Этот проект демонстрирует, как создать функциональный блог, подобный Telegraf, преодолевая его ограничения и расширяя возможности.
Backend-разработка может быть довольно сложной из-за огромного количества инструментов, библиотек и пакетов, из которых приходится выбирать.
Однако правильные инструменты способны значительно облегчить работу разработчика.
Сегодня мы познакомимся с 10 инструментами, которые сделают backend-разработку проще.
Этот список вас удивит.
<h2>1. Encore — фреймворк для backend‑разработки на TypeScript и Go, предназначенный для создания надёжных и типобезопасных приложений.</h2>
Создание масштабируемых приложений с использованием облачных сервисов часто сопряжено с плохим опытом разработки. Разработчикам приходится управлять сложной инфраструктурой и выполнять рутинные задачи, что замедляет их работу.
Encore помогает решить эту проблему, предлагая полный набор инструментов, ускоряющий разработку приложений.
Это как если бы у вас была кухня, полностью укомплектованная ингредиентами и инструментами, и вы могли бы сразу приступить к готовке, не тратя время на сбор всего необходимого.
Encore предоставляет opensource-фреймворк для backend-разработки (на TypeScript и Go), который позволяет определять инфраструктуру в виде типобезопасных объектов прямо в вашем приложении, объединяя инфраструктуру с кодом приложения. Encore автоматически занимается предоставлением инфраструктуры и DevOps, анализируя код приложения.
Это позволяет быстро создавать готовые к продакшену backend’ы, используя такие инструменты, как микросервисы, Postgres и Pub/Sub, без излишней сложности и забот о DevOps. Дополнительно вы получаете:
Запутались в выборе платформы для работы с документацией? Функций море, терминология запутанная, а вариантов столько, что глаза разбегаются—даже опытные специалисты порой теряются! Мы собрали для вас 10 ключевых критериев, которые помогут найти идеальную систему управления документацией без лишней головной боли. Давайте разберёмся вместе!
Резервное копирование является важнейшей частью управления базами данных, гарантируя, что данные будут восстанавливаемы и защищены от неожиданных сбоев. Избитую фразу про две категории людей, которые не делают бэкапы и которые уже делают бэкапы, можно назвать грустной самоиронией, за которой стоят террабайты потерянных данных и сотни миллионов рублей списанных убытков.
В этой статье рассмотрим задачу управления резервным копированием для PostgeSQL с помощью популярного Open Source решения PG Back Web.
Качество данных и его значение для среднего бизнеса. Что такое качество данных? Почему качество данных так важно для среднего бизнеса? Кто относится к среднему бизнесу в России? Основные риски низкого качества данных. Основные рекомендации по выбору решений.
