Что такое векторная база данных?

От базовых понятий, таких как что такое вектор?, до продвинутых возможностей: настройка payload'ов, гибридный поиск, шардинг, мультитенантность, квантизация, RBAC и многое другое.

Эта статья охватывает всё, что нужно знать о векторных базах данных 🌹

👉 @SQLPortal

Краткая и точная шпаргалка по SQL.

👉 @SQLPortal

В Postgres есть удобные команды psql, начинающиеся на \d, для получения информации о таблицах. Вот полезные примеры:

Таблицы

\d — список всех объектов (таблиц, вьюх, индексов и т.п.)
\d <table_name> — описание конкретной таблицы
\dt — список только таблиц
\dti+ — таблицы с информацией о размере и типе
\dp — права доступа к таблицам

Индексы

\di — список всех индексов
\di <index_name> — описание конкретного индекса

Представления (views)

\dv — список всех вьюх
\dv <view_name> — описание конкретной вьюхи

Эти команды экономят время при анализе схемы БД прямо из psql.

👉 @SQLPortal

B-деревья — самая распространённая структура данных для индексов в базах данных.

Но как они работают?

Попробуй этот интерактивный онлайн-инструмент, чтобы увидеть это на практике:

> Дерево остаётся сбалансированным при добавлении новых значений
> Поиск ключей происходит путём обхода дерева

👉 @SQLPortal

Избегай ошибок при приведении значений к другому типу данных в Oracle SQL с помощью:

CAST ( ... AS <data type> DEFAULT [ NULL | <val> ] ON CONVERSION ERROR )

Если значение не может быть преобразовано, будет возвращено [ NULL | <val> ] вместо ошибки.

Это также работает в функциях, специфичных для типов, например TO_DATE и других.

👉 @SQLPortal

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

👉 @SQLPortal

Хочешь меееедленный код для базы данных?

Начни с написания цикла, а внутри него помести SQL-операторы, обрабатывающие по одной строке за итерацию: 😂

FOR i IN 1 .. n LOOP  
  [SELECT | UPDATE | DELETE] ... WHERE col = i;  
END LOOP;

Чтобы сделать быстро — обрабатывай все данные одним SQL-запросом

👉 @SQLPortal

Единственный MCP-сервер, который вам когда-либо понадобится

MindsDB позволяет выполнять запросы к данным из 200+ источников — Slack, Gmail, соцсетей и других — с помощью SQL или естественного языка.

Федеративный движок запросов с встроенным MCP-сервером.

✅ Полностью open-source
⭐️ 31k+ звёзд на GitHub

👉 @SQLPortal

В PostgreSQL есть специальный параметр для логирования долго выполняющихся запросов — log_min_duration_statement.

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

ALTER DATABASE postgres SET log_min_duration_statement = '500ms';

Это полезно для того, чтобы:

> определить, какие запросы работают медленно;
> понять, где можно добавить индексы для повышения производительности.

Параметр можно задать и на уровне сессии, если нужно логировать (или, наоборот, исключить из логирования) только конкретные запросы:

SET log_min_duration_statement = '20000ms';

log_min_duration_statement — действительно мощный инструмент, но мы обычно не рекомендуем устанавливать его на очень низкие значения (0, 1 или 5 мс), так как это приведёт к логированию практически всех операций базы данных. Это создаст шум в логах и может занять много места на диске.

👉 @SQLPortal

Ищешь бесплатную базу данных MongoDB?

✓ Трафик включён
✓ 512 МБ хранилища
✓ 3000 операций в секунду

Без ограничения по времени использования — идеально для практики

> free-mongo-db

👉 @SQLPortal

Для фоновых задач, таких как vacuum и создание индексов, Postgres использует специальное выделение памяти под названием maintenance_work_mem. Обычные запросы используют work_mem, чтобы определить, сколько памяти может быть выделено на одну операцию или соединение.

Если требуется ускорить выполнение задач, таких как:

> выполнение vacuum,
> создание индексов,
> создание индексов для материализованных представлений,

используйте:

SET maintenance_work_mem = '8GB';

Установите значение, которое предоставит вашим операциям больше памяти. По умолчанию используется 64MB. Этот параметр можно задать как глобально на уровне системы, так и локально для одной сессии.

👉 @SQLPortal

Если у вас есть пространственные данные, которые вы хотите визуализировать на карте, этот блог показывает, как подключить QGIS — инструмент с открытым исходным кодом для картографии — к базе данных PostgreSQL/PostGIS

👉 @SQLPortal

При разработке приложений для бронирования Postgres значительно упрощает задачу предотвращения перекрытия бронирований.

С помощью ограничения EXCLUDE можно гарантировать, что не будет создано двух бронирований с одинаковым room_id на пересекающиеся временные интервалы, обеспечивая целостность данных на уровне базы данных

👉 @SQLPortal

Базы данных PostgreSQL с высокой нагрузкой на запись могут исчерпать идентификаторы транзакций (transaction IDs). Обычно это становится проблемой при достижении около 2 миллиардов транзакций. В критический момент PostgreSQL завершает работу, чтобы предотвратить повреждение данных.

Для большинства приложений это никогда не вызывает проблем. Но для систем с очень интенсивной записью за этим нужно следить. 🤵

