Изпечатай

[rcbandit22]

Правя си в момента експерименти с Java Server Faces и PostgreSQL. Ще си напрявя огромна база данни за да си държа документите и лесно да си го достъпвам с web interface. Спрях се на решението с JSF да се качва като Java обект файла и да се вкарва в базата данни обекта. Да но ако документа е 1-2 мегабайта няма проблем, но какво става ако обекта е 2 гигабайта. Естествено ще има проблем out of memory exception, въпреки че за няколко секунти ще се заета паметта.

Спрях се на решението да складирам файловете в базата данни а не на HDD с линк към базата защото ще ми е по-лесно следтова да правя backup.

И се замислех какво ще стане ако сложа например 20 GB swap на сървъра за да може ако RAM недостига сървъра да ползва swap. Ако се чете или пише по Swap да очаквам ли доста голямо забавяне? Имате ли наблюдения?

[gat3way]

Ще държиш по 1-2 гигабайта blob-ове в базата? Звучи като рецепта за драма

А иначе ползването на swap-а е бавно, сега зависи от скоростта на RAM паметта, както и диска. Разликата обикновено в порядъка на няколко хиляди пъти, макар че със SSD нещата може да не са чак толкова радикални. Проблемът обаче е че ти няма как да контролираш достатъчно добре какво да влиза в swap-а и какво не, никой не е казал че трябва да е огромния обект, а не примерно text сегмента (изпълнимия код) на софтуера който върви на машината, затова и резултатите може да са абсолютно непредсказуеми. Съвсем отделно че kernel thread-овете дето се занимават с обслужването на swap паметта, ще изреват на умряло ако трябва да се занимават с обеми памет от порядъка на 20GB и ще заемат прилично много процесорно време докато се занимават с това. Като цяло, RAM паметта е евтина в днешно време, аз бих гледал да разчитам колкото може по-малко на swap.

[rcbandit2]

Ще държиш по 1-2 гигабайта blob-ове в базата? Звучи като рецепта за драма

Ще споделиш ли какви проблеми си виждал с подобни решения?

[gat3way]

Мне, единственият опит с това ми е отпреди много време, когато държахме прикачените файлове за наш webmail в mysql база. Тогава ползвахме myisam, innodb не помня дали съществуваше, и да е имало трябва да е било новост. Отказахме се (програмистите пренаписаха нещото така че да пази файлове) заради две неща - бекъпите взеха да се влачат грозно, а при срив и скапана база, myisamchk минаваше за часове, дали не и дни. Innodb щеше да ни реши единия от двата проблема. След това никога не ми е минавало през главата да го правя. Единственото удобство е че базата ти гарантира консистентността на данните - няма да имаш останали файлове, за които няма запис в базата или обратното - записи срещу липсващи файлове, цялата мъка която иначе приложението би трябвало да прави - като например при неуспешна DB операция, това да се отчете и върху файла и т.н.

Това го заплащаш с цената на производителност, като не че няма какво да направиш, ама каквото и да направиш, няма как базата да стане по-бърза от файловата система. Да не говорим че трябва много да внимаваш как си организираш таблиците (да нашиеш blob-овете заедно с всички други метаданни в една единствена голяма таблица скоро ще те утрепе, представи си един SELECT отгоре какво прави).

Колкото и умно да го измислиш обаче, просто DBMS-ите не са мислени да държат огромни BLOB-ове, това им е просто някакъв много частен случаи, докато файловите системи са правени с тази идея изначално. Дори първоначално да нямаш много проблеми, с времето фрагментацията нараства и базата няма да управлява това по-добре от една файлова система.

[rcbandit2]

Тествах в PostgreSQL да съхранявам приблизително 20 мегабайта файлове - работи много добре и бързо, но за файлове над 500 мегабайта получавам грешка java.lang.OutOfMemoryError: Java heap space

Трябва изглежда да се направи конфигурация и на Java.

[remotexx]

И не само на Java
следващата греда която ще удариш е когато е по-голям от наличната памет
т.е. съвета ми е да се научиш как да го подадеш като stream а не целия наведнъж 

...не знам как точно става в твоя случай - Джава и ПостГре но по подразбиране повечето параметри се подават наведнъж, но трябва да има и опция за stream

Малка добавка
Ето тук един пример
https://jdbc.postgresql.org/documentation/80/binary-data.html

setBinaryStream() transfers a set number of bytes from a stream into the column of type bytea. This also could have been done using the setBytes() method if the contents of the image was already in a byte[].

[rcbandit2]

Ето кода

http://stackoverflow.com/questions/37091760/java-lang-outofmemoryerror-java-heap-space-during-bytea-download