Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
 Re: Выбор сервера, чтобы не тормозило ...  [new]
imkot
Member

Откуда: г. Барнаул, Алтайский край
Сообщений: 516
Интересный топик получился.
Как я понимаю на таких объемах данных правильным решением будет Db2?
Просто больше никто ничего не предложил...
Может спросить админа какого-нибудь сайта как организовано хранение такого количетсва картинок?
Например админа ifun или чего-то подобного? У них там объемы немаленькие (по количеству).
20 окт 06, 07:01    [3285337]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Так платформу-то сообщите, может? Под FreeBSD/Linux без проблем и в файлах хранить. Под виндой вот похоже тюнинг файловой системы нужен сначала.
20 окт 06, 07:25    [3285356]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
imkot
Member

Откуда: г. Барнаул, Алтайский край
Сообщений: 516
DocAl
Так платформу-то сообщите, может? Под FreeBSD/Linux без проблем и в файлах хранить. Под виндой вот похоже тюнинг файловой системы нужен сначала.

Дык вопрос не я задавал. А вопрошающий по всей видимости пропал после второго своего поста. Видно решил забить на это дело.
20 окт 06, 07:34    [3285367]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
А... Гм, да, топик вышел интересный.)
20 окт 06, 07:35    [3285369]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
ЛП
2 c127
"всякие ограничения операционки" в таких задачах наступают очень быстро, в вынь2000 начиная с нескольких сотен файлов уже заметно невооруженным глазом

А можно поподробнее - что именно заметно невооруженным глазом?


Заметны тормоза например в открывании каталогов. У меня относительно медленная машина, на быстрых заметно позже. NTFS я упомянул потому что именно там я заметил тормоза, но это не важно, на других обычных ФС будет то же самое. Больше файлов - большие тормоза, причем тормоза растут линейно.

Задача работает так: находится строка в таблице, из строки берется имя файла и строится полный или относительный путь. Это быстро если правильно построены индексы. Потом по полному имени читается файл. Если файлов много, то это медленно, поскольку сколько бы файлов не было, они в NTFS, ext2, ext3 и некоторых других не индескируются. А ведь мы хотим повторять это много раз в секунду. Запустите и получите большой тормоз.

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

DocAl

% find images -type f | wc -l
376428

А сколько анаогичный count выполнялся бы в правильно проиндесированной БД? Чтобы было с чем сравнивать.

DocAl
"Куча времени", потраченная на борьбу, составляет порядка пары часов (первоначально большое количество файлов не предполагалось).
Хотя, конечно, при большом желании и излишке ресурсов (или при наличии объективных предпосылок, так бывает), можно хранить и в базе.)

Бекапить все эти файлы на другую машину собираемся или как? Лучше инкрементально. За целостностью между файлами и БД тоже будет ОС следить, или все-таки скрипты писать прийдется? А попробуйте для упражнения, интересное занятие. Вряд ли в два часа уложитесь, таки получается куча времени.



imkot
Интересный топик получился.
Как я понимаю на таких объемах данных правильным решением будет Db2?
Просто больше никто ничего не предложил...
Может спросить админа какого-нибудь сайта как организовано хранение такого количетсва картинок?
Например админа ifun или чего-то подобного? У них там объемы немаленькие (по количеству).


Деньги за СКЛ сервер платить хотите? Если да, то берите то, что лучше знаете, оракл, МССКЛ, сайбейз, ДБ2, они все легко справятся с этой задачей, она с точки зрения СУБД простая.

Я исходил из того, что Вы денег платить не хотите. Бесплатные Оракл и МССКЛ имеют ограничения на размер базы по-моему, у Вас картинки, поэтому наверняка в ограничения не впишитесь. У ДБ2 ограничений на размер базы нет. Можно взять постгре или МуСКЛ, наверное тоже будут работать, но ДБ2 надежнее, я бы выбрал ее. Тем более есть много БД с картинками, построенных на ДБ2, например БД патентного бюро США, чуть ли не самая большая БД в мире по какому-то там существенному параметру, если не ошибаюсь.
21 окт 06, 03:02    [3291407]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 с127
Заметны тормоза например в открывании каталогов. У меня относительно медленная машина, на быстрых заметно позже. NTFS я упомянул потому что именно там я заметил тормоза, но это не важно, на других обычных ФС будет то же самое. Больше файлов - большие тормоза, причем тормоза растут линейно.

