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

Question

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

почти не меняется, но есть в ней колонка, которая меняется постоянно (грубо говоря, дата следующего опроса состояния, само состояние меняеться не частно)
есть ли какие то практики, отделять эту колонку, что бы она была в отдельном файле?

#backend #devops #pgsql #programming #russian

0

12.05.2022

8 ответов

21 просмотр

Василий Автор вопроса

alex che
Не иметь индексов по этой колонке, тогда будет апд...

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

0

12.05.2022

alex che

Василий
идея такая, колон содержит условное число, выбирае...

Такую priority queue я бы вынес в отдельную таблицу. Либо вообще хранил бы не в таблицах, потому что ей не нужен ACID

0

12.05.2022

Василий Автор вопроса

alex che
Такую priority queue я бы вынес в отдельную таблиц...

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

0

12.05.2022

Ilya Anfimov

На самом деле накладных там байт 60-80, думаю. Около 40 на heap tuple и большэ 20 на primary key. Плюс — доступ из основной таблицы к этой колонке — это плюс два page access. Довольно много. Но если в основной таблицэ записи хотя бы по килобайту в среднем — то выигрыша в скорости можно достичь. При правильной работе (которая, на самом деле, требует глубокого понимания происходящего). А вот надо ли вам с этим возиться — это другой вопрос. Если база ненагружэнная — то интеллектуальные затраты однозначно не будут оправданы.

0

12.05.2022

alex che

Василий
идея такая, колон содержит условное число, выбирае...

Будет вобще шикарно, если вы будете хранить не время следующей обработки, а расписание. Тогда расписание будет почти никогда не менятся тоже. Запрос на выбор сущеностей на обработку по расписнию типа create index queue_phase on queue(shortest_phase, id); select id from queue where shortest_phase >= $1 and shortest_phase <= $2 and true_phase >= $3 % true_period and true_phase < $4 % true_period; Это запрос, поддерживающий несколько возможных периодов обращения, при условии, что они все делятся на некоторый минимальный период, и фаза по этому минимальному периоду достаточно селективна. Например, с периодом час, а какие-то 2 часа.

0

12.05.2022

Василий Автор вопроса

alex che
Будет вобще шикарно, если вы будете хранить не вре...

не совсем понял вашу мысль: я могу за одно обращение, брать только одну запись в обработку, причем время, когда будет "вызвана следующая запись непредсказуема. опять же, расписание все равно предпологает фиксацию что задача выполнилась и требуется ждать следующую итерацию. но в любом случае спасибо за ваш вариант, утром попробую обдумать его еще раз

0

12.05.2022

alex che

Василий
не совсем понял вашу мысль: я могу за одно обращен...

Ну вы сказали, что после выполнения задачи она откладывается на будущее. Если она откладывается ровно на 9 часов, то это уже расписание. То, что за раз можно обрабатывать только одну задачу — не проблема. Моим методом вы выберете все задачи, которые по расписанию с 23:00 до 23:01, допустим 10 штук, запомните эти 10 штук в приложении и выполните по очереди. Потом запросите с 23:01 до 23:02

0

12.05.2022

alex che · Accepted Answer

alex che

Не иметь индексов по этой колонке, тогда будет апдейтить лучше. Если нужен индекс — есть смысл вынести в отдельную таблицу.

0

12.05.2022

172 похожих чатов

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

8 ответов

Похожие вопросы