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

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

Какой размер кластера? Было ли зарезервировано место под MFT? Было ли отключено банальное протоколирование времени последнего доступа к файлу/каталогу (это в первую очередь советуется при рассмотрении вопросов, связанных с хранением большого кол-ва файлов)?

Как проводивший "эксперимент" отвечаю: не было проделано ничего из вышеупомянутого. Ну просто потому, что тест осуществлялся на коленке на домашней машине и за десять минут, да и предполагалось ловить тормоза, а не ограничения на количество файлов на разделе (благо понятно, что это самое проектируемое количество задаётся при форматировании). Вот вывод chkdsk на состояние ~ соответствующее началу теста.
chkdsk

4096 bytes in each allocation unit.
8110808 total allocation units on disk.
164219 allocation units available on disk.

Размер кластера стандартный, место в MFT зарезервировано не было, собственно, использовался уже порядком подзабитый раздел, где большая часть места в MFT уже была занята. Однако обещаные тормоза вплоть до полного забития MFT обнаружены не были (да, в общем-то и после этого тоже, по крайней мере, фар довольно шустро бегал по этим директориям).
23 окт 06, 06:17    [3293423]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
mv
Member

Откуда:
Сообщений: 8876
ЛП
Патамушта зачем.
Файловая система должна хранить файлы.
Веб-сервер должен плеваться хтмл-страничками.
РСУБД должна ворочать кортежами.
Ледокол должен колоть лёд.

А, понятно...
Попробуйте разобраться - поначалу да, ничерта не понятно.
А потом во вкус войдете - и Вас тоже от использования СУБД за уши не оттащат.
23 окт 06, 13:35    [3295598]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
mv
ЛП
Патамушта зачем.
Файловая система должна хранить файлы.
Веб-сервер должен плеваться хтмл-страничками.
РСУБД должна ворочать кортежами.
Ледокол должен колоть лёд.

А, понятно...
Попробуйте разобраться - поначалу да, ничерта не понятно.
А потом во вкус войдете - и Вас тоже от использования СУБД за уши не оттащат.

Багровость Филиппа Филипповича приняла несколько сероватый оттенок.
- В спальне принимать пищу, - заговорил он слегка придушенным голосом, - в смотровой читать, в приемной одеваться, оперировать в комнате прислуги, а в столовой осматривать. Очень возможно, что Айседора Дункан так и делает. Может быть, она в кабинете обедает, а кроликов режет в ванной. Может быть. Но я не Айседора Дункан!.. - Вдруг рявкнул он и багровость его стала желтой. - Я буду обедать в столовой, а оперировать в операционной! Передайте это общему собранию и покорнейше вас прошу вернуться к вашим делам, а мне предоставить возможность принять пищу там, где ее принимают все нормальные люди, то-есть в столовой, а не в передней и не в детской.
:)

Нравится Вам для хранения файлов использовать РСУБД - используйте. Можете даже и других агитировать. Но аргументы надо тщательнЕе подбирать.
А пока что идут какие-то нелепые попытки доказать, что файловая система не годится для выполнения тех задач, для которых она собственно и предназначена, т.е. для хранения файлов. А SQL бесполезен для доступа к файлам, ага. А принтер бесполезен для распечатки документов. Я вот попробовал миллион файлов на печать отправить - у меня тонер закончился. Ну типа и все ясно, проверили, не работает.
23 окт 06, 15:22    [3296706]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
mv
Member

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

Что, аксцесс не мозет бальшие файлы держать?
23 окт 06, 15:53    [3297023]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

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

Что, аксцесс не мозет бальшие файлы держать?

Что, FAT не мозет бальшие файлы держать?
23 окт 06, 15:56    [3297072]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
mv
ЛП
Нравится Вам для хранения файлов использовать РСУБД - используйте. Можете даже и других агитировать. Но аргументы надо тщательнЕе подбирать.
А пока что идут какие-то нелепые попытки доказать, что файловая система не годится для выполнения тех задач, для которых она собственно и предназначена, т.е. для хранения файлов.

Что, аксцесс не мозет бальшие файлы держать?

Нет конечно :)
Больше 2Гб - ну никак :)
Однако при чем тут аксес?
23 окт 06, 15:57    [3297080]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
mv
Member

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

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

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

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

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

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

Читайте внимательно и не выдергивайте из контекста:
Пьяный Лох> "Ведь Вы даже не удосужились узнать - сколько именно раз в секунду автору топика нужно получить "это"?"
c127> "Это верно, ошибся. Но не сильно"

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

ЛП

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