Ыть пардон - что такое "открывание каталогов"?
Чем открывание?
Консервным ключом, али виндоуз експлорером? И даже если там проблемы - не проблемы ли это консервного ключа?
Давайте фсе-таке уточнять, а?

Если файлов много, то это медленно, поскольку сколько бы файлов не было, они в NTFS, ext2, ext3 и некоторых других не индескируются

Давайте я скажу, что это неправда, а вы меня попытаетесь убедить в обратном?
Индексируются. Как-то. Как именно - не знаю, не буду врать.
Таперича убеждайте в обратном.

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

Сколько раз в секунду мы хотим "это" получить, и сколько раз в секунду мы можем "это" получить?
Какие Ваши цифры?
Почему Вы решили, что эти Ваши цифры будут "большим тормозом" для автора топика? Ведь Вы даже не удосужились узнать - сколько именно раз в секунду автору топика нужно получить "это"?

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

Еще раз - откуда следует, что оно не индексируется? Вопрос без подъёбок, чисто из интереса - в своё время именно в ту сторону смотрели.

Я исходил из того, что Вы денег платить не хотите

Хех... А это откуда проследовало? (хоть и не ко мне было обращено)
21 окт 06, 03:16    [3291415]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
Ultrin
Предложите сервер, для такой базы - в день добавляются примерно 1000000 (лимон) записей типа (индекс, строка(под 10 символов)) да плюс еще картинки эдак так под 50000 (каждая размером под 15 киолбайт). Программа, работающая с этой базой должна быстро получить по индексу картинку и несколко информационных записей. Раз в год планируется все выкидывать и начинать заполнять базу с начала.
Что выбрать
MySQL, PostgreSQL - потянут ли?
MSSQL - очень интересно, глядя на то что можно подцепить еще и DBF которые рядом с базой валяюися, но быстро сможет?
Oracle,DB2 - база ведь простенькая, не будет ли это стрельбой из пушки по воробью


Да забыл сказать. Не бойтесь стрельбы из пушки по воробъям. Во-первых задачи имеют свойство расширяться. Во-вторых это если платить, то существенно чтобы не переплатить, а бесплатное если работает, то остальне не важно. А в третьих администрируется ДБ2 (и оракл) несложно, а внимания требует к себе меньше, чем какой-нибудь МуСКЛ, поскольку более мощная и не заметит многих ошибок, один раз настроил и забыл.
21 окт 06, 03:20    [3291417]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
c127
администрируется ДБ2 (и оракл) несложно, а внимания требует к себе меньше, чем какой-нибудь МуСКЛ, поскольку более мощная и не заметит многих ошибок, один раз настроил и забыл.
*ик
Аргументация этого утверждения будет какая или при словах Оракл и ДиБи2 все должны были пасть ниц?) Какие такие ошибки заметить "какой-нить МуСКЛ", и не заметит "более мощная СУБД", если и ту и другую адекватно грамотно настроить? В Мощные СУБД встроена автокоррекция для битой памяти или отлетевших головок жёсткого диска?
21 окт 06, 03:26    [3291420]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
DocAl
В Мощные СУБД встроена автокоррекция для битой памяти или отлетевших головок жёсткого диска?

Память - вряд ли, тут вся надежда на железку и контроль CRC блоков (в оракеле по умолчанию отключен), а вот автокоррекция отлетевшего диска таки встроена (Oracle ASM - своеобразный софтварный raid)
21 окт 06, 03:34    [3291421]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
c127

DocAl

% find images -type f | wc -l
376428

А сколько анаогичный count выполнялся бы в правильно проиндесированной БД? Чтобы было с чем сравнивать.

Простите, но мне в интернет-магазине фотографии товаров клиентам сервить надо, а не сидеть пересчитывать. Причём, с одной стороны, если уж приспичит -- так у меня в базе информация о них " правильно проиндексированна", а с другой, ~10 секунд на 400 000 картинок в 1 000 директорий дают примерную оценку задержки доступа к любой из них не более 10 мс, что, как бы, вполне сравнимо с average seek time, от которого вы никуда не уйдёте.
c127

