DBA question

[vg]

картинки хранить на файл сервере, а в базе только ссылки. почему объяснять долго... печатать лень

раскажи нам а то у меня база с 200 тыс. картинок по 70 мег некоторые.
И как-то неплохо работает.

http://www.russianlook.com

А почему она должна плохо работать? В большинстве операций в записями где есть BLOBы (хоть и таких размеров) не происходит более тяжёлых дисковых операций в сравнении с записями без таковых. BLOB в записи - это может быть некоторый пейлоад фактического BLOB + ссылка на остальное. Доступ к остальному - по ссылке на страницу (не помню точно, для MSSQL, кажется, 8k) + офсет на странце. Тяжёлыми будут операции фетч самого BLOB-а. Я правильно понимаю?

[Lepsik]

А почему она должна плохо работать?

это пусть папа Карла обьяснит. там вообще 3 таблицы с разрешениями 160x160, 800x800 и оригинальные - каждая таблица на отдельном драйве.

да и чтение блоба идет с той же скоростью что и с диска.

[sz]

> да и чтение блоба идет с той же скоростью что и с диска

А запись?
А вообще, пусть папа Карло объясняет.
А то этих умников, которые "я так сделал и работает" на верный путь наставлять - совершенно неблагодарное занятие.

[StS]

А то этих умников, которые "я так сделал и работает" на верный путь наставлять - совершенно неблагодарное занятие.

[trn]A ty poprobuj.
Konkretnyj primer. V internet-magazine pochti na kazhdyj tovar est' foto. Razmer kartinki nebol'shoj. apdejtov prakticheski net. Vstavki redki (nachal'nyj wtap napolneniya BD kartinkami ne rassmatrivaem).
Kak by ty v wtom sluchae sdelal i pochemu.
[/trn]

[sz]

Конечно файлами бы сделал. Даже не рассматривая тему локов при апдейте (этот интернет магазин, скорее всего, достаточно маленький, чтобы это не имело особого значения).
Ключевые слова - интернет магазин. Это значит, что для вставки в html тебе все равно придется файл генерить и на диск класть. Так почему не сразу в файле хранить?

Если же хочешь абстрактных доводов против блобов:

1. Представь себе, что у тебя датабазный сервер перестанет справляться. Твои действия? Ставить второй и разбивать базу между клиентами (что, кстати говоря, иногда чревато еще и редизайном аппликухи). При этом, если сервер у тебя не постгрес и не муэскуэль, то придется весьма немало платить производителям. За каждый такт процессора, между прочим. Поэтому сервер надо жалеть и не грузить лишним.

2. Ну сам понимаешь, если у тебя картинка 20 мегов и ты ее апдейтишь, то сервер испугается количеству затронутых сегментов и вполне вероятно сделает лок на всю таблицу. Чем это плохо, нужно объяснять?

А дальше пусть папа Карло распинается - он лучше меня эту тему знает.

[Vovchik]

2. Ну сам понимаешь, если у тебя картинка 20 мегов и ты ее апдейтишь, то сервер испугается количеству затронутых сегментов и вполне вероятно сделает лок на всю таблицу. Чем это плохо, нужно объяснять?

А дальше пусть папа Карло распинается - он лучше меня эту тему знает.

Сие произойдет в мелкомягком сикуеле - как пить дать. В Оракле такого не произойдет. А вот в постгресе - это уж надо читать че там про блокировки у него написано.

[sz]

> В Оракле такого не произойдет

С чего это, оно не произойдет-то?
Разве Оракл никогда полнотабличных локов не делает?
Конечно, делает.
Всем же понятно, что если у тебя из сегментов 1, 2, 3, 4, 5 нужно залочить 1, 3 и 5, то быстрее полный лок сделать. Я глубоко в Оракл не лазил, но уверен, что он не такой дурак, чтобы не сообразить, что один полный лок быстрее десятка локальных.

[Yuri Dimant]

Мои два цента против картинок

1)Если в будушем когда-нибудь будешь менять базу ( на другую платформу)
то формат блоба может быть несовместим или с болью в сердце будешь их конертировать ,потому like web browsers, each vendor has implemented things with their own slant.

2)

Не надо говорить если база полетела ( все твои фаилы на диске)

3) Имея картинки на диске ты позволяешь доступ к ним с разных аппликации
(FTP, web browser, etc) without having to write application code to pull the data out of the database, since you can't just 'SELECT image FROM table' and have the image appear in Enterprise Manager or Query Analyzer.
[/code]

[Earl Grey]

А что делать если собранные картинки нужно дистрибьютить? Скажем, каталог послать одним файлом (не зипом!) вместе со специальным вьюером, не делая содержимое фолдера "прозрачным".

