Библиотека баз данных
Самая большая библиотека бесплатных книг по SQL По всем вопросам- @haarrp @ai_machinelearning_big_data - machine learning @pythonl - Python @itchannels_telegram - 🔥 best it channels @ArtificialIntelligencedl - AI РКН: № 5037640984
Показати більше📈 Аналітичний огляд Telegram-каналу Библиотека баз данных
Канал Библиотека баз данных (@sql_lib) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 10 153 підписників, посідаючи 12 007 місце в категорії Технології та додатки та 62 552 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 10 153 підписників.
За останніми даними від 27 жовтня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -23, а за останні 24 години на -1, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 8.60%. Протягом перших 24 годин після публікації контент зазвичай збирає N/A% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 873 переглядів. Протягом першої доби публікація в середньому набирає 0 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 12.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як sql, субд, индекс, user_id, архитектура.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Самая большая библиотека бесплатных книг по SQL
По всем вопросам- @haarrp
@ai_machinelearning_big_data - machine learning
@pythonl - Python
@itchannels_telegram - 🔥 best it channels
@ArtificialIntelligencedl - AI
РКН: № 5037640984”
Завдяки високій частоті оновлень (останні дані отримано 28 жовтня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
vector bucket. Внутри него вы создаете векторные индексы, указывая размерность векторов и метрику расстояния (косинусную или евклидову).
🟡Дальше все работает как магия
Вы просто загружаете в индекс свои эмбеддинги вместе с метаданными для фильтрации, а S3 берет на себя всю грязную работу по хранению, автоматической оптимизации и обеспечению субсекундного ответа на запросы. Никакого управления инфраструктурой.
Один бакет может содержать до 10 тысяч индексов, а каждый индекс, в свою очередь, десятки миллионов векторов.
🟡Главная сила этого решения - в экосистеме.
S3 Vectors бесшовно интегрируется с Bedrock Knowledge Bases. Теперь при создании базы знаний для RAG-приложения можно просто указать S3-бакет в качестве векторного хранилища.
Процесс создания RAG-пайплайна для тех, кто уже живет в облаке AWS, упрощается до нескольких кликов. То же самое касается и SageMaker Unified Studio, где эта интеграция тоже доступна из коробки.
🟡"One more thing" анонса - умная интеграция с сервисом OpenSearch.
AWS предлагает гибкую, многоуровневую стратегию. Нечасто используемые или «холодные» векторы можно экономично хранить в S3 Vectors. А когда для части данных потребуется максимальная производительность и низкая задержка в реальном времени, например, для системы рекомендаций, их можно быстро экспортировать в OpenSearch.
Это очень прагматичный инженерный подход, позволяющий балансировать между стоимостью и производительностью.
Пока сервис находится в статусе превью и доступен в регионах US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), and Asia Pacific (Sydney) Regions.
Попробовать S3 Vectors можно в Amazon S3 console.
🟡Статья
🖥Github
@ai_machinelearning_big_data
#AI #ML #RAG #Amazonjson_extract, json_set, json_insert, json_remove и других
- Примеры SQL-запросов для работы с вложенными JSON-структурами
🔧 Зачем это нужно:
- Хочешь хранить метаинформацию, конфиги или вложенные структуры — JSON в SQLite отличный выбор
- Не нужно ставить отдельную NoSQL-СУБД: всё работает локально
- Идеально подходит для embedded-приложений, десктопных утилит, мобильных приложений
💡 Примеры:
- Вставка JSON:
INSERT INTO configs (id, data) VALUES (1, '{"theme": "dark", "font": {"size": 14}}');
https://www.blackslate.io/articles/explore-sqlite-json-operations-using-jdbcinactive → banned → active?
У нас есть таблица логов смены статусов пользователей:
CREATE TABLE user_status_log (
user_id INT,
status TEXT, -- 'active', 'inactive', 'banned'
changed_at TIMESTAMP
);
Каждый раз, когда пользователь меняет статус, добавляется запись.
🔍 Найди пользователей, которые хотя бы один раз:
• стали inactive
• потом были banned
• и либо так и остались забанены, либо позже перешли в active
Важно:
• Статусы могут меняться много раз
• Нас интересует первая последовательность inactive → banned (→ optional `active`)
• Если пользователь не вернулся в `active`, всё равно считаем, что условие выполнено
---
🧠 Решение с оконными функциями:
WITH ranked_status AS (
SELECT
user_id,
status,
changed_at,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY changed_at) AS rn
FROM user_status_log
),
status_with_next AS (
SELECT
user_id,
status,
changed_at,
LEAD(status) OVER (PARTITION BY user_id ORDER BY changed_at) AS next_status,
LEAD(changed_at) OVER (PARTITION BY user_id ORDER BY changed_at) AS next_changed_at
FROM ranked_status
),
transitions AS (
SELECT
user_id,
changed_at AS from_time,
next_changed_at AS to_time,
status AS from_status,
next_status AS to_status
FROM status_with_next
WHERE next_status IS NOT NULL
),
flagged_users AS (
SELECT DISTINCT user_id
FROM (
SELECT
user_id,
MAX(CASE WHEN from_status = 'inactive' AND to_status = 'banned' THEN 1 ELSE 0 END) AS went_inactive_then_banned,
MIN(CASE WHEN from_status = 'banned' AND to_status = 'active' THEN 1 ELSE 0 END) AS banned_then_active
FROM transitions
GROUP BY user_id
) t
WHERE went_inactive_then_banned = 1
)
SELECT *
FROM flagged_users;
🧩 Почему это интересно?
• Используются оконные функции LEAD(), ROW_NUMBER()
• Нужно отслеживать последовательные пары статусов
• Объединяем логику в несколько CTE-слоёв
• Придётся думать не только о текущем статусе, но и о контексте (что было до и что после)
Подобные задачи — хороший способ прокачать мышление о временных событиях в SQL.pgvector. Это расширение позволяет сохранять и сравнивать векторы прямо внутри PostgreSQL.
📦 Установка PGVector (Linux)
git clone --branch v0.8.0 https://github.com/pgvector/pgvector.git
cd pgvector
make
sudo make install
Или просто:
• macOS: brew install pgvector
• Docker: pgvector/pgvector:pg17
• PostgreSQL 13+ (через APT/YUM)
🔌 Подключение расширения в базе
CREATE EXTENSION vector;
После этого ты можешь использовать новый тип данных vector.
🧱 Пример использования
Создаём таблицу:
CREATE TABLE items (
id bigserial PRIMARY KEY,
embedding vector(3)
);
Добавляем данные:
INSERT INTO items (embedding) VALUES ('[1,2,3]'), ('[4,5,6]');
Поиск ближайшего вектора:
SELECT * FROM items
ORDER BY embedding <-> '[3,1,2]'
LIMIT 5;
🧠 Операторы сравнения
PGVector поддерживает несколько видов расстояний между векторами:
- <-> — L2 (евклидово расстояние)
- <#> — скалярное произведение
- <=> — косинусное расстояние
- <+> — Manhattan (L1)
- <~> — Хэммингово расстояние (для битовых векторов)
- <%> — Жаккар (для битовых векторов)
Также можно усреднять вектора:
SELECT AVG(embedding) FROM items;
🚀 Индексация для быстрого поиска
HNSW (лучшее качество):
CREATE INDEX ON items USING hnsw (embedding vector_l2_ops);
Параметры можно настраивать:
SET hnsw.ef_search = 40;
#### IVFFlat (быстрее создаётся, но чуть менее точный):
CREATE INDEX ON items USING ivfflat (embedding vector_l2_ops) WITH (lists = 100);
SET ivfflat.probes = 10;
🔍 Проверка версии и обновление
SELECT extversion FROM pg_extension WHERE extname='vector';
ALTER EXTENSION vector UPDATE;
📌 Особенности
- Работает с PostgreSQL 13+
- Поддержка до 2000 измерений
- Расширяемый синтаксис
- Можно использовать DISTINCT, JOIN, GROUP BY, ORDER BY и агрегации
- Подходит для RAG-пайплайнов, NLP и встраивания LLM-поиска в обычные SQL-приложения
🔗 Подробнее
💡 Храни embedding'и прямо в PostgreSQL — и делай семантический поиск без внешних векторных БД.