Магия оптимизации SQL запросов

Думаю, каждый хоть раз использовал команду explain или хотя бы слышал про нее. Эта команда демонстрирует план выполнения запроса, но как именно СУБД приходит к нему остается загадкой. Да и как вообще СУБД понимает, что выбранный запрос оптимален? Неужели она проверяет все возможные варианты?
В этой статье я постараюсь дать небольшое представление о том, как работают оптимизаторы запросов с теоретической точки зрения.

Начнем с того, что можно выделить два основных подхода к поиску наиболее эффективного варианта выполнения: эвристический и стоимостной.

https://habr.com/ru/articles/709898/

#db

👉 @database_info

Как я искал ПДн в 300 базах данных [и сохранил рассудок]

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

Если этого не сделать, то рано или поздно данные могут утечь и ещё можно нарваться на высокие штрафы при утечке. Задача безопасников (и основная выгода от их наличия в компании) — минимизация таких рисков.

Вот только у нас несколько сотен баз данных, где-то около трёхсот. Даже если просто заглянуть в них и попытаться сделать выборку — это займёт весьма продолжительное время. И никто не имеет полной картины, где что хранится.

Скорее всего, вам скоро предстоит такое же, поэтому сейчас покажу артефакты, которые я нашёл в процессе.

https://habr.com/ru/companies/skyeng/articles/792494/

#db

👉 @database_info

Postgres: Графовая база данных, о которой вы не знали

PostgreSQL (Postgres) - это мощная реляционная база данных, которая может хранить широкий спектр типов и структур данных. Когда речь заходит о хранении структур данных графов, мы можем обратиться к базам данных, предназначенным для этого случая, например Neo4J или Dgraph. Придержите лошадей! Хотя Postgres обычно не рассматривается при работе с графовыми структурами данных, она прекрасно подходит для хранения и эффективного запроса графовых данных.

https://www.dylanpaulus.com/posts/postgres-is-a-graph-database

#db

👉 @database_info

Как работают атомарные транзакции в базе данных?

Атомарность делает возможным, чтобы транзакция имела только 2 результата:
- она успешно выполняет все операции и фиксируется
- прерывается из-за сбоя и отменяет все изменения

В единой базе данных атомарность возможна благодаря сохранению всех изменений в данных в журнале опережающей записи (WAL).
Каждый раз при внесении изменений WAL сохраняет их на диске, чтобы они сохранились надолго.
Каждая запись в WAL содержит всю информацию для отмены всех изменений.
Однако подход WAL недостаточен, если транзакция затрагивает более одной базы данных.
В таких ситуациях часто используется протокол двухфазной фиксации (2PC).
Согласно этому протоколу, один процесс должен быть координатором, а остальные - участниками.
Задача координатора - следить за тем, чтобы участники выполняли свою часть работы.
Чаще всего координатором является клиентский процесс, которому требуется транзакция.

Протокол состоит из 2 этапов:

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

После ответа участники ждут дальнейших инструкций.

2. Коммит.
Если все участники готовы, координатор посылает им запрос на фиксацию. В противном случае он попросит прервать транзакцию.
Этот шаг является точкой невозврата: транзакция должна быть зафиксирована или прервана.

Протокол 2PC работает, но имеет ряд недостатков:
- он медленный, так как требует многократных обходов между процессами
- блокируется при сбое координатора или отказе участника на этапе фиксации.

Репликация задействованных процессов делает 2PC более надежным, но добавляет сложности.

#db

👉 @database_info