Как упаковать, точнее держать упакованным?

[ajkj3em]

Как упаковать, точнее держать упакованным?

zip с пасвордом ? я подозреваю, что библиотек для чтения zip archive
как файловой системы должно быть ну если не валом, то как минимум
несколько штук

(пасворд - чисто для убирания прозрачности естественно)

[hawk]

> В Оракле такого не произойдет

С чего это, оно не произойдет-то?
Разве Оракл никогда полнотабличных локов не делает?
Конечно, делает.
Всем же понятно, что если у тебя из сегментов 1, 2, 3, 4, 5 нужно залочить 1, 3 и 5, то быстрее полный лок сделать. Я глубоко в Оракл не лазил, но уверен, что он не такой дурак, чтобы не сообразить, что один полный лок быстрее десятка локальных.

Lock escalation свойственна Sybase -> MSQL да DB2. Так уж получилось, но реализация oracle не делает lock escalation. Во многом, потому-что он не держит в памяти список всех локов.
Postgresql - кстати тоже.

Кстати, практически все RDBMS позволяют хранить BLOBs отдельно, соот. сама таблица и операции на ней не должны пострадать.

С производительностью. Зависит от задачи. Если надо миллионы чтений и раз в квартал один update -то наверное filesystem лучше, если картинки полу или совсем динамические : генерация на лету вполне приемлема. Кстати, что-бы передать картинку в броузер, вовсе не обязательно ее на диск класть Content-type, и вперед в поток.

[vg]

... Кстати, что-бы передать картинку в броузер, вовсе не обязательно ее на диск класть Content-type, и вперед в поток.

This is exactly what I need. Could you, please, explain to me how to proceed? I am fetching a file downloading it into a temporary folder and then creating a new “explorer” (viewer) process passing the file’s name as a parameter. I need browse pdf, doc, rtf, xls files.
Thanks.

[StS]

2. Ну сам понимаешь, если у тебя картинка 20 мегов и ты ее апдейтишь, то сервер испугается количеству затронутых сегментов и вполне вероятно сделает лок на всю таблицу. Чем это плохо, нужно объяснять?

[trn]Starina, ty voobsche chitaesh' chto v wtom trede napisano? [/trn]
Размер картинки небольшой. апдейтов практически нет.

Предполагается что будет production DB and DB для изощренных и извращенных запросов, которая еженочно копируется из production. Если хранить картинки отдельно, то надо организовывать отдельную процедуру копирования.
Если картинки отдельно - отдельный механизм копирования файлов с продакшн сервера. Плюс отдельная головная боль с пермишинами на файлы.

[trn]Dovod #2 otpadaet.[/trn]

1. Представь себе, что у тебя датабазный сервер перестанет справляться. Твои действия?

[trn]On perestanet spravlyat'sya ne zavtra, i ne cherez god. Ya postavlju bolee moschnyj server. Zhelezo desheveet i proizvoditel'nost' processorov rastet. Tak chto dovod #1 zvuchit tozhe neubeditel'no.

Esche argumenty est'?[/trn]

[StS]

This is exactly what I need. Could you, please, explain to me how to proceed? I am fetching a file downloading it into a temporary folder and then creating a new “explorer” (viewer) process passing the file’s name as a parameter. I need browse pdf, doc, rtf, xls files.
Thanks.

[trn]Na tebe kusok iz springa.[/trn]

Код: Выделить всё

  protected ModelAndView handleRequestInternal(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse) throws Exception
  {
    httpServletResponse.setContentType("image/jpg");
    ServletOutputStream os = httpServletResponse.getOutputStream();
[skip]
//      get BLOB
[skip]
    if(blob!=null)
    {
      os.write(blob.getData());
    }
    os.close();
    return null;
  }

[Vovchik]

> В Оракле такого не произойдет

С чего это, оно не произойдет-то?
Разве Оракл никогда полнотабличных локов не делает?
Конечно, делает.
Всем же понятно, что если у тебя из сегментов 1, 2, 3, 4, 5 нужно залочить 1, 3 и 5, то быстрее полный лок сделать. Я глубоко в Оракл не лазил, но уверен, что он не такой дурак, чтобы не сообразить, что один полный лок быстрее десятка локальных.

Оракл - не делает. Вообще самое главное преимущество Оракла - это его механизм трансакций и блокировок. Который оченнь сильно отличается от всяких там сикуелей серверов, сайбэйсов, информиксов и прочей деребедени. Сей механизм кстати был слизан мускулем и постгресом. По крайней мере это то что написано там в доках.