Таблица или много файлов ?

← →
Dimedrol (2002-12-05 18:13) [0]

Коллеги, мне предстоит делать 1 проект, но вот хотел посоветоваться...

Это будет база данных картинок.
Картинки на компактах.
Их много ;-) (ок. 10,000 картинок, ок. 100 компактов...)

Проект проги :
Прога шерстит заданный каталог,
делает из картинко превьюшки (примерно 120 на 200)
и сохраняет их в базе вместе с описанием...

Потом будут искать картинки по описанию (дате, ключ. словам и т.п.)
и на выходе юзер хочет видеть превьюшку (только ее!)
ну и описание...

Так вот вопрос. Я тут думаю, как лучше организовать хранение
превьюшек :
Как много файлов на диске,
или пихать в BLOB-поля ?
(я посчитал тогда база будет ок. 1 гига или даже больше)

База - Firebird under Linux...
Платформа не слабая ;-) - Черный сервак IBM X-series 220 по-моему...,
2-ной XEON 850, 2 SCSI винта по 30 гектар, 2 гига памяти... ну в общем так... ;-)

Что скажете ?

← →
Anatoly Podgoretsky (2002-12-05 19:04) [1]

Один компакт 650 иб * 100 = 65 гб, без учета остальных данных и превьшек

← →
asmith (2002-12-05 19:43) [2]

Вывод очевидный - хранить все на файловой системе, причем на NTFS. Дабы не наблюдалась деградация файловой системы не допускать хранения очень большого количества файлов в одном фолдере. Для этого организовать "партиционирование" данных по разным фолдерам, храня их список в базе и управляя им. В базе хранить только ссылки на файлы (полные пути). Для управления таким архивом можно построить некий ImageServer, обеспечивая доступ клиентам только через него и закрыв доступ к самой файловой шаре, где картинки хранятся. Применение ImageServer позволит также организовать распределенный архив, построенный из различных устройств (диски, ленты, оптические диски).

← →
Anatoly Podgoretsky (2002-12-05 20:00) [3]

Даже превьюшки займут 120*100*1(2,3,)*10000 от 120 до 500 мегабайт

← →
Sergey13 (2002-12-06 09:19) [4]

2Dimedrol © (05.12.02 18:13)
>Так вот вопрос. Я тут думаю, как лучше организовать хранение
превьюшек :
>Как много файлов на диске,
>или пихать в BLOB-поля ?
ИМХО, и так и так можно.
По первому в плюсах - с файлами картинок работать(ИМХО) попроще чем с BLOBами. В минусах - невозможно гарантировать целостность самих файликов от шаловливых ручек.
По второму - обратная картина.

← →
Dimedrol (2002-12-06 13:42) [5]

2 asmith
NTFS - бреется! Я же сказал - тачка на Линухе. (EXT3)
А хранить на винте (в любом виде) я собираюсь только(!) превьюшки

2 Anatoly Podgoretsky ©
Сами картинки храним на сидюках! А на счет размера всех превьюшек -
я же грил, 2 винта по 30 гигов + 2 гига RAM-a. Не то что 500 мегов, но и гиг и 5 для хранения - не проблема

2 Sergey13 ©
Нуууу.. мммдаа... я в принципе так и думал.

К стати, как вам такая моя мысль, что в случае "частичного" ;-)
падения системы или базы,
восстановить отдельные файлы можно легче, чем превьюшки
из BLOB-ов...
А может все таки с BLOB-ами удабнее чем,
что например визуализацию легче будет сделать. А?!
Вспомните хотя-бы демо-базу в Дельфи - biolife.db
Там и картинки внутри...

← →
passm (2002-12-06 14:19) [6]

Dimedrol © (06.12.02 13:42)> На такие размеры можно что-нибудь и посерьезнее Interbase"а :)

← →
Дмитрий К.К. (2002-12-06 16:24) [7]

Задача выеденного яйца не стоит. Клиент-серверная СУБД. Blob-поля для хранения графики. Чё еще?

← →
Dimedrol (2002-12-08 19:40) [8]