DocAl
"Куча времени", потраченная на борьбу, составляет порядка пары часов (первоначально большое количество файлов не предполагалось).
Хотя, конечно, при большом желании и излишке ресурсов (или при наличии объективных предпосылок, так бывает), можно хранить и в базе.)

Бекапить все эти файлы на другую машину собираемся или как? Лучше инкрементально. За целостностью между файлами и БД тоже будет ОС следить, или все-таки скрипты писать прийдется? А попробуйте для упражнения, интересное занятие. Вряд ли в два часа уложитесь, таки получается куча времени.

Утилит инкрементального бакапа масса, вовсе необязательно изобретать этот велосипед самостоятельно. Нужные же "скрипты" алгоритмически тривиальны.

С другой стороны, я не утверждаю, что нет таких ситуаций, когда картинки в базе хранить было бы показано. Например, когда во главу угла ставится разграничение доступа к документам, а не среднее время доступа к каждому из них, плюс хочется аудита доступа к ним, добавьте ещё какой-то паранойи по вкусу -- тогда может быть вполне разумным хранить их в БД. Но тогда вопрос бы ставился, в первую очередь, о безопасности, а не скорости доступа.
21 окт 06, 03:54    [3291426]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
И куда ш оне все деваются....

Я конечно понимаю, что с127 человек могучий, и имеет обыкновение обдумывать ответ в течение суток (ничего против, кстате, оч даж карашо)... но ведь на простейшие вопросы надо отвечать "от зубов" :)
21 окт 06, 03:55    [3291427]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
andrey_anonymous
DocAl
В Мощные СУБД встроена автокоррекция для битой памяти или отлетевших головок жёсткого диска?

Память - вряд ли, тут вся надежда на железку и контроль CRC блоков (в оракеле по умолчанию отключен), а вот автокоррекция отлетевшего диска таки встроена (Oracle ASM - своеобразный софтварный raid)
А хардварный не судьба использовать? В конце-концов, если хочется именно софтварный -- так они в Linux/FreeBSD в изобилии, было б железо, на котором строить. Никак не в обиду пользователям Оракла, но он у меня ассоциируется с хохмой фидошных времён (кажется) о радиотелефоне со встроенным экскаватором и пулемётом.
21 окт 06, 04:02    [3291429]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
DocAl
andrey_anonymous
DocAl
В Мощные СУБД встроена автокоррекция для битой памяти или отлетевших головок жёсткого диска?

Память - вряд ли, тут вся надежда на железку и контроль CRC блоков (в оракеле по умолчанию отключен), а вот автокоррекция отлетевшего диска таки встроена (Oracle ASM - своеобразный софтварный raid)
А хардварный не судьба использовать?

?????
Вы спросили "встроено ли?" - я ответил.
При чем тут "судьба"?
21 окт 06, 04:09    [3291431]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
При том, что при наличии железных ресурсов для RAID массива, его настройка будет частью адекватной настройки СУБД. А при отсутствии этих ресурсов, как бы, никакой ASM не спасёт.
21 окт 06, 04:14    [3291437]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
DocAl
При том, что при наличии железных ресурсов для RAID массива, его настройка будет частью адекватной настройки СУБД. А при отсутствии этих ресурсов, как бы, никакой ASM не спасёт.

Не скажите.
ASM позволяет, к примеру, получить отказоустойчивое решение и без аппаратного RAID - только дисков напхайте. Может быть актуально для "бюджетных" по железу решений.
Для "топовых" же решений ASM позволит спокойно пережить отказ самого RAID-контроллера, если таковых в системе хотя бы два :)
Ну и плюс бонусы вроде упрощенного администрирования.
Однако это все далеко за пределами топика, предлагаю не заморачиваться.

