вчерашний разговор об условиях задачи

скорость с субд вообще помоему на втором месте

вы все про скорость, а могу ли я доверять данным в mat.view?

нет, для этого есть SSOT

а потом прочитаешь все данные, которые там лежат

С чего вдруг? ? ты в курсе, в какой момент читаются все данные?

ну что ты, ты делаешь запрос, чтобы не прочитать из таблицы данные

в смысле что будет делать СУБД вовремя join

Прочитает индекс

Прочитает индекс

он не просто почитает, он будет в нём искать причём каждый ключь по отдельности

Прочитает индекс

а потом по полученому tid искать данные в основной таблице

а потом по полученому tid искать данные в основной таблице

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

он не просто почитает, он будет в нём искать причём каждый ключь по отдельности

это будет не скан

а потом по полученому tid искать данные в основной таблице

данные "ключ-значение" читаются в рамках индекса

это будет не скан

иии?

и еще

при денормализации будет сплошная таблица фактов, малейшее условие - это скан таблицы

данные "ключ-значение" читаются в рамках индекса

чего? в postgres индексы отделены от данных.

иии?

я так понимаю, что такое индекс и как он работает вам неизвестно

при денормализации будет сплошная таблица фактов, малейшее условие - это скан таблицы

ну так будут те же индексы по нужным полям

ну так будут те же индексы по нужным полям

так будет по меньшей таблице, а джойны отсеют данные

я так понимаю, что такое индекс и как он работает вам неизвестно

я понимаю как они работают в postgres так как я их там ковырял (brin, gist).

ну т.е. вы понимаете отличие scan от seek, да?

так будет по меньшей таблице, а джойны отсеют данные

это всё зависит того какие у вас данные, тут бабушка надвое сказала.

это всё зависит того какие у вас данные, тут бабушка надвое сказала.

да какие бы они не были, любое условие в одной таблице даст отсев по другой

это стандарт как бы

ну т.е. вы понимаете отличие scan от seek, да?

да, толкьо вот postgres этим не оперирует, он с данными через буфер менеджер работает который всегда делает read 8 килобайт даже если надо небольшую ноду в btree прочитать

--- Всем привет. Столкнулся с такой проблемой: после массивного апдейта(каждую запись отдельно, не в транзакции) индекс не достроен. Это я понимаю по выборке сразу после апейтов и через какое то время. Это нормальное поведение? Что посмотреть посоветуете? Заранее спасибо

короче join двух таблиц медленее чем index-scan по денормализованной таблице у которой размер 2х.

не суть как называть

короче join двух таблиц медленее чем index-scan по денормализованной таблице у которой размер 2х.

хуясе

ну ок

я даже продолжать не буду, если это так в постгрес - это печально

если вы ошибаетесь, то продолжать нет смысла

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

Ну ка ну ка, почему же?

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

конечно, если у вас есть выборка в первой таблице и join со второй будет только один раз... это конечно другой разговор

но мы же говорим про те данные которые имеет смысл денормализовывать

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

да, я понял так

но мы же говорим про те данные которые имеет смысл денормализовывать

А какие данные имеет смысл денормализовывать?

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

в денормализации вы сделаете хренову кучу индексов на одну таблицу

в денормализации вы сделаете хренову кучу индексов на одну таблицу

а так у вас будет куча индексов на много таблиц...

+ уникальные ключи

там будут ровно те же индексы, что нужны и для выборок по двум таблицам

а так у вас будет куча индексов на много таблиц...

как следствие, я буду читать только то, что необходимо, а не все

типа в нормализованной версии я не буду делать индексы по тем полям, по которым я делаю выборки?

Это повышения формирование таблицы фактов

Вот только таблица фактов в полном виде нужна в редких случаях и обычно там скорость не нужна

типа в нормализованной версии я не буду делать индексы по тем полям, по которым я делаю выборки?

не будешь их читать в большинстве случаев

денормализация нужна только для olap и подобия

как следствие, я буду читать только то, что необходимо, а не все

