Комментарии 8
Примечание: поскольку pg_largeobject — системная таблица, ее нельзя секционировать.
Это не страшно. Другое дело, что содержимое системных таблиц попадает в дамп при использовании ключика -s|--schema-only. Т.е. при создании дампа для обновления мажорной версии ПГ. Соответственно, когда у вас в pg_largeobject приличный объём, обновление будет отнюдь не быстрым. Мне коллеги подкидывали ситуацию, когда время обновления 100 Гб экземпляра с непустой pg_largeobject было более 10 часов.
PS. Я сам не проверял, но по логам обновления дело было именно в pg_largeobject. И это было пару-тройку лет назад. Рекомендую проверить, как оно сейчас.
1.Как обеспечивается репликация, когда хранение файлов осуществляется в базе данных. Как это влияет на производительность?
2. СУБД работает с файлами на сервере, как загрузить файл в базу данных с клиентской машины?
1.Как обеспечивается репликация, когда хранение файлов осуществляется в базе данных. Как это влияет на производительность?
Для типа BFILE (внешний файл) реплицируются только значения BFILE, т.е., по сути дела, это путь к файлу и имя файла. Решение проблемы репликации самих внешних файлов, а также того, чтобы на реплике пути к внешним файлам соответствовал путям к внешним файлам на основном сервере, возложена на пользователя.
Значения типа SFILE целиком хранятся в БД и реплицируются обычным образом, как и другие значения БД. Естественно, при больших объемах файлов это плохо влияет на производительность. Если для пользователя критична производительность при репликации, то следует использовать BFILE (т.е. ссылки на файлы) и обеспечивать репликацию самих файлов самостоятельно.
2. СУБД работает с файлами на сервере, как загрузить файл в базу данных с клиентской машины?
Для типа BFILE файл загружается на сервер средствами пользователя. СУБД "узнаёт" об этом файле только в момент создания значения BFILE (т.е. ссылки на внешний файл).
Для типа SFILE файлы можно загрузить либо с помощью серверных, либо с помощью клиентских функций. Подробности лучше посмотреть в документации:
А можете привести примеры кейсов, когда файлы нужно именно в базе хранить? На больших проектах и так почти все проблемы с производительностью связаны с работой базы, а тут еще файлы в нее писать. Потом еще мучаться с бекапированием и обновлением. Когда есть куча других вариантов, тот же s3.
В моей голове хранение файлов в базе - это моветон.
Работая в прошлом в банке с АБС на oracle был кейс что в бд хранились файлы с образцами подписей клиентов. Файлы занимают сущие копейки и хранить их в бд кажется логичным, тем более оракл это умел.
Согласен с тем, что хранить большие файлы в БД — плохая идея. Но некоторые пользователи так делают, это факт. Достаточно часто спрашивают об этом при переходе на Postgres с Oracle, где есть возможность хранить файлы в БД.
Большое спасибо за материал. Добавлю с чем мы столкнулись ещё.
Мало того, что в text и bytea нельзя положить больше 1Гб, но если вы положите строку меньше 1Гб но больше 0.5 Гб, например 600 Мб, то извлечь ее через SELECT нельзя. Только через copy. Как объяснили в поддержке, это особенность libpq. Было ли у вас такое?
Работа с файлами в СУБД PostgreSQL и Postgres Pro Enterprise: барьеры и варианты их преодоления