Возвращаясь к топику: хранение картинок в БД может иметь смысл не только для разграничения доступа.
Могут играть роль аспекты:
- Надежность: единая система и стратегия резервного копирования, автоматическое восстановление всех данных до последней транзакции.
- Целостность: обеспечение соответствия каталога картинок имеющимся файлам.
- Единый интерфейс поиска и доступа к фалам: упрощается создание приложений, интеграция с иными системами.
- Может оказаться полезным функционал того же Spatial.
- Легкая интеграция с системами Content Management.
- Тут не уверен, но вроде существуют механизмы поиска изображений по содержимому.
- Без проблем организуется доступ по множеству интерфейсов: от FTP и NFS до IMAP, при этом логика доступа программируется.
....
На самом деле это далеко не все - только то, что "само вспомнилось".
21 окт 06, 04:33    [3291454]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 andrey_anonymous
Возвращаясь к топику: хранение картинок в БД может иметь смысл не только для разграничения доступа.
Могут играть роль аспекты:
- Надежность: единая система и стратегия резервного копирования, автоматическое восстановление всех данных до последней транзакции.

Пардон, а что, файловые системы по Вашему - не умеют бекапиться? :))
Транзакционность у них (файловых систем) как бы тоже есть (зависит от, конечно)

- Целостность: обеспечение соответствия каталога картинок имеющимся файлам

Уже не в первый раз создали себе проблему, и уже не в первый раз её решаем?
Целостность чего и чего - Вы почему-то не удосужились узнать у автора топика?
В зависимости от - целостность можно точно так же обеспечить кастомными аттрибутами файла, храня ффсе унутре файловой системы. Оно работает, более того, каждый день работает.

- Единый интерфейс поиска и доступа к фалам: упрощается создание приложений, интеграция с иными системами.

Так ви таки про файловую систему говорите?
Вах, низаметиль :(
Потому ушёль, и дальше нечеталь :(
21 окт 06, 04:51    [3291463]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Пьяный Лох
Возвращаясь к топику: хранение картинок в БД может иметь смысл не только для разграничения доступа.
Могут играть роль аспекты:
- Надежность: единая система и стратегия резервного копирования, автоматическое восстановление всех данных до последней транзакции.

Пардон, а что, файловые системы по Вашему - не умеют бекапиться? :))

Не о том речь.
Если каталог в БД, а файлы - на диске, то придется создать:
1) стратегию резервного копирования БД
2) стратегию резервного копирования ФС
3) механизмы обеспечения взаимного соответствия БД и ФС.
Почему тут вообще появилась БД? Очень просто. Каталог может представлять из себя более сложную структуру нежели обычная иерархия - например, включать различные классификаторы, пользовательские комментарии, может быть увязан с workflow и т.д. - все, что требуется для решения задач предприятия.
Пьяный Лох
- Целостность: обеспечение соответствия каталога картинок имеющимся файлам

Уже не в первый раз создали себе проблему, и уже не в первый раз её решаем?
Целостность чего и чего - Вы почему-то не удосужились узнать у автора топика?
"Могут играть роль" и "Непременно потребуется автору топика" - несколько различные категории.
Пост скорее ответ коллегам, не наблюдающим вообще никакого смысла в хранении файлов в БД.
А степень актуальности для задачи автора топика пусть определит автор топика.
Пьяный Лох
В зависимости от - целостность можно точно так же обеспечить кастомными аттрибутами файла, храня ффсе унутре файловой системы.
Упс... Ню-ню :)
Можно, конечно, при известном энтузазизме... Вот только в условиях конкурентной среды для решения задачи потребуется реализовать кастомную СУБД :)
Пьяный Лох
Оно работает, более того, каждый день работает.
В однопользовательском доступе или под специфической задачей - вполне допускаю.
Как общее решение - весьма сомнительно.
Пьяный Лох
- Единый интерфейс поиска и доступа к фалам: упрощается создание приложений, интеграция с иными системами.

Так ви таки про файловую систему говорите?
Нет, про БД.
Ищем "закаты" and "море", после чего получаем файлы через тот же интерфейс.
Why not?
21 окт 06, 05:12    [3291469]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
imkot
Member

Откуда: г. Барнаул, Алтайский край
Сообщений: 516
Оффтоп.
Читаю и балдею.
Автор топика кажется давно уже пропал, а народ все еще бьется :)
Но все же интересно: победит чье-то мнение или нет.
ЗЫ: дай-то бог не встретиться с такой задачей :)
21 окт 06, 12:36    [3291632]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 andrey_anonymous
Не о том речь.
Если каталог в БД, а файлы - на диске, то придется создать:
1) стратегию резервного копирования БД
2) стратегию резервного копирования ФС
3) механизмы обеспечения взаимного соответствия БД и ФС.