в этом смысл денормализации ¯\_(ツ)_/¯

то есть при выборках в нормализованных данных я не буду использовать индексы?

Это повышения формирование таблицы фактов

Простите, пожалуйста, но я не понимаю данной фразы. От слова совсем. НЕ согблаговолит ли благородный дон, объяснить ее смысл?

если у тебя практически любой запрос делает join данных в отношениии 1 к 1 то тут и нужна денормализация

пока это звучит так

Простите, пожалуйста, но я не понимаю данной фразы. От слова совсем. НЕ согблаговолит ли благородный дон, объяснить ее смысл?

Не соблоговолит в таком тоне

короче, смотри

у меня в приложении есть страница "друзья друзей"

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

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

это все еще медленнее, чем джойны?

невкурил, почему 4, но у тебя либо избыточность данных, либо джойн

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

Не соблоговолит в таком тоне

А в каком тоне обращаться? Я без подколов, мне реально непонятна фраза. :(

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

как только вася пупкин поменяет имя/фамилию, ты попадаешь в полную жопу

не-не

давай не про жопу

Мне кажется тут много "дополнительных факторов" - например структура таблиц, помещаются ли индексы в память, если не помещаются - то скорость io и тп. Что быстрее на абстрактном коне в вакууме не скажешь

это медленнее или нет?

это быстрее, только в чтении, в хранении и записи/обновлении ты в жопе

как только появляется новый пользователь - у тебя лишния запись в БД

как только появляется новый пользователь - у тебя лишния запись в БД

если он появляется в 0.00001% случаев от чтения то это замечательно

под словом "запись" я подразумеваю не только сам факт наличия данных, но и процесс

если он появляется в 0.00001% случаев от чтения то это замечательно

процент там будет явно не такой

ну я вот то же у себя пишу некоторые данные сразу в 4 места (не говоря уже про кеш), но делаю я это раз в 5-10 минут вообще (а не для каждого объекта), а читаю я данные из таблицы до сотни раз в секунду. Ну вот и бенефит.

у меня с начала всё было нормализованно, после денормализации я смог ускорится где то в 20х раз .

это быстрее, только в чтении, в хранении и записи/обновлении ты в жопе

УРА

про хранение и записи смотри выше про SSOT

про хранение и записи смотри выше про SSOT

не взлетит

в рамках постгреса может это у вас заебись практика

в postgres есть транзакции, ура! :)

но в рамках архитектуры БД, это полный ппц

в postgres есть транзакции, ура! :)

кэп

чувак, я на кассандре вообще пишу, когда у меня нет условий конкретного движка

молодец, а я пользуюсь БД под проект

если ты соизволишь почитать, как сейчас делаются дела в двадцать первом веке - ты узнаешь, что вот так они и делаются

если ты соизволишь почитать, как сейчас делаются дела в двадцать первом веке - ты узнаешь, что вот так они и делаются

как скажешь, поэтому наверно в том же авито 6NF

господи, авито - это помойка

господи, авито - это помойка

ну а твои бложики не помойка, ок

а аргумент к авторитету - это худший аргумент на свете

но в рамках архитектуры БД, это полный ппц

дык по тому что теория мало сейчас связана с практикой, всё сильно поменялось с 80х

дык по тому что теория мало сейчас связана с практикой, всё сильно поменялось с 80х

ага, шли от денормализации к нормалным формам от 3NF до 6NF, а тут вдруг выясняется, что в постгресе заебись денормализация

вон, в кликхаус денормализация

а толку

все прекрасно работает, пока в лучшем случае звезда

как только надо написать сложный запрос, получить точное значние или сделать снежинку - мы в жопе

началось

anchor model bingo

а поменять структуру, так это вообще полный анрил

ага, шли от денормализации к нормалным формам от 3NF до 6NF, а тут вдруг выясняется, что в постгресе заебись денормализация

так оно и есть, говорю как разработчик postgres, у postgres вообще проблемы с запросами у которых больше 8 join