Структуру проекта можно посмотреть на гитхабе, его также можно запустить и произвести замеры на вашем оборудовании. Ссылка есть в начале статьи. Если коротко, там имеются индексы, но логику в них можно не искать. В данном случае они существуют только для того, чтобы мешать вставкам, симулируя работу реальной системы. В качестве ИД используется последовательность в постгресе, uuidv4 не используется. По последнему пункту (удаление индексов перед вставкой) есть исследование, но оно в другой статье, ссылку на которую дал LeshaRB.
Спасибо за комментарий. Согласен, ждать восстановления индекса в текущей реализации для данного бизнес процесса не имеет смысла. В этой статье я хотел показать замеры полного процесса "от звонка до звонка". Ну и в целом не рекомендую использовать данный подход, потому что он может сильно повлиять на производительность системы. Как в момент вставок (пользователи работают без индексов), так и в момент восстановления индексов. Все эти процессы так или иначе будут грузить и без того часто сильно загруженную БД.
Ну лучше точно не будет, т.к. PostgreSQL будет выполнять дополнительные действия. Данные модификатор не про скорость и распараллеливание процесса создания индекса, как можно подумать, а про то, что PG не накладывает блокировки на запись, и индекс создается параллельно другим процессам вставки (обновления). Вот тут подробнее описано https://postgrespro.ru/docs/postgresql/current/sql-createindex#SQL-CREATEINDEX-CONCURRENTLY
Не совсем так. Этим процессом мы управляем вручную. Т.е. сначала складываем в буфер то что мы хотим сохранить методом copy, затем отправляем в БД. На моем примере я делал вставки батчами по 5_000 записей.
Согласен.
Структуру проекта можно посмотреть на гитхабе, его также можно запустить и произвести замеры на вашем оборудовании. Ссылка есть в начале статьи. Если коротко, там имеются индексы, но логику в них можно не искать. В данном случае они существуют только для того, чтобы мешать вставкам, симулируя работу реальной системы. В качестве ИД используется последовательность в постгресе, uuidv4 не используется. По последнему пункту (удаление индексов перед вставкой) есть исследование, но оно в другой статье, ссылку на которую дал LeshaRB.
Спасибо за ссылку.
Если интересно, вышла вторая статья. Она +- про тоже самое что и тут, только больше информации по спрингу. https://habr.com/ru/companies/gazprombank/articles/1010784/
Спасибо за отзыв. Рад что понравилось.
Спасибо за комментарий. В данном случае имелась ввиду экосистема спринга.
Все зависит от того сколько данных ему приходится фильтровать. На графиках выше видна деградация.
Спасибо за комментарий. Согласен, ждать восстановления индекса в текущей реализации для данного бизнес процесса не имеет смысла. В этой статье я хотел показать замеры полного процесса "от звонка до звонка". Ну и в целом не рекомендую использовать данный подход, потому что он может сильно повлиять на производительность системы. Как в момент вставок (пользователи работают без индексов), так и в момент восстановления индексов. Все эти процессы так или иначе будут грузить и без того часто сильно загруженную БД.
Спасибо! Рад что понравилось :)
Хороший подход. Однако когда речь идет про финансы, он может не устраивать бизнес.
Ну лучше точно не будет, т.к. PostgreSQL будет выполнять дополнительные действия. Данные модификатор не про скорость и распараллеливание процесса создания индекса, как можно подумать, а про то, что PG не накладывает блокировки на запись, и индекс создается параллельно другим процессам вставки (обновления). Вот тут подробнее описано https://postgrespro.ru/docs/postgresql/current/sql-createindex#SQL-CREATEINDEX-CONCURRENTLY
Нет, не использовался.
Не совсем так. Этим процессом мы управляем вручную. Т.е. сначала складываем в буфер то что мы хотим сохранить методом copy, затем отправляем в БД. На моем примере я делал вставки батчами по 5_000 записей.