Терміни

Тут зібрані 304 терміни курсу разом з англійськими відповідниками. Відповідники тут не для краси: документація, man-сторінки й повідомлення про помилки майже завжди англійською, і треба знати, що саме там шукати.

Пояснення навмисно короткі, на одне речення. Це нагадування для того, хто модуль уже читав, а не заміна йому — за подробицями йдіть за посиланням на модуль.

I. Реляційна модель і SQL

СУБД— DBMS (database management system)

Програма, що бере на себе зберігання даних, одночасний доступ до них, відновлення після збою й відповіді на запити, щоб кожен застосунок не реалізовував це сам. модуль 1

модель даних— data model

Опис того, з чого складається одиниця зберігання (рядок, документ, вершина, вектор) і які операції над нею природні; від моделі залежить, які запити база виконує легко. модуль 1

незалежність даних— data independence

Властивість реляційної моделі, за якої програма описує, які дані їй потрібні, і не залежить від того, як вони розкладені на диску й які індекси є. модуль 1

транзакція— transaction

Група команд між BEGIN і COMMIT, яка комітиться цілком або не комітиться зовсім. Гарантії ізоляції між транзакціями розбирає модуль 10. модуль 1

OLTP— OLTP (online transaction processing)

Навантаження з тисяч коротких запитів на секунду, кожен з яких читає або змінює кілька рядків (оформити замовлення, списати залишок). модуль 1

OLAP— OLAP (online analytical processing)

Навантаження з рідкісних важких запитів, що читають мільйони рядків і підсумовують їх (виручка за місяцями, когорти покупців). модуль 1

NoSQL— NoSQL

Умовна назва баз даних, що з'явилися в кінці 2000-х для масштабування запису на багато вузлів і відмовилися від частини можливостей реляційних СУБД (JOIN, транзакцій на кілька записів). Не означає «без SQL». модуль 1

NewSQL— NewSQL

Умовна назва розподілених баз, що намагаються поєднати SQL і транзакції з серіалізованістю між вузлами з горизонтальним масштабуванням (Spanner, CockroachDB). модуль 1

key-value база— key-value store

База, де значення зберігається й читається за ключем, без запитів за вмістом значення (Redis, DynamoDB). модуль 1

документна база— document database

База, одиницею запису й читання якої є вкладений документ, зазвичай JSON або BSON (MongoDB). модуль 1

wide-column база— wide-column store

База, що розкладає рядки за ключем партиції по багатьох вузлах і дозволяє кожному рядку мати власний набір колонок (Cassandra, ScyllaDB). модуль 1

графова база— graph database

База, де дані подано вершинами й ребрами, а запити обходять зв'язки між ними (Neo4j). модуль 1

колонкова база— columnar database

База, що зберігає таблицю по колонках, а не по рядках; читає лише потрібні колонки, тому добре підходить для аналітики (DuckDB, ClickHouse). модуль 1

векторна база— vector database

База, що шукає найближчих сусідів за ембедингами (числовими векторами) замість пошуку за точним збігом (pgvector). модуль 1

відношення— relation

Математичний об'єкт реляційної моделі, що складається із заголовка (набір атрибутів з доменами) і тіла (множина кортежів). У SQL йому відповідає таблиця. модуль 2

кортеж— tuple

Один елемент відношення, набір значень по одному на кожен атрибут. У SQL це рядок. модуль 2

атрибут— attribute

Іменований компонент відношення, значення якого беруться зі свого домену. У SQL це колонка. модуль 2

домен— domain

Множина допустимих значень атрибута. У SQL його задають типом колонки та обмеженнями на нього. модуль 2

потенційний ключ— candidate key

Мінімальний набір атрибутів, значення якого різні в усіх кортежах відношення; з нього не можна прибрати жоден атрибут без втрати унікальності. модуль 2

первинний ключ— primary key

Потенційний ключ, обраний головним способом ідентифікації кортежу. У SQL його значення унікальні й не мають NULL. модуль 2

зовнішній ключ— foreign key

Атрибут або набір атрибутів, значення яких мусять збігатися зі значенням потенційного ключа іншого (або того самого) відношення. Порожнє значення перевірку пропускає. модуль 2

сурогатний ключ— surrogate key

Ключ без змісту в предметній області, який видає сама база, наприклад значення identity. Не змінюється, але унікальності предметної області не гарантує. модуль 2

природний ключ— natural key

Ключ, узятий з предметної області: артикул, код країни, податковий номер. Змінюється разом зі світом, тож його рідко роблять первинним. модуль 2

обмеження цілісності— integrity constraint

Правило, якому має відповідати кожен допустимий стан бази. СУБД відхиляє зміну, що його порушує. модуль 2

NULL— NULL

Позначка, що значення немає. Порівняння з нею дає unknown, навіть коли порівнюють NULL із NULL. модуль 2

тризначна логіка— three-valued logic

Логіка SQL з трьома значеннями істинності: true, false і unknown. WHERE, ON і HAVING пропускають лише true, CHECK відхиляє лише false. модуль 2

реляційна алгебра— relational algebra

