🖥 Блокировка состояния Terraform с использованием S3 (без DynamoDB)

В этом посте мы рассмотрим:

- Зачем нужна блокировка состояния Terraform
- Блокировка состояния с помощью DynamoDB
- Блокировка состояния только с использованием S3, без DynamoDB
- Когда стоит использовать DynamoDB
- Когда можно обойтись только S3
- Лучшие практики хранения state-файлов в S3

🔗 Подробнее

#devops #девопс

@sqlhub

🚀 AWESOME DATA SCIENCE

Репозиторий данных с открытым исходным кодом для изучения, применения и решения реальных проблем в data science.

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

🖥 GitHub

@sqlhub

👣 Оптимизация выделения памяти в Go: как одна строчка замедлила всё на 30%

В базе данных Dolt (аналог Git, но для SQL-таблиц) после рефакторинга один из бенчмарков (types_scan) внезапно стал работать на 30% медленнее. Причина? Казалось бы, невинная строчка кода.

📉 Что произошло
Метод GetBytes() начал вызывать ReadBytes() у интерфейса ValueStore. Всё выглядело логично, пока не включили профилировщик Go и не обнаружили странную активность:
🔍 runtime.newobject вызывался слишком часто → программа делала много лишних аллокаций в куче.

📦 Где зарыта собака

func (vs nodeStore) ReadBytes(...) ...

Этот метод использовал приёмник по значению (vs nodeStore). Это значит, что вся структура копировалась при каждом вызове метода, даже если она большая.

🚑 Как пофиксили
Просто поменяли на приёмник по указателю:

func (vs *nodeStore) ReadBytes(...) ...

Вуаля — аллокейшны исчезли, производительность восстановилась.

🧠 Вывод
❗ Методы с приёмником по значению = риск лишнего копирования и аллокаций
🛠 Даже один маленький метод может резко замедлить ваш код
🔍 Профилировка в Go — мощный инструмент. Используй pprof!

Полный разбор в блоге DoltHub
Подробнее про Dolt

@golang_google

🖥 Задача: “Невидимая строка”

Дана таблица users:

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name TEXT,
  deleted_at TIMESTAMP
);

Вы выполняете:

SELECT COUNT(*) FROM users WHERE deleted_at = NULL;

✔️ И получаете... 0. Хотя вы уверены, что есть пользователи, у которых deleted_at не задано.

Вопрос:
Что не так с запросом? Как правильно получить количество “неудалённых” пользователей?

Вопрос: В чем ошибка? И как надо правильно писать такой фильтр?

✔️ Правильный запрос будет выглядеть так:

Чтобы проверить, является ли значение NULL, нужно использовать специальный оператор IS NULL.

SELECT COUNT(*) FROM users WHERE deleted_at IS NULL;

Этот запрос корректно найдёт все строки, где в столбце deleted_at действительно отсутствует значение (т.е. он равен NULL), и посчитает их количество.

Итог:
Не используйте = или != для сравнения с NULL.
Используйте IS NULL для проверки на NULL.
Используйте IS NOT NULL для проверки на не NULL (если бы вам понадобилось посчитать удалённых пользователей, у которых deleted_at заполнено).

@sqlhub

✔️ Presto (prestoDB/presto)

Это высокопроизводительный распределённый движок SQL для анализа больших объёмов данных в реальном времени. Основные характеристики:

Распределённая архитектура
Состоит из координатора и множества воркеров, которые параллельно выполняют фрагменты запросов, обеспечивая низкую задержку даже при обработке петабайтовых данных
GitHub

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

Плагинные коннекторы
Из коробки доступны коннекторы к Hive (HDFS/S3), Cassandra, Kafka, MongoDB, MySQL, PostgreSQL, Elasticsearch и многим другим системам хранения. При желании можно написать собственный плагин
GitHub
.

Масштабируемость и отказоустойчивость
Горизонтальное масштабирование за счёт добавления воркеров, автоматическое перераспределение задач при выходе узлов из строя.

Удобство развёртывания
Можно собрать из исходников через Maven (./mvnw clean install), развернуть через Docker (официальный образ есть в папке docker/), или сразу использовать готовые пакеты на prestodb.io.

