Библиотека баз данных

🌟 Zvec: встраиваемая векторная база данных для RAG без внешних сервисов.

Alibaba открыла исходный код Zvec - встраиваемой векторной СУБД, которую авторы называют «SQLite для векторных баз данных».

Проект заточен на локальные RAG-пайплайны, семантический поиск и агентские сценарии на ноутбуках, мобильных устройствах или другом edge-железе.

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

Существующие решения не подходят для маломощных устройств: 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

🖥 Sql тренажеры для практики

▪sql-academy.org
▪sql-ex.ru
▪schoolsw3.com
▪SQL Fiddle
▪sqltest.online
▪Oracle LiveSQL
▪stratascratch.com
▪stepik.org (Интерактивный тренажер SQL)
▪sql-practice.com
▪pgexercises.com
▪HackerRank
▪sqlzoo.net

📌 EXISTS РАБОТАЕТ БЫСТРЕЕ COUNT

SQL-совет: перестаньте считать всё через COUNT(*)

Многие пишут так:

SELECT COUNT(*)
FROM orders
WHERE user_id = 123;

Чтобы проверить — есть ли записи.

Проблема:
COUNT(*) считает все строки, даже если нужна просто проверка существования.
На больших таблицах это лишняя нагрузка и медленный запрос.

Правильнее использовать EXISTS.

Почему это лучше:
- База останавливается на первой найденной строке
- Меньше чтения данных
- Быстрее на больших таблицах
- Использует индексы эффективнее

Пример:

-- Плохо
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
);

🔥 Полезная подборка каналов только код, практика и самые передовые инструменты, которые используют разработчики прямо сейчас.👇

🖥 ИИ: t.me/ai_machinelearning_big_data

🖥 Python: t.me/pythonl

🖥 Linux: t.me/linuxacademiya

🖥 C++ t.me/cpluspluc

🖥 Docker: t.me/DevopsDocker

🖥 Хакинг: t.me/linuxkalii

🖥 Devops: t.me/DevOPSitsec

👣 Golang: t.me/Golang_google

🖥 Аналитика: t.me/data_analysis_ml

🖥 Javascript: t.me/javascriptv

🖥 C#: t.me/csharp_ci

🖥 Java: t.me/javatg

🖥 Базы данных: t.me/sqlhub

👣 Rust: t.me/rust_code

🤖 Технологии: t.me/vistehno

💰 Экономика и инвестиции в ИИ t.me/financeStable

💼 Актуальные вакансии: t.me/addlist/_zyy_jQ_QUsyM2Vi

🖥 Chatgpt бот в тг: t.me/Chatgpturbobot

📚 Бесплатные ит-книги: https://t.me/addlist/HwywK4fErd8wYzQy

🖥Подборка по Golang: https://t.me/addlist/MUtJEeJSxeY2YTFi

⚡️ Лучшие ИИ ресурсы: https://t.me/addlist/2Ls-snqEeytkMDgy

Самое лучшее в этом: ты учишься даже тогда, когда “нет времени, просто потому что читаешь правильную ленту.

💡 SQL-совет, который спасает от самой “хитрой” ошибки

Одна из самых коварных ситуаций в SQL - когда ты ожидаешь данные, а запрос возвращает 0 строк, хотя “всё правильно”.
Чаще всего причина - `NOT IN` + `NULL`.

Если в подзапросе есть хотя бы один 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
);

🖥 Интерактивный SQL-тренажёр для аналитиков в телеграм боте:


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

✔ практические кейсы
✔ удобный эмулятор работы Аналитика бесплатно
✔ пополняем задачами с реальных собеседований
✔ собираем фидбек и улучшаем тренажёр вместе с вами

Готов работать с данными уверенно? Попробуй симулятор и расти как аналитик.

t.me/Analitics_databot

🖥 SQL-квест: фэнтезийное приключение для аналитиков данных

Представь фэнтези-мир, где заклинания - это SQL-запросы, а древние артефакты спрятаны в таблицах и JSON-документах.

🧙Ты - боевой дата-аналитик, который с помощью SQL, Python, ETL и визуализаций охотится за харизматичным злодеем Архивариусом Пакостусом, что ломает индексы, крадёт данные и готовит “шторм данных” на столицу.🔮

В каждом эпизоде тебя ждут: выборы с последствиями, хитрые задачи от простых SELECT до рекурсивных CTE и BigQuery, юмор, эпик и неожиданные повороты.

Хочешь проверить, сможешь ли ты спасти королевство не мечом, а запросами? Тогда добро пожаловать в SQL-квест.

🪄 Начать квест: https://uproger.com/sql-kvest-fentezijnoe-priklyuchenie-dlya-analitikov-dannyh/

SQL хитрый совет для про 💡

Используй 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.