Data Science. SQL hub

Полезная шпаргалка по консольным командам Git 👍

В Git полно команд, и если ты часто их забываешь, эта шпаргалка специально для тебя. В репозитории можно быстро почитать об основных командах и концепциях, а затем одним вальяжным нажатием на Ctrl+C скопировать их.

Приятный бонус — всё написано на русском. Так что сохраняем!

#git #шпаргалка

📦 Распределенная база данных FoundationDB 🚀

FoundationDB — это распределенная база данных, оптимизированная для обработки больших объемов структурированных данных. Она использует упорядоченное хранилище ключ-значение и поддерживает ACID-транзакции, обеспечивая высокую производительность как для чтения, так и для записи.

🚀Основные моменты:
- Поддержка ACID-транзакций для надежности данных.
- Высокая производительность для рабочих нагрузок с частыми записями.
- Гибкая архитектура для масштабирования на кластерах серверов.
- API для взаимодействия на различных языках программирования.

📌 GitHub: https://github.com/apple/foundationdb

@sqlhub

🐘 Postgres использует архитектуру «отдельный процесс на каждое подключение», поэтому в большинстве случаев вам нужен connection pooler.

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

1) Session pooling - каждое приложение-подключение закрепляется за одним pooled-соединением.
2) Transaction pooling - каждую транзакцию привязывают к pooled-соединению и освобождают сразу после завершения.
3) Statement pooling - каждое выражение получает соединение, но нет поддержки многозапросных транзакций, что сильно ограничивает кейсы.

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

Именно transaction pooling, тот режим, который PlanetScale применяет для всех своих PgBouncer-инстансов.

@sqlhub

Microsoft запустила VibeVoice Realtime на Hugging Face - лёгкую стриминговую text-to-speech модель, которая начинает озвучивать текст примерно за 300 миллисекунд.

Идеально для живых данных и разговоров с LLM.

huggingface.co/microsoft/VibeVoice-Realtime-0.5B

🖥 Оптимизация запросов с индексами

Индексы могут значительно ускорить выполнение ваших запросов в SQL, особенно на больших таблицах. Убедитесь, что вы создали индексы на колонках, которые часто используются в условиях WHERE и JOIN.

CREATE INDEX idx_customer_lastname ON customers(last_name);

SELECT * FROM customers
WHERE last_name = 'Smith'
ORDER BY first_name;

SELECT COUNT(*) FROM orders
WHERE customer_id IN (SELECT id FROM customers WHERE last_name = 'Smith');

SQLite-Vec — крошечная и портативная vectorDB на базе SQLite

SQLite-Vec — это сверхлёгкая и очень быстрая векторная база данных, встроенная прямо в SQLite. Идеальный вариант для on-device RAG, edge-приложений и локальных AI-сценариев без тяжёлой инфраструктуры.

Почему это интересно:
- Работает поверх обычного SQLite
- Минимальный оверхед и высокая скорость
- Отлично подходит для локального поиска по эмбеддингам

Ключевые возможности:
- Matryoshka embedding slicing — работа с усечёнными эмбеддингами
- До 32x экономии места за счёт бинарной квантизации
- Поддержка метрик L2, cosine и Hamming distance
- SQL-запросы для vector search без отдельной vectorDB

По сути, это vector search без Kubernetes, без сервисов и без боли — просто SQLite с суперспособностями.

Отличный выбор для:
- локальных RAG-агентов
- десктопных AI-приложений
- embedded-систем
- офлайн-поиска по знаниям

🔍 Быстрый клиент PostgreSQL для разработчиков

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

🚀Основные моменты:
- Мгновенный запуск за 2 секунды
- Редактор запросов с подсветкой синтаксиса
- Поддержка темного и светлого режимов
- Безопасное хранение учетных данных
- Анализ производительности запросов

📌 GitHub: https://github.com/Rohithgilla12/data-peek

🕒 Расширенный планировщик задач для PostgreSQL

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

🚀 Основные моменты:
- Полностью управляемая конфигурация через базу данных
- Поддержка YAML для удобного определения цепочек задач
- Возможность передачи параметров и автоматического повторения задач
- Встроенные задачи, такие как отправка email и импорт файлов
- Расширенные возможности планирования по типу cron

📌 GitHub: https://github.com/cybertec-postgresql/pg_timetable

@sqlhub

🖥 SQL большой гайд. Как правильно выбрать ORM

Эта статья - не про «как написать SELECT, а про настоящую инженерную работу: принципы нормализации, дизайн схем, практики оптимизации SQL, работа с транзакциями, и главное - как выбрать и использовать ORM так, чтобы он помогал, а не мешал.

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

Готовы? Тогда начинаем строить архитектуру, которую не стыдно масштабировать.

https://uproger.com/sql-bolshoj-gajd-kak-pravilno-vybrat-orm/

