Какой тип БД лучше пользовать?

← →
Deus (2003-03-16 05:20) [0]

Раньше никогда БД не писал, вот сижу и думаю, что лучше подойдет под мои условия. Гуру баз данных, подскажите, плиз. Нужно: хранить некоторые файлы в нестандартных (малораспространенных) графических форматах. Объем БД единицы-десятки гиг. Принимать файлы с сетки/передавать в сеть по своему же протоколу. Количество принимаемых/передаваемых файлов - 100-200 (вероятно до 1000) в час. Объем каждого файла - 300 - 500 кб. Хотелось бы, что бы лицензия на саму БД была не очень дорога (как для сервера, так и для клентов). Спросил у местных гуру, посоветовали Interbase. Какой под нее нужен софт? И сколько это счастье будет стоить?

← →
Rad © (2003-03-16 05:45) [1]

Interbase будет стоить... хз, это у Borland надо спросить.
Совершенно бесплатно - Firebird (opensource клон Interbase), но при таких объемах - его использование не тривиально.
Собственно, http://www.ibase.ru (ключевые слова: FAQ, IBExpert :))

А почему файлы в базе? Нельзя хранить ссылки и отдавать файлы по запросу - тем более, что протокол свой?

← →
MsGuns © (2003-03-16 14:45) [2]

Определись с инфой. Если у тебя 99% информации - это графика, но с этими данными работает мало пользователей и в основном читают, то см. Rad © (16.03.03 05:45). В смысле храни медию "Как есть", а вотт ссылки на них в таблицах. Здесь подойдет даже любая локалка или даже просто текстовые файла - ссылки.
Если же картинки постоянно меняются, да еще с N-го кол-ва ПК, да еще надо защита информации, то без клиент-серверной СУБД не обойтись, а при таких объемах (в гигах), возможно, даже InterBase "не вытянет"

← →
Anatoly Podgoretsky © (2003-03-16 15:04) [3]

Это примерно 3.5 терабайт в год, трудновато будет найти технику, что нибудь типа AS6000 с Ораклом на AIX. Стоимость много мегабаксов.

← →
Deus (2003-03-18 00:29) [4]

Всем большое спасибо за ответы. Уточняю. Десятки гиг - это максимальный объем базы. База должна периодически сбрасываться на компакты, что бы не разрастаться. Файлы в основном будут записываться в базу и иногда запрашиваться из неё. Поток, возможно, будет и меньше, чем 100 файлов в час, а общий объем, думаю, не более, чем 200-300 мег в сутки, хотя не факт. Попробую сделать, как сказал Rad. Тогда вопрос: в какой базе хранить ссылки? У каждого файла кроме собсно пути к нему нужно хранить еще несколько строк-описаний файла, и по этим строкам делать выборки файлов.

← →
_BasiL_ © (2003-03-18 08:57) [5]

> Deus (18.03.03 00:29)

Я бы сделал папки на каждый год, в них подпапки на каждый месяц, а дельше дни. В месяцах папку с базами данных на каждый день, соответственно у тебя получится на каждый месяц до 31 БД в которых, как ты говоришь, будет не больше 1000 записей. Выборку БД-ых можно сделать через КомбоБох. Тип БД можно использовать практически любой, т.к. количество записей не будет превышать 1000 штук.

← →
passm © (2003-03-18 09:53) [6]

Выбор DB2 может оказаться хорошим решением. Есть Graphics & Text Extenders (не приходилось пользоваться). И гигабайты не проблема. Кстати, дешевле Oracle.

← →
MsGuns © (2003-03-18 10:49) [7]

>passm © (18.03.03 09:53)

Насколько я понял из Deus (18.03.03 00:29), графика будет только читаться клиентами. Дополнение же (модификации, удаления) будут делаться централизованно и неинтерактивно, т.е. типа версирования или реплицирования. В этом случае на фига ему завязываться на монстра типа DB2 ?

Автору сабжа посоветовал бы посмотреть любой мультимедийный CD , где большое кол-во граф. или звуковой инфы организовано в виде простого дерева каталогов и самой примитивной БД (иногда в виде текстовых файлов, иногда в виде плэй-листов).

MsGuns © (18.03.03 10:49)> Использовать или не использовать СУБД, разумеется решать автору вопроса.
Потом у меня нет ощущения "монстрости".
Есть удобные вещи для хранения/распределения информации подобного рода:
1. Распределение типов данных (INDEX, DATA, LONG DATA) по различным физическим устройствам в зависимости от их скорости. Понятно, зачем :)
2. Тип данных DATALINK. То есть ссылка на файл/URL с данными.
3. Распределение BUFFER POOLS...

Разумеется надо определить стоит ли игра свечь. Но это опять решать автору.

← →
Deus (2003-03-21 04:46) [9]

Всем спасибо. Пока остановился на IB 6 и чем-то похожем на вариант _BasiL_. А там посмотрим по ходу пьесы. Еще вопрос: насколько надежна IB 6 при сбоях? Инфа, в базе, не очень критична, но все таки, потеря нежелательна. Помогало ли кому кому зеркалирование на уровне БД (посмотрел - в IB есть такое, насколько понял), на уровне ОС (soft raid массив на Win NT) или харда (истинное hard-зеркалирование)? Я как-то, помню, по поводу зеркальных soft-массивов видел информацию об их неэффективности.

Не бери IB6, бери Firebird.
Поясняю: IB6, начиная с какой-то версии (сорри, номер не помню) - закрыт обратно, следовательно - небесплатен. Та версия, которая последней была еще открыта - говорят, глюкалово.
Firebird же - opensource. Т.е., бесплатен и достаточно быстро развивается.

Надежность? В целом, очень даже ничего. Есть несколько случаев, когда при совпадении некоторых условий (например, отключение питания и происходившая в это время сборка мусора) база может конкретно (вплоть до "окончательно") попортиться - но, опять же, в целом всё достаточно надёжно. Была бы резервная копия нормальная :)
И вообще, т.к. "Инфа, в базе, не очень критична", то можно сказать, что Firebird (мы же о нём говорим, правда?) надежен

По поводу прочего:
http://www.ibase.ru/devinfo/hddspeed.htm
http://www.ibase.ru/devinfo/doc_calford_1.htm#hardware

Какой тип БД лучше пользовать? Найти похожие ветки