Клиенты и интеграции
Имеется CLI (presto-cli), JDBC/ODBC‑драйверы, REST API. Лёгко встраивается в BI‑инструменты и платформы визуализации.

Сферы применения
Ad‑hoc‑аналитика, интерактивные дашборды, federated query (объединение данных из разных источников), подготовка данных для машинного обучения.

https://github.com/prestodb/presto

@sqlhub

✔️ Wal-listener — это инструмент для прослушивания логов транзакций PostgreSQL (WAL) и конвертации их в удобный для обработки формат JSON.

Возможности

- Прослушивание изменений в PostgreSQL в режиме реального времени.
- Поддержка нескольких слотов репликации.
- Удобный вывод в формате JSON.
- Готов к использованию в качестве сервиса.

Пример использования

1. Создаём слот репликации:

   SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');
   

2. Запускаем wal-listener:

   wal-listener --dsn "host=localhost port=5432 user=postgres dbname=test" --slot test_slot
   

3. Получаем JSON-объекты при изменениях в базе данных.

https://github.com/ihippik/wal-listener

#devops #девопс #PostgreSQL #sql

@sqlhub

🖥 Задача: Анализ пользовательского поведения с аномалиями в SQL

## Условие задачи:

Дана таблица user_events со следующей структурой:

CREATE TABLE user_events (
    user_id INT,
    event_time TIMESTAMP,
    event_type VARCHAR(50),
    platform VARCHAR(50)
);

🎯 Каждая строка описывает событие пользователя:
- user_id — идентификатор пользователя,
- event_time — время события,
- event_type — тип события (`login`, purchase, logout, error и т.д.),
- platform — платформа (`iOS`, Android, `Web`).

Требуется:

1. Найти пользователей, которые:
- Выполнили покупку (`purchase`),
- Но не заходили в систему (`login`) в течение последних 7 дней перед покупкой.

2. Найти пользователей, у которых:
- Более 30% всех событий за последний месяц составляют события типа error.

3. Рассчитать для каждого пользователя:
- Среднее время между входом (`login`) и следующим выходом (`logout`).
- Если logout отсутствует после login — игнорировать такую сессию.

---

## Дополнительные условия:

- Считайте, что данные могут быть объемными: миллионы строк.
- Решение должно быть оптимизировано: избегайте подзапросов в подзапросах без индексов, старайтесь минимизировать количество проходов по данным.
- Можно использовать оконные функции (`WINDOW FUNCTIONS`) и временные таблицы (`CTE`) для упрощения запросов.
- Платформу можно игнорировать в расчетах.

---

## Что оценивается:

- Умение использовать оконные функции и агрегаты.
- Умение правильно интерпретировать условия задачи в SQL-операции.
- Оптимизация запросов под большие объемы данных.
- Чистота, читаемость и структурированность кода SQL-запросов.

---

Примечание:
Эта задача проверяет как технические навыки работы с SQL, так и внимательность к деталям формулировки задачи. Небрежная реализация может дать неверные результаты, особенно на больших данных.

🔥 Подсказки и намёки для решения задачи

## Задание 1: Найти пользователей с покупками без логина за последние 7 дней

**Намёк:**
- Используйте оконную функцию LAG() или MAX() с фильтрацией событий login.
- Для каждой покупки проверяйте, был ли login в пределах 7 дней до события purchase.
- Можно применить LEFT JOIN событий login к событиям purchase.

## Задание 2: Найти пользователей с долей ошибок > 30%

**Намёк:**
- Используйте оконные функции COUNT(*) и SUM(CASE WHEN event_type = 'error' THEN 1 ELSE 0 END).
- Постройте долю ошибок на основе всех событий пользователя за последние 30 дней (`WHERE event_time >= CURRENT_DATE - INTERVAL '30 days'`).

## Задание 3: Рассчитать среднее время между login и следующим logout

**Намёк:**
- Используйте оконную функцию LEAD() для поиска следующего события после login.
- Пара login -> logout должна иметь корректный порядок по времени.
- Отбрасывайте случаи, где следующего logout нет или это событие другого типа.

@sqlhub