@sqlhub

🔥 На stepik вышел курс, который учит Создавать настоящие AI-сервисы, а не просто запускать скрипты?

Этот практический курс по Python и FastAPI покажет, как собрать полноценное приложение с ИИ, базой данных, автогенерацией контента и Telegram-ботом.

Ты пройдёшь путь от первого HTTP-запроса до рабочего сервиса, который сам генерирует текст через ИИ, сохраняет данные, отправляет результаты по расписанию и отвечает пользователям.

Никакой теории ради теории - только практические шаги, из которых рождается реальный продукт.

🎁 48 часов действует скидка в 40% процентов

👉 Начать учиться на Stepik

📌 Durable Execution Engine на SQLite:

• Durable Execution (DE) - это подход, который позволяет выполнять длинные многошаговые процессы так, чтобы после сбоя можно было продолжить с последнего успешного шага, а не запускать всё заново.

• В статье показан простой Proof of Concept - Persistasaurus: лёгкий DE-движок на Java, который использует SQLite как хранилище состояния.

• Потоки (flows) пишутся как обычный Java-код: методы помечаются аннотациями @Flow и @Step, а их прогресс автоматически сохраняется. Если процесс падает, можно безопасно перезапустить его без повторного выполнения шагов.

• Идея не новая, но современная Java + SQLite позволяют сделать удивительно компактное и понятное решение без тяжёлой инфраструктуры.

Почему это полезно:

• Упрощает работу с долгоживущими процессами
• Избавляет от повторных вычислений и экономит ресурсы
• Подходит для прототипов, внутренних сервисов и задач средней сложности

Что учитывать:

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

🔗 Читаем тут: morling.dev/blog/building-durable-execution-engine-with-sqlite/

🐘 Открыт прием заявок на выступления для специалистов по PostgreSQL

Мероприятие: PG BootCamp Russia — официальное российское комьюнити-мероприятие PostgreSQL
Когда: весна 2026 г. (дата уточняется)
Где: г. Москва
Больше о мероприятиях PG BootCamp

В отличие от коммерческих конференций, предметом докладов выступает «ванильная» версия этой СУБД. Темы выступлений, связанные с коммерческими продуктами, не принимаются. Доклады (их обычно до 16 в два трека) делятся по темам разработки и эксплуатации. Формат предполагает камерную атмосферу, максимальную практическую пользу и содержательное профессиональное общение.

Открыт прием заявок на выступления:

🔹Исследование внутренней архитектуры PostgreSQL
🔹 Оптимизация производительности в высоконагруженных системах
🔹Анализ сложных задач и методов их решения
🔹 Инструменты и методологии для DBA
🔹 R&D-исследования, связанные с Postgres

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

🎙Подать заявку на выступление

🖥 Выбор NoSQL базы данных в бэкенд-разработке

✓ Введение
Правильный выбор NoSQL базы критически важен для построения масштабируемых и гибких backend-систем.
NoSQL решает задачи, где классические SQL-базы ограничивают: работа с неструктурированными данными, огромные объёмы информации и экстремальные нагрузки.

✓ 1. Когда выбирать NoSQL
- Когда данные неструктурированные или полуструктурированные
- Когда нужна горизонтальная масштабируемость
- Когда важна высокая скорость чтения и записи
- Когда строгие схемы SQL тормозят разработку

✓ 2. Типы NoSQL баз данных и где их применять

• Документные базы (MongoDB, CouchDB)
- Идеальны для JSON-подобных документов
- Гибкие схемы
- Подходят для CMS, профилей пользователей, каталогов товаров

• Key-Value хранилища (Redis, DynamoDB)
- Максимальная скорость операций
- Отличны для кэша, хранения сессий, лидербордов
- Для простых структур данных и быстрых lookup-запросов

• Колонковые базы (Cassandra, HBase)
- Оптимизированы под огромные объёмы записей
- Используются в аналитике, IoT, потоках событий
- Масштабируются горизонтально практически бесконечно

• Графовые базы (Neo4j, JanusGraph)
- Созданы для данных со сложными взаимосвязями
- Подходят для соцсетей, рекомендаций, antifraud-систем

✓ 3. Как выбрать NoSQL базу
- Тип данных: документы, ключ-значение, графы, wide-columns
- Требования к масштабированию
- Паттерны запросов: lookup, обход графов, агрегации
- Баланс между консистентностью и доступностью (CAP)
- Готовые интеграции, драйверы, инструменты
- Нагрузка на чтение и запись
- Сложность настройки и поддержки

✓ 4. Сильные стороны NoSQL
- Масштабирование “вширь”
- Гибкость схем
- Высокая доступность
- Поддержка огромных массивов данных

