Настоящее исследование посвящено комплексному анализу глобальных климатических изменений на основе исторических метеорологических данных за период с 1950 по 2024 год. Мы фокусируемся на шести ключевых странах, представляющих основные климатические зоны планеты.
Greengage DB — это массивно-параллельная реляционная СУБД на базе Greenplum OSS, которая подходит для хранения и обработки данных. Позволяет выполнять сложные аналитические запросы над большими объёмами данных, предоставляя к ним гетерогенный доступ за счёт различного рода коннекторов и средств интеграции.
Но помимо функциональных возможностей, есть и ряд других необходимых вещей, таких как мониторинг, аудит, резервирование и пр. Они требуются для обеспечения полноценной и надёжной работы системы, особенно если речь идёт о промышленной эксплуатации. В рамках данной статьи как раз хочется обсудить подход к резервированию кластера Greengage: какие тут есть возможности, каковы подводные камни и многое другое.
В этой статье поговорим о не самом гламурном, но жизненно важном — маскировании данных. Маскирование может касаться имён, телефонов, номеров карт, медицинских диагнозов и другой чувствительной информации. Если ваша компания до сих пор передает данные подрядчикам или аналитикам как они есть в базе, это в один «прекрасный» момент обязательно обернётся репутационной или финансовой проблемой для бизнеса.
В этой статье разберём, зачем нужно маскирование, какие данные требуют защиты, и представим opensource-инструмент, который поможет решить эти задачи гибко и эффективно.
Привет! Я Андрей Сташок, бэкенд-разработчик в KTS. В этой статье я расскажу о запуске параллельных тестов через pytest-xdist.
Почему это важно?
Объясню на нашем примере. При разработке продуктов мы постоянно выполняем юнит-тестирование. Раньше мы проверяли все последовательно, и с расширением тестовой базы время проведения испытаний заметно возрастало. Распараллеливание через pytest-xdist помогло нам сильно ускориться, и сегодня я хочу поделиться этим трюком с вами.
Я расскажу, как запускать параллельные тесты для реляционной БД PostgreSQL (с драйверами asyncpg и psycopg2) и key-value БД Redis. Для подключения к реляционной БД мы будем использовать SQLAlchemy, а для Redis — библиотеку redis. Кроме того, я рассмотрю, как автоматизировать выполнение миграций при каждом запуске тестов с использованием alembic.
Если в таблицах БД PostgreSQL есть поля большого размера, при выгрузке часть строк таких таблиц может не выгружаться с выдачей ошибки ERROR: out of memory. Столкнуться с подобной ситуацией можно, например, при выгрузке утилитой pg_dump таблиц, в которых хранятся XML-документы, или при выгрузке таблицы public.config системы «1C:Предприятие». В статье рассматриваются причины возникновения подобных ошибок и способы решения проблемы.
Много было сказано про Serverless в нагрузках без сохранения состояния. Действительно, когда у вас есть контейнеры или функции их легко почти мгновенно масштабировать и нет большой разницы, на какой именно машине это делать.
Но данные имеют очень конкретную привязку к диску, на котором размещены. Что создает немало сложностей к самой концепции бессерверных вычислений.
В этой статье я хочу показать, где бессерверная архитектура может быть применима, и рассмотрю несколько новых, и весьма перспективных решений в этой области, таких как Neon, Warpstream и TiDB.
Когда в проекте используется составной B-tree индекс, важно не просто "создать индекс", а сделать это правильно — иначе запросы могут не только не ускориться, но и начать работать медленнее. Возникает логичный вопрос: как выбрать порядок колонок, чтобы индекс действительно работал эффективно? Брутфорсом? По интуиции? По селективности?
В этой статье я расскажу, как подходить к построению составных индексов в PostgreSQL, на что реально влияет порядок колонок. Также разберём простое правило ESR, которое помогает упростить выбор и получать стабильный прирост производительности на всех стендах.
В арсенале Postgres Pro есть мощное, но порой недооцененное оружие — декларативное секционирование. Оно только звучит сложно, а на деле позволяет элегантно «нарезать» гигантские таблицы, превращая их из неповоротливых монстров в управляемые и быстрые структуры. Делимся нетайными знаниями, которые помогут оптимизировать запросы и упростить жизнь.
Привет, Хабр!
В этой статье рассмотрим классическую проблему «мягкого удаления» на уровне схемы баз данных и её влияние на аналитику.
Почти в каждой системе встречается требование «не удалять данные окончательно».
Асинхронность в JavaScript, где и как использовать в web разработке на frontend и backend. Цепочка промисов и их параллельные выполнение.
Всем привет! Меня зовут Илья Криволапов, тружусь системным аналитиком в SENSE на проекте одного из цветных банков РФ. В профессии я уже пятый год и, несмотря на фамилию, ломал прод всего лишь несколько незначительных раз (надеюсь).
На досуге я преподаю в университете дисциплину «Хранение и обработка больших объемов данных» и за все время у меня накопилось много полезной информации. Непростительно хранить такой клад у себя в столе, поэтому я подготовил для читателей Хабра ультимативный гайд по оптимизации или хорошему такому, грамотному проектированию баз данных с расчетом на масштабирование.
Всего в цикле будет 3 статьи. В первой поговорим о двух разных подходах масштабирования БД и о том, как лучше его делать и как лучше не делать (Никогда. Пожалуйста).
Кому будет полезно? Всем отвечающим за «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.
Согласны? Узнали? Тогда поехали!
PGConf.Russia 2025 прошла в месте историческом: в Центре Международной Торговли. История её короткая, но эффектная: построили в конце 70-х, ЦМТ был сначала Совинцентром, потом «Хаммеровским центром» - это было в то время такое окно в Европу. Через окно входили и выходили технологии и бизнес. Скульптура Меркурия перед фасадом мелькала тогда то и дело в новостях. Бизнес, судя, например, по машинам на парковке, это здание (комплекс зданий) отнюдь не позабыл. Хотел написать (и, как видите, написал) круче только в Кремлёвском Дворце Съездов эту конференцию провести, но и не так, и КДС тут не при чём. Но я был впечатлён и вспоминал с некоторыми коллегами былые технологические события, проходившие здесь во времена, когда таких мест было раз два и обчёлся, а может и раз - без два.
Привет, Хабр!
Один параметр PostgreSQL может похоронить вашу производительность, если вы о нём забудете — это fillfactor. Почему однократная настройка числа приводит к неожиданным page split, bloat и мучительному откату запросов? Давайте разбираться.
Эта история началась с шутки на офисной кухне 10 декабря, но, как водится, у каждой приличной шутки, она вдруг стала интересной для воплощения, а в конце переросла в не самую технически простую реализацию с хождением по многочисленным граблям.
А началось всё просто: пока все вокруг спорят как настраивать железо и тюнить операционные системы дабы выжать лишних TPS, мы решили проверить как отреагирует движок PostgreSQL если загрузить в него действительно большой объём данных. Например, давайте сделаем базу размером один петабайт и посмотрим как он это переживёт.
На дворе было 10 декабря, руководство поставило задачу сдать отчёт 20 января, до нового года оставалось меньше месяца, а в руках появился знакомый всем инженерам зуд.
Шардирование, двухфазный коммит и распределенные транзакции окружены определенными мифами и заблуждениями. Например, может быть достаточно неочевидно, что двухфазный коммит обеспечивает только атомарность транзакций, но не их изоляцию. Поэтому мы решили написать пост, который бы помог разобраться в этих сложных вещах и сделать правильный выбор, когда Postgres'а Вам станет мало и Вы столкнётесь с шардированием.
Привет, меня зовут Костя Осипов, и я занимаюсь разработкой СУБД. На Хабре есть несколько моих статей про MySQL, Tarantool и про всякое-разное. Кроме того, я веду Telegram-канал, где делюсь инсайтами в области управления базами данных. Сегодня я выступаю в роли основателя компании Picodata, создающей одноимённую открытую СУБД, и управляющего директора ПАО Arenadata по исследованиям и разработке. Ниже — вольный пересказ моего недавнего доклада на HighLoad. Он про то, что нас ждёт в мире СУБД завтра, и, в частности, про место резидентных СУБД в архитектурах будущего.
Greenmask — это кроссплатформенный инструмент, разработанный на Go специально для безопасной работы с данными PostgreSQL: он помогает делать логические бэкапы, восстанавливать таблицы и при необходимости — анонимизировать чувствительную информацию. Главное преимущество Greenmask — полная совместимость с pg_dump и pg_restore. То есть, если вы уже работаете с этими инструментами, интеграция Greenmask не потребует пересмотра всей инфраструктуры.
Один из ключевых сценариев использования утилиты - подготовка баз данных для тестового стенда. Greenmask позволяет упростить процесс дампа продуктивных баз, обработки их для анонимизации тех же персональных данных, снижения размера баз (в тестовой среде зачастую не нужны терабайты данных с прода), восстановления дампов в тестовый контур.
Ниже в статье я опишу базовый функционал, примеры конфигураций для начала работы с Greenmask, а так же рассмотрим примеры трансформации данных при дампе таблиц.
Официальный сайт: https://greenmask.io
Документация: https://docs.greenmask.io/latest/
GitHub-репозиторий: https://github.com/GreenmaskIO/greenmask (уже 1308 звезд)
Telegram-канал: https://t.me/greenmask_ru
Коннекты обычно не приносят много головной боли на начальных этапах разработки. Вообще работа с ними обычно делается один раз, во время настройки, и дальше тюнится по необходимости. Но эта необходимость возникает часто в виде непонятных ошибок, которые выкидываются в случайных местах, непонятных графиков в графане и суеты админов вашей базы данных. Я постарался собрать ту информацию, которая позволит вам не потеряться в такой ситуации и даже поможет определить суть проблемы.
Задачи на собеседованиях. Денежные переводы в SQL. Обновление счетов и уровни изоляций
Задача перевода денег в первом приближении сводится к обновлению пары строк и кажется простой — но обеспечение корректности при параллельном доступе может быть неожиданно сложным для только знакомящихся с уровнями изоляций БД.
