Hacker News Digest

• Данные на странице IMDB иерархические: фильм → режиссёр, жанры, актёры → персонажи.
• Иерархия двунаправленная: фильм→актеры и актер→фильмы.
• Реляционная БД хранит всё в плоских таблицах; при выводе строим нужную иерархию.
• Ручная сборка — утомительна, это «объектно-реляционное несоответствие».

SQL не умеет выдавать структуру
Цель: JSON вида

{"title":"Baby Driver","director":["Edgar Wright"],"writer":["Edgar Wright"],
 "genres":["Action","Crime","Drama"],
 "actors":[{"name":"Ansel Elgort","characters":["Baby"]}, …]}

Пошаговые запросы:

-- название
SELECT primaryTitle FROM title WHERE tconst='tt3890160';

-- режиссёры
SELECT p.primaryName
FROM title t
JOIN principal pr ON t.tconst=pr.tconst
JOIN person   p  ON pr.nconst=p.nconst
WHERE t.tconst='tt3890160' AND pr.category='director';

-- сценаристы
... AND pr.category='writer';

-- актёры
SELECT p.nconst, p.primaryName
FROM title t
JOIN principal pr ON t.tconst=pr.tconst
JOIN person   p  ON pr.nconst=p.nconst
WHERE t.tconst='tt3890160' AND pr.category='actor';

-- персонажи
SELECT pc.nconst, pc.character
FROM title t
JOIN principal pr          ON t.tconst=pr.tconst
JOIN principal_character pc ON pr.nconst=pc.nconst
WHERE t.tconst='tt3890160';

Попытка объединить всё в один запрос даёт декартово произведение (режиссёры×сценаристы) и пропуск записей при отсутствии одной из ролей. Поэтому приходится делать множество отдельных запросов и собирать итоговую структуру на клиенте.

• Обсуждение крутится вокруг «объектно-реляционного несоответствия»: SQL хорошо хранит нормализованные данные, но плохо отдаёт их иерархически.
• Многие считают, что виноват сам язык: нет встроенных вложенных отношений, агрегация в JSON делается громоздко, JOIN-ы приходится «переделывать» в коде.
• Часть участников предлагает решать задачу внутри СУБД: Postgres-функции json_agg, LATERAL-подзапросы, денормализованные VIEW и «JSON-проекции».
• Другие уверены, что проблема надумана: деревья в SQL вполне строятся (adjacency list, nested sets, closure table), просто нужно знать приёмы; ORM и NoSQL лишь откладывают боль.
• Упоминаются альтернативные пути: GraphQL-слой поверх SQL, графовые СУБД, документные хранилища (MongoDB), event-sourcing с CQRS, но каждый имеет свои trade-off.

Один большой сервер вместо оркестра микросервисов

Современный сервер Azure с двумя AMD EPYC 3-го поколения даёт:

• 128 физических ядер / 256 потоков
• до 8 ТБ ОЗУ, 200 ГБ/с пропускная способность
• 128 линий PCIe 4.0 → 30 NVMe + 100 Гбит/с сеть
• 4 TFLOPS — в 2000 г. хватило бы для первой строчки Top500

Что он умеет

• 800 Гбит/с видео (Netflix)
• 1 млн IOPS в NoSQL, 70 k IOPS в PostgreSQL
• 500 k RPS nginx, компиляция ядра Linux за 20 с, кодирование 4K-видео 75 fps

Сколько стоит

• Аренда:
  – OVH: 128 ядер, 512 ГБ ОЗУ, 50 Гбит/с — $1 318/мес.
  – Hetzner: 32 ядра, 128 ГБ — €140/мес.
  – AWS m6a.metal: 96 ядер, 768 ГБ — $6 055/мес.
• Покупка: ~$40 000 за аналогичную конфигурацию у Dell.

Вывод
Для большинства задач один такой сервер перекрывает потребности всей компании. Распределённые системы нужны редко; чаще достаточно «одного большого сервера» и простого деплоя.

• «Облачный налог» заставляет инженеров выбирать только дорогие облачные решения, хотя за $200/мес. у Hetzner можно взять 48 ядер и 128 ГБ ОЗУ, тогда как AWS даёт лишь 4 vCPU и 16 ГБ.
• Многие участники подтверждают: при стабильной нагрузке гибрид «colo + VPS» или одна большая машина дешевле и проще, чем микросервисы и K8s.
• Ключевые риски: единая точка отказа, необходимость админов и железных рук; зато нет «meta-слоёв» Docker-proxy-nginx и можно выжимать максимум из железа.
• Часть команд тратит годы на «cloud-native» пайплайны и закрывается, не успев выйти на рынок; проще начать с PaaS/Hetzner и переезжать, когда счёт действительно больно.
• Для критичных задач достаточно двух физических серверов (active/backup) и CDN; 99,9 % доступности хватает большинству бизнесов, которым на деле не нужен 100 % uptime.