Обычно решение заключается в выполнении VACUUM или настройке параметров автovacuum, чтобы строки и транзакции корректно очищались.

Если вы хотите проверить, насколько вы близки к wraparound (переполнению XID), вот запрос для диагностики:

WITH max_age AS (
  SELECT
    2000000000 AS max_old_xid,
    setting AS autovacuum_freeze_max_age
  FROM pg_catalog.pg_settings
  WHERE name = 'autovacuum_freeze_max_age'
),
per_database_stats AS (
  SELECT
    datname,
    m.max_old_xid::int,
    m.autovacuum_freeze_max_age::int,
    age(d.datfrozenxid) AS oldest_current_xid
  FROM pg_catalog.pg_database d
  JOIN max_age m ON (true)
  WHERE d.datallowconn
)
SELECT
  MAX(oldest_current_xid) AS oldest_current_xid,
  MAX(ROUND(100 * (oldest_current_xid / max_old_xid::float))) AS percent_towards_wraparound,
  MAX(ROUND(100 * (oldest_current_xid / autovacuum_freeze_max_age::float))) AS percent_towards_emergency_autovac
FROM per_database_stats;

👉 @SQLPortal

Давайте попрактикуемся в SQL

Из приведённых выше таблиц напишите SQL-запрос, который находит продавцов (salespeople) и клиентов (customers), проживающих в одном городе

👉 @SQLPortal

Знаете ли вы, что в Postgres есть функция для подсчёта промежуточных и общих итогов? Вместо написания отдельных SUM или ручной работы в таблицах, используйте операторы ROLLUP и CUBE

Они позволяют автоматически вычислять промежуточные и общие итоги по измерениям в вашем запросе. В сочетании с date_trunc можно агрегировать данные по неделям, месяцам или годам

👉 @SQLPortal

Секреты оптимизации SQL-запросов

Вот 20 проверенных техник, которые я регулярно использую для оптимизации SQL-запросов: 😊

• Грамотно используйте индексы:
Индексируйте критически важные столбцы, используемые в WHERE, JOIN, ORDER BY и GROUP BY.

• Избегайте SELECT *:
Выбирайте только необходимые столбцы, чтобы сократить объём передаваемых данных и время обработки.

• Реализуйте пагинацию корректно:
Используйте OFFSET и FETCH NEXT или пагинацию методом поиска (seek method) для эффективного постраничного вывода.

• Ограничивайте количество строк как можно раньше:
Применяйте фильтрацию на ранних этапах, чтобы максимально сократить размер выборки.

• Избегайте функций в WHERE:
Функции над столбцами блокируют использование индексов — переписывайте условия, используя «сырые» столбцы.

• Упрощайте JOIN:
Минимизируйте количество соединений и избегайте избыточных JOIN-ов.

• Выбирайте правильные типы JOIN:
Используйте INNER JOIN, LEFT JOIN или EXISTS там, где это уместно, чтобы избежать лишней обработки данных.

• Используйте корректные типы данных:
Сопоставляйте типы данных в JOIN и WHERE, чтобы обеспечить эффективное использование индексов.

• Запрашивайте только изменённые данные:
Реализуйте инкрементальную обработку, а не полный повторный запрос таблиц.

• Группируйте операции:
Пакетная вставка, обновление или удаление снижают накладные расходы на транзакции.

• Исключайте избыточные подзапросы:
Используйте JOIN или CTE вместо повторяющихся подзапросов.

• Используйте EXISTS вместо IN:
EXISTS часто работает быстрее, чем IN, особенно на больших объёмах данных.

• Нормализуйте с умом:
Балансируйте между нормализацией и денормализацией в производительно критичных запросах.

• Применяйте материализованные представления:
Предварительно рассчитывайте сложные агрегации и запросы для ускорения чтения.

• Анализируйте планы выполнения:
Регулярно проверяйте execution plan, чтобы находить и устранять ресурсоёмкие операции.

• Избегайте подстановок с начальным %:
LIKE '%abc' не использует индексы эффективно.

• Делайте транзакции короткими:
Сокращайте время выполнения транзакций, чтобы уменьшить блокировки и конфликты.

• Регулярно обновляйте статистику:
Актуальные статистики обеспечивают точное планирование запросов СУБД.

• Используйте подсказки (query hints) с осторожностью:
Применяйте только после тестирования и при необходимости конкретной оптимизации.

• Постоянно отслеживайте и настраивайте:
Регулярно анализируйте производительность запросов и проактивно оптимизируйте медленные запросы.

👉 @SQLPortal

Что происходит, когда данные в Postgres превышают размер страницы в 8 КБ? Они TOASTятся. 🍞

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

Если у вас много больших значений, стоит пересмотреть модель данных — возможно, получится сделать её менее TOAST-зависимой.

▶️Подробнее — в полном блоге о TOAST

👉 @SQLPortal

50 практических вопросов по SQL для отработки навыков запросов, часто появляющихся на собеседованиях

> SQL‑скрипты для создания тестовых данных (таблицы, вставка строк)

> Вопросы типа: «Напишите запрос, чтобы вывести уникальные значения», «Найдите N‑ю максимальную зарплату» и т.д.

> Готовые решения и объяснения

▶️читать

👉 @SQLPortal