Не, простите, я ж самого начала сказал, что скрипач не нужен :)

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

Так же я понимаю, что если по условиям задачи НЕ требуется РСУБД, и решили для хранения файлов обойтись одной лишь файловой системой, без РСУБД, то и всю дополнительную информацию надо хранить в той же самой файловой системе, привязав её к файлам.

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

Почему тут вообще появилась БД?

Ну, расскажите - почему?

Очень просто. Каталог может представлять из себя более сложную структуру нежели обычная иерархия - например, включать различные классификаторы, пользовательские комментарии, может быть увязан с workflow и т.д. - все, что требуется для решения задач предприятия.

Это Ваши выдумки, или это можно прочитать в постановке задачи от автора топика?
может со зрением у меня чего...

Упс... Ню-ню :)
Можно, конечно, при известном энтузазизме... Вот только в условиях конкурентной среды для решения задачи потребуется реализовать кастомную СУБД :)

Конкурентный доступ - имеется в виду многопользовательская работа (причем не в режиме read-only)? Если да, то Вы может быть (а может и не быть) правы, только вот опять вопрос - откуда следует необходимость?

В однопользовательском доступе или под специфической задачей - вполне допускаю.
Как общее решение - весьма сомнительно.

А кто претендует на общее решение? Вы претендуете? Ну флаг Вам в руки, конечно же. А я по первому сообщению веду обсуждение.
21 окт 06, 19:05    [3292051]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
DocAl
*ик
Аргументация этого утверждения будет какая или при словах Оракл и ДиБи2 все должны были пасть ниц?) Какие такие ошибки заметить "какой-нить МуСКЛ", и не заметит "более мощная СУБД", если и ту и другую адекватно грамотно настроить? В Мощные СУБД встроена автокоррекция для битой памяти или отлетевших головок жёсткого диска?

Ошибки администратора разумеется.


Пьяный Лох
2 с127
Заметны тормоза например в открывании каталогов. У меня относительно медленная машина, на быстрых заметно позже. NTFS я упомянул потому что именно там я заметил тормоза, но это не важно, на других обычных ФС будет то же самое. Больше файлов - большие тормоза, причем тормоза растут линейно.

Ыть пардон - что такое "открывание каталогов"?
Чем открывание?
Консервным ключом, али виндоуз експлорером? И даже если там проблемы - не проблемы ли это консервного ключа?

Фаром. Поиск фаровский и виндовзный тоже явно тормозят, когда натыкаются на большую диреркторию.

Пьяный Лох
Ведь Вы даже не удосужились узнать - сколько именно раз в секунду автору топика нужно получить "это"?

Это верно, ошибся. Но не сильно. В постановке задачи сказано: "Программа, работающая с этой базой должна быстро получить по индексу картинку и несколко информационных записей. Раз в год планируется все выкидывать и начинать заполнять базу с начала."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351165&pg=1#3274048
А у Вас они не ищутся никак, ни быстро ни медленно, поскольку не хранятся больше двух дней.

Пьяный Лох

Если файлов много, то это медленно, поскольку сколько бы файлов не было, они в NTFS, ext2, ext3 и некоторых других не индескируются

Давайте я скажу, что это неправда, а вы меня попытаетесь убедить в обратном?
Индексируются. Как-то. Как именно - не знаю, не буду врать.
Таперича убеждайте в обратном.

Не буду, зачем. Уже пытались создать 2 млн файлов, неудачно, а это всего два дня работы системы. https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351165&pg=1#3285273
На других ФС поломается не через два дня, а через 20, разница не принципиальная.

Ломается даже на хранении, до поиска дело даже не дошло. Задайте "ls random_name" в цикле, посмотрите на время поиска. О чем мы спорим не понимаю, ведь все ясно, проверили, не работает.

Хранить большое число файлов в ФС конечно же можно, но их нужно разбрасывать по разным поддиректориям, причем следить, чтобы много поддиректорий в одну директориию тоже не попадало. В нашей системе файлы получают уникальное 32 (по-моему) цифровое имя имя по основанию 16, и каждые две буквы - новый уровень поддиректория в дереве. Плучается глубина 16, в каждой поддиректории не больше 256 поддиректорий либо файлов. Вроде пока работает, но повозиться пришлось немало, хорошо что не мне, несмотря на то что алгоритмы тривиальны. Если бы эти данные хранили в БД, то не было бы пробмем, но у нас используется чужая тулза, которая умеет работать только с файлами.
22 окт 06, 06:31    [3292545]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
Пьяный Лох


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

