powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор сервера, чтобы не тормозило ...
25 сообщений из 163, страница 2 из 7
Выбор сервера, чтобы не тормозило ...
    #34068347
Фотография imkot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Интересный топик получился.
Как я понимаю на таких объемах данных правильным решением будет Db2?
Просто больше никто ничего не предложил...
Может спросить админа какого-нибудь сайта как организовано хранение такого количетсва картинок?
Например админа ifun или чего-то подобного? У них там объемы немаленькие (по количеству).
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34068364
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так платформу-то сообщите, может? Под FreeBSD/Linux без проблем и в файлах хранить. Под виндой вот похоже тюнинг файловой системы нужен сначала.
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34068371
Фотография imkot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DocAlТак платформу-то сообщите, может? Под FreeBSD/Linux без проблем и в файлах хранить. Под виндой вот похоже тюнинг файловой системы нужен сначала.
Дык вопрос не я задавал. А вопрошающий по всей видимости пропал после второго своего поста. Видно решил забить на это дело.
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34068373
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А... Гм, да, топик вышел интересный.)
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071481
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ЛП2 c127
"всякие ограничения операционки" в таких задачах наступают очень быстро, в вынь2000 начиная с нескольких сотен файлов уже заметно невооруженным глазом
А можно поподробнее - что именно заметно невооруженным глазом?

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

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

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

DocAl
% find images -type f | wc -l
376428
А сколько анаогичный count выполнялся бы в правильно проиндесированной БД? Чтобы было с чем сравнивать.

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



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

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

Я исходил из того, что Вы денег платить не хотите. Бесплатные Оракл и МССКЛ имеют ограничения на размер базы по-моему, у Вас картинки, поэтому наверняка в ограничения не впишитесь. У ДБ2 ограничений на размер базы нет. Можно взять постгре или МуСКЛ, наверное тоже будут работать, но ДБ2 надежнее, я бы выбрал ее. Тем более есть много БД с картинками, построенных на ДБ2, например БД патентного бюро США, чуть ли не самая большая БД в мире по какому-то там существенному параметру, если не ошибаюсь.
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071485
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 с127
Заметны тормоза например в открывании каталогов. У меня относительно медленная машина, на быстрых заметно позже. NTFS я упомянул потому что именно там я заметил тормоза, но это не важно, на других обычных ФС будет то же самое. Больше файлов - большие тормоза, причем тормоза растут линейно.
Ыть пардон - что такое "открывание каталогов"?
Чем открывание?
Консервным ключом, али виндоуз експлорером? И даже если там проблемы - не проблемы ли это консервного ключа?
Давайте фсе-таке уточнять, а?

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

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

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

Я исходил из того, что Вы денег платить не хотите
Хех... А это откуда проследовало? (хоть и не ко мне было обращено)
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071486
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
UltrinПредложите сервер, для такой базы - в день добавляются примерно 1000000 (лимон) записей типа (индекс, строка(под 10 символов)) да плюс еще картинки эдак так под 50000 (каждая размером под 15 киолбайт). Программа, работающая с этой базой должна быстро получить по индексу картинку и несколко информационных записей. Раз в год планируется все выкидывать и начинать заполнять базу с начала.
Что выбрать
MySQL, PostgreSQL - потянут ли?
MSSQL - очень интересно, глядя на то что можно подцепить еще и DBF которые рядом с базой валяюися, но быстро сможет?
Oracle,DB2 - база ведь простенькая, не будет ли это стрельбой из пушки по воробью

