Как не писать бинарники в WAL

Доброго дня!

Есть приложение, которое хранит картинки в БД PostgreSQL в поле bytea (размер 100K - 2M) и некоторые метаданные в простых полях (числа, строки)

Вставка идет довольно интенсивно, при этом тормозит запись в WAL. Сейчас проблема решена путем размещения WAL-а на RAM-диске. Но это порождает другую проблему: при особо интенсивной загрузке картинок кончается место на RAM диске.

Мне, в принципе, не нужно писать эти картинки в WAL и при сбоях допустимо терять бинарники (т.к. есть откуда её скачать еще раз). Но недопустимо терять прочие параметры картинки.

Вопрос: есть ли возможность управлять записью в WAL так, чтобы часть данных не шла в БД через лог?

Я могу, писать бинарник в отдельную таблицу, в отдельную БД или даже в отдельный инстанс PostgreSQL (последнее нежелательное, конечно). Подскажите, как отключить WAL там, куда пишется бинарник.

Заранее спасибо.

Bulk insert by COPY.

originator, CREATE UNLOGGED TABLE

+ дополнительная таблица для важной информации.

V&N
originator, CREATE UNLOGGED TABLE

Помогло.
Спасибо!

originator
V&N originator, CREATE UNLOGGED TABLE Помогло. Спасибо!

надеюсь что вы ВНИМАТЕЛЬНО прочли документацию про UNLOGGED
в двух частях
1)она не реплицируется от слова вообще
2)при сбое сервера (reset нажали или Kill -9 или база упала) таблица обнуляется (ВСЯ а не последние вставленные данные)
(т.е. вы не последнюю картинку потеряете а вообще все)

PS: бинарники надо на файловой системе держать... им в базе не место... картинки в базе имеют совершенно запредельный overhead по процессору при отдаче.


--Maxim Boguk
www.postgresql-consulting.ru

Maxim Boguk

originator пропущено... Помогло. Спасибо! надеюсь что вы ВНИМАТЕЛЬНО прочли документацию про UNLOGGED в двух частях 1)она не реплицируется от слова вообще 2)при сбое сервера (reset нажали или Kill -9 или база упала) таблица обнуляется (ВСЯ а не последние вставленные данные) (т.е. вы не последнюю картинку потеряете а вообще все) PS: бинарники надо на файловой системе держать... им в базе не место... картинки в базе имеют совершенно запредельный overhead по процессору при отдаче. --Maxim Boguk www.postgresql-consulting.ru

Некогда не понимал зачем картинки хранить в БД. Это все равно что, головой открывать двери. Вроде и можно, но есть же руки. Ну хоть одно преимущество кто то может сказать?

Electric200
Ну хоть одно преимущество кто то может сказать?

"консистентность", погуглите

Maxim Boguk
пропущено... PS: бинарники надо на файловой системе держать... им в базе не место... картинки в базе имеют совершенно запредельный overhead по процессору при отдаче. --Maxim Boguk www.postgresql-consulting.ru

стесняюсь спросить -- это теперь так модно у технарей, грести словеса в кучку ?

я к чему -- мы пишем по 2*(2--3 млн) картинок в день. в базу (точнее - в базы). Отдаём по 200--300тыс на просмотр.

вероятно, мы что-то делаем не так. хотелось бы аргументов.

т.е. осторожно интересуюсь внятным тест-кейсом, или , на запредельный крайняк (при немощи, временной недееспособности, поносе и т.п.) -- пальцевых рассуждений по природе означенного оверхеда. (хер с ней, с консистентностью).

зы. смеяться там, где лопата

Любая методика должна использоваться в разумных пределах с учетом области, где применение будет ее наиболее эффективным.
Если на реальном примере аргументировано растолкуете, преимущества хранения изображений в БД, то я растолкую недостатки. Только на примере реального проекта, а не стора с 10 картинками и 3 запросами.