Администрирование баз данных *

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

В рамках данной статьи мы не будем концентрироваться на какой-то конкретной СУБД, а посмотрим те советы, которые подойдут любой базе данных.

Недавно мы представили два новых пул-реквеста в ClickHouse, которые будут доступны в ClickHouse 24.4. Эти изменения повышают производительность JOIN'ов во многих производственных сценариях, в некоторых случаях увеличивая скорость выполнения запросов на несколько порядков.

Много лет в комьюнити PostgreSQL никто не верил что эта СУБД в принципе может использоваться в системах с большой транзакционной нагрузкой. То есть, какие-то тестовые лаборатории, бэкенд веб-приложений средней руки и так далее — вот его типичные задачи. А когда нужна серьёзная нагрузка, это уже надо брать СУБД за много денег и не сомневаться. Ну и раз никто не верил, то и не развивал особенно его в эту сторону, оставляя всё больше повисших в воздухе вопросов.

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

Мы успешно обновили кластер 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. Дополнительно вы получаете: