Приветствуем вас на заключительном этапе в цикле статей о Greenplum. Ранее мы уже обсудили то, как выглядит архитектура системы. Посмотрели «под капот», подробнее обсудили виды хостов и их предназначение, узнали, как обрабатываются запросы пользователей.

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

Освежить память о содержании предыдущих статей можно здесь и здесь.

В данной статье мы совместно с @omoskvinрасскажем о том, что влияет на оптимальность выполнения запросов, как отслеживать различные проблемы и, конечно же, как с ними справляться. 

Привет! Меня зовут Олег Кретинин, и я разработчик в команде общих компонентов в Яндекс Еде. Сегодня я расскажу о том, как мы смогли успешно снять нагрузку с нашей базы данных, а также уменьшить её размер.

Помимо сервисов, написанных на C++, Go и Python, у нас есть монолит, он же «кора», на PHP, который всё ещё представляет огромную кодовую базу, хранит кучу логики и предоставляет данные по API для 120 сервисов.

После обновления фреймворка и версии PHP мы принялись за решение другой проблемы, которая всё чаще и чаще давала о себе знать. В тот период у нас возросло количество инцидентов, связанных с базой данных, и нам нужно было что‑то придумать, чтобы стабилизировать проект максимально быстро. Случалось, что всё сыпалось во время праздничных дней, когда количество заказов увеличивалось на 30–40%, или во время разовых массовых операций, например когда однажды в большую сеть ресторанов добавлялся бесплатный соус к каждой позиции меню.

Речь здесь пойдёт о стабильности стандартной статистики Postgres и об идее очередного расширения - на этот раз альтернативы команде ANALYZE. Всё началось с того, что заканчивая работу над предыдущей статьёй я вдруг заметил, что результат выполнения одного и того же запроса теста Join Order Benchmark (JOB) в серии последовательных прогонов может отличаться в разы и даже на порядки - причем как по значению параметра execution-time, так и по pages-read. Это выглядело очень странно, поскольку и тест и ноутбук и все настройки оставались теми же - даже погода за окном. И я решил расследовать, что происходит …

Всем привет! Меня зовут Светлана Анохина, я младший бизнес-партнёр по информационной безопасности в Ozon. Несмотря на небольшой стаж, опыт работы у меня довольно разносторонний, ведь моя роль предполагает участие практически во всех аспектах безопасности (если интересно, кто такие бизнес-партнёры по ИБ, то рекомендую почитать статьи моих коллег Даши или Максима на эту тему).

До этого я работала в команде Compliance, где активно занималась защитой данных. Сейчас моя зона ответственности охватывает безопасность в логистике и товарных операциях: склады, пункты выдачи заказов, курьерская доставка и все сопутствующие процессы.

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

Но всё изменилось, когда я впервые устроилась работать в команду безопасности данных крупной компании. Я увидела, как это выглядит в реальной жизни: настоящие утечки, реальные данные и конкретные последствия. Тогда я осознала, что даже самая простая ошибка или недосмотр могут привести к тому, что чья-то личная информация окажется у злоумышленников, и защита данных — это не прихоть, а насущная необходимость. Каждая строка кода, каждое принятое решение могут стать барьером между безопасностью и катастрофой.

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

За время своей работы в e-commerce-компаниях я собрала некоторый перечень подходов и инструментов защиты, которые реализую в своём направлении. Сегодня я хочу рассказать о маскировании вам, моим коллегам, которые так же, как и я, стремятся сделать данные безопасными, а жизнь пользователей — спокойной.

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

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

Да, IT-найм сломан, но и соискатели не упрощают ситуацию потенциальным руководителям и себе самим. Пара примеров, как не надо делать.

При использовании DAX аналитикам важно следить не только за корректностью результатов, но и за производительностью системы при обработке запросов. Одним из инструментов повышения эффективности является корректное использование функции SUMMARIZE. Всем, кто работает с большими объемами данных, активно изучает синтаксис DAX, а также интересующимся особенностями SUMMARIZE — добро пожаловать под кат!

Это продолжении серии статей о принятых изменениях в PostgreSQL 18. На этот раз речь пойдет о завершившемся в ноябре коммитфесте.

А самое интересное из предшествующих коммитфестов можно прочитать здесь: 2024-07, 2024-09.

Согласно статистике, в сентябрьских коммитфестах меньше всего коммитов. Но похоже, что для релизного цикла 18-й версии это не так. Много принятых патчей и много интересных новых возможностей, информацией о которых хочется поделиться.

Напомню, что самое интересное из июльского коммитфеста можно прочитать здесь: 2024-07.

Подумал, что необходим небольшой пост, посвященный сетевым адаптерам/интерфейсам, которые устанавливают в своих ИТ-ландшафтах пользователи. Речь пойдет не столько о конкретных моделях, сколько про то, что сеть такой же компонент информационной системы (как и те же диски, память, CPU), и на него нужно обращать не менее тщательное внимание. Многие его просто игнорируют и недооценивают – «Ну сеть и сеть, что там с ней может быть не так? Вот же 10 Гбит/с. Вот график пропускной способности. Всё прекрасно.».

Продолжаем посты на тему технических интервью. Новый пост, который мы позаимствовали у автора Дилана Смита, будет для джунов по специальностям «Системный аналитик», «Backend‑разработчик» и «Fullstack‑разработчик». Иногда такой вопрос также попадается на интервью архитекторам и инженерам баз данных. Ответ на вопрос из заголовка может быть как очень коротким, где всего четыре пункта, так и развернутым — включая примеры кода и диаграммы. Естественно, мы рассмотрим тему во всех подробностях.

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

В этой части совсем простая идея по одновременному решению систем линейных уравнений "пачками".

Некоторое время назад я запустил Telegram-бота для мониторинга сайтов и обозначил в нём тариф из двух строчек.

Сколько строк на SQL понадобилось для реализации такого тарифа и как в целом устроен биллинг в моём боте расскажу в статье.

Некоторое время назад я запустил Telegram-бота для мониторинга сайтов и обозначил в нём тариф из двух строчек.

Сколько строк на SQL понадобилось для реализации такого тарифа и как в целом устроен биллинг в моём боте расскажу в статье.

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

Плюс в статье делюсь своей технической реализацией в ознакомительных целях.

Привет, Хабр! Меня зовут Кирилл Салихов, и я занимаюсь разработкой бизнес-приложений на платформе .NET в компании КРОК. При оптимизации процессов развертывания приложений возник вопрос о том, как эффективно хранить SQL-код, предназначенный для применения к базе данных, чтобы избежать необходимости в ручном труде и перемещении файлов.

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

Привет, Хабр!

Сегодня рассмотрим проблему N+1 запросов в Django. N+1 запросы появляются, когда ваш код делает много мелких SQL-запросов вместо нескольких крупных.

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

В этой части используем двойную рекурсию для "раскраски" регионов на карте.

Этот вопрос волнует многих начинающих аналитиков и даже тех, кто уже частично освоил профессию, но не уверен, пришло ли время делать следующий шаг.

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

Привет, Хабр! В этой статье я хотел бы поговорить про особенности план-факт анализа, а также о работе с денормализованной таблицей, которая «была, есть и будет использоваться», потому что оказывается удобной для некоторых приемов работы с BI. Под катом вы найдете 7 примеров решения типовых задач план-факт анализа, включая расчет долей, отображение данных с учетом иерархии, разбивку по регионам и так далее. Всех, кому интересны эти практические аспекты, жду под катом :)