Так же я понимаю, что если по условиям задачи НЕ требуется РСУБД, и решили для хранения файлов обойтись одной лишь файловой системой, без РСУБД, то и всю дополнительную информацию надо хранить в той же самой файловой системе, привязав её к файлам.

Согласен, именно так, если бы там не требовалось хратить и получать дополнительную информацию ("должна быстро получить по индексу картинку и несколко информационных записей"). А так в результате длительных усилий Вы построите свою СУБД в файловой системе. Так зачем городить огород, лучше взять готовую СУБД.
22 окт 06, 06:50    [3292547]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
c127
используется чужая тулза, которая умеет работать только с файлами.

Просто для информации - полюбопытствуйте про oracle ifs, может оказаться интересно.
22 окт 06, 16:03    [3292901]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
mv
Member

Откуда:
Сообщений: 8876

Полный атас.
Не проще ли не спорить, а закатать рукава, да слепить тестовую систему?
Если неспеша - то максимум на один вечер работы.



Posted via ActualForum NNTP Server 1.3

22 окт 06, 19:45    [3293070]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
mv
Member

Откуда:
Сообщений: 8876

Попробовал: FireBird 2.0.
Т.к. требуемая структура не описана, то обошелся одной табличкой.
Табличка простая:

CREATE GENERATOR GEN_BIGTABLE_ID;

CREATE TABLE BIGTABLE (
    ID           INTEGER NOT NULL,
    NAME         VARCHAR(255),
    DESCRIPTION  VARCHAR(255),
    IMAGE        BLOB SUB_TYPE 0 SEGMENT SIZE 80
);

ALTER TABLE BIGTABLE ADD CONSTRAINT PK_BIGTABLE PRIMARY KEY (ID);


CREATE DESCENDING INDEX BIGTABLE_IDX1 ON BIGTABLE (ID);
/*Просто так, чтобы не очень быстро заливка шла - и еще кое-для чего :)*/


/* Trigger: BIGTABLE_BI */
CREATE TRIGGER BIGTABLE_BI FOR BIGTABLE
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
  IF (NEW.ID IS NULL) THEN
    NEW.ID = GEN_ID(GEN_BIGTABLE_ID,1);
END



Т.е. по одной картинке на запись.

Залил 1 миллион записей чуть меньше, чем за 30 минут (Commit после каждых
1000 insert).
В blob каждой записи - картинка, размером от 10 до 27 кб (в среднем - 16,5
кб).

Файл базы получился - 18 гигов. Учитывая, что картинок залито в 20 раз
больше, чем запланировано от "ежедневно планируемых", то осмелюсь
предположить, что время заливки "суточных данных" составит менее 2 минут, а
общий "годовой" размер базы будет около 370 гигов. (и меня и винта-то такого
нет
)

Читается "по индексу"(как було заказано) быстро. Очень. :) Поверьте на
слово.

....
И чё? И ни чё...
....
Быстро или нет залил? - ХЗ...
Что за данные будут? Где (локально/удаленно) они будут лежать? Какие
характеристики сети?
Какое железо сервера?
Какие требования по времени доступа/времени записи? Сколько пользователей?
Что значит "раз в год все выкидывать"? Грохнуть файл? -это быстро. Грохнуть
табличку - уже помедленнеее.
Или что еще?
Бэкапить будем? Если да, то как? И как часто? (мноха хихабайтов - это вам не
хухры -мухры, для FireBird, возможно, придется NBACKUP - инкрементальный
бэкап использовать)
....
А мы тут распинаемся...ди-би-два, эн-тэ-эф-эс, виндоус...

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



Posted via ActualForum NNTP Server 1.3

22 окт 06, 23:48    [3293281]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 c127
Фаром. Поиск фаровский и виндовзный тоже явно тормозят, когда натыкаются на большую диреркторию.

