VY
iwanttobeleve
Аа, я имел ввиду блокировки на чтение и запись, я так понимаю, блокировка, которую он держит все время не мешает ни писать ни читать, и только эксклюзивная в конце и в начале не даёт ни писать ни читать?
да, именно так.
Size: a a a
2020 July 16
i
да, именно так.
Спасибо большое!
А вы не знаете , может быть так, что по каким-то причинам эксклюзивная блокировка держалась дольше тайм-аута?
А вы не знаете , может быть так, что по каким-то причинам эксклюзивная блокировка держалась дольше тайм-аута?
VY
iwanttobeleve
Спасибо большое!
А вы не знаете , может быть так, что по каким-то причинам эксклюзивная блокировка держалась дольше тайм-аута?
А вы не знаете , может быть так, что по каким-то причинам эксклюзивная блокировка держалась дольше тайм-аута?
таймаут влияет на то, как долго пытаемся взять блокировку.
вы расскажите что у вас за ситуация была, а то гадать не хочется
вы расскажите что у вас за ситуация была, а то гадать не хочется
i
таймаут влияет на то, как долго пытаемся взять блокировку.
вы расскажите что у вас за ситуация была, а то гадать не хочется
вы расскажите что у вас за ситуация была, а то гадать не хочется
Да ситуации пока не было, просто нужно запустить репак и сориентироваться, сколько будет простой работы с базой
Но при этом репак такой, что бы таблица пересоздалась в другом tablespace, то есть на другом диске.
Но при этом репак такой, что бы таблица пересоздалась в другом tablespace, то есть на другом диске.
YS
не поняла. что именно вы имеете в виду. например есть 5кк записей которые обновились за час. запускаю джобу по updated_at > current_timestamp - interavl ‘’1 hour’ и так каждый час
Да уж. :( Вы понимаете, что чуть что не так — и этот подход уже теряет данные направо и налево (видел такое много раз)?
В сторону: вот откуда все эту дрянь берут и почему верят, что оно обязано (или вообще может) работать? ;(
В сторону: вот откуда все эту дрянь берут и почему верят, что оно обязано (или вообще может) работать? ;(
VY
iwanttobeleve
Да ситуации пока не было, просто нужно запустить репак и сориентироваться, сколько будет простой работы с базой
Но при этом репак такой, что бы таблица пересоздалась в другом tablespace, то есть на другом диске.
Но при этом репак такой, что бы таблица пересоздалась в другом tablespace, то есть на другом диске.
не будет простоя
VY
надеюсь индекс по полю updated_at конечно есть?
на горячей таблице такой индекс вырубит HOT, что может быть больно
СГ
на горячей таблице такой индекс вырубит HOT, что может быть больно
но у них вся таблица в память не влазит, иначе фуллскан придётся делать для выборки изменившихся строк. Да, палка о двух концах - но какие есть альтернативы?
AG
Yaroslav Schekin
Да уж. :( Вы понимаете, что чуть что не так — и этот подход уже теряет данные направо и налево (видел такое много раз)?
В сторону: вот откуда все эту дрянь берут и почему верят, что оно обязано (или вообще может) работать? ;(
В сторону: вот откуда все эту дрянь берут и почему верят, что оно обязано (или вообще может) работать? ;(
Тут больше вопрос, что и зачем апдейтится так много и часто. И что анализируют в итоге.
AG
но у них вся таблица в память не влазит, иначе фуллскан придётся делать для выборки изменившихся строк. Да, палка о двух концах - но какие есть альтернативы?
Альтернатива — лог изменений, как было выше сказано, только инсерты. Либо в партицию, либо(какашками не кидать) в отдельную таблицу yyyymmddhh
YS
Тут больше вопрос, что и зачем апдейтится так много и часто. И что анализируют в итоге.
Нет, мой вопрос — о важности корректности результатов анализа.
Если кого-то устраивает, что в ответ на запросы он получает не результаты, а "мнения" (что-то произвольно далёкое от правильного ответа), то почему бы и нет (можно ещё "данных" из /dev/random туда добавить). ;)
Если кого-то устраивает, что в ответ на запросы он получает не результаты, а "мнения" (что-то произвольно далёкое от правильного ответа), то почему бы и нет (можно ещё "данных" из /dev/random туда добавить). ;)
VY
у нас ребята делают такие вещи на PgQ, складывая только ID нужных записей в одну очередь и с добавлением пэйлоад в другую. вычитывают их в несколько потоков. без нареканий много лет
YB
Yaroslav Schekin
Да уж. :( Вы понимаете, что чуть что не так — и этот подход уже теряет данные направо и налево (видел такое много раз)?
В сторону: вот откуда все эту дрянь берут и почему верят, что оно обязано (или вообще может) работать? ;(
В сторону: вот откуда все эту дрянь берут и почему верят, что оно обязано (или вообще может) работать? ;(
у нас нет этого подхода. я пытаюсь вытащить все сейчас
YB
надеюсь индекс по полю updated_at конечно есть?
конечно
AG
Yaroslav Schekin
Нет, мой вопрос — о важности корректности результатов анализа.
Если кого-то устраивает, что в ответ на запросы он получает не результаты, а "мнения" (что-то произвольно далёкое от правильного ответа), то почему бы и нет (можно ещё "данных" из /dev/random туда добавить). ;)
Если кого-то устраивает, что в ответ на запросы он получает не результаты, а "мнения" (что-то произвольно далёкое от правильного ответа), то почему бы и нет (можно ещё "данных" из /dev/random туда добавить). ;)
Такое бывает. Когда в отчете для управленцев расходы на сотни миллионов, например, округляются до тысяч.
YB
Yaroslav Schekin
Да уж. :( Вы понимаете, что чуть что не так — и этот подход уже теряет данные направо и налево (видел такое много раз)?
В сторону: вот откуда все эту дрянь берут и почему верят, что оно обязано (или вообще может) работать? ;(
В сторону: вот откуда все эту дрянь берут и почему верят, что оно обязано (или вообще может) работать? ;(
а что конкретно вы тут имели в виду про дрянь?
СГ
Альтернатива — лог изменений, как было выше сказано, только инсерты. Либо в партицию, либо(какашками не кидать) в отдельную таблицу yyyymmddhh
я бы на месте Елены, вообще попробовал бы колоночную СУБД для этих целей. Тот же кликхаус. Там сразу есть и встроенные механизмы анализа
AG
я бы на месте Елены, вообще попробовал бы колоночную СУБД для этих целей. Тот же кликхаус. Там сразу есть и встроенные механизмы анализа
туда эти данные надо ещё вытащить из источника за приемлемое время, с этим как раз проблемы
там ETL, где E не укладывается в срок
там ETL, где E не укладывается в срок
СГ
туда эти данные надо ещё вытащить из источника за приемлемое время, с этим как раз проблемы
там ETL, где E не укладывается в срок
там ETL, где E не укладывается в срок
можно новые данные направить в КХ, тем самым снимется нагрузка с ПГ (insert/update). И уже забирать старые данные с ПГ и заливать в КХ
EM
туда эти данные надо ещё вытащить из источника за приемлемое время, с этим как раз проблемы
там ETL, где E не укладывается в срок
там ETL, где E не укладывается в срок
а в чем проблема заливки данных в CH ?