Где я говорил об ограничениях ФС на нескольких сотнях файлов? Процитируйте. Я говорил о ТОРМОЗАХ, заметных невооруженным глазом на нескольких сотнях фалов.

ЛП

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

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

Товарищ, 50000 это РАЗМЕР картинки, а картинок - 1 млн в день.
Предложите сервер, для такой базы - в день добавляются примерно 1000000 (лимон) записей типа (индекс, строка(под 10 символов)) да плюс еще картинки эдак так под 50000 (каждая размером под 15 киолбайт).

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351165&pg=1#3274048

Все, надоело, читайте внимательно и воздастся.
24 окт 06, 00:34    [3299227]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
mv
Member

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

Картинок - 50 000. По 15 кб.


Posted via ActualForum NNTP Server 1.3

24 окт 06, 00:50    [3299245]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 с127
Линейный рост тормозов - не в сортировке, а в поиске

О как! А совсем недавно говорили, что при открытии (то бишь сопстна к сортировке, я так понимаю):
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351165&pg=2#3291407
"... Заметны тормоза например в открывании каталогов. У меня относительно медленная машина, на быстрых заметно позже. NTFS я упомянул потому что именно там я заметил тормоза, но это не важно, на других обычных ФС будет то же самое. Больше файлов - большие тормоза, причем тормоза растут линейно..."
Слово "открывание" - видно, слова "поиск" - не видно.
Вы уж определитесь, чего там у Вас тормозит, а то вдруг завтра выяснится, что это "тормоза растут линейно" еще к чему-нибудь другому относились, а вовсе не к открытию, не к поиску, не к сортировке, и вообще не к файлам :)

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

Ну так оно и ищет быстро, поэтому ошиблись Вы сильно :)
Теперь Вы попытались сползти на то, что оно якобы не хранится больше двух дней. Оно, конечно, тоже неправда, но к быстроте поиска не относится никак.

Где я говорил об ограничениях ФС на нескольких сотнях файлов? Процитируйте. Я говорил о ТОРМОЗАХ, заметных невооруженным глазом на нескольких сотнях фалов.

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

Товарищ, 50000 это РАЗМЕР картинки, а картинок - 1 млн в день.

Чуть ниже Вы даже смогли выделить bold'ом то, что размер картинки - 15Кб. Но прочитать этого Вы видимо были уже не в состоянии

читайте внимательно

Только после Вас, пжалста

И не надо гнилых отмазок лепить. Ну налажали через слово, ну с кем не бывает :)
24 окт 06, 00:55    [3299247]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
ЛП
2 с127
Линейный рост тормозов - не в сортировке, а в поиске

О как! А совсем недавно говорили, что при открытии (то бишь сопстна к сортировке, я так понимаю):
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351165&pg=2#3291407
"... Заметны тормоза например в открывании каталогов. У меня относительно медленная машина, на быстрых заметно позже. NTFS я упомянул потому что именно там я заметил тормоза, но это не важно, на других обычных ФС будет то же самое. Больше файлов - большие тормоза, причем тормоза растут линейно..."
Слово "открывание" - видно, слова "поиск" - не видно.


Не прикидывайтесь дурачком, Вы все прекрасно поняли, когда нужно было, только подзабыли:
ЛП
Начали с утверждения, что будут тормоза при поиске, а теперь плавно сползли на то, что якобы оно просто не влезет.

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351165&pg=2#3293405

ЛП

Где я говорил об ограничениях ФС на нескольких сотнях файлов? Процитируйте. Я говорил о ТОРМОЗАХ, заметных невооруженным глазом на нескольких сотнях фалов.

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

Внимательно читайте.
Утверждается, что:
1) ограничения наступают очень быстро. Это правда, 2 млн файлов создать не удалось, а это для данной задачи немного.
2) в виндовз начиная с нескольких сотен файлов некоторые эффекты ограничений заметны невооруженным глазом. И это правда, я привел пример с фаром.

Но это два РАЗНЫХ утверждения, там стоит запятая, называется сложносочиненное предложение. Для проверки замените запятую на точку, смысл не изменится. Если это было непонятно, то приношу извинения, мне казалось что совршенно очевидно о чем идет речь, на нескольких сотнях файлов катастрофы конечно же не случится, но предвестники уже имеются и видны невооруженным глазом.




Ну что Вы прицепились, пусть все так как Вы говорите, я кругом неправ, но Вам же продемонстрировали независимо от меня, что много файлов (2 млн) в одном каталоге хранить нельзя, не то что искать. Интересно посмотреть на поиск, если их даже сложить не удается, среди чего Вы собираетесь искать? Поиск тоже будет тормозить, но его уже можно не обсуждать.

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