2 passm ©
;-))) Это что по-твоему... большой размер данных ? ;-)
Что касается запросов там не будет ничего сложнее
простых "селектов", а ты посмотри какое у меня железо...

2 Дмитрий К.К. ©
Нууууу... да ты крут...
Может еще и индекс предложишь по Blob-полю сделать ? ;-)
Я к тому затеял этот постинг, что есть много нюансов,
как то:
а что системе быстрее будет найти -
запись в базе или , например, файл на диске ?
Ответишь мне однозначно ? А ?!

← →
Сергєєв Володимир (2002-12-08 20:40) [9]

Хочешь - я угадаю как тебя зовут ? :)))
Наверное ты кодишь для какого-то полиграфического предприятия или для издательства, в общем рекламные проспекты вы делаете. А хранить те надо клипарты. Сам недавно такой фигней страдал.

Я сделал так:
Две таблицы. В одной есть поле IMAGE_ID, IMAGE_BODY и еше куча полей со справочной информацией и ссылками к другим таблицам (у меня картинки еще и группировались по направлениям). По IMAGE_ID построен индекс, IMAGE_BODY - превьюшка.
Есть вторая таблица с полями IMAGE_ID и IMAGE_BODY(отношение записей один-ко-одному), в которой в IMAGE_BODY хранится картинка, но в ЗААРХИВИРОВАННОМ виде в виде ZIP. Если в результате выборки какая-то картинка заинтересовала юзера, то прога даунлоадит из базы этот бинарный поток в файл *.zip, а потом его разархивирует. (Разархивашию я делал при помощи компонента TZip. Прога от него толстеет на 200кБ, и еще нужно ей две DLL в сумме на 100 кБ. Не помню уже, где я его взял, компонетой пользуюся уже года три, хочешь - вышлю.)

Практика показывает, что юзеру как правило надо просмотреть картинки найденные по условию, из них он отбырает от силы штук 20-30.

Было у меня тогда 50 компактов, залить это все получилось на два IDE 40 ГБ и база была двухфайловая 35 и 18 (это то, на чем я остановился, что у них сейчас - не знаю) ГБ.

Для просмотра превьюшек - обыкновенный TDBImage. Дык главное что - всю это шуршало на IDE !!! И довольно быстро. А разделение на две таблицы я сделал для ускорения запросов.

Единственное, с чем придется потрахатся - рекурсивный обход каталогов компакта, автоархивация файла, а потом - залить поток в БД. Я сделал по это дело что-то вроде утилиты в сочетании с компьютерной игрой "подставка для кофе" - выдвинуть дверцу сидюка. Сказал сторожу, что когда выедет сидюк - вставить следующий компакт, а сам пошел домой спать. Утром все было готово.

Ответый вопрос можно ?

У меня вот тут почти такая же конфига тачки. Я вообще программер, а не сисадмин, но все же. Не подскажешь инфу, как на таком добре Линукс развести. То бишь, идея состоит в том, чтобы сам линукс поставить на СКаЗИ, чтоб грузился уже с него.
На ИДЕ линукс, а потом монтировать скази - это не интересно.

← →
Дмитрий К.К. (2002-12-08 21:11) [10]

> Dimedrol © (08.12.02 19:40)
> Нууууу... да ты крут...
> Может еще и индекс предложишь по Blob-полю сделать ? ;-)
> Я к тому затеял этот постинг, что есть много нюансов,
> как то:
> а что системе быстрее будет найти -
> запись в базе или , например, файл на диске ?
> Ответишь мне однозначно ? А ?!

Я не ГРЮ, шо я крут. Просто задача гроша ломаного не стоит.
Ты САМ написал (цитирую): "Потом будут искать картинки по описанию (дате, ключ. словам и т.п.)".
При чем тут индекс по BLOB-полю?????????
BLOB-поле использовать только для графики, поля других типов - для поиска.

Разберись с хаосом, царящим в твоей голове.

← →
Dimedrol (2002-12-09 18:42) [11]

