Библиотека баз данных
Самая большая библиотека бесплатных книг по SQL По всем вопросам- @haarrp @ai_machinelearning_big_data - machine learning @pythonl - Python @itchannels_telegram - 🔥 best it channels @ArtificialIntelligencedl - AI РКН: № 5037640984
Показати більше📈 Аналітичний огляд Telegram-каналу Библиотека баз данных
Канал Библиотека баз данных (@sql_lib) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 10 349 підписників, посідаючи 11 949 місце в категорії Технології та додатки та 63 517 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 10 349 підписників.
За останніми даними від 04 червня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -67, а за останні 24 години на -3, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 6.12%. Протягом перших 24 годин після публікації контент зазвичай збирає 2.99% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 634 переглядів. Протягом першої доби публікація в середньому набирає 310 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 2.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як sql, субд, индекс, user_id, архитектура.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Самая большая библиотека бесплатных книг по SQL
По всем вопросам- @haarrp
@ai_machinelearning_big_data - machine learning
@pythonl - Python
@itchannels_telegram - 🔥 best it channels
@ArtificialIntelligencedl - AI
РКН: № 5037640984”
Завдяки високій частоті оновлень (останні дані отримано 05 червня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
📎Решение застарелых архитектурных проблем PostgreSQL для современных нагрузок и масштабирования 📎Временные таблицы для Postgres. Почему это важно для платформы 1С и что можно улучшить? 📎Разделение Compute и Storage: архитектурный прорыв для PostgreSQL в облаке 📎Опыт вынесения OLAP-нагрузки на реплику 📎Highload "из ниоткуда": когда проблема не в СУБД, а в клиентской архитектуре 📎Опыт эксплуатации, проблемы и производительность PostgreSQL на Эльбрус, Baikal-S, Loongson, Repka Pi, x86 📎Поиск проблем планирования запросов до их воздействия на производительность 📎Тестирование, баги и уроки работы с патчем 64-битного счетчика транзакций PostgreSQL 📎Работа с логами PostgreSQL 📎…и другие (всего 25 выступлений)🗓 19 марта 📍 Москва, офлайн + онлайн ➡️ БЕСПЛАТНАЯ РЕГИСТРАЦИЯ
Существующие решения не подходят для маломощных устройств: Faiss дает только ANN-индекс без скалярного хранилища и крэш-рекавери; DuckDB-VSS ограничен в опциях индексирования; Milvus и облачные векторные хранилища требуют сеть.Под капотом - Proxima, векторный движок продакшен-уровня, который Alibaba сама использует в собственных сервисах. Поверх него сделали лаконичный Python API: 🟢полный CRUD и поддержка схем; 🟢поиск по нескольким векторам для комбинации разных эмбеддинг-моделей; 🟢встроенный реранкер с weighted и RRF; 🟢гибридный поиск (векторный + фильтры по скалярным полям) с инвертированными индексами. Это позволяет собирать локальных ассистентов, которые одновременно используют семантический поиск, множественную фильтрацию и несколько эмбеддинг-моделей - все в одном движке. По производительности Zvec заявляет победу на бенче VectorDBBench с датасетом Cohere 10M - более 8 000 QPS при сопоставимом реколле. Это вдвое больше, чем у лидера ZillizCloud и с более быстрым построением индекса. Авторы объясняют успех глубокой оптимизацией под CPU: SIMD, кэш-эффективные структуры, многопоточность и prefetching. Пока платформенная поддержка ограничена (Windows отсутствует), но для Linux x86/ARM64 и macOS Zvec уже готов к экспериментам на Python 3.10–3.12. 📌Лицензирование: Apache 2.0 License. 🟡Статья 🟡Документация 🖥GitHub @ai_machinelearning_big_data #AI #ML #VDB #ZVEC #Alibaba
-- Плохо
SELECT COUNT(*)
FROM orders
WHERE user_id = 123;
-- Хорошо
SELECT EXISTS (
SELECT 1
FROM orders
WHERE user_id = 123
);
-- Или в условии
SELECT *
FROM users u
WHERE EXISTS (
SELECT 1
FROM orders o
WHERE o.user_id = u.id
);🔸 Узнаете об эффективных подходах — от тактических SQL-приёмов до стратегических архитектурных решений. 🔸 Разберёте конкретные методы, применимые к любой СУБД, и тонкие нюансы оптимизации. 🔸 Получите готовый набор фишек для ускорения запросов и витрин уже на следующий день.Проведет вебинар Георгий Семенов, руководитель команды Analytics Engineering в Яндексе. Его опыт (VK, Wildberries, ЦУМ, ВТБ) и 14 лет в управлении IT-проектами — это концентрат практических знаний без воды. Все участники получат в подарок практический урок из курса SQL Pro про оптимизацию запросов — навсегда. Ускорьте свою аналитику одним кликом: simulative.ru/web-sql-speedup
NULL, то NOT IN ломает логику и не вернёт ничего.
Правило:
- ❌ Не используй `NOT IN` с подзапросами
- ✅ Используй `NOT EXISTS` или LEFT JOIN ... IS NULL
-- ❌ ПЛОХО: NOT IN ломается из-за NULL
SELECT *
FROM users u
WHERE u.id NOT IN (
SELECT user_id
FROM banned_users
);
-- ✅ ХОРОШО: NOT EXISTS безопасен
SELECT *
FROM users u
WHERE NOT EXISTS (
SELECT 1
FROM banned_users b
WHERE b.user_id = u.id
);COUNT(*) FILTER вместо CASE WHEN — быстрее, чище и читаемее.
❌ Как делают обычно:
SELECT
COUNT(CASE WHEN status = 'success' THEN 1 END) AS success_cnt,
COUNT(CASE WHEN status = 'error' THEN 1 END) AS error_cnt
FROM events;
✅ Как делают профи:
Копировать код
SELECT
COUNT(*) FILTER (WHERE status = 'success') AS success_cnt,
COUNT(*) FILTER (WHERE status = 'error') AS error_cnt
FROM events;
Почему это важно:
- меньше вычислений внутри агрегаций
- оптимизатору проще строить план
- код короче и легче поддерживать
- особенно эффективно в аналитических запросах
Где работает:
- PostgreSQL
- SQLite (частично)
- DuckDB
- ClickHouse (через аналоги)
Мелочь, но именно из таких мелочей складывается SQL уровня senior.IN (subquery) - почти всегда выгоднее заменить его на EXISTS.
❌ Часто медленно:
SELECT *
FROM orders o
WHERE o.user_id IN (
SELECT u.id FROM users u WHERE u.country = 'US'
);
✅ Обычно быстрее и безопаснее:
SELECT *
FROM orders o
WHERE EXISTS (
SELECT 1
FROM users u
WHERE u.id = o.user_id
AND u.country = 'US'
);
Почему это важно:
- IN может материализовать подзапрос целиком
- EXISTS работает как semi-join и рано останавливается
- Лучше масштабируется на больших данных
- Меньше сюрпризов с NULL
Особенно критично в PostgreSQL, MySQL и Oracle на больших таблицах.
Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
