Базы данных *

Во времена пика интереса к NoSQL базам данных простоватые K-V хранилища были несколько обойдены вниманием - отчасти это понятно, вещь не очень "инновационная", можно даже сказать старинная. В то же время своя "ниша" у них находится до сих пор (не считая того что они используются в более сложных БД в качестве индексов).

В то же время в обычной SQL-ной базе проекта порой "не хватает" такого общего K-V хранилища для разнородных (семантически) записей. В своих проектах я такую обычно завожу. Среди коллег этот подход порой вызывает негатив :)

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

Переезд с Microsoft на Linux - это то, с чем сталкивается последнее время практически каждый инженер, и меня сия чаша тоже не миновала. Но за годы работы с MS я привык раздавать права на все что угодно через группы в AD и отказываться от этого совершенно не хотелось.

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

В статье рассматривается пошаговое создание образов «с нуля» для контейнерного движка Podman. Внутрь контейнера «упакована» база данных Oracle Database 21c Express Edition. И всё это отечественной операционной системе РЕД ОС.

*2 контейнера

Сегодня я к вам с новым практическим проектом на Python. На этот раз мы создадим полноценного Telegram-бота для продажи цифровых товаров с базой данных, которой будем управлять через SQLAlchemy 2, админ-панелью, пользовательской частью и интегрированной оплатой через Юкассу.

Я шаг за шагом проведу вас через все этапы разработки такого бота: начиная от регистрации токена в BotFather и заканчивая деплоем готового продукта на удаленном хостинге, чтобы бот мог бесперебойно работать 24/7 без привязки к вашему компьютеру или интернет-соединению.

Это третья и заключительная часть цикла статей по настройке памяти в PostgreSQL. Полагаю, она получилось уже не такой заумной, как предыдущие две, и представляет из себя некий сухой остаток с собирательным примером, в котором показано как выбирать параметры PostgreSQL по настройке оперативной памяти. Если же хочется погрузиться в руду, то милости просим в Часть 1 и Часть 2. Тем не менее, цепочка логических рассуждений сохранена – как делаем, зачем и почему.

Привет, Хабр! Мы завершаем серию статей о миграции аналитического хранилища данных с платформы Teradata на GreenPlum. В предыдущих статьях мы рассказали о нашем опыте и результатах автоматизированного переписывания SQL‑скриптов с помощью реализованных сервисов миграции кода и переноса архива данных. В этот раз мы расскажем вам о нашем опыте и результатах кросс‑платформенной проверки качества данных во время и после миграции, а также о трудностях и решениях, связанных с этим процессом.

Завершая нашу серию, мы подходим к ключевому аспекту миграции данных — проверке и обеспечению качества данных после переноса. Теперь, когда перед нами стоят два параллельно функционирующих хранилища, возникает вопрос о точности и согласованности данных между ними.

Часто в распределенных ИТ-ландшафтах компании используют несколько хранилищ данных под разные задачи. Это делает их важным компонентом любой системы Change Data Capture (CDC) — они помогают отслеживать изменения данных и связывать используемые хранилища. Но далеко не все CDC-инструменты способны ответить на актуальные запросы бизнеса.

Меня зовут Евгений Афанасьев. Я архитектор VK Tech в команде Tarantool. В этой статье я расскажу о том, с какими вызовами сталкиваются современные компании при работе с данными и как на них помогает отвечать Tarantool CDC.

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

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

Недавно мы представили два новых пул-реквеста в 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, которые постоянно развивались, и в которых иногда появлялись изменения, нарушающие обратную совместимость. Всё это привело к тому, что инженеры, в масштабах всей организации, тратили много времени на поддержку и оптимизацию механизмов доступа к данным наших микросервисов.