2 Дмитрий К.К. ©
Знаешь, во время моего 4+ -летнего опыта программинга
для www-серверов на SSI, PHP, MySQL, и т.п.
я уж разобрался, что такое база данных, и по каким полям нужно, а по каким не нужно строить индексы...
И если прочитаешь внимательнее мои поистинги, то ты не найдешь
вопроса типа - "как ЭТО ВСЕ сделать" ?
Я прекрасно знаю как это все делается.
Я _могу_это_все_сделать_ всеми_способами.

Я спрашиваю - что оптимальнее ?
Что быстрее найти ?
Кто может что делал, и может
поделиться опытом в виде совета ,
а не указывать мне,- что твориться в моей голове.

Нельзя ли немного повежливее...

2 Сергєєв Володимир
Нуууууу... ;-)))))
Попадание почти как у "точечного ракетно-бомбового удара",
то есть 99% ! 8-)

Только у нас - это картинки от Аssociated Рress и пишут их на сидюки.
В принципе задача НЕ стоит сделать вместо сидюков - винт.
Просто диски у чувака будут стоять на полочке, а просто нужно организовать поиск
по описанию и результат поиска -
список превбюшек с описанием и указание - где и на какой полочке лежит диск.
потому что если у нас пойдет дальше (а ведь, обязательно пойдет! ;-)
то там никакого винта не хватит... Даи не нужно, я считаю.
Винт - для обработки информации, а не для хранения.

Так вот, если сталкивался, Аssociated Рress засовывает ОПИСАНИЯ
своих картинок прямо в свои JPEG-и. И у них есть свой (стоящий у нас)
Image Server. Но... как обычно - удобство хромает... ;-)

Мне нужно будет ходить по сидюку, выдергивать описания из
картинок, и помещать их в базу вместе с превьюшкой.

Так что зиповать, думаю не стоит.
Мне - критично по скорости.

По поводу Линуха...
Если в системе 2 винта, то во всяком случае -
у меня Линух для Ламеров ;-) -- Mandrake -- так вот там
при установке можно выбрать на какой винт ставить.

Если изначально в системе 1 винт, то можно туда все энто дело спокойно
засетУпить, а потом другой винт Линух может даже автоматом
монтировать - при запуске. По крайней мере так делает самый последний
мой - Mandrake 9.0

Или... что у тебя ?

← →
Дмитрий К.К. (2002-12-09 20:28) [12]

Потом все-таки расскажи, какой путь ты выбрал ;)

← →
Diouzshev (2002-12-09 20:30) [13]

ИМХО запихать всю эту кучу в tar, нафиг файловой системе содержать лишние 20000 файлов?
а в базу затолкать описания и пр. беду для поиска....
а скорость и так будет приемлемая (опять же ИМХО)

← →
Diouzshev (2002-12-09 20:36) [14]

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

← →
Сергєєв Володимир (2002-12-09 21:02) [15]

2 Dimedrol ©
У меня имеется RedHat7.3. Становиться на СКАЗИ он просто не хочет. Он даже его не видит. Я его уже и сконсоли сетапить, и в графике - ничего не помагает. На графике ложится анаконда с каким-то идиотским сообщением и с кучей адресов (так и напоминает Вин98 "Программа выполнила недопустимую операцию ...")
С консоли - СКАЗИ просто нет. В БИОСах ковырялся - вроде все в порядке. Ради прикола Вин2000 Адвансед сервер - с ходу лег на СКАЗИ.
Подрубил левый ИДЕ - пожалуйста. И СКАЗИ сам находит, и даже на первом запуске оси уже автоматом их монтирует. Но вот на ИДЕ - неинтересно. Задача в том и состоит, чтобы ядро со свопом положить на СКАЗИ.

В общем фигня эта вся нужна для завода. А там - отчетность по зарплате, табельные работников, бухгалтерия и кое-какая инфа. Базу сам писал - 117 таблиц (47 повторяют RDB$, только так, как мне надо. Я в них дублирую все по-своему). Работников - 12000. Т.е. за один месяц - проводок на 2,5 млн записей по всем таблицам. Каждые полгода - выгрузка содержимого проводок в другую базу - архив.

