🔍 Инструменты чтения плана запроса: EXPLAIN и EXPLAIN ANALYZE

Когда запрос в базе работает медленно — не надо гадать на кофейной гуще. В PostgreSQL есть два супер-инструмента, которые позволяют увидеть, что именно делает оптимизатор и где запрос тратит время

Речь про EXPLAIN и EXPLAIN ANALYZE

🥰 EXPLAIN — прогноз плана

EXPLAIN показывает, как PostgreSQL собирается выполнить запрос:
— какие индексы может использовать
— какой тип сканирования выберет (Seq Scan, Index Scan, Bitmap Index Scan)
— предполагаемое количество строк
— стоимость выполнения (cost)

😁 Полезно, когда ты хочешь понять теоретический план без реального запуска запроса

Пример запроса

EXPLAIN SELECT * FROM users WHERE email = 'test@mail.com';

⸻

⚡️ EXPLAIN ANALYZE — фактические замеры

EXPLAIN ANALYZE выполняет запрос реально и показывает:
— сколько времени занял каждый шаг
— реальное количество строк
— время старта операции
— расхождение между прогнозами и фактами

Если EXPLAIN — теория, то EXPLAIN ANALYZE — практика

Пример запроса

EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@mail.com';

📝 Тут внимательнее: запрос действительно выполнится, поэтому с UPDATE/DELETE используй на тестовых данных

⸻

😴 Что смотреть в плане?
1) Seq Scan — сигнал: возможно нет индекса
2) Row Estimate vs Actual Rows — если сильно расходится, оптимизатор ошибся → можно помочь статистикой
3) Filter / Recheck — где происходит фильтрация
4) Timing — какой узел съедает больше всего времени
5) Planning Time / Execution Time — понять, где узкое место

🚀 Пост Guru Node.js: @DemetraIT

📝 CAP-теорема простыми словами

Иногда на собесах или работе можно встретить вопрос про CAP теорему

В распределённых системах нельзя одновременно обеспечить три свойства:
1) C — Consistency: все узлы возвращают одинаковые данные
2) A — Availability: система всегда отвечает (не важно ошибки в бд или успех)
3) P — Partition tolerance: работает даже при проблемах сети при масштабировании

Причем в реальности выбираем P неизбежно, так как сеть ненадежна.
Поэтому реальный выбор — между C и A

☺️ CP — согласованность важнее доступности

Система лучше не ответит, чем вернёт разные данные из разных узлов
Примеры: Zookeeper, etcd, PostgreSQL в синхроне

💀 AP — доступность важнее согласованности

Система отвечает всегда, даже если данные временно расходятся. Это может быть удобно, например, при реализации лайков (не страшно, если будет расхождение)
Примеры: Cassandra, MongoDB, Dynamo-подобные

💡 Итог
CAP — это про компромисс: что для тебя важнее при аварии — доступность или корректность данных?

Есть еще так NewSQL, которые якобы могут и масштабироваться, советую почитать про такой вид бд

🚀 Пост Guru Node.js: @DemetraIT

🎶 Архитектура Node.js и зачем нужен V8

🧠 Что такое Node.js
Напомню, что нода — это рантайм, который позволяет выполнять JavaScript вне браузера

😎 Из чего состоит Node.js
1) V8 — JS-движок от Google
Парсит и компилирует JavaScript в машинный код

2) Event Loop (libuv)
Управляет асинхронностью, таймерами, I/O, очередями задач

3) Thread Pool
Для блокирующих операций: fs, crypto, dns

4) C++ bindings
Связь между JS и системными вызовами ОС

Далее разберем v8 под капотом

🐗 Что есть внутри V8
— Call Stack (стек)
Хранит контекст выполнения функций

— Heap (куча)
Память для объектов, массивов, замыканий

— Garbage Collector
Автоматически очищает неиспользуемую память (рекомендую изучить подробнее)

— JIT-компиляция
Превращает JS в машинный код на лету

Помнить про внутренность v8 важно, так как иногда это спрашивают на собеседованиях


🚀 Пост Guru Node.js: @DemetraIT