Набір операцій над відношеннями (вибірка, проєкція, JOIN, об'єднання, різниця, перейменування), що повертають відношення. Теоретична основа SQL і планувальника запитів. модуль 2

проєкція— projection

Операція алгебри, що лишає з відношення вибрані атрибути й прибирає повтори. У SQL це список у SELECT разом з DISTINCT. модуль 2

мультимножина— bag (multiset)

Набір елементів, у якому той самий елемент може траплятися кілька разів. Результат SQL-запиту є мультимножиною, а відношення моделі множиною. модуль 2

логічний порядок виконання— logical query processing order

Послідовність кроків, якою стандарт SQL визначає результат SELECT (FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY, LIMIT); від неї залежить, де видно псевдоніми й віконні функції. модуль 3

OUTER JOIN— outer join

JOIN (LEFT, RIGHT або FULL), який зберігає рядки однієї чи обох таблиць без пари й заповнює відсутні колонки значеннями NULL. модуль 3

CROSS JOIN— cross join

JOIN без умови (CROSS JOIN), що повертає всі пари рядків двох таблиць, тобто їх декартів добуток. модуль 3

розмноження рядків— fan-out

Повторення рядка однієї таблиці в результаті JOIN стільки разів, скільки йому відповідає рядків другої таблиці; через нього суми й лічильники виходять завищеними. модуль 3

агрегатна функція— aggregate function

Функція, що згортає набір рядків до одного значення (count, sum, avg, min, max); майже всі агрегатні функції пропускають NULL, а count(*) рахує рядки. модуль 3

підзапит— subquery

Запит SELECT усередині іншого запиту, який повертає одне значення, список значень або таблицю. модуль 3

корельований підзапит— correlated subquery

Підзапит, що посилається на колонки зовнішнього запиту й тому логічно обчислюється для кожного зовнішнього рядка окремо. модуль 3

semi-join— semi-join

Перевірка «для рядка є хоча б одна пара в іншій таблиці» без розмноження рядків; у SQL її записують через EXISTS або IN. модуль 3

anti-join— anti-join

Вибір рядків, яким немає пари в іншій таблиці; у SQL його записують через NOT EXISTS або LEFT JOIN з перевіркою IS NULL. модуль 3

CTE— common table expression (CTE)

Іменований підзапит WITH name AS (...), винесений перед основним запитом; у PostgreSQL 12 і новіших його вбудовують в запит, якщо на нього посилаються один раз. модуль 3

рекурсивний CTE— recursive CTE

CTE, що складається з початкової частини й рекурсивної, яка повторно застосовується до рядків попереднього кроку, доки не дасть порожній результат; використовується для дерев і графів. модуль 3

віконна функція— window function

Функція з OVER, що обчислює значення по «вікну» пов'язаних рядків і не згортає їх, на відміну від агрегату з GROUP BY. модуль 3

рамка вікна— window frame

Підмножина рядків розділу вікна, по якій рахується віконна функція для поточного рядка; за замовчуванням з ORDER BY вона тягнеться від початку розділу до поточного рядка разом з його рівними за ключем. модуль 3

LATERAL-підзапит— lateral subquery

Підзапит у FROM з ключовим словом LATERAL, який виконується для кожного рядка таблиць ліворуч від нього й може на них посилатися; так розв'язують задачу «топ-N на групу». модуль 3

мова визначення даних— data definition language (DDL)

Підмножина SQL, яка створює, змінює й видаляє об'єкти схеми: таблиці, обмеження, індекси, представлення (`CREATE`, `ALTER`, `DROP`). модуль 4

мова маніпулювання даними— data manipulation language (DML)

Підмножина SQL, яка змінює вміст таблиць: `INSERT`, `UPDATE`, `DELETE`, `MERGE`. модуль 4

число з плаваючою комою— floating-point number

Двійковий наближений формат (`real`, `double precision`). Більшість десяткових дробів, зокрема 0.1, він зберігає з похибкою, яка накопичується в сумах, тому гроші в ньому не зберігають. модуль 4

часова позначка з поясом— timestamp with time zone

Тип `timestamptz`. Зберігає момент часу в UTC, а пояс застосовує на вході й виході за налаштуванням сесії; сам пояс у значенні не зберігається. модуль 4

upsert— upsert

Вставка, яка за конфлікту з наявним ключем оновлює рядок замість помилки; у PostgreSQL це `INSERT … ON CONFLICT`. Виконується однією атомарною командою. модуль 4

представлення— view

Збережений запит із ім'ям. Даних не зберігає: під час звернення підставляється в запит, тому завжди показує свіжі дані. модуль 4

матеріалізоване представлення— materialized view

Представлення, результат якого збережено як таблицю й оновлюється командою `REFRESH MATERIALIZED VIEW`, а не під час кожного звернення. модуль 4

обчислювана колонка— generated column

Колонка, значення якої обчислюється з інших колонок того ж рядка. Записати в неї значення не можна. Віртуальна обчислюється під час читання, збережена (`STORED`) під час запису. модуль 4

блокування таблиці— table-level lock

Блокування всієї таблиці в одному з восьми режимів, від `ACCESS SHARE` до `ACCESS EXCLUSIVE`. Тримається до кінця транзакції; режими, що конфліктують, чекають у черзі. модуль 4

черга блокувань— lock queue

Порядок, у якому запити чекають на блокування. Запит, що чекає несумісного режиму, блокує й тих, хто прийшов після нього, навіть якщо вони не конфліктують із поточним власником. модуль 4

міграція схеми— schema migration

Версійована зміна структури бази (DDL і, за потреби, даних), яку застосовують до працюючої бази відтворюваним скриптом. модуль 4

обмеження `NOT VALID`— NOT VALID constraint

`CHECK` чи зовнішній ключ, додані без перевірки наявних рядків. Діє на нові й змінені рядки одразу; старі перевіряє пізніше `VALIDATE CONSTRAINT` з послабленим блокуванням. модуль 4

переписування таблиці— table rewrite

Створення нового файлу таблиці з усіма рядками, яке вимагає деяких змін схеми (наприклад, `integer` → `bigint`). Триває пропорційно розміру таблиці, зазвичай під `ACCESS EXCLUSIVE`. модуль 4

недійсний індекс— invalid index

Індекс, який лишився після невдалого `CREATE INDEX CONCURRENTLY`. Кожен запис його оновлює, а запити ним не користуються; його видаляють і будують заново. модуль 4

розширити, мігрувати, звузити— expand/contract

Схема зміни без простою: додати нове поряд зі старим (розширити), перенести дані порціями (мігрувати), перемкнути застосунок і прибрати старе (звузити). Кожен крок сумісний з обома версіями застосунку. модуль 4

сутність— entity

Тип об'єктів предметної області з власною ідентичністю: покупець, замовлення, товар. На ER-діаграмі її малюють прямокутником, у схемі їй зазвичай відповідає таблиця. модуль 5

ER-діаграма— entity-relationship diagram

Схема сутностей і зв'язків між ними, з якої починають проєктування бази. Нотація Чена позначає зв'язки ромбами, а crow's foot кодує кардинальність і обов'язковість на кінцях ліній. модуль 5

кардинальність зв'язку— cardinality

Скільки об'єктів однієї сутності може відповідати об'єкту іншої: один до одного, один до багатьох чи багато до багатьох. Обов'язковість зв'язку (нуль чи хоча б один) задають окремо. модуль 5

проміжна таблиця— junction table

Таблиця, що розкладає зв'язок «багато до багатьох» на два зв'язки «один до багатьох». Містить зовнішні ключі на обидві сторони й атрибути самого зв'язку, як `order_items` між замовленнями й товарами. модуль 5

суперключ— superkey

Будь-який набір колонок, що визначає всі інші колонки таблиці. Потенційний ключ є мінімальним суперключем. модуль 5

функціональна залежність— functional dependency

Твердження `X → Y`: два рядки з однаковим `X` завжди мають однакове `Y`. Це властивість предметної області; дані можуть її спростувати, але не довести. модуль 5

нормальна форма— normal form

Умова на функціональні залежності таблиці, що виключає певний клас аномалій: 1НФ, 2НФ, 3НФ, НФБК, 4НФ. Форми впорядковано за силою: кожна наступна (до НФБК) включає вимоги попередньої. модуль 5

нормалізація— normalization

Розкладання таблиці на менші за її функціональними залежностями, щоб кожен факт зберігався в одному місці. Розклад має бути без втрат: `JOIN` частин повертає початкову таблицю. модуль 5

аномалія оновлення— update anomaly

Суперечність у даних, що виникає, коли один факт повторено в багатьох рядках і змінено не в усіх. Аналогічно аномалії вставки (факт не записати без стороннього) і видалення (разом із рядком зникає сторонній факт). модуль 5

багатозначна залежність— multivalued dependency

Залежність, коли ключу відповідає цілий набір значень однієї колонки, незалежний від іншого набору при тому самому ключі. Її усуває 4НФ. модуль 5

денормалізація— denormalization

Свідоме повторення даних заради швидшого читання. Виправдана, коли повторюване значення можна перерахувати з решти даних і є механізм, що тримає його правильним. модуль 5

EAV— entity-attribute-value (EAV)

Антипатерн: атрибути зберігають не колонками, а рядками `(сутність, назва, значення)`. Типи, обмеження й зовнішні ключі для таких значень недоступні. модуль 5

поліморфний зв'язок— polymorphic association

Антипатерн: посилання на кілька таблиць через пару `(тип, ідентифікатор)`. Зовнішній ключ не може вказувати в різні таблиці, тож база не захищає від сиріт. модуль 5

м'яке видалення— soft delete

Замість `DELETE` рядок позначають видаленим. Зберігає посилання й історію, але персональні дані лишаються, доки їх не анонімізовано, а кожен запит мусить враховувати мітку. модуль 5

UUIDv7— UUIDv7

UUID, у якому перші 48 біт — час Unix у мілісекундах, а решта випадкова. Значення зростають із часом, тож вставки в B-дерево йдуть у правий край; у PostgreSQL 18 його дає `uuidv7()`. модуль 5

SQL-ін'єкція— SQL injection

Атака, у якій дані користувача потрапляють у текст запиту й змінюють його структуру, тож база виконує не те, що задумав автор запиту. модуль 6

параметр запиту— bind parameter

Значення, яке драйвер передає базі окремо від тексту запиту й підставляє в місце `$1`, `$2` уже після розбору тексту. модуль 6

prepared statement— prepared statement

Prepared statement (підготовлений запит) — запит, розібраний базою один раз і збережений у сеансі під іменем; далі його виконують, передаючи лише значення параметрів. модуль 6

простий протокол— simple query protocol

Режим обміну з PostgreSQL, де клієнт надсилає одне повідомлення з повним текстом запиту, у якому можна об'єднати кілька команд через крапку з комою. модуль 6

розширений протокол— extended query protocol

Режим обміну з PostgreSQL, де розбір (Parse), прив'язування значень (Bind) і виконання (Execute) йдуть окремими повідомленнями, а текст може містити лише одну команду. модуль 6

білий список— allowlist

Перелік допустимих значень, з якого застосунок вибирає фрагмент запиту (назву колонки, напрям сортування) замість того, щоб вставляти в запит рядок користувача. модуль 6

ORM— ORM (object-relational mapper)

Бібліотека, що відображає рядки таблиць на об'єкти мови програмування й сама будує запити SQL за викликами методів. модуль 6

проблема N+1— N+1 problem

Запит за списком із N елементів, який виконує ще по одному запиту на кожен елемент, тож сторінка робить 1 + N запитів замість двох-трьох. модуль 6

ліниве завантаження— lazy loading

Поведінка ORM, за якої пов'язані об'єкти (позиції замовлення, товар) читаються з бази лише в момент першого звернення до них у коді. модуль 6

пул з'єднань— connection pool

Набір уже відкритих з'єднань до бази, які застосунок по черзі позичає для запитів замість того, щоб відкривати нове з'єднання щоразу. модуль 6

режим пулу— pool mode

Правило PgBouncer, коли серверне з'єднання повертається в пул: після закриття клієнта (session), після завершення транзакції (transaction) або після кожного запиту (statement). модуль 6

серверне з'єднання— server connection

З'єднання між PgBouncer і PostgreSQL. На відміну від клієнтських з'єднань до PgBouncer, їх небагато, і кожному відповідає процес бази. модуль 6

збережена процедура— stored procedure

Іменований блок коду, що живе в базі й викликається командою `CALL`; на відміну від функції, може сам комітити й відкочувати транзакції. модуль 6

тригер— trigger

Функція, яку база сама викликає до або після `INSERT`, `UPDATE` чи `DELETE` на таблиці, для кожного рядка або для всієї команди. модуль 6

PL/pgSQL— PL/pgSQL

Процедурна мова PostgreSQL зі змінними, умовами й циклами, якою пишуть функції, процедури й тригери. модуль 6

II. Всередині реляційної СУБД

сторінка даних— data page

Блок фіксованого розміру (8 КіБ у PostgreSQL, 16 КіБ в InnoDB), яким СУБД читає, кешує й пише файли таблиць та індексів; окремо від сторінки пам'яті ОС. модуль 7

вказівник на рядок— line pointer

Чотирибайтовий запис у заголовку сторінки PostgreSQL із зсувом і довжиною рядка на сторінці; через нього адреса рядка не залежить від того, де він лежить усередині сторінки. модуль 7

ctid— ctid

Системна колонка з адресою версії рядка в таблиці PostgreSQL: пара «номер сторінки, номер вказівника». Змінюється при UPDATE і VACUUM FULL. модуль 7

heap-файл— heap file

Файл таблиці як масив сторінок без порядку: новий рядок іде на будь-яку сторінку з вільним місцем. Так зберігає таблиці PostgreSQL. модуль 7

вирівнювання— alignment

Вимога, щоб значення типу починалося з адреси, кратної 1, 2, 4 або 8 байтів; для цього між колонками рядка виникають порожні байти, тож порядок колонок впливає на розмір рядка. модуль 7

бітова карта NULL— null bitmap

Необов'язкове поле заголовка рядка: по одному біту на колонку, що показує, які значення відсутні. Сам NULL не займає байтів даних. модуль 7

TOAST— TOAST

Механізм PostgreSQL для значень завбільшки понад приблизно 2 КіБ: їх стискають і, якщо треба, виносять шматками в окрему службову таблицю, лишаючи в рядку вказівник. модуль 7

buffer pool— buffer pool

Область пам'яті СУБД, де лежать копії сторінок даних; запити працюють із ними, а не з файлами. У PostgreSQL має розмір shared_buffers. модуль 7

алгоритм годинника— clock sweep

Політика витіснення буферів: стрілка обходить їх по колу, зменшує лічильник використання й витісняє той, де лічильник дійшов до нуля. модуль 7

кільце буферів— buffer ring

Невелика частина пулу, яку PostgreSQL виділяє для одноразового проходу (велике сканування, VACUUM), щоб він не витіснив гарячі сторінки решти запитів. модуль 7

подвійне кешування— double buffering

Стан, коли та сама сторінка лежить і в buffer pool СУБД, і в сторінковому кеші ОС, бо читання йде через файлову систему. модуль 7

прямий ввід-вивід— direct I/O

Читання й запис файлів повз кеш сторінок ОС (прапорець O_DIRECT); СУБД з власним кешем так уникають подвійного кешування. модуль 7

кластерний індекс— clustered index

Індекс, у листових сторінках якого лежать самі рядки таблиці в порядку ключа; так влаштовано кожну таблицю InnoDB за первинним ключем. модуль 7

рядкове зберігання— row store

Схема, за якої значення одного рядка лежать у файлі поруч; зручна для вставки й читання рядка цілком, але запит на одну колонку читає й решту. модуль 7

B+-дерево— B+-tree

Збалансоване дерево, у якому кожен вузол є сторінкою: пари «ключ → адреса рядка» лежать лише в листових сторінках, а внутрішні сторінки тримають роздільні ключі. Так влаштований типовий індекс PostgreSQL і InnoDB. модуль 8

листова сторінка— leaf page

Сторінка нижнього рівня B+-дерева (leaf), де лежать самі ключі з адресами рядків. Листові сторінки зв'язані в ланцюжок за порядком ключів, тож діапазон читається без повернення до кореня. модуль 8

розбиття сторінки— page split

Поділ повної сторінки індексу надвоє, коли в неї треба вставити ще один ключ: частина ключів переїжджає в нову сторінку, а батьківська отримує роздільний ключ. Висота дерева зростає лише тоді, коли ділиться корінь. модуль 8

складений індекс— composite index

Індекс за кількома колонками, у якому записи впорядковано спершу за першою колонкою, у межах її рівних значень за другою і так далі. модуль 8

правило лівого префікса— leftmost prefix rule

Складений індекс найкраще працює для умов, що задають початок його списку колонок: рівність на перших, потім не більше одного діапазону. Умова лише на пізнішу колонку індекс майже не використовує (PostgreSQL 18 пом'якшує це для першої колонки з малою кількістю значень). модуль 8

покриваючий індекс— covering index

Індекс, що містить усі колонки запиту, зокрема додані через `INCLUDE`, тож запит обходиться без читання таблиці. модуль 8

частковий індекс— partial index

Індекс лише для рядків, що відповідають умові `WHERE` у його визначенні. Малий за розміром і дешевий на запис, але запит використовує його, лише якщо його умова випливає з умови індексу. модуль 8

індекс за виразом— expression index

Індекс за значенням виразу над колонками, наприклад `lower(email)`. Запит використовує його, лише якщо містить той самий вираз. модуль 8

GIN— GIN (generalized inverted index)

Тип індексу, що зберігає відображення «значення → список рядків». Підходить для `jsonb`, масивів і повнотекстового пошуку, де рядок містить багато значень; повільніший на запис, ніж B-дерево. модуль 8

GiST— GiST (generalized search tree)

Тип індексу для даних, що впорядковуються не лінійно: геометрія, діапазони, пошук найближчих сусідів за відстанню. модуль 8

BRIN— BRIN (block range index)

Тип індексу, що для кожної групи сторінок таблиці зберігає лише найменше й найбільше значення колонки. Займає кілобайти на гігабайти даних, але діє, лише коли значення йдуть у порядку зберігання, як час у журналі подій. модуль 8

HOT-оновлення— HOT update (heap-only tuple)

Оновлення в PostgreSQL, що не змінює індексованих колонок і вміщує нову версію рядка на тій самій сторінці: нові записи в індекси не потрібні, індекс веде до старої версії, а та до нової. модуль 8

write amplification— write amplification

Write amplification (підсилення запису) — відношення обсягу реально записаних даних до обсягу змін, які зробив користувач. Кожен індекс, що оновлюється разом із рядком, збільшує його. модуль 8

планувальник запитів— query planner

Частина СУБД, що з еквівалентних способів виконати запит вибирає той, який за оцінкою найдешевший, і будує з нього план виконання. модуль 9

план виконання— execution plan

Дерево вузлів (сканування, JOIN, сортування, агрегація), яке виконавець обходить знизу вгору, щоб отримати результат запиту; його показує EXPLAIN. модуль 9

вартість— cost

Оцінка планувальника в умовних одиницях (одиниця — читання сторінки підряд), складена з вартості читання сторінок і обробки рядків; за нею порівнюються плани, а не за часом. модуль 9

кардинальність— cardinality

Кількість рядків, яку повертає вузол плану; планувальник оцінює її зі статистики (rows), а EXPLAIN ANALYZE показує справжню (actual rows). модуль 9

вибірковість— selectivity

Частка рядків таблиці, що проходять умову; від неї залежить, який спосіб читання таблиці найдешевший. модуль 9

Seq Scan— sequential scan

Вузол плану, що читає всю таблицю сторінка за сторінкою й перевіряє умову на кожному рядку (послідовне сканування); найдешевший, коли потрібна велика частка рядків. модуль 9

Bitmap Heap Scan— bitmap scan

Вузли Bitmap Index Scan і Bitmap Heap Scan. Спершу з індексу збирається бітова карта сторінок, потім ці сторінки читаються в фізичному порядку по одному разу. модуль 9

Index Only Scan— index-only scan

Вузол Index Only Scan, що бере значення з індексу й звертається до таблиці лише для сторінок, не позначених у карті видимості; кількість таких звернень показує Heap Fetches. модуль 9

карта видимості— visibility map

Бітова карта таблиці, що позначає сторінки, на яких усі версії рядків видимі всім транзакціям; її виставляє VACUUM, а оновлення знімають. модуль 9

Nested Loop— nested loop

Алгоритм JOIN (вкладений цикл), що для кожного рядка зовнішнього входу шукає пари у внутрішньому, зазвичай через індекс; підходить для малих зовнішніх входів і довільних умов. модуль 9

Hash Join— hash join

Алгоритм JOIN за рівністю, що будує хеш-таблицю з меншого входу й проходить другий вхід один раз; якщо таблиця не вміщається в пам'ять, працює порціями через тимчасові файли. модуль 9

Merge Join— merge join

Алгоритм JOIN за рівністю, що одночасно проходить два входи, впорядковані за ключем; вигідний, коли порядок уже є (індекс) або потрібен на виході. модуль 9

скидання на диск— spill

Запис проміжних даних сортування, хеш-таблиці чи агрегації в тимчасові файли, коли вони не вміщаються в work_mem; у плані його видно як Disk, Batches більше одиниці або temp written. модуль 9

розширена статистика— extended statistics

Статистика по кількох колонках (CREATE STATISTICS — dependencies, ndistinct, mcv), яка виправляє оцінку кардинальності, коли умови на колонки залежать одна від одної. модуль 9

паралельний план— parallel plan

План із вузлом Gather, у якому кілька процесів-робітників виконують одну й ту саму частину плану над різними частинами даних, а провідний процес збирає результат. модуль 9

рівень ізоляції— isolation level

Налаштування транзакції, яке визначає, які аномалії конкурентного виконання система їй дозволяє. модуль 10

брудне читання— dirty read

Аномалія, коли транзакція бачить зміни іншої транзакції, яка ще не закомітила і може відкотитися. модуль 10

неповторюване читання— non-repeatable read

Аномалія, коли повторне читання того самого рядка в одній транзакції дає інше значення, бо між читаннями інша транзакція закомітила зміну. модуль 10

фантомне читання— phantom read

Аномалія, коли повторний запит з тією самою умовою повертає інший набір рядків, бо інша транзакція додала або видалила рядки. модуль 10

втрачене оновлення— lost update

Аномалія, коли дві транзакції читають те саме значення, обидві записують результат власного обчислення, і зміна однієї зникає. модуль 10

write skew— write skew

Аномалія, коли дві транзакції читають те саме, пишуть різні рядки і разом порушують правило, яке кожна окремо дотримала. модуль 10

snapshot isolation— snapshot isolation

Рівень ізоляції, за якого транзакція працює з незмінним знімком даних на початок своєї роботи; допускає write skew. модуль 10

SERIALIZABLE— serializable

Найсуворіший рівень ізоляції, за якого результат дорівнює якомусь послідовному виконанню транзакцій; у PostgreSQL це SSI з помилками 40001. модуль 10

MVCC— MVCC (multiversion concurrency control)

Схема, у якій зміна рядка створює нову версію, а читачі бачать версію, що відповідає їхньому знімку, тож читання не блокують запис. модуль 10

версія рядка— row version

Окремий фізичний екземпляр рядка в таблиці; у PostgreSQL кожне UPDATE створює нову версію, а стару лишає до очищення. модуль 10

двофазне блокування— two-phase locking (2PL)

Протокол, за якого транзакція спершу лише захоплює блокування, а відпускає їх усі тільки після завершення; гарантує серіалізованість ціною очікувань. модуль 10

VACUUM— VACUUM

Процес PostgreSQL, що прибирає мертві версії рядків, позначає місце для повторного використання й заморожує старі номери транзакцій. модуль 10

bloat— bloat

Стан, коли таблиця або індекс займають значно більше місця, ніж потрібно живим даним, бо мертві версії рядків не прибрано. модуль 10

wraparound— transaction ID wraparound

Ситуація, коли 32-бітний лічильник транзакцій PostgreSQL наближається до кола, а старі рядки не заморожено; сервер перестає приймати записи. модуль 10

WAL— write-ahead log (WAL)

Послідовний журнал змін, який СУБД дописує раніше, ніж змінені сторінки потрапляють у файли даних; за ним повторюють зміни після збою, будують бекапи й репліки. модуль 11

LSN— LSN (log sequence number)

Позиція в журналі у байтах від його початку; у PostgreSQL її друкують як два шістнадцяткові числа, наприклад 0/AE013218. Кожна сторінка зберігає LSN останньої зміни. модуль 11

сегмент WAL— WAL segment

Файл журналу фіксованого розміру (типово 16 МБ). Його ім'я складається з номера лінії часу й номера сегмента в шістнадцятковому записі. модуль 11

torn page— torn page

Частково записана сторінка: початок уже новий, кінець ще старий, бо збій стався посеред запису 8 КіБ. модуль 11

повний образ сторінки— full-page image

Копія цілої сторінки в журналі, яку записують при першій зміні сторінки після контрольної точки, щоб відновлення могло замінити розірвану сторінку. модуль 11

контрольна точка— checkpoint

Момент, коли СУБД скидає на диск усі змінені сторінки з buffer pool й записує адресу, з якої після збою починати повтор журналу. модуль 11

точка REDO— REDO point

LSN, з якого відновлення після збою починає повтор журналу; записується контрольною точкою в pg_control. модуль 11

redo— redo

Застосування записів журналу до сторінок під час відновлення; запис пропускають, якщо LSN сторінки вже не менший за LSN запису, тому повтор безпечно повторювати. модуль 11

fsync— fsync

Системний виклик, який повертається, коли ядро вважає дані файла записаними на пристрій; на ньому тримається довговічність коміту. модуль 11

груповий коміт— group commit

Скидання журналу одним викликом для кількох транзакцій, які комітяться одночасно, щоб не чекати диска окремо для кожної. модуль 11

логічний бекап— logical backup

Копія, зроблена запитами до бази: скрипт SQL або архів, з якого відтворюють таблиці й дані; відновлює стан на момент початку копіювання. модуль 11

фізичний бекап— physical backup

Копія файлів каталогу даних разом із журналом, потрібним для узгодженості; основа для відновлення на момент часу. модуль 11

безперервне архівування WAL— continuous archiving

Копіювання кожного завершеного сегмента журналу в окреме сховище, щоб з базовим бекапом відтворити стан бази на будь-яку мить. модуль 11

timeline— timeline

Гілка історії журналу; після відновлення з архіву сервер відкриває нову timeline з наступним номером, щоб нові записи не змішувались зі старими. модуль 11

інкрементальний бекап— incremental backup

Копія лише тих блоків, що змінилися після попередньої копії; для відновлення її поєднують із ланцюжком попередніх копій. модуль 11

III. Масштабування і розподіленість

мастер— primary (leader)

Вузол, який приймає запис і віддає його зміни іншим копіям. У документації PostgreSQL він зветься primary. модуль 12

репліка— replica (follower)

Копія бази, яка отримує зміни від мастера й застосовує їх у тому самому порядку. У режимі hot standby відповідає на читання, але не приймає запис. модуль 12

потокова реплікація— streaming replication

Фізична реплікація PostgreSQL: процес walsender на мастері надсилає байти WAL репліці в міру їх появи, а walreceiver записує їх і застосовує. модуль 12

слот реплікації— replication slot

Запис на мастері, який пам'ятає, до якої позиції WAL дійшов споживач, і не дає прибрати WAL далі. Покинутий слот тримає журнал, поки не заповниться диск. модуль 12

синхронна реплікація— synchronous replication

Режим, у якому COMMIT повертає успіх лише після підтвердження від репліки (отримала, зберегла чи застосувала, залежно від synchronous_commit). Ціна: затримка мережі в кожному коміті. модуль 12

асинхронна реплікація— asynchronous replication

Режим, у якому мастер підтверджує коміт, не чекаючи репліки. Швидко, але закомічені транзакції, яких репліка не отримала, зникають, якщо мастер загине. модуль 12

лаг реплікації— replication lag

Відставання репліки від мастера: у байтах WAL (різниця LSN) або в часі (write_lag, flush_lag, replay_lag у pg_stat_replication). модуль 12

читання власних записів— read-your-writes

Гарантія, що користувач після свого запису бачить його в наступних читаннях. Під лагом порушується, якщо читання потрапило на репліку, яка ще не застосувала цей запис. модуль 12

монотонне читання— monotonic reads

Гарантія, що користувач не бачить даних «з минулого» після того, як побачив новіші. Порушується, коли два читання потрапляють на репліки з різним лагом. модуль 12

конфлікт із відновленням— recovery conflict

Ситуація на репліці, коли застосування WAL вимагає прибрати те, що потрібне запиту, який ще виконується; запит скасовують із помилкою canceling statement due to conflict with recovery. модуль 12

логічна реплікація— logical replication

Реплікація змін на рівні рядків таблиць за моделлю публікація-підписка. Дозволяє копіювати частину таблиць і працювати між різними мажорними версіями, але не переносить DDL і послідовності. модуль 12

failover— failover

Перехід ролі мастера до іншого вузла (перемикання): вручну (pg_promote) або автоматично (Patroni). Після перемикання нова лінія часу починається з позиції, до якої дійшла репліка. модуль 12

split brain— split brain

Стан, коли два вузли одночасно вважають себе мастером і приймають запис у різні історії, які вже не злити без втрат. модуль 12

фенсинг— fencing

Гарантоване виключення старого мастера з роботи (вимкнення вузла, відбирання мережі чи сховища) до того, як новий почне приймати запис, щоб не допустити розщеплення мозку. модуль 12

кворум— quorum

Мінімальна кількість вузлів, відповіді яких потрібні для рішення. У реплікації без мастера читання з R і запис у W вузлів із N перетинаються, якщо R + W > N. модуль 12

партиціювання— partitioning

Поділ однієї таблиці на частини (партиції) всередині одного сервера; частини лишаються однією таблицею для запитів, а запит із ключем партиціювання читає лише потрібні. модуль 13

шардинг— sharding

Поділ даних між окремими серверами (шардами), кожен з яких зберігає свою частину й обробляє запити до неї; масштабує запис, але ускладнює транзакції та запити через кілька шардів. модуль 13

ключ шардування— shard key

Колонка, за значенням якої правило розміщення визначає, на якому шарді лежить рядок; від нього залежить, які запити дешеві, а які розсилаються на всі шарди. модуль 13

консистентне хешування— consistent hashing

Спосіб розміщення, за якого вузли й ключі відображаються в один замкнений у кільце простір хешів, а ключ належить першому вузлу за годинниковою стрілкою; додавання вузла переселяє лише сусідню дугу. модуль 13

гарячий ключ— hot key

Ключ, на який припадає непропорційно велика частка запитів; хеш-шардинг його не розподіляє, і шард із ним стає вузьким місцем. модуль 13

scatter-gather— scatter-gather

Виконання запиту без ключа шардування. Запит розсилається на всі шарди, а відповіді збираються; затримку визначає найповільніший шард. модуль 13

колокація— co-location

Розміщення даних, що з'єднуються або читаються разом, на одному шарді, щоб запит і транзакція не виходили за його межі. модуль 13

двофазний коміт— two-phase commit (2PC)

Протокол атомарного коміту на кількох вузлах. Спершу кожен учасник готується й обіцяє, що зможе зафіксувати, потім координатор розсилає спільне рішення; якщо координатор зникне між фазами, учасники чекають із блокуваннями. модуль 13

лінеаризованість— linearizability

Модель консистентності, за якої система поводиться так, ніби копія одна: кожна операція спрацьовує миттєво між початком і відповіддю, а порядок збігається з реальним часом. Не плутати із серіалізованістю транзакцій. модуль 13

causal consistency— causal consistency

Модель, за якої всі бачать причинно пов'язані операції в однаковому порядку (відповідь після запитання); незалежні операції можуть бути видимі в різному порядку. модуль 13

eventual consistency— eventual consistency

Гарантія, що коли записи припиняються, усі копії врешті збігаються; нічого не обіцяє про те, що бачать читачі в проміжку, і потребує правила розв'язання конфліктних записів. модуль 13

теорема CAP— CAP theorem

Твердження (Брюер, Гілберт і Лінч), що в мережі, яка може втрачати повідомлення, неможливо водночас гарантувати лінеаризовність і відповідь кожного живого вузла на кожен запит; вибір постає лише під час розділення мережі. модуль 13

PACELC— PACELC

Розширення CAP (Абаді): при розділенні вибирають між доступністю й консистентністю, а без розділення між затримкою й консистентністю. модуль 13

консенсус— consensus

Задача, у якій група вузлів ухвалює одне рішення (лідер, наступний запис журналу), хоч частина вузлів і повідомлень зникає; алгоритми (Raft, Paxos) спираються на правило більшості. модуль 13

IV. Нереляційні бази даних

cache stampede— cache stampede

Лавина запитів до бази в момент, коли значення зникло з кешу: багато одночасних запитів бачать промах і кожен сам іде перераховувати те саме значення. модуль 14

cache-aside— cache-aside

Спосіб кешування, у якому кеш про базу нічого не знає: застосунок сам читає кеш, на промаху бере дані з бази й кладе їх у кеш. модуль 14

write-through— write-through

Спосіб кешування, у якому кожен запис іде і в базу, і в кеш в одному шляху, тож кеш лишається теплим, але запис дорожчає. модуль 14

інвалідація кешу— cache invalidation

Скидання або оновлення закешованого значення після того, як змінилися дані, з яких його порахували; найважче в кешуванні через гонки між читачами й записом. модуль 14

TTL— TTL (time to live)

Час життя ключа: після його спливу ключ вважається простроченим і зникає; страхувальна сітка кеша, коли інвалідація пропустила зміну. модуль 14

витіснення— eviction

Видалення ключів, коли пам'ять сховища впирається в ліміт; за політикою (`allkeys-lru`, `volatile-ttl`, `noeviction`) обирається, що саме викинути або чи відмовити в записі. модуль 14

hit rate— hit rate

Частка звернень до кеша, на які він відповів сам: влучання, поділені на суму влучань і промахів. модуль 14

RDB— RDB snapshot

Спосіб персистентності Redis і Valkey: час від часу дочірній процес після fork записує знімок усього набору в файл; компактний, але аварія губить усе після останнього знімка. модуль 14

AOF— AOF (append-only file)

Спосіб персистентності Redis і Valkey: кожну команду запису дописують у журнал, а параметр `appendfsync` вирішує, коли виконувати `fsync`. модуль 14

хеш-слот— hash slot

Одна з 16 384 комірок, на які Valkey Cluster ділить простір ключів за `CRC16(ключ) mod 16384`; кожен вузол володіє діапазоном слотів. модуль 14

хеш-тег— hash tag

Частина ключа у фігурних дужках, яку одну хешують при виборі слота, щоб кілька ключів потрапили в той самий слот і їх можна було зачепити однією командою. модуль 14

HyperLogLog— HyperLogLog

Імовірнісна структура для підрахунку унікальних елементів: фіксований розмір (≈ 12 КБ) і стандартна похибка близько 0.81 %. модуль 14

stream— stream

Структура Redis і Valkey для журналу подій із групами споживачів: прочитане повідомлення лишається в списку непідтверджених, доки споживач не виконає `XACK`. модуль 14

stale-while-revalidate— stale-while-revalidate

Стратегія кеша, за якої прострочене значення віддається одразу, а свіже перераховується у фоні; користувачі не чекають перерахунку. модуль 14

fencing-токен— fencing token

Число, що зростає з кожним взятим блокуванням: сховище відхиляє запис із токеном, меншим за вже бачений, тож клієнт зі спізнілим блокуванням не затре дані. модуль 14

патерн доступу— access pattern

Одне конкретне питання, яке застосунок ставитиме базі, разом із частотою й обсягом відповіді: «замовлення покупця за датою». У DynamoDB перелік патернів доступу складають до схеми, бо від нього залежать ключі й індекси. модуль 15

item— item

Одиниця зберігання в таблиці DynamoDB: набір атрибутів з первинним ключем, до 400 КБ. Items однієї таблиці можуть мати різні набори атрибутів, крім ключових. модуль 15

ключ сортування— sort key

Другий атрибут первинного ключа DynamoDB. Впорядковує items всередині однієї колекції ітемів і дозволяє читати діапазон: `begins_with`, `BETWEEN`, зворотний порядок. модуль 15

item collection— item collection

Усі items з однаковим ключем партиції. Лежать разом і читаються одним запитом; у таблиці з локальним вторинним індексом колекція обмежена 10 ГБ. модуль 15

single-table design— single-table design

Спосіб моделювання, за якого різні сутності лежать в одній таблиці DynamoDB, а ключі з префіксами (`PROD#…`, `ORDER#…`) підібрано так, щоб те, що читається разом, опинилось в одній item collection. модуль 15

глобальний вторинний індекс— global secondary index (GSI)

Копія items таблиці DynamoDB, організована за іншим ключем партиції й сортування. Оновлюється асинхронно, тому читання з нього лише eventually consistent; ключ індексу задають звичайні атрибути item. модуль 15

локальний вторинний індекс— local secondary index (LSI)

Індекс DynamoDB з тим самим ключем партиції, що в таблиці, але іншим ключем сортування. Створюється лише разом із таблицею, дозволяє сильно консистентні читання, але обмежує item collection 10 ГБ. модуль 15

index overloading— index overloading

Один вторинний індекс, що обслуговує кілька сутностей, бо їхні ключі індексу розрізняються префіксами: той самий GSI віддає і замовлення покупця, і товари продавця. модуль 15

розріджений індекс— sparse index

Вторинний індекс, у який потрапляють лише items, що мають ключові атрибути індексу. Індекс за `promo_code` містить тільки замовлення з промокодом, а не всю таблицю. модуль 15

backfill— backfill

Фаза створення нового GSI на наявній таблиці, коли база проходить усі items й записує в індекс ті, що мають ключові атрибути. До кінця заповнення (`ACTIVE`) індекс недоступний для запитів. модуль 15

adaptive capacity— adaptive capacity

Автоматичний перерозподіл пропускної здатності DynamoDB до партицій із більшим трафіком, зокрема винесення гарячого item на окрему партицію. Стелі однієї партиції (3000 читань і 1000 записів на секунду) не підіймає. модуль 15

одиниця читання й запису— read and write capacity unit (RCU, WCU)

Міра пропускної здатності DynamoDB. Одиниця читання це одне strongly consistent читання item до 4 КБ на секунду або два eventually consistent; одиниця запису це один запис до 1 КБ на секунду. модуль 15

BSON— BSON

Двійковий формат документів MongoDB: JSON із додатковими типами (дата, `Decimal128`, `ObjectId`, ціле й дробове число різних розмірів), у якому зберігаються дані й передаються запити. модуль 16

колекція— collection

Набір документів у MongoDB, відповідник таблиці; документи однієї колекції не зобов'язані мати однакові поля, якщо цього не вимагає валідація схеми. модуль 16

ObjectId— ObjectId

Типовий ключ `_id` у MongoDB, 12 байтів; починається з часу створення в секундах, тож ключі, створені пізніше, майже завжди більші. модуль 16

вкладений документ— embedded document

Документ або масив документів усередині іншого документа. Читається й змінюється разом із ним однією операцією. Не плутати з ембедингом для векторного пошуку. модуль 16

посилання між документами— document reference

Поле, що містить `_id` документа з іншої колекції; сервер сам його не перевіряє, з'єднання виконує застосунок або `$lookup`. модуль 16

$lookup— $lookup

Стадія aggregation pipeline, що додає до кожного документа відповідні документи з іншої колекції: аналог `LEFT JOIN`, без зовнішніх ключів і гарантій цілісності. модуль 16

валідація схеми— schema validation

Правила колекції (зазвичай `$jsonSchema`), за якими сервер відхиляє вставку чи зміну документа; без них схему підтримує лише застосунок. модуль 16

multikey-індекс— multikey index

Індекс за полем-масивом: у ньому окремий запис на кожен елемент масиву кожного документа, тож запит за одним елементом знаходить документ без сканування колекції. модуль 16

aggregation pipeline— aggregation pipeline

Послідовність стадій (`$match`, `$unwind`, `$group`, `$sort`, `$lookup`), кожна з яких читає виведення попередньої; основний спосіб робити звіти в MongoDB. модуль 16

сканування колекції— collection scan (COLLSCAN)

План, у якому MongoDB читає всі документи колекції; відповідає `Seq Scan` у PostgreSQL, у `explain` позначається `COLLSCAN`. модуль 16

write concern— write concern

Параметр запису в MongoDB (`w`, `j`), що визначає, скільки вузлів replica set мають підтвердити запис, перш ніж клієнт отримає успіх; `w: 1` чекає лише мастера, `w: "majority"` чекає більшість. модуль 16

read concern— read concern

Параметр читання в MongoDB, що визначає, які дані бачить запит: `local` (що є на вузлі, навіть якщо може відкотитись), `majority` (підтверджені більшістю), `snapshot` (знімок на момент початку транзакції). модуль 16

багатодокументна транзакція— multi-document transaction

Транзакція MongoDB, що змінює кілька документів або колекцій атомарно. З 4.0 на replica set, з 4.2 на шардованому кластері; одиночний документ атомарний і без неї. модуль 16

oplog— oplog

Журнал операцій змін у MongoDB (колекція `local.oplog.rs`), який репліки читають і відтворюють; відповідає потоку WAL у потоковій реплікації PostgreSQL. модуль 16

replica set— replica set

Група вузлів MongoDB з одним мастером (primary) і репліками (secondaries); автоматично обирає нового мастера, коли поточний зникає. Навіть один вузол у replica set вмикає oplog і транзакції. модуль 16

LSM-дерево— LSM-tree (log-structured merge-tree)

Структура зберігання, що нічого не змінює на місці: записи накопичуються в пам'яті, скидаються на диск відсортованими незмінними файлами, а фонова компакція зливає файли. Швидкий запис оплачується складнішим читанням і write amplification. модуль 17

memtable— memtable

Відсортована структура в пам'яті, куди LSM-база спершу записує зміни. Коли вона розростається, її вміст скидається на диск у новий SSTable. модуль 17

commit log— commit log

Файл, у який Cassandra й ScyllaDB дописують кожен запис до того, як він потрапить у таблицю. Відіграє роль WAL: після аварії memtable відновлюється з нього. Типово `fsync` робиться за розкладом, а не на кожен запис. модуль 17

SSTable— SSTable (sorted string table)

Незмінний файл на диску з відсортованими за ключем рядками, який дає скидання memtable або компакція. Складається з даних, індексу, bloom-фільтра й службових файлів. модуль 17

компакція— compaction

Фонове злиття SSTable в новий файл: лишає найновішу версію кожної комірки, викидає перекриті версії й прострочені tombstone. Стратегії (size-tiered, leveled, time-window) по-різному міняють read, write і space amplification. модуль 17

bloom-фільтр— bloom filter

Компактна структура, що про ключ каже «тут точно немає» або «можливо є». Хибного «немає» не дає, хибне «можливо» має малу задану імовірність. Дозволяє LSM-базі не читати SSTable, де ключа нема. модуль 17

tombstone— tombstone

Запис із міткою часу, що позначає видалення комірки, рядка, діапазону чи партиції. Живе щонайменше `gc_grace_seconds` і зникає при компакції після цього. Читання мусить пройти маркери на шляху, тож їх велика кількість сповільнює запити. модуль 17

ключ партиції— partition key

Перша частина первинного ключа в Cassandra й ScyllaDB. Її хеш (token) визначає, які вузли зберігають рядки партиції. Не плутати з партиціюванням таблиці в PostgreSQL: тут партиція є одиницею розподілу між вузлами. модуль 17

ключ кластеризації— clustering key

Колонки первинного ключа після ключа партиції. Впорядковують рядки всередині партиції, тож діапазон у ній читається послідовно. модуль 17

таблиця на запит— table per query

Підхід до моделювання в Cassandra й ScyllaDB: записують список запитів, і кожному відповідає окрема таблиця з ключем, що дозволяє прочитати одну партицію. Дані дублюються між таблицями, а застосунок пише в усі. модуль 17

бакет— time bucket

Часовий відрізок (наприклад місяць), який додають до ключа партиції, щоб партиція не росла без меж. Запит, що охоплює кілька відрізків, читає кілька партицій. модуль 17

рівень консистентності— consistency level

Параметр запиту в Cassandra й ScyllaDB (`ONE`, `QUORUM`, `ALL` та інші): скільки реплік мають відповісти, щоб запит вважався успішним. Окремо для запису й читання; при `R + W > N` читання бачить останній підтверджений запис. модуль 17

часовий ряд— time series

Послідовність записів, прив'язаних до моменту часу, яка здебільшого лише дописується й читається вікнами за часом. Типові потреби: партиціювання за часом, ретеншн і даунсемплінг. модуль 17

ретеншн— retention

Правило, за яким старі дані видаляються: за віком, а не за вмістом. Дешево робиться цілими блоками: відчепленням партиції в PostgreSQL або закінченням TTL у файлі зі стратегією time-window. модуль 17

даунсемплінг— downsampling

Заміна докладних даних часового ряду агрегатами за крупніший відрізок (година, день): рядків стає в десятки разів менше. У PostgreSQL це матеріалізоване представлення з `GROUP BY` за часом. модуль 17

граф властивостей— property graph

Модель даних із вузлів і напрямлених ребер, у якій і вузли, і ребра мають властивості, а вузли ще й мітки; лежить в основі Neo4j, GQL і SQL/PGQ. модуль 18

вузол— node

Сутність графа властивостей, наприклад покупець чи товар; має одну або кілька міток і набір властивостей. модуль 18

ребро— relationship

Напрямлений зв'язок між двома вузлами графа властивостей із типом і власними властивостями; запит може читати його в будь-який бік. модуль 18

мітка— label

Назва типу вузла в графі властивостей, як Customer чи Product; за міткою запит обирає початкові вузли. модуль 18

триплет RDF— RDF triple

Факт у вигляді «суб'єкт — предикат — об'єкт», з яких складається RDF; ребро в ньому властивостей не має. модуль 18

SPARQL— SPARQL

Мова запитів до RDF-даних, рекомендація W3C (версія 1.1 від 2013 року). модуль 18

Cypher— Cypher

Декларативна мова запитів до графів властивостей з Neo4j, яка малює шаблон текстом, як (a)-[:FRIEND]-(b); версія Cypher 25 наближена до GQL. модуль 18

index-free adjacency— index-free adjacency

Спосіб зберігання графа, коли вузол безпосередньо посилається на свої ребра, тож крок обходу є розіменуванням вказівника, а не пошуком в індексі. модуль 18

обхід графа— graph traversal

Послідовне проходження від стартового вузла по ребрах до сусідів, їхніх сусідів тощо; рекурсивний CTE і шаблони Cypher виражають обхід по-різному. модуль 18

шаблон шляху— path pattern

Опис форми шляху в графі в Cypher, GQL і SQL/PGQ: вузли, ребра, їхні типи й мітки та кількість повторів, наприклад -[:FRIEND]-{1,6}. модуль 18

пошук у ширину (BFS)— breadth-first search

Обхід, який обробляє вузли за зростанням відстані від старту й відкидає вже відвідані; у SQL його дає рекурсивний CTE з UNION, у Cypher SHORTEST. модуль 18

вибух шляхів— path explosion

Зростання кількості шляхів з глибиною приблизно в разів, що дорівнює середній кількості сусідів, тоді як кількість різних досяжних вузлів обмежена розміром графа. модуль 18

GQL— GQL

Мова запитів до графів властивостей, стандарт ISO/IEC 39075:2024; окрема мова, не розширення SQL. модуль 18

SQL/PGQ— SQL/PGQ

Частина 16 стандарту SQL:2023: таблиці описують як граф властивостей (CREATE PROPERTY GRAPH) і запитують шаблонами через GRAPH_TABLE; у PostgreSQL немає. модуль 18

найкоротший шлях— shortest path

Шлях між двома вузлами з найменшою кількістю ребер; у Cypher його шукає SHORTEST або shortestPath(), а не перебір усіх шляхів. модуль 18

V. Аналітика і пошук

колонкове зберігання— columnar storage

Спосіб зберігання таблиці, за якого значення однієї колонки лежать підряд окремо від інших колонок; запит читає лише потрібні колонки, а однорідні значення добре стискаються. модуль 19

векторизоване виконання— vectorized execution

Виконання запиту, за якого оператори плану передають одне одному пачку з тисяч значень однієї колонки, а не по одному рядку; зменшує накладні витрати на виклики й дає змогу застосувати SIMD. модуль 19

RLE— run-length encoding (RLE)

Стиснення, що замінює серію однакових значень парою «значення, кількість повторів»; працює для відсортованих колонок і колонок з довгими серіями. модуль 19

словникове кодування— dictionary encoding

Стиснення, що зберігає перелік різних значень колонки й пише замість кожного значення його номер у переліку. модуль 19

дельта-кодування— delta encoding

Стиснення, що зберігає різницю з попереднім значенням замість самого значення; ефективне для зростаючих послідовностей, як ідентифікатори чи час. модуль 19

мін-макс індекс— zone map

Найменше й найбільше значення колонки для кожного шматка даних (групи рядків, гранули); запит пропускає шматки, діапазон яких не перетинає умову. Аналог BRIN. модуль 19

розріджений первинний індекс— sparse primary index

Індекс, що зберігає один запис на групу рядків (у ClickHouse на гранулу з 8192 рядків), а не на кожен рядок; працює, бо таблицю впорядковано за ключем індексу. модуль 19

гранула— granule

Найменша порція рядків таблиці MergeTree, яку ClickHouse читає й адресує розрідженим індексом; типово 8192 рядки. модуль 19

група рядків— row group

Горизонтальна частина файлу Parquet (а також блок сховища DuckDB), у якій кожна колонка лежить окремим шматком з власною статистикою мінімуму й максимуму. модуль 19

таблиця фактів— fact table

Центральна таблиця схеми «зірка», що зберігає вимірювані події (рядок замовлення з кількістю й ціною) і ключі до вимірів. модуль 19

таблиця вимірів— dimension table

Довідник, за яким групують і фільтрують факти: товар, покупець, час, категорія. модуль 19

схема «зірка»— star schema

Організація аналітичних даних, за якої таблиця фактів пов'язана з кожним виміром напряму одним ключем, а виміри не нормалізуються далі. модуль 19

схема «сніжинка»— snowflake schema

Різновид зірки, у якому виміри нормалізовано: товар посилається на категорію, покупець на населений пункт; менше дублювання, більше `JOIN`. модуль 19

ETL і ELT— ETL and ELT

Два порядки доставки даних в аналітику: ETL перетворює дані до завантаження, ELT завантажує сирі дані й перетворює їх запитами вже в аналітичній системі. модуль 19

захоплення змін (CDC)— change data capture (CDC)

Читання потоку змін рядків з журналу транзакційної бази (для PostgreSQL через логічне декодування WAL) і доставка його в інші системи майже в реальному часі. модуль 19

інвертований індекс— inverted index

Індекс, що для кожної лексеми зберігає список документів, де вона трапляється. Запит читає кілька списків замість усіх документів; так влаштований GIN над `tsvector` і індекс Lucene. модуль 20

лексема— lexeme

Нормалізована форма слова, яку зберігає `tsvector`: «чохли» й «чохлів» дають лексему «чохол». модуль 20

стемінг— stemming

Нормалізація слів відрізанням закінчень за правилами. Дає основу, яка не обов'язково є словом, і не знає чергувань на кшталт «чохол» — «чохлів». модуль 20

лематизація— lemmatization

Зведення форми слова до початкової за словником (hunspell, Morfologik). Для мов із багатою морфологією, як українська, точніша за стемінг. модуль 20

стоп-слова— stop words

Дуже поширені слова («для», «від», «і»), які прибирають з індексу й запиту, бо вони не відрізняють документи один від одного. модуль 20

BM25— BM25

Формула ранжування: сума по словах запиту з множників `IDF` (рідкісне слово важить більше) і насиченої частоти слова з поправкою на довжину документа. Типова в Lucene й OpenSearch. модуль 20

косинусна відстань— cosine distance

Міра віддаленості двох векторів: `1 − cos(кут між ними)`. У pgvector оператор `<=>`; для нормованих векторів дорівнює `1 − скалярний добуток`. модуль 20

ANN— approximate nearest neighbours (ANN)

Наближений пошук найближчих сусідів: індекс повертає майже найближчі вектори швидше за точний пошук і платить за це recall. модуль 20

HNSW— HNSW

Індекс ANN у вигляді графа з шарів: верхні шари рідкі й дають довгі стрибки, нижній містить усі вектори. Параметри `m`, `ef_construction`, `ef_search`. модуль 20

IVFFlat— IVFFlat

Індекс ANN, що ділить вектори на кластери (`lists`) і шукає лише в кількох найближчих до запиту (`probes`). Будується швидко, але потребує даних на момент побудови. модуль 20

recall— recall

Частка справжніх відповідей, які повернув пошук. Recall@10 для ANN-індексу: скільки з десяти точних найближчих сусідів він знайшов. модуль 20

nDCG— nDCG

Метрика якості видачі з урахуванням місця: релевантний документ на місці `r` дає `1/log2(r + 1)`, сума ділиться на найкращу можливу. Значення від 0 до 1. модуль 20

гібридний пошук— hybrid search

Поєднання повнотекстового й векторного пошуків: два списки результатів зливають в один, найчастіше за місцями (RRF). модуль 20

reciprocal rank fusion— reciprocal rank fusion (RRF)

Злиття списків за місцями: документ отримує `Σ 1 / (k + ранг)` по кожному списку, `k` зазвичай 60. Не залежить від шкал оцінок. модуль 20

VI. Експлуатація і вибір

роль— role

Єдина в PostgreSQL сутність для користувача й групи: з правом LOGIN вона підключається, без нього лише збирає привілеї, які видають іншим ролям. модуль 21

PUBLIC— PUBLIC

Псевдороль «усі ролі». За замовчуванням має CONNECT на нові бази й EXECUTE на нові функції, тож ці права відбирають явно. модуль 21

привілеї за замовчуванням— default privileges

Налаштування ALTER DEFAULT PRIVILEGES: які права автоматично отримує об'єкт, створений названою роллю в схемі. Діють лише на майбутні об'єкти цієї ролі. модуль 21

SECURITY DEFINER— SECURITY DEFINER

Властивість функції виконуватись з правами власника, а не викликача. Дає контрольований прохід до даних, але потребує фіксованого search_path і відкликання EXECUTE у PUBLIC. модуль 21

захист на рівні рядків (RLS)— row-level security (RLS)

Механізм, який додає до кожного запиту до таблиці умову на рядки за політиками CREATE POLICY. Без політики для ролі вона не бачить жодного рядка. модуль 21

обхід RLS— RLS bypass

Випадки, коли політики не діють: суперкористувач і роль з BYPASSRLS завжди, власник таблиці, поки не виконано FORCE ROW LEVEL SECURITY. модуль 21

pg_hba.conf— pg_hba.conf

Файл правил автентифікації клієнтів: для типу з'єднання, бази, ролі й адреси вказує метод. Діє перший рядок, що збігся. модуль 21

SCRAM-SHA-256— SCRAM-SHA-256

Типовий метод автентифікації за паролем у PostgreSQL з версії 14. Сервер зберігає значення для перевірки, а пароль у мережі не передається. модуль 21

sslmode— sslmode

Параметр libpq, що задає вимогливість клієнта до TLS. Типовий prefer не гарантує шифрування, require шифрує без перевірки сервера, verify-full перевіряє ланцюжок і ім'я. модуль 21

персональні дані— personal data

Відомості, за якими можна впізнати людину: ім'я, email, дата народження, адреса, а іноді й поведінка. Для бази це набір вимог до доступу, строку зберігання й стирання. модуль 21

анонімізація— anonymisation

Необоротна заміна персональних даних у рядку так, що людину вже не впізнати, а сам рядок лишається для обліку. Копії в бекапах і системах-споживачах цим не змінюються. модуль 21

логічне декодування— logical decoding

Витягання змін рядків із WAL через слот реплікації й плагін виводу. На ньому тримаються логічна реплікація й CDC. модуль 21

outbox— transactional outbox

Шаблон, коли подію для іншої системи пишуть у таблицю в тій самій транзакції, що й зміну даних, а окремий процес доставляє її з повтором. модуль 21

подвійний запис— dual write

Запис застосунку в дві системи окремими кроками. Збій між кроками лишає системи різними, бо спільного коміту немає. модуль 21

polyglot persistence— polyglot persistence

Підхід, коли різні задачі системи зберігають у різних базах під свою модель даних. Ціна: синхронізація, ще один бекап, моніторинг і команда на кожну. модуль 21