su
Ок всем спасибо
Удалять тоже не стоит, потому что данный вопрос может быть интересен кому-либо еще
и теперь уже никто и никогда этого не узнает..
Size: a a a
2021 March 30
b
Lina M
После пересмотра схемы, было решено вынести в отдельную таблицу пары из entities_data с привязкой к
Но я не могу сообразить как можно/нужно поступить с агрегацией теперь. Ибо все мысли так или иначе приводят к решению первым вариантом.
Я пытался сделать агрегацию средствами Postgres'a, но получилось лишь частично. Делал array_agg всех task_id, у которых были равны лишь значения ключей из поля entities_data, но это вроде бы не совсем то, что должно получится, а как соединить вообще все пары из entities_data, когда связаны лишь несколько из них не имею пока понятия.
Надеюсь получилось донести свои мысли.
Были мысли по поводу того, что, поскольку агрегация миллиона записей логически не может быть совершена в течение пары секунд (т.е. каждый раз при добавлении новой записи в
Соответственно, для новой задачи будет указана связь с другими записями через 5-10-20-30 минут в худшем случае, если предыдущая операция агрегации была произведена прямо до добавления записи в таблицу.
task.id
В результате чего пример выше был дополнен новой таблицей task_entities (id primary key, name, task_id primary key, foreign key):id="math-1234-9c", name="math", task_id="f0b31453-7bd4-490f-b517-a8fc23d2ff3f"Теперь
id="prog-847-8j", name="prog", task_id="f0b31453-7bd4-490f-b517-a8fc23d2ff3f"
id="geo-8370-8s", name="geo", task_id="f0b31453-7bd4-490f-b517-a8fc23d2ff3f"
id="phys-4321-9b", name="phys", task_id="e4ccb5f5-3876-485a-ab2f-2fe5342b350c"
id="geo-812-1k", name="geo", task_id="e4ccb5f5-3876-485a-ab2f-2fe5342b350c"
id="nop-92-5g", name="nop", task_id="e4ccb5f5-3876-485a-ab2f-2fe5342b350c"
id="math-1202-7f", name="math", task_id="8a7f4365-f50e-48d6-a0c6-d7cd555488a1"
id="prog-847-8j", name="prog", task_id="8a7f4365-f50e-48d6-a0c6-d7cd555488a1"
entities в явном виде связаны с определённой задачей.Но я не могу сообразить как можно/нужно поступить с агрегацией теперь. Ибо все мысли так или иначе приводят к решению первым вариантом.
Я пытался сделать агрегацию средствами Postgres'a, но получилось лишь частично. Делал array_agg всех task_id, у которых были равны лишь значения ключей из поля entities_data, но это вроде бы не совсем то, что должно получится, а как соединить вообще все пары из entities_data, когда связаны лишь несколько из них не имею пока понятия.
Надеюсь получилось донести свои мысли.
Были мысли по поводу того, что, поскольку агрегация миллиона записей логически не может быть совершена в течение пары секунд (т.е. каждый раз при добавлении новой записи в
task), то необходимо изменить подход для составления агрегации: сделать сервис, который каждые 5-10-20-30 минут будет запускать операцию агрегации (sql запрос postgres'a) на всех имеющихся в таблице данных. Соответственно, для новой задачи будет указана связь с другими записями через 5-10-20-30 минут в худшем случае, если предыдущая операция агрегации была произведена прямо до добавления записи в таблицу.
А вам связанные задачи нужны когда вы смотрите на текущую или для какой-то массовой выборки? В первом случае вам может хватить gin индекса и нескольких запросов вида entities_data @> '{"geo": "geo-123"} при просмотре текущей записи.
В рамках текущей структуры вам «похожие» нужно искать нужно только для новых/изменившихся записей, а уж если у них есть похожие, то вписывать новую запись в пару к найденной.
Далее, я не понимаю, зачем вам guid in_relation, если ключами связи по факту являются geo-123, nop-467 и подобные?
Ещё правильнее было бы вынести entities_data в отдельную таблицу, каждый ключ (geo, nop...) сделав столбцом с индексом - так будет ещё быстрее.
В рамках текущей структуры вам «похожие» нужно искать нужно только для новых/изменившихся записей, а уж если у них есть похожие, то вписывать новую запись в пару к найденной.
Далее, я не понимаю, зачем вам guid in_relation, если ключами связи по факту являются geo-123, nop-467 и подобные?
Ещё правильнее было бы вынести entities_data в отдельную таблицу, каждый ключ (geo, nop...) сделав столбцом с индексом - так будет ещё быстрее.
su
А да затупил, прошу прощения )
b
Lina M
После пересмотра схемы, было решено вынести в отдельную таблицу пары из entities_data с привязкой к
Но я не могу сообразить как можно/нужно поступить с агрегацией теперь. Ибо все мысли так или иначе приводят к решению первым вариантом.
Я пытался сделать агрегацию средствами Postgres'a, но получилось лишь частично. Делал array_agg всех task_id, у которых были равны лишь значения ключей из поля entities_data, но это вроде бы не совсем то, что должно получится, а как соединить вообще все пары из entities_data, когда связаны лишь несколько из них не имею пока понятия.
Надеюсь получилось донести свои мысли.
Были мысли по поводу того, что, поскольку агрегация миллиона записей логически не может быть совершена в течение пары секунд (т.е. каждый раз при добавлении новой записи в
Соответственно, для новой задачи будет указана связь с другими записями через 5-10-20-30 минут в худшем случае, если предыдущая операция агрегации была произведена прямо до добавления записи в таблицу.
task.id
В результате чего пример выше был дополнен новой таблицей task_entities (id primary key, name, task_id primary key, foreign key):id="math-1234-9c", name="math", task_id="f0b31453-7bd4-490f-b517-a8fc23d2ff3f"Теперь
id="prog-847-8j", name="prog", task_id="f0b31453-7bd4-490f-b517-a8fc23d2ff3f"
id="geo-8370-8s", name="geo", task_id="f0b31453-7bd4-490f-b517-a8fc23d2ff3f"
id="phys-4321-9b", name="phys", task_id="e4ccb5f5-3876-485a-ab2f-2fe5342b350c"
id="geo-812-1k", name="geo", task_id="e4ccb5f5-3876-485a-ab2f-2fe5342b350c"
id="nop-92-5g", name="nop", task_id="e4ccb5f5-3876-485a-ab2f-2fe5342b350c"
id="math-1202-7f", name="math", task_id="8a7f4365-f50e-48d6-a0c6-d7cd555488a1"
id="prog-847-8j", name="prog", task_id="8a7f4365-f50e-48d6-a0c6-d7cd555488a1"
entities в явном виде связаны с определённой задачей.Но я не могу сообразить как можно/нужно поступить с агрегацией теперь. Ибо все мысли так или иначе приводят к решению первым вариантом.
Я пытался сделать агрегацию средствами Postgres'a, но получилось лишь частично. Делал array_agg всех task_id, у которых были равны лишь значения ключей из поля entities_data, но это вроде бы не совсем то, что должно получится, а как соединить вообще все пары из entities_data, когда связаны лишь несколько из них не имею пока понятия.
Надеюсь получилось донести свои мысли.
Были мысли по поводу того, что, поскольку агрегация миллиона записей логически не может быть совершена в течение пары секунд (т.е. каждый раз при добавлении новой записи в
task), то необходимо изменить подход для составления агрегации: сделать сервис, который каждые 5-10-20-30 минут будет запускать операцию агрегации (sql запрос postgres'a) на всех имеющихся в таблице данных. Соответственно, для новой задачи будет указана связь с другими записями через 5-10-20-30 минут в худшем случае, если предыдущая операция агрегации была произведена прямо до добавления записи в таблицу.
Я бы добавил поле processed / created_at
Select new_entry.task_id, old_entry.task_id
From task_entities as old_entry
Join task_entities as new_entry on (old_entry.task_id = new_entry.task_id and and old_entry.id = new_entry.id old_entry.processed and new_entry.processed = false)
Должно превратить задачу из O(N*log(N)) в O(log(N)).
Select new_entry.task_id, old_entry.task_id
From task_entities as old_entry
Join task_entities as new_entry on (old_entry.task_id = new_entry.task_id and and old_entry.id = new_entry.id old_entry.processed and new_entry.processed = false)
Должно превратить задачу из O(N*log(N)) в O(log(N)).
ГА
Подскажите, если кластер публикующий данные сменил мастера, то на подписчиках надо полностью перезаливать реплицируемые данные или можно как то обойти.
a
Array_Agg(...) as wto_to_svoe
SM
Array_Agg(...) as wto_to_svoe
супер !, спасибо )
S
С чем может быть связана ошибка: 2021-03-30 06:21:14 UTC [2927]: [15-1] 605c26e3.b6f 0 projectdbhere projectdbhere [unknown] 172.17.0.1 ERROR: could not resize shared memory segment "/PostgreSQL.1577662288" to 50438144 bytes: No space left on device
??
Места на диске превеликое множество. Бежит в докере.
??
Места на диске превеликое множество. Бежит в докере.
СГ
С чем может быть связана ошибка: 2021-03-30 06:21:14 UTC [2927]: [15-1] 605c26e3.b6f 0 projectdbhere projectdbhere [unknown] 172.17.0.1 ERROR: could not resize shared memory segment "/PostgreSQL.1577662288" to 50438144 bytes: No space left on device
??
Места на диске превеликое множество. Бежит в докере.
??
Места на диске превеликое множество. Бежит в докере.
увеличьте объём доступной памяти /dev/shm
AV
Или плохая идея, но сработает — поставить
`
max_parallel_workers 0`
docker_args: " --shm-size=1G"` / docker run --shm-size=1G лучшеMC
Yaroslav Schekin
В EXPLAIN не будет, а вывод auto_explain ищите в логах (ну или в сессии — как уровень сообщений поставите).
Спасибо! это уже ближе к тому, что нужно :)
S
Или плохая идея, но сработает — поставить
`
max_parallel_workers 0`
docker_args: " --shm-size=1G"` / docker run --shm-size=1G лучшеда, памяти и диска там полно сейчас попробую
S
k🥔
Здравствуйте, подскажите пожалуйста, как поменять настройки базы данных, чтобы возвращало current_time всегда с правильно временной зоной
СК
Здравствуйте, подскажите пожалуйста, как поменять настройки базы данных, чтобы возвращало current_time всегда с правильно временной зоной
а правильная - это какая ?
k🥔
а правильная - это какая ?
в моем случае для Украины
k🥔
пробовал так, но оно все равно дает 7 часов утра
СК
в моем случае для Украины
ну так поставьте таймзону для Украины, делов то )
гугл вам даст 100500 страниц с тем как это сделать
гугл вам даст 100500 страниц с тем как это сделать
СК
нет, вам нужно похоже установить глобальный параметр
а не для базы данных
а не для базы данных