|
Организация нормальной скорости чтения/запись огромных таблиц
#40138155
Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
Ссылка на вложение 2:
|
|||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
Добрый день, форумчане. Прошу помощи в деликатном вопросе: как организовать хранение данных. Есть процедура на Java, которая должна очень быстро выбирать данные, выполнять расчёт и сохранять обновления в эти же таблицы. Заранее прошу прощения, если мой вопрос кажется глупым. Ниже будут 2 раздела. Один раздел - краткое описание. Другой раздел - подробное описание. Краткое описание Имеем таблицу движений (поступлений и трат), сгруппированных по распределению (в одном распределении от 1 до нескольких трат и поступлений).Также имеем таблицу состояния счетов на момент окончания распределения. В этой таблице хранятся 2 типа записей: стандартные (insert) и пересчитанные (update)Задача следующая: Периодически поступают заявки по номеру счёта пересчитать бенефиты распределения и бенефиты счетов, участвовавших в транзакциях, на момент после распределения. 1. То есть в начале выполнения заявки имеем номер счёта. 2. Далее по номеру счёта необходимо найти все траты с него и все поступления на него (хранятся в таблице fund_movements). Получили. Также 3. берём все все траты и поступления в найденных распределениях. 4. Собрав целиком распределения, мы для каждого счёта-участника берём по previous_movement_number состояние счёта из таблицы account_properties. Таким образом, мы по начальному условию "счёт" получили все распределения и состояния счетов на момент ДО распределения. 5. Затем мы по неким формулам всё пересчитываем и получаем новые значения для fund_movements.movement_benefit и для account_properties.participation_benefit_1, account_properties.participation_benefit_2, account_properties.participation_benefit_3. 6. Расчёт окончен. Теперь надо сохранить: обновляем fund_movements.movement_benefit и вставляем записи с новым состоянием счетов в account_properties. Если уже есть записи с типом "update" для этих счетов по этим распределениям в account_properties, то не вставляем, а обновляем их. 7. Но это ещё не всё. Теперь по всем счетам, по которым были поступления в наших распределениях, требуется запустить весь цикл заново. И так ещё 2 раза. То есть получается что-то типа распространения пересчёта по цепочке на глубину в 4 уровня. Вся ситуация осложняется тем, что кол-во записей в fund_movements - около 2 млрд записей (1.5 ТБ), а в account_properties около 9 млрд записей (не помню сколько ГБ). Подробное описание в процессе Итог Задача стоит пересчитывать максимально быстро на возможностях постгреса. Постгрес PostgreSQL 13.6. Почему вместо DDL-скриптов скриншоты ексельника? Потому что задача промышленная, не могу светить реальные структуры данных и переименовал. Если требуется, то сгенерю скрипты создания таблиц и приложу - только скажите. Заранее всем спасибо за советы/рекомендации. ... |
|||||||||||||||||||
:
Изменено: 18.10.2023, 18:45 - Лёнька
Нравится:
Не нравится:
|
|||||||||||||||||||
18.10.2023, 18:34 |
|
|
start [/forum/topic.php?fid=53&tid=2186860]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
1288ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
others: | 269ms |
total: | 1631ms |
0 / 0 |