Когда реляционное хранилище плохо подходит — Примеры

Пример 1 — Таблица, большинство столбцов которой пусты

Таблица ниже хранит в одном месте каталог книг и каталог загрузок. У большинства строк большинство этих столбцов пусты, а каждый новый вид элемента добавляет столбцы ещё. Назовите, что эта таблица имитирует, решите, действительно ли изменяющиеся атрибуты переменные, и постройте форму, которую вы бы хранили вместо неё.

CREATE TABLE items (
  id          bigint PRIMARY KEY,
  title       text NOT NULL,
  author      text,        -- только для книг
  pages       integer,
  isbn        text,
  duration    integer,     -- только для загрузок
  resolution  text,
  media_id    text
);

Решение

title: Ship It
kind: book
detail: { author: "A. Writer", pages: 320, isbn: "9780000000000" }

title: Systems in Practice
kind: download
detail: { durationSeconds: 5400, resolution: "1080p", mediaId: "med_a1" }

Реляционная модель предполагает, что у каждой строки таблицы одни и те же атрибуты, а здесь это явно не так: изменяющаяся часть действительно переменна, а не просто разрежена. Значит, перед нами форма документа, которая надела на себя столбцы, и ограничения на неиспользуемые столбцы в ней бессмысленны. Честных вариантов два: таблица на каждый вид, соединяемая, когда нужны обе, либо документ с полем kind, форму которого валидируют на границе. Второй вариант схему не убирает; однако её обеспечение переезжает в код, который читает данные, а невалидируемая коллекция накапливает там десяток вариантов одной записи.

Пример 2 — Три набора данных и что решает хранилище каждого

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

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

Решение

хранилище сессий    выбирается только по одному ключу      -> ключ-значение
каталог товаров     атрибуты различаются по записи         -> документное
социальный граф     обход на несколько уровней вглубь      -> графовое

ни одну из трёх не решает размер

Реляционный движок поддерживает индексы и планировщик, чтобы отвечать на вопросы, которых никто ещё не задавал, а нагрузка сессий лишь просит значение ключа и платит за механизмы, которых никогда не использует. Графовый запрос — соединение, повторённое неизвестное число раз: неуклюжее в выражении и прямое там, где связи и есть данные. Во всех трёх случаях несоответствие в том, как данные устроены и читаются, а не в том, сколько их; обычное обоснование — масштаб, а обычная реальность — небольшая нагрузка с неудобной схемой.