Теперь задачу решайте.
24 окт 06, 03:08    [3299326]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
Согласен, ошибся, NTFS как-то индексирует файлы, она сама вроде и есть индекс
http://www.easeus.com/data-recovery-ebook/ntfs-index-record-and-contents.htm
Но по-видимому файлы индексируются криво, поскольку тормоза при поиске наблюдались конкретные, из-за чего у нас и вынуждены были разбить хранилище на поддиректории.
24 окт 06, 03:56    [3299341]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 с127
Не прикидывайтесь дурачком, Вы все прекрасно поняли, когда нужно было, только подзабыли

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

Давайте все-таки без передергиваний обходиться?

Ну что Вы прицепились, пусть все так как Вы говорите, я кругом неправ, но Вам же продемонстрировали независимо от меня, что много файлов (2 млн) в одном каталоге хранить нельзя, не то что искать.

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

Так что Вы уж извините, но пока что мне продемонстрировали, что северный варвар способен не только сломать свой нефритовый стержень, но и поранить при этом руки.

Интересно посмотреть на поиск, если их даже сложить не удается, среди чего Вы собираетесь искать? Поиск тоже будет тормозить, но его уже можно не обсуждать

Вот Вы утверждаете, что на нескольких сотнях тормоза при поиске (или при сортировке, я запутался в Ваших постоянных подменах собственных слов) - уже видны невооруженным глазом. И в то же самое время серверный варвар DocAI, проводивший "эксперимент", утверждает, что "обещаные тормоза вплоть до полного забития MFT обнаружены не были (да, в общем-то и после этого тоже, по крайней мере, фар довольно шустро бегал по этим директориям)."
Кому верить?

СУБД там все равно будет, где же еще хранить 1 млн новых записей в день, тоже в ФС?

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

Так со мной спорить не нужно, Вы меня убедили, что рост даже не линейный, а хуже (при сортировке)

Вау, так Вы по прежнему считаете, что файловая система ничего не индексирует?
Индексирует, с127, еще как индексирует. Используя те же самые деревья, что и в индексах во многих СУБД. Если эти деревья работают в одном случае с удовлетворительной скоростью, то и в другом они тоже будут работать. И наоборот. По крайней мере я не вижу причин, по которым бы это было не так.
24 окт 06, 03:59    [3299342]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
ЛП
Вау, так Вы по прежнему считаете, что файловая система ничего не индексирует?

с127
Согласен, ошибся, NTFS как-то индексирует файлы, она сама вроде и есть индекс

Слава яйцам... не прошло и недели...
24 окт 06, 04:01    [3299343]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
ЛП
ЛП
Вау, так Вы по прежнему считаете, что файловая система ничего не индексирует?

с127
Согласен, ошибся, NTFS как-то индексирует файлы, она сама вроде и есть индекс

Слава яйцам... не прошло и недели...


Не болтайте языком попусту, предложите свое решение задачи.

Печальный опыт с большим числом файлов не только у меня. Существует целая стратегия борьбы с большими директориями, почитайте

http://www.dtsearch2.com/faq/dts0206.htm#GeneralIndexingStrategy
In our experience and that of some of our customers, NTFS can become slow or unstable when storing very large numbers of files in a single folder. To avoid this problem, we recommend distributing documents in a folder tree, or aggregating documents into ZIP files, to reduce the number of files in individual NTFS folders. (Windows Vista contains an improved file system that may eliminate this issue for Vista users.)


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


ЛП
По-моему я уже трижды предложил один из возможных вариантов решения - хранить те самые "несколько информационых записей" вместе с картинкой, в виде аттрибутов файла.


ЛП=="Пьяный Лох"?

Какие у файла бывают атрибуты, чтобы сложить в среднем по 20 записей, да еще с полями? А вдруг потребуется индекс на поле? А главное зачем, если именно для этого весь мир использует СУБД и все работает.

ЛП
Если эти деревья работают в одном случае с удовлетворительной скоростью, то и в другом они тоже будут работать. И наоборот.

Неправда, зависит от реализации. Не знаю как там сделаны индексы, и почему они тормозят, но они тормозят, причем сильно, это экспериментальный факт. Я это наблюдал сам и ссылку привел, можно при желаннии найти еще и все об одном и том же, как бороться с тормозами НТФС. Причем тормоза начинаются с относительно небольшого числа файлов.
24 окт 06, 04:29    [3299344]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 с127
Печальный опыт с большим числом файлов не только у меня.

Северных варваров много.

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

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

Хотя можно было положить в СУБД и обойтись без всех этих проблем.

Можно. Можно и кроликов в ванной резать.

ЛП=="Пьяный Лох"?

Смотрите-ка, у Вас сегодня просто День Знаний какой-то :)
Не так давно узнали, что NTFS оказывается индексировать чаво-то умеет, теперь вот еще одно открытие :)

Какие у файла бывают атрибуты, чтобы сложить в среднем по 20 записей

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

да еще с полями?

Откуда Вы взяли поля?
Читайте внимательнее первое сообщение: "записей типа (индекс, строка(под 10 символов))"

А вдруг потребуется индекс на поле?

Ну а вот тут уже ничего внятного не скажу. По условиям задачи вроде как не требуется, а так - вдруг кто и индексирует (WinFS, например, но это на следующую лекцию отложим )

Неправда, зависит от реализации.

Ага. Пузырьковая реализация B-дерева.

Не знаю как там сделаны индексы, и почему они тормозят, но они тормозят, причем сильно, это экспериментальный факт. Я это наблюдал сам и ссылку привел, можно при желаннии найти еще и все об одном и том же, как бороться с тормозами НТФС. Причем тормоза начинаются с относительно небольшого числа файлов

Ага. Только вот у DocAI тормозов не наблюдается, и у меня винда спокойно прожевывает тысячи файлов в каталогах, не особо беспокоясь по поводу рандомного поиска. А Вы все с относительно небольшим числом файлов мучаетесь...
24 окт 06, 05:06    [3299350]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
ЛП
да еще с полями?

Откуда Вы взяли поля?
Читайте внимательнее первое сообщение: "записей типа (индекс, строка(под 10 символов))"

А (индекс, строка(под 10 символов)) это что не поля? Еще раз спрашиваю, как Вы в ФС сложите эти 20 записей на картинку с этими полями или полем или чем угодно? Хотя бы теоретически. Практически уже не спрашиваю, в смысле практики с Вами все ясно, Вы такие задачи либо не решали, либо хорошо умеете это скрывать.

ЛП
Ага. Только вот у DocAI тормозов не наблюдается,

Конечно не наблюдается, просто система валится, до поиска дело не доходит. Поиск DocAI не проверял, не нужно трындеть что тормозов нет, хотя я предлагал проверить тут
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351165&pg=2#3292545


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

Единственный наблюдаемый результат по хранению файлов в ФС такой, что 2 миллиона файлов в директорию добавить не удалось. Напоминаю, что у нас по ТЗ должно быть больше 18 млн файлов. И это при том, что до поиска еще дело не дошло. Вы говорите что DocAl неправильно добавлял файлы и файлы эти неправильные. Хорошо, никаких проблем, добавьте правильно, в чем же дело. Но нет, одни разговоры о том, что в принципе решение должно работать, особенно если поднапрячься. Так никто не спорит, в принципе можно посадить 50000 девочек и они будут бумажки перекладывать. Тоже будет работать при определенных усилиях.

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

И главный вопрос все еще остается нераскрытым: а нахрена вообще эти проблемы с файловой системой, если РСУБД задачу решают гораздо проще и абсолютно гарантированно.
24 окт 06, 10:10    [3299952]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Да я и сам, собственно, говорю, что я добавлял неправильно, и ФС не подготовлена была, и размер файлов неадекватный. Просто для адекватного теста у меня не было 300 гигового свободного диска, а отсутствие тормозов показал и мой тест, сделанный в два часа ночи на коленке за 10 минут.
При 2 миллионах файлов тормозов файловой системы _НЕТ_! Может быть, вы расскажете подробно, о каких именно тормозах вы речь ведёте? Всё ж таки, два миллиона файлов при десятке тысяч в каждой из поддиректорий -- это таки никак не меньше "нескольких сотен файлов".
24 окт 06, 10:18    [3300010]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
DocAl
При 2 миллионах файлов тормозов файловой системы _НЕТ_! Может быть, вы расскажете подробно, о каких именно тормозах вы речь ведёте?

Люди путаются в понятиях со страшной силой.
Тест "тормозов поиска" Far-ом некорректен по определению - это скорее тест процедуры сортировки имен файлов, реализованной в FAR.
Можно заменить на тест производительности перечисления (enumeration), если установить свойство панели FAR "unsorted".
Время же поиска и открытия файла с помощью FAR можно проверить только кнопкой F3 :)
24 окт 06, 11:03    [3300352]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
В винде нет встроенных утилит, которые позволили бы померять эти "тормоза" объективно. В FreeBSD я измерял время доступа к реальным файлам реального набора изображений, в среднем оно составляло 12мс с незначительными отклонениями.
Для "нескольких сотен файлов" на винде нам грозились "жуткими тормозами", на двух миллионах, разложенных в поддиректории по десять тысяч в каждой, тормоза не обнаружены. Конкретного описания тормозов не указано.
24 окт 06, 11:55    [3300789]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 c127
А (индекс, строка(под 10 символов)) это что не поля?