✓ 5. Ограничения NoSQL
- Иногда более слабая консистентность
- Ограниченные возможности сложных запросов
- Нет строгих отношений как в SQL
- Порог вхождения для SQL-разработчиков

→ Хочешь глубже разобраться?
В *Backend Development with Projects Ebook* разберёшь, как выбирать, проектировать и интегрировать NoSQL в реальных проектах.

@sqlhub

🖥 Что нового для разработчиков в Oracle AI Database 23.26.0

В свежем релизе появилось сразу несколько функций, которые упрощают аналитику, делают работу с API удобнее и улучшают интеграцию SQL с JavaScript.

🔹 Главное обновление

- Появилась SQL клауза QUALIFY. Теперь можно фильтровать результаты оконных функций напрямую, без вложенных подзапросов. Упрощает сложные аналитические выборки.

- Добавлена функция GRAPHQL(). Можно выполнять запросы к базе в синтаксисе GraphQL и получать JSON ответ. Полезно для API сервисов и современных приложений.

- В MLE JavaScript теперь поддерживаются SQL объекты и коллекции. Это позволяет возвращать и принимать пользовательские типы прямо из JS функций.

- Для PL SQL пакетов появилось ключевое слово RESETTABLE. Обновление пакета больше не вызывает ORA 04068, что делает деплой безопаснее.

📈 Зачем это нужно

Обновление делает Oracle удобнее для разработчиков, особенно если вы строите API, используете аналитику, комбинируете SQL и JavaScript или разрабатываете приложения с AI и ML нагрузкой.

https://www.geraldonit.com/whats-new-for-developers-in-oracle-ai-database-23-26-0/

@sqlhub

🔥 SQL разбор ошибок

Одна из самых частых ошибок в SQL - вытаскивать слишком много строк без явных условий фильтрации. Люди часто пишут запросы без WHERE, забывают ограничивать выборку и получают огромные таблицы, перегруженные джоины и медленные отчёты.

Особенно опасно - JOIN без условий: это создаёт декартово произведение и может положить базу.

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

SELECT *
FROM users
JOIN orders
-- Ошибка: отсутствует ON, создаётся декартово произведение
LIMIT 100;

-- Правильно:
SELECT u.id, o.id
FROM users u
JOIN orders o ON o.user_id = u.id
LIMIT 100;

3 вида шардирования баз данных:

• Range-based — разбивает данные по диапазонам значений ключа
• Hash-based — выбирает шарду с помощью хеш-функции
• Tenant-based — каждому клиенту (тенанту) выделяется своя отдельная база

Пояснения:

Range-based sharding делит данные по диапазонам ключа (например: ID 1–1 000 — первая шарда, 1 001–2 000 — вторая).

Hash-based sharding использует хеш от ключа, чтобы определить, в какую шарду поместить или откуда прочитать запись. Это даёт более равномерное распределение.

Tenant-based sharding выделяет каждому клиенту собственную базу данных, что упрощает изоляцию, миграции и управление данными.

Просто, понятно и работает во всех масштабах.

🖥 Вышли новые релизы для тех, кто использует PostgreSQL в окружениях с несколькими СУБД.

IvorySQL 5.0
Свежий релиз проекта, который развивает редакцию PostgreSQL с целью обеспечить максимальную совместимость с Oracle.

Ключевые особенности:
- работает как почти полная замена стандартного PostgreSQL
- добавлена настройка compatible_db, включающая режим совместимости с Oracle
- подходит для приложений, изначально написанных под Oracle
- код на C
- лицензия Apache 2.0

IvorySQL позиционируется как прозрачный переходный слой между экосистемами PostgreSQL и Oracle.

Источник
postgresql точка org слеш about слеш news слеш ivorysql 50 released major oracle compatibility expansion on postgresql 180 foundation 3180

https://www.postgresql.org/about/news/ivorysql-50-released-major-oracle-compatibility-expansion-on-postgresql-180-foundation-3180/

🚨 SQL Никогда НЕ ДЕЛАЙ ТАК #sql

НИКОГДА НЕ ЛОМАЙ ИНДЕКСЫ ФУНКЦИЯМИ: не оборачивай индексируемые поля в функции внутри WHERE.

Как только ты пишешь LOWER(), CAST(), COALESCE() или любые вычисления по колонке — индекс перестаёт работать, и запрос падает в полное сканирование таблицы.

Это одна из самых тихих причин, почему запросы внезапно превращаются в тормоза.

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

 Плохо: индекс по email НЕ используется  
SELECT *  
FROM users  
WHERE LOWER(email) = 'user@example.com';

-- Хорошо: нормализуем значение заранее  
SELECT *  
FROM users  
WHERE email = 'user@example.com';

-- Или создаём функциональный индекс (PostgreSQL)  
CREATE INDEX idx_users_email_lower ON users (LOWER(email));