В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

pro.elixir

1014 membersпожаловаться на группу
2019 December 23

ВК

Василий Кузнецов in pro.elixir
atanych
Кто в курсе, в PSQL если делать REFRESH MATERIALIZED VIEW Х раз в секунду, это плохая идея?
если для вас MATERIALIZED VIEW это приговор, который нельзя изменить, и данные не должны устаревать более чем на секунду - есть ли смысл спрашивать?
или речь о том, чтобы как то по другому оформить это?
очень мало контекста
источник
16:07пожаловаться#1

ВК

Василий Кузнецов in pro.elixir
почти всегда это будет плохая идея
источник
16:08пожаловаться#2

a

atanych in pro.elixir
задача на самом деле дико простая, есть табличка,
| user_id | points |

в эту табличку пишут 17 раз в секунду, нужна всегда актуальная position, которая берется по points

мы пока решаем в лоб, через оконные функции, но не очень быстро это, если в табл хотяб 400к записей
источник
16:13пожаловаться#3

V

V in pro.elixir
CQS в каком-либо виде рассматриваете? Т.е. отдельное вычисление значения при вставке.
источник
16:15пожаловаться#4

AB

Alexey Bolshakov in pro.elixir
ну евент сорс же. не?
источник
16:15пожаловаться#5

a

atanych in pro.elixir
нет пока, только начали оптимайзить, если бы у нас гдето был расчитана позиция, это было бы идеально, но обновление VIEW очень высокочастотное - вариант отбросили
источник
16:20пожаловаться#6

SK

S. Karpieš in pro.elixir
atanych
задача на самом деле дико простая, есть табличка,
| user_id | points |

в эту табличку пишут 17 раз в секунду, нужна всегда актуальная position, которая берется по points

мы пока решаем в лоб, через оконные функции, но не очень быстро это, если в табл хотяб 400к записей
Я бы это через триггеры в базе сделал, чтобы обновлять только то, что изменилось, а не всю таблицу
источник
16:20пожаловаться#7

SK

S. Karpieš in pro.elixir
S. Karpieš
Я бы это через триггеры в базе сделал, чтобы обновлять только то, что изменилось, а не всю таблицу
Главное сделать так, чтоб в фунцкции не писать никаких селектов, тогда будет летать
источник
16:21пожаловаться#8

a

atanych in pro.elixir
с тригерами скорее всего будет тоже самое, что и с ВЬЮ, если ты имеешь ввиду, чтоб расчитывать позицию и записывать в БД при каждом апдейте табл
источник
16:22пожаловаться#9

a

atanych in pro.elixir
V
CQS в каком-либо виде рассматриваете? Т.е. отдельное вычисление значения при вставке.
вот это сейчас рассмотрим, спасибо 👍
источник
16:22пожаловаться#10

Е

Евгений in pro.elixir
что за CQS?
источник
16:37пожаловаться#11

Е

Евгений in pro.elixir
Гуглится Command-query separation, но похоже, что речь не об этом.
источник
16:38пожаловаться#12

SK

S. Karpieš in pro.elixir
atanych
с тригерами скорее всего будет тоже самое, что и с ВЬЮ, если ты имеешь ввиду, чтоб расчитывать позицию и записывать в БД при каждом апдейте табл
ну зависит, как эта позиция считается, если она зависит от всех остальных записей, то да, проблема.

А всякие conters cache на триггерах работают идеально и супер-быстро
источник
16:41пожаловаться#13

V

V in pro.elixir
Евгений
что за CQS?
Command-Query Segregation. Оно-оно
источник
16:44пожаловаться#14

Е

Евгений in pro.elixir
И чем оно тут поможет?
источник
16:44пожаловаться#15

Е

Евгений in pro.elixir
По мне так вообще ортогонально вопросу. Или я чего-то не догоняю.
источник
16:45пожаловаться#16

VS

Vladimir Sekisov in pro.elixir
atanych
задача на самом деле дико простая, есть табличка,
| user_id | points |

в эту табличку пишут 17 раз в секунду, нужна всегда актуальная position, которая берется по points

мы пока решаем в лоб, через оконные функции, но не очень быстро это, если в табл хотяб 400к записей
лучше дайте запрос, которым view генерите ,
а то из такой формулировки
только один вариант возникает - в чем проблема и нафига view?
источник
16:47пожаловаться#17

a

atanych in pro.elixir
нет живого вью, но это будет примерно так
SELECT * FROM records ORDER BY points DESC
источник
16:48пожаловаться#18

V

V in pro.elixir
Евгений
И чем оно тут поможет?
Вычисляемое значение position зависит от вставляемого points. Можно вычислять position не массовым пересчётом materialized view, а точечно только для обновляемых points.
источник
16:48пожаловаться#19

a

atanych in pro.elixir
atanych
нет живого вью, но это будет примерно так
SELECT * FROM records ORDER BY points DESC
а, ну еще там будет 
ROW_NUMBER() OVER (ORDER BY
источник
16:50пожаловаться#20