Спасибо за инетрес к статье! Если говорить про foreign keys и views, чаще всего всё будет работать, но лучше перед использованием проверить зависимости (чтото типа SELECT * FROM pg_depend WHERE refobjid = 'your_table'::regclass;) Триггеры переносятся, но я бы рекомендовал проверить их после репака.
Насчет шардирвоания. Увы я не эксперт. Прошу прощения, не подскажу.
Насколько я знаю проблема с ограничениями целостности с отложенной проверкой в pgrepack всё ещё актуальна, и её нужно учитывать. Это обсуждалось и в официальном трекере pg_repack и не закрыто как решённое. Проблема затрагивает достаточно специфичные сценарии, но может быть критичной. Можно также рассмотреть pg_squeeze как альтернативу, хотя он тоже не всегда корректно работает с отоложенными проверками.
Спасибо большое за ваш комментарий, но я явно отразил этот момент с диском в разделе "Ограничения и Грабли". Ну и вы абсолютно правы - магии не бывает. Разные инстурменты работают с разными нюансами и ограничениями. Нужно правильно выбирать их под свои задачи.
Спасибо за валидный комментарий. Вы правы. Судя по всему в мае 2024 года в pg_vector действительно появилась поддержка HNSW. И если я правильно понял только для последних версий PG (16 и 17). Еще раз спасибо, я отредактирую статью по следам нашей дискусии.
Спасибо за комментарий, согласен с вашим мнением. Поэтому пишу однозначно что лично я считаю что для реально большого и требовательного проекта можно посмотреть другие инструменты и предлогаю рейтинг.
Спасибо за комментарий — отличный технический вопрос. Но у меня немного другое отношение к этой теме. Да, временные таблицы в PostgreSQL могут дать снижение производительности в определенных ситуациях. Но просто потому что устроены они иначе, чем в MS SQL.
Они создаются на уровне сессии, и не подпадают под autovacuum, и при больших объёмах без явного ANALYZE могут давать неоптимальные планы выполнения. Это особенно заметно при сложных JOIN или GROUP BY о чем действительно очень подробно и по делу написано в представленной вами статье.
PostgreSQL это не MS SQL. Поэтому подходы в лоб типа: "Просто возьми и сделай импортозамещение!" может дать не самый оптимальный результат. Нужно глубже разбираться с инструментами из которых мы строим приложение. И PostgreSQL очень крутой пример.
Спасибо за такой развернутый и крутой комментарий! А еще за интерес к статье. Позволил себе дополнить первый раздел по следам описанных вами идей. Благодарю!
Спасибо за валидный коммент! Да, такое действительно может случится и это классическая ошибка на реплике и возникает, когда долгий SELECT мешает применять WAL-журнал, и Postgres вынужден прервать запрос.
В разделе про HTAP я несколько раз указываю что нет и быть не может одной конфигурации подходящей под разные профили. По этому возможно лучшим решением будет разнести нагрузку на разные кластеры.
Ну и конечно обязательно наличие мониторинга и проактивных реакций. Авария по причине распухания одной из нод в кластере не должно стать для вас сюрпризом.
Со стороны нашей услуги мы гарантируем что ресурсов хватит и представляем в договоре SLA по досутпности S3 API 99,98%. Возможно в вашем кейсе есть проблема с производительностью со стороны клиентского приложения.
Да, вы абсолютно правы. Разумеется, для фактической имплементации я бы рекомендовал использовать готовые клиенты, умеющие в S3 API: minio, aws cli, rclone и др. по. Как я указывал в заключении к статье, код и кейс представлены только для раскрытия принципиального подхода в реализации асинхронной репликации. Ведь любое приложение использует тот же S3 API что и python+boto3.
Спасибо за инетрес к статье!
Если говорить про foreign keys и views, чаще всего всё будет работать, но лучше перед использованием проверить зависимости (чтото типа SELECT * FROM pg_depend WHERE refobjid = 'your_table'::regclass;)
Триггеры переносятся, но я бы рекомендовал проверить их после репака.
Насчет шардирвоания. Увы я не эксперт. Прошу прощения, не подскажу.
Насколько я знаю проблема с ограничениями целостности с отложенной проверкой в pgrepack всё ещё актуальна, и её нужно учитывать. Это обсуждалось и в официальном трекере pg_repack и не закрыто как решённое. Проблема затрагивает достаточно специфичные сценарии, но может быть критичной. Можно также рассмотреть pg_squeeze как альтернативу, хотя он тоже не всегда корректно работает с отоложенными проверками.
Спасибо большое за ваш комментарий, но я явно отразил этот момент с диском в разделе "Ограничения и Грабли".
Ну и вы абсолютно правы - магии не бывает. Разные инстурменты работают с разными нюансами и ограничениями. Нужно правильно выбирать их под свои задачи.
Спасибо за столь развернутый и подробный комментарий. Позволю себе отредактироваить и отразить подсвеченные вами моменты в статье.
Спасибо за валидный комментарий. Вы правы. Судя по всему в мае 2024 года в pg_vector действительно появилась поддержка HNSW. И если я правильно понял только для последних версий PG (16 и 17). Еще раз спасибо, я отредактирую статью по следам нашей дискусии.
Спасибо за комментарий, согласен с вашим мнением. Поэтому пишу однозначно что лично я считаю что для реально большого и требовательного проекта можно посмотреть другие инструменты и предлогаю рейтинг.
Благодарю за комментарий, буду продолжать эту тему дальше, подписывайтесь.
Спасибо за интересную статью, про крутой инструмент!
Спасибо за интерес к статье! Спасибо что напомнили этот мем, улыбнуло. Легенда говорил (а может и не говорил) 640кб должно хватить всем!
Хорошее замечание, согласен с вами. Есть сборки для pg для 1С. В том числе в качестве готовой услуги в нашем облаке https://selectel.ru/services/cloud/managed-databases/postgresql-1c/
Спасибо за интерес к статье!
Спасибо за комментарий — отличный технический вопрос. Но у меня немного другое отношение к этой теме. Да, временные таблицы в PostgreSQL могут дать снижение производительности в определенных ситуациях. Но просто потому что устроены они иначе, чем в MS SQL.
Они создаются на уровне сессии, и не подпадают под
autovacuum, и при больших объёмах без явногоANALYZEмогут давать неоптимальные планы выполнения. Это особенно заметно при сложныхJOINилиGROUP BYо чем действительно очень подробно и по делу написано в представленной вами статье.PostgreSQL это не MS SQL. Поэтому подходы в лоб типа: "Просто возьми и сделай импортозамещение!" может дать не самый оптимальный результат. Нужно глубже разбираться с инструментами из которых мы строим приложение. И PostgreSQL очень крутой пример.
Спасибо за такой развернутый и крутой комментарий! А еще за интерес к статье. Позволил себе дополнить первый раздел по следам описанных вами идей. Благодарю!
Валидное дополнение, спасибо! Отражу в разделе про статистику. Благодарю!
Спасибо за интерес к статье! Я дополню раздел про кластеризацию по следам вашего комментария. Благодарю.
Отразил, спасибо за идею!
Спасибо за валидный коммент! Да, такое действительно может случится и это классическая ошибка на реплике и возникает, когда долгий SELECT мешает применять WAL-журнал, и Postgres вынужден прервать запрос.
В разделе про HTAP я несколько раз указываю что нет и быть не может одной конфигурации подходящей под разные профили. По этому возможно лучшим решением будет разнести нагрузку на разные кластеры.
Ну и конечно обязательно наличие мониторинга и проактивных реакций. Авария по причине распухания одной из нод в кластере не должно стать для вас сюрпризом.
Вы абсолютно правы, так будет куда оптимальнее. Спасибо за дальный совет!
Со стороны нашей услуги мы гарантируем что ресурсов хватит и представляем в договоре SLA по досутпности S3 API 99,98%. Возможно в вашем кейсе есть проблема с производительностью со стороны клиентского приложения.
Да, вы абсолютно правы. Разумеется, для фактической имплементации я бы рекомендовал использовать готовые клиенты, умеющие в S3 API: minio, aws cli, rclone и др. по. Как я указывал в заключении к статье, код и кейс представлены только для раскрытия принципиального подхода в реализации асинхронной репликации. Ведь любое приложение использует тот же S3 API что и python+boto3.