Хммм... знаете ли, я был знаком с разработчиком файлового манагера для PTS DOS... программер настолько могучий, что для отображения списков файлов он не придумал ничего лучше, чем использовать пузырьковую сортировку. И что теперь, файловая система от этого хуже стала?

Но вернемся к нашим баранам, то бишь всяким там фарам.
Вы открываете фаром каталог и видите тормоза. Тормоза растут линейно. Файловая система, по Вашему утверждению, ничего не индексирует. Хммм... Вы понимаете, что в совокупности всё это есть бред? Не бывает линейных алгоритмов сортировки неиндексированных массивов. Где-то Вы в очередной раз ошиблись.

Это верно, ошибся. Но не сильно

Фига ж себе несильно. Начали с утверждения, что будут тормоза при поиске, а теперь плавно сползли на то, что якобы оно просто не влезет. Вам не кажется, что это таки две большие разницы?
То, что могут быть трудности с хранением - это одно, а то, что уже на нескольких сотнях файлов у Вас наступают какие-то ограничения ОС - это детские страшилки, их внукам перед сном рассказывайте.

Пьяный Лох
с127
Если файлов много, то это медленно, поскольку сколько бы файлов не было, они в NTFS, ext2, ext3 и некоторых других не индескируются

Давайте я скажу, что это неправда, а вы меня попытаетесь убедить в обратном?

Не буду, зачем.

Ну и чудненько. Мудрое решение.
Во всех обзорах про NTFS пишется, что дескать там фсякие B-деревья используются для индексации, а Вы бы вдруг стали доказывать, что индексации нет. Неудобненько получилось бы.
Опять таки во всех обзорах преимущества NTFS-а начинают сказываться при большом (несколько тысяч) кол-ве файлов в каталоге, а у Вас на нескольких сотнях видите ли ограничения ОС.
"... Как уже неоднократно было показано, SQL бесполезен для доступа к данным... " (с) ЧАЛ.

Уже пытались создать 2 млн файлов, неудачно, а это всего два дня работы системы.

Мы один и тот же топик читаем? Как из 50000 картинок в день Вы смогли получить, что 2 млн - это два дня работы?

На других ФС поломается не через два дня, а через 20, разница не принципиальная.

Я так полагаю, что учитывая Вашу двадцатикратную ошибку по количеству файлов, эту Вашу фразу надо читать как "на других ФС поломается не за 20 дней, а за 400"?

О чем мы спорим не понимаю, ведь все ясно, проверили, не работает.

Если не получилось с разбега лбом открыть дверь - это не значит, что дверь принципиально не открывается. Вполне возможно, что открывается, причем быть может даже в другую сторону.
Какой размер кластера? Было ли зарезервировано место под MFT? Было ли отключено банальное протоколирование времени последнего доступа к файлу/каталогу (это в первую очередь советуется при рассмотрении вопросов, связанных с хранением большого кол-ва файлов)?
А так, знаете ли, я (например) в ДБ2 с бодуна попробую чего-нить понаписать в гигабайтных объемах, получу какую-нибудь каку, и скажу, что дескать "РСУБД не предназначены для хранения большого кол-ва информации". Дескать все ведь ясно, проверили, не работает.

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

Храните дополнительную информацию прямо вместе с файлом, в чем проблемы то???
Т.е. не факт, что по условиям задачи оно обязательно получится, но точно так же не факт, что обязательно не получится.

А так в результате длительных усилий Вы построите свою СУБД в файловой системе. Так зачем городить огород, лучше взять готовую СУБД.

Да не предлагаю я писать СУБД поверх файловой системы. Равно как и не предлагаю писатьт файловую систему унутре СУБД.

---------------------------------------

2 mv
Полный атас.
Не проще ли не спорить, а закатать рукава, да слепить тестовую систему?
Если неспеша - то максимум на один вечер работы.

Был бы незадействованный полутерабайтный винт - так бы и сделал. Ан нетути :(

Если организация хранения файлов в СУБД совсем не накладна по сравнению с
хранением в файловой - то почему бы ее не использовать?

Патамушта зачем.
Файловая система должна хранить файлы.
Веб-сервер должен плеваться хтмл-страничками.
РСУБД должна ворочать кортежами.
Ледокол должен колоть лёд.
23 окт 06, 04:43    [3293405]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить