💻 Выбираем базу данных правильно

В мире разработки выбор БД — ключ к производительности, масштабируемости и эффективности. Это не просто SQL vs NoSQL, а поиск инструмента под данные, нагрузку и цели бизнеса. От IoT до ИИ — тип не важен, важна задача. Разбираем:

➡️ SQL
💬 Структурированность, ACID, надёжность.
📦 Для: финансы, CRM, ERP.
📌 Примеры: MySQL, PostgreSQL.

➡️ NoSQL
💬 Document DB: JSON/XML (MongoDB, Couchbase).
🔑 Key-Value: быстрый доступ (Redis, DynamoDB).
📊 Columnar: аналитика (Cassandra, Redshift).
🔗 Graph DB: связи (Neo4j, Cosmos DB).

➡️ Специализированные
📍 Time-Series: метрики, IoT (InfluxDB, TimescaleDB).
📍 Vector DB: ИИ, поиск (Milvus, Pinecone).
📍 Spatial DB: карты (PostGIS, Oracle Spatial).

➡️ Высокая производительность
⚡️ In-Memory: скорость (SAP HANA, MemSQL).
🧱 NewSQL: масштаб + SQL (Spanner, CockroachDB).

➡️ Нишевые
🧬 Blockchain DB: доверие (BigchainDB).
📦 Object-Oriented: кодовая структура (ObjectDB).

🎯 БД — это про масштабируемость, интеллект и гибкость. Выбирайте под задачу, а не по привычке.

#sql #nosql #db

@sqlhub

🖥 Блокировка состояния 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