Если поцепить ядро на ИДЕ, а СКАЗИ монтировать, то (при всем моем уважении к этой оси) Линуксу будет просто плохо на элементарной процедуре выборки-суммирования. Так что такие вот делы.
--------------------

Насчет сабжа - не мучай голову. Кидай все в БЛОБы.(я имею в виду только превьюшки). С АссПресс никогда не сталкивался тесно, поэтому ничего про него сказать не могу. Это уже тебе долбаться как из них маленькие превьюшки сделать.

Единственное, о чем стоит заметить, это об компоненте DBImage. Некорректно он работает с JPEG (на Вин98 иногда после вызова метода Next если следующая БЛОБ запись была JPEG - ловил "Программа віполнила недопустимую операцию..."), а GIF - для него вообще загадка. Сперва решил эту проблему установкой ВинНТ5.0 Видимо че-то борланды брали из ДЛЛ Мелкомягких, а там в свою очередь было не все в порядке.
А потом как-то скачал библиотеку IBO и там в ThirdParty был компонент - замена DBImage. Дык он почти все форматы что видит AcdSee поднимал из БЛОБов. Только прога от него на 1,2 метра толстеет. Но зато больше никаких "Программа выполнила недопустимую операцию..." Зато уже стало необязательным держать все превьюшки в каком-то одном формате изображений.

← →
Jeer (2002-12-09 21:07) [16]

asmith (05.12.02 19:43)

На мой взгляд - самое то.
(тип FS не так важен)

← →
Сергєєв Володимир (2002-12-09 21:48) [17]

2 Dimedrol ©

В догонку. Есть тута одни знакомые, они в нашем Приватбанке такое же железо (они даже тачки вместе покупали) развели на РедХате7.0. А вот скоты делиться, как это сделали - не желают. Че-то начали поливать про то, что надо сперва диски разбить, потом исходники туда слить, а потом уже собрать ядро прямо на железе.
У меня конечно высокое самомнение, но не настолько, чтобы позволить себе связаться с подобной фигней. Может есть другие способы, как это развести ?

Если бы не этот дибильный закон в нашей стране (Украина) про нелегальное копирование... и все остальное, где теперь это уголовное преступление до 1 года, то развел бы я это все под Вин2000 Сервер в терминалах и не мучал бы себе голову. А т.к. наше правительство очень рьяно защищает интересы Micro$oft, то приходится мучаться вот так.
--------------------------

В сабж. А ты действительно все-таки просто ради интереса поделись потом, по какому пути пошел.

← →
Dimedrol (2002-12-10 14:24) [18]

Всем

Конечно, если не забуду, расскажу, что выбрал... ;-)

2 Сергєєв Володимир
В качестве DB-Aware Components планирую юзать уже опробованные - EhLib.
Компоненты доступа - стандартные от Delphi-6.
Пока к ним у меня никаких нареканий не было... Тьфу, тьфу !
Мне конечно нужно чтобы DBImage работал нормально,
а к стати, глюки в DBImage в какой версии Delphi у тебя были ?
---------------------
По поводу Линуха...
Странно что он не видит СКАЗИ-винта...
В принципе, знаешь, преимущество СКАЗИ явно видно только когда
несколько устройств на 1 шине.
Думаю если поставить какой-нить 1 нормальный ИДЕ винт типа АТА-133 7200 и т.п. - будет не хуже.

Если памяти много - сервак часть базы и наиболее частые селекты
ваще будет в памяти держать и винт тут ему не будет нужен.

Знакомые твои, по-моему, какой-то геморой себе придумали.
К стати, если ты все еще "ставишь"(!) систему, т.е.
ломать пока особо нечего ;-) может, так... если ничего не поможет,
попробуешь Мандраку 9-ю поставить, а ?!
Говорю я уже несколько версий юзал, причем все на разных
серверах - без проблем.
Двойные винты, СКАЗИ, ИДЕ - без проблем.
Или тебе прямо НЕОБХОДИМО на РедХате ?!

В принципе, думаю, должно быть все равно, ведь
ядро-то одно.

Таблица или много файлов ? Найти похожие ветки