Да забыл сказать. Не бойтесь стрельбы из пушки по воробъям. Во-первых задачи имеют свойство расширяться. Во-вторых это если платить, то существенно чтобы не переплатить, а бесплатное если работает, то остальне не важно. А в третьих администрируется ДБ2 (и оракл) несложно, а внимания требует к себе меньше, чем какой-нибудь МуСКЛ, поскольку более мощная и не заметит многих ошибок, один раз настроил и забыл.
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071487
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127 администрируется ДБ2 (и оракл) несложно, а внимания требует к себе меньше, чем какой-нибудь МуСКЛ, поскольку более мощная и не заметит многих ошибок, один раз настроил и забыл.*ик
Аргументация этого утверждения будет какая или при словах Оракл и ДиБи2 все должны были пасть ниц?) Какие такие ошибки заметить "какой-нить МуСКЛ", и не заметит "более мощная СУБД", если и ту и другую адекватно грамотно настроить? В Мощные СУБД встроена автокоррекция для битой памяти или отлетевших головок жёсткого диска?
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071488
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DocAlВ Мощные СУБД встроена автокоррекция для битой памяти или отлетевших головок жёсткого диска?
Память - вряд ли, тут вся надежда на железку и контроль CRC блоков (в оракеле по умолчанию отключен), а вот автокоррекция отлетевшего диска таки встроена (Oracle ASM - своеобразный софтварный raid)
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071490
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127
DocAl
% find images -type f | wc -l
376428
А сколько анаогичный count выполнялся бы в правильно проиндесированной БД? Чтобы было с чем сравнивать.

Простите, но мне в интернет-магазине фотографии товаров клиентам сервить надо, а не сидеть пересчитывать. Причём, с одной стороны, если уж приспичит -- так у меня в базе информация о них " правильно проиндексированна", а с другой, ~10 секунд на 400 000 картинок в 1 000 директорий дают примерную оценку задержки доступа к любой из них не более 10 мс, что, как бы, вполне сравнимо с average seek time, от которого вы никуда не уйдёте.
c127
DocAl"Куча времени", потраченная на борьбу, составляет порядка пары часов (первоначально большое количество файлов не предполагалось).
Хотя, конечно, при большом желании и излишке ресурсов (или при наличии объективных предпосылок, так бывает), можно хранить и в базе.)
Бекапить все эти файлы на другую машину собираемся или как? Лучше инкрементально. За целостностью между файлами и БД тоже будет ОС следить, или все-таки скрипты писать прийдется? А попробуйте для упражнения, интересное занятие. Вряд ли в два часа уложитесь, таки получается куча времени.

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

С другой стороны, я не утверждаю, что нет таких ситуаций, когда картинки в базе хранить было бы показано. Например, когда во главу угла ставится разграничение доступа к документам, а не среднее время доступа к каждому из них, плюс хочется аудита доступа к ним, добавьте ещё какой-то паранойи по вкусу -- тогда может быть вполне разумным хранить их в БД. Но тогда вопрос бы ставился, в первую очередь, о безопасности, а не скорости доступа.
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071491
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И куда ш оне все деваются....

Я конечно понимаю, что с127 человек могучий, и имеет обыкновение обдумывать ответ в течение суток (ничего против, кстате, оч даж карашо)... но ведь на простейшие вопросы надо отвечать "от зубов" :)
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071492
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous DocAlВ Мощные СУБД встроена автокоррекция для битой памяти или отлетевших головок жёсткого диска?
Память - вряд ли, тут вся надежда на железку и контроль CRC блоков (в оракеле по умолчанию отключен), а вот автокоррекция отлетевшего диска таки встроена (Oracle ASM - своеобразный софтварный raid)А хардварный не судьба использовать? В конце-концов, если хочется именно софтварный -- так они в Linux/FreeBSD в изобилии, было б железо, на котором строить. Никак не в обиду пользователям Оракла, но он у меня ассоциируется с хохмой фидошных времён (кажется) о радиотелефоне со встроенным экскаватором и пулемётом.
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071493
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DocAl andrey_anonymous DocAlВ Мощные СУБД встроена автокоррекция для битой памяти или отлетевших головок жёсткого диска?
Память - вряд ли, тут вся надежда на железку и контроль CRC блоков (в оракеле по умолчанию отключен), а вот автокоррекция отлетевшего диска таки встроена (Oracle ASM - своеобразный софтварный raid)А хардварный не судьба использовать?
?????
Вы спросили "встроено ли?" - я ответил.
При чем тут "судьба"?
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071497
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
При том, что при наличии железных ресурсов для RAID массива, его настройка будет частью адекватной настройки СУБД. А при отсутствии этих ресурсов, как бы, никакой ASM не спасёт.
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071507
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DocAlПри том, что при наличии железных ресурсов для RAID массива, его настройка будет частью адекватной настройки СУБД. А при отсутствии этих ресурсов, как бы, никакой ASM не спасёт.
Не скажите.
ASM позволяет, к примеру, получить отказоустойчивое решение и без аппаратного RAID - только дисков напхайте. Может быть актуально для "бюджетных" по железу решений.
Для "топовых" же решений ASM позволит спокойно пережить отказ самого RAID-контроллера, если таковых в системе хотя бы два :)
Ну и плюс бонусы вроде упрощенного администрирования.
Однако это все далеко за пределами топика, предлагаю не заморачиваться.

Возвращаясь к топику: хранение картинок в БД может иметь смысл не только для разграничения доступа.
Могут играть роль аспекты:
- Надежность: единая система и стратегия резервного копирования, автоматическое восстановление всех данных до последней транзакции.
- Целостность: обеспечение соответствия каталога картинок имеющимся файлам.
- Единый интерфейс поиска и доступа к фалам: упрощается создание приложений, интеграция с иными системами.
- Может оказаться полезным функционал того же Spatial.
- Легкая интеграция с системами Content Management.
- Тут не уверен, но вроде существуют механизмы поиска изображений по содержимому.
- Без проблем организуется доступ по множеству интерфейсов: от FTP и NFS до IMAP, при этом логика доступа программируется.
....
На самом деле это далеко не все - только то, что "само вспомнилось".
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071514
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 andrey_anonymous
Возвращаясь к топику: хранение картинок в БД может иметь смысл не только для разграничения доступа.
Могут играть роль аспекты:
- Надежность: единая система и стратегия резервного копирования, автоматическое восстановление всех данных до последней транзакции.
Пардон, а что, файловые системы по Вашему - не умеют бекапиться? :))
Транзакционность у них (файловых систем) как бы тоже есть (зависит от, конечно)

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

- Единый интерфейс поиска и доступа к фалам: упрощается создание приложений, интеграция с иными системами.
Так ви таки про файловую систему говорите?
Вах, низаметиль :(
Потому ушёль, и дальше нечеталь :(
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071518
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пьяный Лох Возвращаясь к топику: хранение картинок в БД может иметь смысл не только для разграничения доступа.
Могут играть роль аспекты:
- Надежность: единая система и стратегия резервного копирования, автоматическое восстановление всех данных до последней транзакции.
Пардон, а что, файловые системы по Вашему - не умеют бекапиться? :))
Не о том речь.
Если каталог в БД, а файлы - на диске, то придется создать:
1) стратегию резервного копирования БД
2) стратегию резервного копирования ФС
3) механизмы обеспечения взаимного соответствия БД и ФС.
Почему тут вообще появилась БД? Очень просто. Каталог может представлять из себя более сложную структуру нежели обычная иерархия - например, включать различные классификаторы, пользовательские комментарии, может быть увязан с workflow и т.д. - все, что требуется для решения задач предприятия.
Пьяный Лох - Целостность: обеспечение соответствия каталога картинок имеющимся файлам
Уже не в первый раз создали себе проблему, и уже не в первый раз её решаем?
Целостность чего и чего - Вы почему-то не удосужились узнать у автора топика?
"Могут играть роль" и "Непременно потребуется автору топика" - несколько различные категории.
Пост скорее ответ коллегам, не наблюдающим вообще никакого смысла в хранении файлов в БД.
А степень актуальности для задачи автора топика пусть определит автор топика.
Пьяный ЛохВ зависимости от - целостность можно точно так же обеспечить кастомными аттрибутами файла, храня ффсе унутре файловой системы.Упс... Ню-ню :)
Можно, конечно, при известном энтузазизме... Вот только в условиях конкурентной среды для решения задачи потребуется реализовать кастомную СУБД :) Пьяный Лох Оно работает, более того, каждый день работает.В однопользовательском доступе или под специфической задачей - вполне допускаю.
Как общее решение - весьма сомнительно.
Пьяный Лох - Единый интерфейс поиска и доступа к фалам: упрощается создание приложений, интеграция с иными системами.
Так ви таки про файловую систему говорите?Нет, про БД.
Ищем "закаты" and "море", после чего получаем файлы через тот же интерфейс.
Why not?
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071631
Фотография imkot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Оффтоп.
Читаю и балдею.
Автор топика кажется давно уже пропал, а народ все еще бьется :)
Но все же интересно: победит чье-то мнение или нет.
ЗЫ: дай-то бог не встретиться с такой задачей :)
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34071962
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 andrey_anonymous
Не о том речь.
Если каталог в БД, а файлы - на диске, то придется создать:
1) стратегию резервного копирования БД
2) стратегию резервного копирования ФС
3) механизмы обеспечения взаимного соответствия БД и ФС.
Не, простите, я ж самого начала сказал, что скрипач не нужен :)

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

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

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

