🖥 Нашёл любопытный проект: `cq` —-SQL query engine для CSV-файлов, написанный на C.

Что умеет:

- выполнять SQL-запросы прямо по CSV
- фильтровать, агрегировать, делать JOIN’ы
- работать быстро и без “тяжёлых” зависимостей
- подходит для логов, датасетов, ETL-скриптов и ад-hoc анализа

То есть вместо Python-скриптов или импорта в БД —
можно просто кинуть SELECT по файлу и получить результат.

⚡️ Репозиторий: https://github.com/baldimario/cq/

🖥 Большой апдейт для Postgres: нормальный поиск прямо в базе

У Postgres давно есть full-text search, но честно - качество ранжирования часто “так себе”.

Если нужен реально удобный поиск по релевантности, обычно приходилось:
- поднимать Elasticsearch
- или подключать Algolia
- и потом вечно мучаться с синхронизацией данных между системами

Проблема не в том, что Postgres не умеет искать текст.
Проблема в том, что стандартный ts_rank даёт довольно базовое ранжирование и сильно уступает современным поисковикам.

Теперь появилась альтернатива.

Команда TigerDatabase выложила в open-source расширение pg_textsearch - оно приносит BM25 ранжирование прямо в Postgres.

Почему BM25 важно:
BM25 - это алгоритм, который лежит в основе Elasticsearch/Lucene и большинства “нормальных” поисковых движков.
То есть это уже проверенный стандарт качества поиска.

Что даёт pg_textsearch:
- BM25 ранжирование с настройками параметров
- очень простой синтаксис:
ORDER BY content <@> 'search terms'
- работает с multi-language конфигами Postgres
- хорошо сочетается с pgvector для hybrid search (keyword + embeddings)

Для RAG это прям полезно:
можно делать гибридное извлечение в одной базе (Postgres),
без внешнего Elasticsearch и без лишнего glue-кода.

И всё это - open-source под лицензией PostgreSQL.

https://github.com/timescale/pg_textsearch

⚡️ Масштабирование до 1 000 000 пользователей - практичный подход с PostgreSQL

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

В начале всё было максимально просто:

Одно приложение - одна база данных.
И этого было достаточно.

Проблемы появились не в коде. Узким местом стала база данных. Архитектура развивалась шаг за шагом, решая конкретные проблемы по мере их появления.

1️⃣ Старт - один основной инстанс
Использовался один primary-инстанс PostgreSQL. Минимум инфраструктуры, низкие расходы и полный фокус на продукте.

Главная мысль этого этапа - не строить "архитектуру уровня Netflix" для проекта с десятками пользователей.

2️⃣ Разделение чтений - Read Replicas
Когда резко вырос read-трафик:

- Primary обрабатывал только записи
- Реплики обрабатывали SELECT-запросы
- Балансировщик распределял чтения

Кодовая база почти не менялась - менялась маршрутизация трафика.

Результат - база перестала быть узким местом из-за чтений.

3️⃣ Проблема соединений - добавление pgBouncer
При росте числа пользователей упёрлись не в CPU, а в количество соединений.

Каждое соединение к базе - это память и ресурсы. Тысячи коннектов начали "душить" систему.

Решение - connection pooling через pgBouncer:

- Меньше реальных соединений к БД
- Выше пропускная способность
- Меньше сбоев под нагрузкой

4️⃣ Масштабирование через кэш
Чтобы выдержать 1M+ пользователей, стало критично не обращаться к базе за каждым запросом.

Добавили Redis как слой кэширования:

- Часто используемые данные отдавались из кэша
- База перестала быть единственной точкой нагрузки
- Задержки заметно снизились

Именно на этом этапе начинается настоящее масштабирование.

Главный урок

На каждом этапе решалась текущая проблема, а не гипотетическая задача будущего.

| Проблема | Решение |
|---------|---------|
| Много чтений | Read Replicas |
| Слишком много соединений | Пул соединений |
| База перегружена запросами | Кэш |
| Сложная инфраструктура | Не добавлялась без реальной необходимости |

Приложение существует, чтобы поддерживать бизнес.
Если бизнес-модель не работает, никакое масштабирование не спасёт.

Масштабирование - это не про технологии ради технологий.
Это про внедрение решений в тот момент, когда они действительно нужны.

milanjovanovic.tech/blog/scaling-monoliths-a-practical-guide-for-growing-systems

🖥 Большинство “парсеров” умирают через 2 дня.
Ты научишься делать те, которые живут в проде.

Это не про BeautifulSoup ради галочки.
Это про системы сбора данных, которые:

• не падают от мелких правок на сайте
• собирают данные в разы быстрее
• обновляют всё сами по расписанию
• обходят ограничения и баны
• выглядят как сервис, а не хаос из файлов

Ты начнёшь видеть сайты не как страницы, а как источники данных, к которым можно подключиться.

В итоге ты сможешь:

• забирать данные для своих проектов
• автоматизировать чужую рутину
• делать инструменты для аналитики
• брать коммерческие заказы на сбор данных

Это навык, который напрямую превращается в деньги.
Не “знаю Python”, а умею добывать данные из интернета профессионально.

🎁 48 часов скидка 50% на Stepik: https://stepik.org/a/269942/

📚 SQL Чек-лист: защита базы данных от взлома

Закрой базу от интернета - БД не должна слушать 0.0.0.0 без нужды. Открывай доступ только из подсети приложения (VPC, private network).

Используй принцип наименьших прав - отдельный пользователь на каждое приложение, только нужные SELECT/INSERT/UPDATE, без SUPER/OWNER.

Пароли и секреты - длинные, уникальные, храни в Secret Manager/.env вне репозитория, регулярно ротируй.

Шифрование - включи TLS для соединений, шифруй бэкапы и диски (at-rest).

Обновления - патчи БД и ОС ставь регулярно, отключай лишние расширения и фичи.

Защита от SQL-инъекций - только параметризованные запросы, никакой конкатенации строк в SQL.

Логи и аудит - включи логирование входов, ошибок, подозрительных запросов, алерты на “подбор паролей”.

Бэкапы + проверка восстановления - делай бэкапы и обязательно тестируй restore, иначе это не бэкап.

Ограничь опасные команды - запрети DROP/ALTER в проде для app-юзеров, разнеси миграции и рантайм доступ.

Rate limiting и защита периметра - firewall/SG, fail2ban/pgbouncer limits, VPN/bastion для админки.

Postgres hardening (quick example)

ufw allow from 10.0.0.0/8 to any port 5432
psql -c "CREATE ROLE app LOGIN PASSWORD 'STRONG';"
psql -c "REVOKE ALL ON DATABASE prod FROM PUBLIC;"
psql -c "GRANT CONNECT ON DATABASE prod TO app;"
psql -c "ALTER SYSTEM SET ssl=on;"
psql -c "ALTER SYSTEM SET log_connections=on;"
psql -c "ALTER SYSTEM SET password_encryption='scram-sha-256';"
systemctl reload postgresql