Интересный факт про vector search: проверка меньшего объёма данных делает поиск быстрее и точнее.

Алгоритм HNSW это основа одних из самых быстрых векторных поисков. Если вы использовали Weaviate или другие векторные базы, вы уже сталкивались с HNSW, это стандартный тип индекса, и не случайно.

HNSW можно представить как многоуровневую транспортную систему для векторов: сверху —> редкие длинные связи для глобальной навигации, средний уровень —> средние связи для регионального поиска, низкий уровень —> плотные связи для всех векторов для точного результата. Поиск начинается сверху, постепенно уточняется на каждом слое и в конце достигает максимальной точности на нижнем уровне. Алгоритм «перепрыгивает» через множество неактуальных данных вместо проверки каждого вектора, что делает его быстрее brute-force методов.

Основные параметры, которые можно настраивать:
• maxConnections —> плотность графа; большее значение повышает точность, но замедляет поиск и требует больше памяти
• ef, efConstruction —> динамический размер списков для поиска и построения графа, влияющий на баланс между скоростью и точностью

HNSW это баланс между скоростью, точностью и расходом памяти; улучшение одного всегда требует компромисса с другими.

Подробнее о настройке HNSW и оптимизации: Weaviate docs

👉 @SQLPortal

Совет для PostgreSQL: используйте NULLS LAST или NULLS FIRST в ORDER BY, чтобы управлять расположением NULL‑значений в результатах запроса.

Пример:

SELECT order_id, product_name
FROM orders
ORDER BY order_date DESC NULLS FIRST;

В этом случае строки с NULL в order_date окажутся в начале результата.

👉 @SQLPortal

Делаешь ли ты эти типичные ошибки в SQL?

Забываешь про NULL
Обрабатываешь данные в памяти Java
Используешь JDBC-пагинацию для больших выборок
Применяешь агрегатные функции вместо оконных

Лукас Эдер объясняет, как делать правильно — и приводит ещё 7 распространённых ошибок.

👉 @SQLPortal

onedump позволяет создавать резервные копии и восстанавливать базы данных MySQL и PostgreSQL на локальном компьютере, S3, Google Drive, Dropbox или SFTP с помощью одного инструмента.

https://github.com/liweiyi88/onedump

👉 @SQLPortal

SQL встречается с семантическим поиском 🔥

Обычные базы данных не понимают естественный язык. Векторные базы не умеют точно фильтровать.

Knowledge Base Algebra от MindsDB решает эту проблему. И всё это полностью open-source.

Можно подключить больше 200 источников данных — как структурированных, так и неструктурированных и собрать единую базу знаний, которая объединяет семантический поиск, фильтрацию по метаданным и сложную булеву логику (SQL) в одной системе.

Пользователи просто пишут запросы обычным языком. Всё.

Для примера взяли рекомендательную систему фильмов с базой на 300k+ тайтлов. У части данных чёткие поля (жанр, рейтинг, год), а у большинства сплошной бардак (сюжеты, отзывы, куски текста).

С привычными инструментами вариантов немного:

Писать жёсткие SQL-фильтры и терять смысл

Использовать LLM, которая просто угадывает

С MindsDB можно задавать вопрос на естественном языке. Система сама определяет, где нужен семантический поиск, где фильтры, где логика, и возвращает точный результат.

И главное всё это можно запускать локально, прямо на своей машине.

👉 @SQLPortal

В Oracle Database 21c улучшили цикл FOR в PL/SQL — теперь он стал куда гибче.

Добавили несколько новых возможностей:

BY — можно задать свой шаг итерации (кастомный инкремент)
IN — поддерживаются списки значений для прохода по ним
WHEN — можно задать условие, при котором тело цикла пропускается
REPEAT WHILE — выражение, определяющее следующее значение
MUTABLE — позволяет изменять значение счётчика прямо внутри цикла

Короче, теперь FOR в PL/SQL стал почти как нормальный итератор из современных языков.

👉 @SQLPortal