Я подозреваю, что не поля
Ежели по индексу надо выбрать запись вида "индекс+строка", то наверное таки выборка индекса по индексу - лишнее :). За вычетом выборки индекса по индексу остается одна лишь только "строка", что уже не "поля", а всего лишь "поле".
Но это не суть как важно.

Еще раз спрашиваю, как Вы в ФС сложите эти 20 записей на картинку с этими полями или полем или чем угодно?

Можно я не буду повторять в четвёртый раз, а?
А то придёт SergSuper, и закроет топик к куям со словами "обсуждение пошло по кругу" :)

В общем так. Ничего кроме трепа от Вас пока услышать не удалось.

Да от Вас в общем-то тоже... Так, пустой треп на фундаменте катастрофических незнаний, отягощенный детскими страшилками...
:)

Единственный наблюдаемый результат по хранению файлов в ФС такой, что 2 миллиона файлов в директорию добавить не удалось.

Единственный продемонстрированный в этом топике результат такой, что 2 миллиона файлов добавить удалось (ну правда какой-то там антивирус зонтиком мигал ), и обещанных тормозов наблюсти не удалось.

Вы говорите что DocAl неправильно добавлял файлы и файлы эти неправильные. Хорошо, никаких проблем, добавьте правильно, в чем же дело.

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

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

Это у Вас проблемы и детские страшилки :)
Теперь к вопросу "нахрен". Например на тот хрен, что NTFS у меня есть, и кушать не просит, а вот DB2 у меня нету, на хрен это счастье мне не сдалось.
Аргумент? Далеко не единственный, причем.

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

2 andrey_anonymous
Люди путаются в понятиях со страшной силой.
Тест "тормозов поиска" Far-ом некорректен по определению - это скорее тест процедуры сортировки имен файлов, реализованной в FAR.

Ну так именно эта процедура сортировки и тормозила у c127 на нескольких сотнях файлов так, что это было заметно невооруженным глазом. Правда потом пошла какае-то перепутаница, то ли это у него сортировка невооруженным глазом тормозила, то ли поиск, но в любом случае - сортировка более "тяжелая операция", и у DocAI не тормозит. Где обещаные тормоза - непонятно. Где "жесть", которую mv упоминал на нескольких тысячах файлов - обратно непонятно.

Если все так плохо, как c127 пытается рассказать, то как же винда сама работает, и не покрывается жестью? У неё ж тысячи файлов в каталогах, а вовсе не сотни.
Как поверх этой якобы покрывшейся жестью винды еще и какие-то эскюэль сервера умудряются жить - совсем неясно.
24 окт 06, 13:47    [3301876]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
ЛП
А то придёт SergSuper, и закроет топик к куям со словами "обсуждение пошло по кругу" :)

а я и не уходил :)
24 окт 06, 14:21    [3302206]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
фсе, баюс, баюс

тока не бросай нас ф терновый куст :)
24 окт 06, 14:23    [3302220]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
mv
Member

Откуда:
Сообщений: 8876
Все ясно.
ЛП - сумасшедший.
24 окт 06, 15:19    [3302763]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
ЛП

Единственный наблюдаемый результат по хранению файлов в ФС такой, что 2 миллиона файлов в директорию добавить не удалось.

Единственный продемонстрированный в этом топике результат такой, что 2 миллиона файлов добавить удалось (ну правда какой-то там антивирус зонтиком мигал ),

И действительно, на самом имел место полный успех, только антивирус с зонтиком портит картину:
Обновление: я таки решил дождаться, и где-то в районе 2 000 000 файлов винда дошла до состояния практически полного нестояния и сказала "кря". Предложила запустить chkdsk.exe, но запустить не смогла, т.к. не смогла открыть необходимые библиотеки. Причём ни создать новый файл, ни открыть старый стало невозможно.
....
И буфер обмена не работает. В общем, вполне себе способ создать забавные глюки на компе, причём можно использовать и не системный раздел.)

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351165&pg=1#3285273
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351165&pg=1#3285296

Продолжайте и дальше болтать языком в том же духе.

ЛП
и обещанных тормозов наблюсти не удалось.

Разумеется, откуда ж им взяться, ведь тест на выбор файлов так и не проведен.
25 окт 06, 01:11    [3305302]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить