DB
тяжелый - запрос медленный
Size: a a a
2019 May 31
DB
тяжесть измеряется по отношению записей в каждой таблице
AŽ
простите не удержался))
IG
Ага, нет. Десять случаев
# автор забыл?IG
еще крышку, собаку и бог знает что еще.
MP
тяжесть измеряется по отношению записей в каждой таблице
А ну, да. Согласен, кэп.
1к записей прочитать наверняка можно быстрее, чем 1м.
Но джоин тут как бы не при чем.
1к записей прочитать наверняка можно быстрее, чем 1м.
Но джоин тут как бы не при чем.
MP
Однако, например, в Постгресе с "тяжестью" джоинов все не так просто.
MP
если, скажем нам надо соединить данные из двух таблиц А и Б, то под "тяжестью" принято подразумевать количество дополнительных чтений, относительно прямого чтения А и прямого Б.
MP
То есть, если по какой-то странной причине ключ джоина получился не индексированным (джоин пл функции, например), то весьма вероятно нарваться на N*N/2 чтений - вот это уже тяжесть.
Что характерно, в некоторых случаях денормализация может практически не дать уменьшения количества чтений.
Что характерно, в некоторых случаях денормализация может практически не дать уменьшения количества чтений.
DB
Я не очень понял, я не спец по базам. Хочу уточнить
DB
если с ключами все нормально при join, вы утверждаете запрос на одну таблицу и запрос с джойном на две таблицы будут работать одинаково?
AG
Напоминает обсуждение сферического коня в вакууме. Есть же explain и все зависит от конкретных случаев, как то: самой БД, размеров и параметров таблиц, данных, от индексов, типа объединения и тд.
MP
если с ключами все нормально при join, вы утверждаете запрос на одну таблицу и запрос с джойном на две таблицы будут работать одинаково?
тут надо определиться о чем речь.
То есть у нас есть некие записи типа А и типа Б, нам надо получить их (допустим все или около того) в виде А+Б соединенными по какому-то значению определенного совпадающего поля.
То есть у нас есть некие записи типа А и типа Б, нам надо получить их (допустим все или около того) в виде А+Б соединенными по какому-то значению определенного совпадающего поля.
MP
мы можем положить записи А в одну таблицу, а Б в другую, тогда для А+Б нам понадобится минимум 2*N чтений (изначально мы предполоджили, что А и Б много и примерно одинаково)
MP
теперь мы подумали и решили положить сразу А+Б в одну кучу (денормализовав) и сразу читать их скопом как надо
MP
по идее чтений должно стать меньше, но это сложный вопрос.
Теперь надо понять как наши данные могут расложиться по блокам СУБД (у постгреса по дефолту 8к страницы)
Теперь надо понять как наши данные могут расложиться по блокам СУБД (у постгреса по дефолту 8к страницы)
MP
... чую я сейчас всех просто запутаю дополнительно....
Н
В случае денормализации, как обеспечиваете целостность? Во время мутации данных делаете запрос за апдейт денормализированных полей, либо же другой вариант?
PP
по идее чтений должно стать меньше, но это сложный вопрос.
Теперь надо понять как наши данные могут расложиться по блокам СУБД (у постгреса по дефолту 8к страницы)
Теперь надо понять как наши данные могут расложиться по блокам СУБД (у постгреса по дефолту 8к страницы)
У него там ещё TOAST есть, что добавляет огоньку для некоторых типов данных.