PostgreSQL использует ленивое «swizzling» указателей (lazy pointer swizzling), чтобы ускорить доступ к буферу и держать данные на диске и в памяти синхронизированными без лишних преобразований. Вот как это работает.

Когда PostgreSQL хранит структуры данных, например страницы B-tree индекса, на диске нельзя использовать обычные указатели из оперативки → адреса на диске и в памяти вообще из разных миров. Но как только данные попадают в память, хочется быстро ходить по структуре через указатели, а не через медленные косвенные ссылки.

На диске PostgreSQL хранит ссылки в виде номеров блоков и смещений. Когда страница читается в общий буферный пул, эти логические ссылки остаются как есть → и вот тут начинается интересное.

Буферные страницы

→ Каждая страница в памяти идентифицируется с помощью структуры BufferTag (в ней указаны база, таблица и номер блока).
→ В памяти PostgreSQL держит массив дескрипторов буферов.
→ Когда нужно получить доступ к странице, код идет через менеджер буферов, который по номеру блока находит реальное местоположение страницы в памяти.
→ Это и есть ленивое swizzling — преобразование адреса выполняется не заранее, а при каждом обращении.

Пример структуры BufferTag из исходников PostgreSQL:

typedef struct
{
  Oid   spcOid;      /* tablespace */
  Oid   dbOid;       /* database */
  Oid   relNumber;   /* relation (table or index) */
  ForkNumber forkNum;/* main, fsm, vm, init forks */
  BlockNumber blockNum; /* block number within the relation */
} BufferTag;

Почему это круто

→ Страницы в буферном пуле сохраняют свой дисковый формат, не нужно ничего конвертировать туда-сюда.
→ Несколько процессов могут обращаться к одной странице, используя номера блоков, а не указатели → это делает параллельный доступ простым и безопасным.
→ Когда страница выкидывается из буфера, не нужно «раскручивать» swizzling обратно.

PostgreSQL таким образом жертвует крошечной долей производительности на каждом обращении (из-за дополнительного уровня косвенности), но выигрывает в простоте буферного менеджмента и надежности при многопоточном доступе.

Очень аккуратный и элегантный дизайн.

👉 @SQLPortal

Тема → Нормализация в SQL

Нормализация → это способ организовать таблицы так, чтобы:
→ каждая единица данных хранилась только один раз
→ данные оставались консистентными и аккуратными
→ обновления и отчёты было проще делать

Представь нормализацию как организацию своих школьных конспектов

Если все записи по математике, физике и английскому ты ведёшь в одной тетради → там быстро начнётся бардак.
А если разделить предметы по отдельным тетрадям → всё становится чище, понятнее и без повторов.
Вот примерно это и делает нормализация в базе данных.

1NF (Первая нормальная форма) → «Без повторяющихся списков»

Каждая ячейка должна содержать одно значение, а не список.

2NF (Вторая нормальная форма) → «Без частичной зависимости»

Не храни данные, которые зависят только от части составного ключа.

3NF (Третья нормальная форма) → «Без лишней информации»

Убираем данные, которые зависят не от ключевых столбцов, а от других колонок.

BCNF (Форма Бойса-Кодда) → усиленная версия 3NF

Правило → любой детерминант должен быть кандидатом в ключ.
(Проще говоря → если один столбец определяет другой, то первый должен быть уникальным идентификатором.)

4NF (Четвёртая нормальная форма) → убирает многозначные зависимости

Если одна запись хранит два независимых списка → раздели их.

5NF (Пятая нормальная форма) → «Самая чистая форма»

Убираем зависимости, возникающие при соединениях.
Если таблицу можно разбить на более мелкие и потом собрать обратно без потери данных → разбей.

Вопрос → почему не нормализовать всё до упора?

Переизбыток нормализации → куча JOIN-ов → запросы тормозят, особенно в отчётах.

Поэтому в транзакционных системах (OLTP) → применяют нормализацию,
а в аналитических (OLAP) → часто используют денормализацию.

👉 @SQLPortal

Топ-10 инструментов для SQL-разработчиков и администраторов баз данных

Подробности: тык

👉 @SQLPortal