Почему тут вообще появилась БД?
Ну, расскажите - почему?

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

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

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


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

Пьяный ЛохВедь Вы даже не удосужились узнать - сколько именно раз в секунду автору топика нужно получить "это"?
Это верно, ошибся. Но не сильно. В постановке задачи сказано: "Программа, работающая с этой базой должна быстро получить по индексу картинку и несколко информационных записей. Раз в год планируется все выкидывать и начинать заполнять базу с начала."
/topic/351165&pg=1#3274048
А у Вас они не ищутся никак, ни быстро ни медленно, поскольку не хранятся больше двух дней.

Пьяный Лох
Если файлов много, то это медленно, поскольку сколько бы файлов не было, они в NTFS, ext2, ext3 и некоторых других не индескируются
Давайте я скажу, что это неправда, а вы меня попытаетесь убедить в обратном?
Индексируются. Как-то. Как именно - не знаю, не буду врать.
Таперича убеждайте в обратном.
Не буду, зачем. Уже пытались создать 2 млн файлов, неудачно, а это всего два дня работы системы. /topic/351165&pg=1#3285273
На других ФС поломается не через два дня, а через 20, разница не принципиальная.

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

Хранить большое число файлов в ФС конечно же можно, но их нужно разбрасывать по разным поддиректориям, причем следить, чтобы много поддиректорий в одну директориию тоже не попадало. В нашей системе файлы получают уникальное 32 (по-моему) цифровое имя имя по основанию 16, и каждые две буквы - новый уровень поддиректория в дереве. Плучается глубина 16, в каждой поддиректории не больше 256 поддиректорий либо файлов. Вроде пока работает, но повозиться пришлось немало, хорошо что не мне, несмотря на то что алгоритмы тривиальны. Если бы эти данные хранили в БД, то не было бы пробмем, но у нас используется чужая тулза, которая умеет работать только с файлами.
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34072256
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Пьяный Лох

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

Так же я понимаю, что если по условиям задачи НЕ требуется РСУБД, и решили для хранения файлов обойтись одной лишь файловой системой, без РСУБД, то и всю дополнительную информацию надо хранить в той же самой файловой системе, привязав её к файлам.
Согласен, именно так, если бы там не требовалось хратить и получать дополнительную информацию ("должна быстро получить по индексу картинку и несколко информационных записей"). А так в результате длительных усилий Вы построите свою СУБД в файловой системе. Так зачем городить огород, лучше взять готовую СУБД.
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34072488
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127используется чужая тулза, которая умеет работать только с файлами.
Просто для информации - полюбопытствуйте про oracle ifs, может оказаться интересно.
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34072621
Фотография mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Полный атас.
Не проще ли не спорить, а закатать рукава, да слепить тестовую систему?
Если неспеша - то максимум на один вечер работы.



Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34072748
Фотография mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Попробовал: FireBird 2.0.
Т.к. требуемая структура не описана, то обошелся одной табличкой.
Табличка простая:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
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
...
Рейтинг: 0 / 0
Выбор сервера, чтобы не тормозило ...
    #34072838
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 c127
Фаром. Поиск фаровский и виндовзный тоже явно тормозят, когда натыкаются на большую диреркторию.
Хммм... знаете ли, я был знаком с разработчиком файлового манагера для PTS DOS... программер настолько могучий, что для отображения списков файлов он не придумал ничего лучше, чем использовать пузырьковую сортировку. И что теперь, файловая система от этого хуже стала?

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

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

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

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

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

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

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

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

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

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

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

Если организация хранения файлов в СУБД совсем не накладна по сравнению с
хранением в файловой - то почему бы ее не использовать?
Патамушта зачем.
Файловая система должна хранить файлы.
Веб-сервер должен плеваться хтмл-страничками.
РСУБД должна ворочать кортежами.
Ледокол должен колоть лёд.
...
Рейтинг: 0 / 0
25 сообщений из 163, страница 2 из 7
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор сервера, чтобы не тормозило ...
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]