🌊 ETL на стероидах: стриминг данных Postgres в реальном времени на Rust 🦀

Supabase выкатили интересный open-source фреймворк - supabase/etl, который позволяет стримить данные из Postgres куда угодно в реальном времени.

Это набор простых, модульных Rust-блоков, из которых можно собрать собственный конвейер Change Data Capture (CDC). Вы получаете полный контроль над тем, как обрабатывать изменения в базе и куда их отправлять — без тяжёлых платформ и сложных конфигов.

Что делает этот фреймворк полезным:

- Прямой стриминг изменений из Postgres (CDC)
- Rust — значит скорость, надёжность и низкие накладные расходы
- Гибкие компоненты: можно строить свои конвейеры под любые нужды
- Подходит для интеграций, аналитики, событийных систем, real-time обновлений
- Легче и прозрачнее, чем классические ETL/ELT-платформы

По сути, это конструктор, из которого можно быстро собрать real-time data pipeline:
достал изменения из Postgres → преобразовал → отправил в Kafka, ClickHouse, S3, API — куда угодно.

Если вы работаете с потоковыми данными, аналитикой или микросервисами - стоит попробовать. Rust + CDC - это мощное сочетание для стабильных и быстрых пайплайнов.

https://github.com/supabase/etl

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

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

→ Некачественно написанный SQL приводит к высоким задержкам, росту нагрузки на CPU и проблемам в нагруженных сервисах.

Основные принципы оптимизации:

✓ 1. Анализ планов выполнения
Он подчёркивает необходимость использовать EXPLAIN / EXPLAIN ANALYZE, чтобы увидеть, как база реально исполняет запрос: где происходят полные сканирования таблиц, плохие джоины или отсутствуют индексы.

✓ 2. Индексация
Он рекомендует ставить индексы на часто используемые поля и ключи, применять составные индексы, но избегать чрезмерной индексации, чтобы не замедлять записи.

✓ 3. Отказ от SELECT *
Он настаивает на выборе только нужных столбцов — это снижает трафик и ускоряет выполнение.

✓ 4. Оптимизация джоинов
Нужно правильно выбирать тип JOIN, индексировать поля, участвующие в соединениях, и избегать слишком глубоких джоин-цепочек.

✓ 5. Грамотные WHERE-фильтры
Фильтровать данные как можно раньше, использовать индексируемые колонки и избегать функций в WHERE, которые «ломают» индексы.

✓ 6. Ограничение числа строк
Использовать LIMIT / OFFSET и постраничный вывод, а не отдавать пользователю огромные выборки.

✓ 7. Избежание проблемы N+1
Фетчить связанные данные заранее через JOIN или батч-запросы.

✓ 8. Кэширование
Он предлагает кэшировать частые запросы с помощью Redis или Memcached, чтобы уменьшить нагрузку на базу.

✓ 9. Нормализация и денормализация
Нормализация уменьшает дублирование, денормализация ускоряет чтение — важно выбирать подход под задачу.

✓ 10. Оптимизация вставок и обновлений
Использовать bulk insert, проверять необходимость обновлений.

✓ 11. Партиционирование таблиц
Он предлагает разбивать большие таблицы по дате или региону, что особенно полезно для логов и аналитики.

Эти рекомендации помогают backend-разработчикам строить более быстрые, масштабируемые и надёжные системы.

🚨 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));

На AI Journey презентовали крупнейший open-source проект в Европе: Сбер открыл доступ к своим флагманским моделям - GigaChat Ultra-Preview и Lightning, а также новое поколение открытых моделей GigaAM-v3 для распознавания речи, все модели генерации изображений и видео новой линейки Kandinsky 5.0 — Video Pro, Video Lite и Image Lite.

GigaChat Ultra-Preview, новая MoE-модель, 702 миллиарда параметров, собранная под русский язык и натренированная полностью с нуля. Читайте подробный пост от команды.

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

Флагманская модель Kandinsky Video Pro сравнялась с Veo 3 по визуальному качеству и обогнала Wan 2.2-A14B. Читайте подробный пост от команды.

Код и веса всех моделей теперь доступны всем пользователям по лицензии MIT, в том числе для использования в коммерческих целях.

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

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

Пояснения:

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

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

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

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

🔥 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;

📌 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/