PostgreSQL 18: оператор RETURNING теперь поддерживает OLD и NEW значения в UPDATE

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

👉 @SQLPortal

Используй Heap Maps в Oracle Database, чтобы увидеть:

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

Matt DeMarco показывает, как с этим работать.

👉 @SQLPortal

Когда нет ни первичного, ни внешнего ключа, а связать таблицы 1 к 1 всё равно нужно

Иногда попадаются такие таблицы, где нет ни PRIMARY KEY, ни FOREIGN KEY, но данные логически связаны один к одному.
Как аккуратно сделать это в SQL?

Самый чистый вариант — сгенерировать порядковый номер для каждой строки через ROW_NUMBER() и потом соединить таблицы по нему.

WITH t1 AS (
  SELECT Product, ROW_NUMBER() OVER (ORDER BY Product) AS rn
  FROM Table_1
),
t2 AS (
  SELECT Price, ROW_NUMBER() OVER (ORDER BY Price) AS rn
  FROM Table_2
)
SELECT t1.Product, t2.Price
FROM t1
JOIN t2 ON t1.rn = t2.rn;

Что тут происходит:

ROW_NUMBER() OVER (ORDER BY Product) пронумеровывает продукты 1, 2, 3...

ROW_NUMBER() OVER (ORDER BY Price) делает то же самое для цен

Потом просто соединяем по rn, и получаем аккуратное 1-к-1 сопоставление

Не путай с RANK() или DENSE_RANK() = они не гарантируют строгую последовательность при дубликатах.
И обязательно добавляй ORDER BY в ROW_NUMBER(), чтобы нумерация была детерминированной.

👉 @SQLPortal

⭐️ Road to Highload: видеопроект о проектировании архитектуры высоконагруженных систем

Инженеры Яндекс 360 накопили значительный опыт в проектировании и разработке систем, которыми пользуются больше 95 миллионов человек ежемесячно.

В этом видеопроекте разработчики на практических примерах рассказывают, как создают архитектуру систем, которые держат 1 000 000 RPS и хранят петабайты мета-данных.

В выпусках обсуждаем:

🎙 Серия 1. Функциональные и нефункциональные требования. Как сбор требований помогает создавать надёжные и масштабируемые решения

🎙 Серия 2. Надёжный API. Принципы проектирования API, которые помогут сделать его консистентным, предсказуемым и поддерживаемым

🎙 Серия 3. Крупноблочная архитектура: карта вашей системы. Как выглядит модель на примере Яндекс Календаря и как ребята применяют её для эффективной коммуникации с различными командами разработки

🎙Серия 4. Практика: Рост баз данных: от единиц запросов к тысячам. Как правильно организовать работу с БД, чтобы система оставалась стабильной и эффективной

🎙 Серия 5. Практика. Взаимодействие со смежными системами. Типичные сложности, с которыми сталкиваются команды при интеграции с внешними сервисами, и как их предотвратить или минимизировать

Смотрите проект, чтобы узнать, как создаются одни из крупнейших облачных сервисов в России:

⭐️ Наш сайт
⭐️ VK Видео
⭐️ Ютуб

Провели бенчмарк 96 комбинаций PostgreSQL 17 и 18 — и результаты местами неожиданны. 😕

В целом Postgres 18 показал себя лучше: заметные улучшения в производительности и несколько действительно интересных оптимизаций.

Подробности, результаты тестов и анализ: смотреть

👉 @SQLPortal

Не нужен весь набор данных — хватит и выборки? Тогда попробуй Postgres TABLESAMPLE.

В PostgreSQL есть встроенная функция для выборки случайных строк из таблицы. Например, чтобы взять примерно 10% строк, можно просто написать:

SELECT * FROM your_table TABLESAMPLE BERNOULLI (10);

Удобно, когда нужно быстро глянуть структуру или прикинуть распределение данных, не прогоняя весь объём.

👉 @SQLPortal

Главный совет для разработчиков, которые только начинают работать с Postgres: всегда задавай statement timeout.

ALTER DATABASE mydatabase
SET statement_timeout = '60s';

👉 @SQLPortal