Выбор сервера, чтобы не тормозило ... / Сравнение СУБД

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

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

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор сервера, чтобы не тормозило ...

163 сообщений из 163, показаны все 7 страниц

все

Выбор сервера, чтобы не тормозило ...

#34062088

Ultrin

Гость

Предложите сервер, для такой базы - в день добавляются примерно 1000000 (лимон) записей типа (индекс, строка(под 10 символов)) да плюс еще картинки эдак так под 50000 (каждая размером под 15 киолбайт). Программа, работающая с этой базой должна быстро получить по индексу картинку и несколко информационных записей. Раз в год планируется все выкидывать и начинать заполнять базу с начала.
Что выбрать
MySQL, PostgreSQL - потянут ли?
MSSQL - очень интересно, глядя на то что можно подцепить еще и DBF которые рядом с базой валяюися, но быстро сможет?
Oracle,DB2 - база ведь простенькая, не будет ли это стрельбой из пушки по воробью

...

Рейтинг:

0 / 0

18.10.2006, 01:10

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34062396

imkot

Участник

Откуда: г. Барнаул, Алтайский край

Сообщения: 525

Рейтинг: 0 / 0

50000 новых картинок в день???

...

Рейтинг:

0 / 0

18.10.2006, 09:48

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34063578

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

СУБД не надо.
Если такая простая структура.

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

18.10.2006, 14:24

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34064721

Ultrin

Гость

Да, где-то 50000 в день :)

База простенькая только в начале - а потом она может и монстром стать :)

При тестовом заливе получается размер базі где-то 1.5 Гина в день...

Так что-же посоветуете? Или ни у кого здесь нет опыта работы с такими базами, а только с Express Edition\ XE все балуются? :((

...

Рейтинг:

0 / 0

18.10.2006, 18:27

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34064794

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

Гыыы...

Из пяти первых топиков в списке тем - аж целых три топика, в которых пытаются использовать СУБД в задачах, для которых использование СУБД не нужно, и даже противопоказано.

Какая-то нездоровая тенденция намечается :)

...

Рейтинг:

0 / 0

18.10.2006, 18:47

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34065378

imkot

Участник

Откуда: г. Барнаул, Алтайский край

Сообщения: 525

Рейтинг: 0 / 0

Это называется поголовная базификация.
Напоминает такие слова как:
- коллективизация,
- всеобуч,
- поднятая целина,
- раз-витый социалисз + электрофикация всей колючей проволоки

...

Рейтинг:

0 / 0

19.10.2006, 07:44

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34065496

Sergey Ch

Участник

Откуда: Благовещенск

Сообщения: 6 775

Рейтинг: 0 / 0

imkot50000 новых картинок в день???
273 Gb в год... MS SQL Server справится без проблем...

...

Рейтинг:

0 / 0

19.10.2006, 09:28

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34065583

Funny_Falcon

Участник

Сообщения: 448

Рейтинг: 0 / 0

Рискну посоветовать таки PostgreSQL. Хотя бы потестьте.

...

Рейтинг:

0 / 0

19.10.2006, 10:11

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34065628

LittleCat

Участник

Откуда: СПб

Сообщения: 350

Рейтинг: 0 / 0

Sergey Ch imkot50000 новых картинок в день???
273 Gb в год... MS SQL Server справится без проблем...
Любая промышленная М-база справится. Если за деньги и на любой (почти) платформе, то Cache, если хочется бесплатно то под Linux GT.M (и такие маленькие картинки можно прям в базе хранить, хотя это, ИМХО, бессмысленно, разве чтобы бороться со всякими ограничениями операционки на количество файлов в одном каталоге)

...

Рейтинг:

0 / 0

19.10.2006, 10:24

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068224

c127

Гость

Возьмите бесплатный ДБ2 и не парьтесь, у него нет ограничения на размер БД. Как раз в этой задаче СУБД будет ИМХО самым простым решением. Размер файлов БД практически не влияет на скорость выбрки, влияет структура БД и что именно вы у нее спрашиваете. Поэтому картинки можно смело хранить в базе. Таблицу с картинками можно положить в отдельный файл, если Вас это беспокоит.

LittleCat Sergey Ch imkot50000 новых картинок в день???
273 Gb в год... MS SQL Server справится без проблем...
Любая промышленная М-база справится. Если за деньги и на любой (почти) платформе, то Cache, если хочется бесплатно то под Linux GT.M (и такие маленькие картинки можно прям в базе хранить, хотя это, ИМХО, бессмысленно, разве чтобы бороться со всякими ограничениями операционки на количество файлов в одном каталоге)
Не пишите чепухи, "всякие ограничения операционки" в таких задачах наступают очень быстро, в вынь2000 начиная с нескольких сотен файлов уже заметно невооруженным глазом, это мы проверили на своем печальном опыте, тоже сложили картинки в файлы. Файлы в каталогах в NTFS не индексируются, если Вы понимаете о чем я. Последующая неизбежная борьба со "всякими ограничениями", типа организации дополнительных подкаталогов, а их тоже не должно быть много, очень неприятна займет кучу времени. Это тоже проверено.

...

Рейтинг:

0 / 0

20.10.2006, 00:46

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068256

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

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

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

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

20.10.2006, 02:02

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068261

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 c127
"всякие ограничения операционки" в таких задачах наступают очень быстро, в вынь2000 начиная с нескольких сотен файлов уже заметно невооруженным глазом
А можно поподробнее - что именно заметно невооруженным глазом?

2 mv
Бррр... Несколько тысяч файлов в одном каталоге - это жесть. Не говоря о прочих неприятностях.
Аналогичный вопрос.
А то вот у меня десять тысяч файлов в каталоге Windows - а я почему-то не наблюдаю тонкого листового железа, покрытого слоем олова :(

...

Рейтинг:

0 / 0

20.10.2006, 02:16

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068262

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

Код: plaintext

1.
2.

% find images -type f | wc -l
   376428

Структура: 1 000 поддиректорий с проектируемым наполнением до 10 000. (реальное на данный момент от 0 до 6 000). Правда, это не винда, а FreeBSD и, соответственно, файловая система UFS2.
"Куча времени", потраченная на борьбу, составляет порядка пары часов (первоначально большое количество файлов не предполагалось).
Хотя, конечно, при большом желании и излишке ресурсов (или при наличии объективных предпосылок, так бывает), можно хранить и в базе.)

...

Рейтинг:

0 / 0

20.10.2006, 02:19

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068267

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

ЛП
А то вот у меня десять тысяч файлов в каталоге Windows

Все в одном каталоге?

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

20.10.2006, 02:31

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068268

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

DocAl
1. Структура: 1 000 поддиректорий ...
2. ...с проектируемым наполнением до 10 000.

Для винды 1 и 2 - пробовали?

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

20.10.2006, 02:33

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068269

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

mv
ЛП
А то вот у меня десять тысяч файлов в каталоге Windows

Все в одном каталоге?

Не, с подкаталогами. А что?
Из этих десяти тысяч файлов примерно две тысячи находится в system32 (это без учета подкаталогов). Две тысячи - оно как бы подходит и под Ваше "несколько тысяч", и под "несколько сотен" с127.
Однако же где покрытое оловом листовое железо, спрашиваю я вас?

...

Рейтинг:

0 / 0

20.10.2006, 02:42

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068273

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

ЛП

В вашем случае все нормально.
Продолжайте, не отвлекайтесь по стронам.

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

20.10.2006, 02:46

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068276

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

20.10.2006, 02:56

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068280

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

Во-первых, в вопросе про винду ничего не было, кроме, разве, упоминания MSSQL. Что, впрочем, не означает, что решение вопроса ограничивается только виндовой платформой.
А во-вторых, по просьбам трудящихся...

...

Рейтинг:

0 / 0

20.10.2006, 03:03

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068281

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

Можно я не буду ждать, пока вся тысяча директорий создастся? Или, всё же, подождать?

...

Рейтинг:

0 / 0

20.10.2006, 03:03

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068300

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

20.10.2006, 05:11

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068305

Di_LIne

Участник

Откуда: Тропик Скорпиона

Сообщения: 48 256

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

20.10.2006, 05:41

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068309

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

9 байт.) Судя по тому, что комп ещё может выдавать, я просто полностью забил allocation units на разделе. Кажется, их количество можно варьировать, зависит от размера кластера. Но не уверен, в администрировании винды не силён.

...

Рейтинг:

0 / 0

20.10.2006, 05:56

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068316

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

Антивирус забавно плющит... У меня Avira Antivir, с зонтиком, так он в трее этим зонтиком теперь хлопает постоянно, то откроет, то закроет...) И буфер обмена не работает. В общем, вполне себе способ создать забавные глюки на компе, причём можно использовать и не системный раздел.)

...

Рейтинг:

0 / 0

20.10.2006, 06:02

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068318

Di_LIne

Участник

Откуда: Тропик Скорпиона

Сообщения: 48 256

Рейтинг: 0 / 0

...

Рейтинг:

0 / 0

20.10.2006, 06:04

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068347

imkot

Участник

Откуда: г. Барнаул, Алтайский край

Сообщения: 525

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

20.10.2006, 07:01

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068364

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

20.10.2006, 07:25

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068371

imkot

Участник

Откуда: г. Барнаул, Алтайский край

Сообщения: 525

Рейтинг: 0 / 0

DocAlТак платформу-то сообщите, может? Под FreeBSD/Linux без проблем и в файлах хранить. Под виндой вот похоже тюнинг файловой системы нужен сначала.
Дык вопрос не я задавал. А вопрошающий по всей видимости пропал после второго своего поста. Видно решил забить на это дело.

...

Рейтинг:

0 / 0

20.10.2006, 07:34

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34068373

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

А... Гм, да, топик вышел интересный.)

...

Рейтинг:

0 / 0

20.10.2006, 07:35

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#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

21.10.2006, 03:02

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071485

Пьяный Лох

Участник

Сообщения: 3 712

Рейтинг: 0 / 0

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

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

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

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

Я исходил из того, что Вы денег платить не хотите
Хех... А это откуда проследовало? (хоть и не ко мне было обращено)

...

Рейтинг:

0 / 0

21.10.2006, 03:16

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071486

c127

Гость

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

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

...

Рейтинг:

0 / 0

21.10.2006, 03:20

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071487

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

21.10.2006, 03:26

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071488

andrey_anonymous

Участник

Откуда: Москва

Сообщения: 18 719

Рейтинг: 0 / 0

DocAlВ Мощные СУБД встроена автокоррекция для битой памяти или отлетевших головок жёсткого диска?
Память - вряд ли, тут вся надежда на железку и контроль CRC блоков (в оракеле по умолчанию отключен), а вот автокоррекция отлетевшего диска таки встроена (Oracle ASM - своеобразный софтварный raid)

...

Рейтинг:

0 / 0

21.10.2006, 03:34

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071490

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

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

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

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

С другой стороны, я не утверждаю, что нет таких ситуаций, когда картинки в базе хранить было бы показано. Например, когда во главу угла ставится разграничение доступа к документам, а не среднее время доступа к каждому из них, плюс хочется аудита доступа к ним, добавьте ещё какой-то паранойи по вкусу -- тогда может быть вполне разумным хранить их в БД. Но тогда вопрос бы ставился, в первую очередь, о безопасности, а не скорости доступа.

...

Рейтинг:

0 / 0

21.10.2006, 03:54

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071491

Пьяный Лох

Участник

Сообщения: 3 712

Рейтинг: 0 / 0

И куда ш оне все деваются....

Я конечно понимаю, что с127 человек могучий, и имеет обыкновение обдумывать ответ в течение суток (ничего против, кстате, оч даж карашо)... но ведь на простейшие вопросы надо отвечать "от зубов" :)

...

Рейтинг:

0 / 0

21.10.2006, 03:55

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071492

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

21.10.2006, 04:02

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071493

andrey_anonymous

Участник

Откуда: Москва

Сообщения: 18 719

Рейтинг: 0 / 0

DocAl andrey_anonymous DocAlВ Мощные СУБД встроена автокоррекция для битой памяти или отлетевших головок жёсткого диска?
Память - вряд ли, тут вся надежда на железку и контроль CRC блоков (в оракеле по умолчанию отключен), а вот автокоррекция отлетевшего диска таки встроена (Oracle ASM - своеобразный софтварный raid)А хардварный не судьба использовать?
?????
Вы спросили "встроено ли?" - я ответил.
При чем тут "судьба"?

...

Рейтинг:

0 / 0

21.10.2006, 04:09

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071497

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

21.10.2006, 04:14

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071507

andrey_anonymous

Участник

Откуда: Москва

Сообщения: 18 719

Рейтинг: 0 / 0

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

Возвращаясь к топику: хранение картинок в БД может иметь смысл не только для разграничения доступа.
Могут играть роль аспекты:
- Надежность: единая система и стратегия резервного копирования, автоматическое восстановление всех данных до последней транзакции.
- Целостность: обеспечение соответствия каталога картинок имеющимся файлам.
- Единый интерфейс поиска и доступа к фалам: упрощается создание приложений, интеграция с иными системами.
- Может оказаться полезным функционал того же Spatial.
- Легкая интеграция с системами Content Management.
- Тут не уверен, но вроде существуют механизмы поиска изображений по содержимому.
- Без проблем организуется доступ по множеству интерфейсов: от FTP и NFS до IMAP, при этом логика доступа программируется.
....
На самом деле это далеко не все - только то, что "само вспомнилось".

...

Рейтинг:

0 / 0

21.10.2006, 04:33

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071514

Пьяный Лох

Участник

Сообщения: 3 712

Рейтинг: 0 / 0

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

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

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

...

Рейтинг:

0 / 0

21.10.2006, 04:51

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071518

andrey_anonymous

Участник

Откуда: Москва

Сообщения: 18 719

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

21.10.2006, 05:12

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071631

imkot

Участник

Откуда: г. Барнаул, Алтайский край

Сообщения: 525

Рейтинг: 0 / 0

Оффтоп.
Читаю и балдею.
Автор топика кажется давно уже пропал, а народ все еще бьется :)
Но все же интересно: победит чье-то мнение или нет.
ЗЫ: дай-то бог не встретиться с такой задачей :)

...

Рейтинг:

0 / 0

21.10.2006, 12:36

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34071962

Пьяный Лох

Участник

Сообщения: 3 712

Рейтинг: 0 / 0

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

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

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

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

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

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

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

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

...

Рейтинг:

0 / 0

21.10.2006, 19:05

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#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

22.10.2006, 06:31

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34072256

c127

Гость

Пьяный Лох

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

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

...

Рейтинг:

0 / 0

22.10.2006, 06:50

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34072488

andrey_anonymous

Участник

Откуда: Москва

Сообщения: 18 719

Рейтинг: 0 / 0

c127используется чужая тулза, которая умеет работать только с файлами.
Просто для информации - полюбопытствуйте про oracle ifs, может оказаться интересно.

...

Рейтинг:

0 / 0

22.10.2006, 16:03

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34072621

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

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

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

22.10.2006, 19:45

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34072748

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

Попробовал: 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

22.10.2006, 23:48

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34072838

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

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

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

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

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

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

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

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

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

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

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

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

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

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

...

Рейтинг:

0 / 0

23.10.2006, 04:43

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34072851

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

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

Как проводивший "эксперимент" отвечаю: не было проделано ничего из вышеупомянутого. Ну просто потому, что тест осуществлялся на коленке на домашней машине и за десять минут, да и предполагалось ловить тормоза, а не ограничения на количество файлов на разделе (благо понятно, что это самое проектируемое количество задаётся при форматировании). Вот вывод chkdsk на состояние ~ соответствующее началу теста.
chkdsk
4096 bytes in each allocation unit.
8110808 total allocation units on disk.
164219 allocation units available on disk.

Размер кластера стандартный, место в MFT зарезервировано не было, собственно, использовался уже порядком подзабитый раздел, где большая часть места в MFT уже была занята. Однако обещаные тормоза вплоть до полного забития MFT обнаружены не были (да, в общем-то и после этого тоже, по крайней мере, фар довольно шустро бегал по этим директориям).

...

Рейтинг:

0 / 0

23.10.2006, 06:17

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34073863

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

23.10.2006, 13:35

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34074301

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

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

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

...

Рейтинг:

0 / 0

23.10.2006, 15:22

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34074434

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

23.10.2006, 15:53

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34074456

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

23.10.2006, 15:56

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34074461

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

23.10.2006, 15:57

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34074570

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

...

Рейтинг:

0 / 0

23.10.2006, 16:20

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34075516

c127

Гость

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

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

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

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

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

ЛП
Уже пытались создать 2 млн файлов, неудачно, а это всего два дня работы системы.
Мы один и тот же топик читаем? Как из 50000 картинок в день Вы смогли получить, что 2 млн - это два дня работы?
Товарищ, 50000 это РАЗМЕР картинки, а картинок - 1 млн в день.
Предложите сервер, для такой базы - в день добавляются примерно 1000000 (лимон) записей типа (индекс, строка(под 10 символов)) да плюс еще картинки эдак так под 50000 (каждая размером под 15 киолбайт) .
/topic/351165&pg=1#3274048

Все, надоело, читайте внимательно и воздастся.

...

Рейтинг:

0 / 0

24.10.2006, 00:34

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34075527

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

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

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

24.10.2006, 00:50

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34075529

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 с127
Линейный рост тормозов - не в сортировке, а в поиске
О как! А совсем недавно говорили, что при открытии (то бишь сопстна к сортировке, я так понимаю):
/topic/351165&pg=2#3291407
"... Заметны тормоза например в открывании каталогов. У меня относительно медленная машина, на быстрых заметно позже. NTFS я упомянул потому что именно там я заметил тормоза, но это не важно, на других обычных ФС будет то же самое. Больше файлов - большие тормоза, причем тормоза растут линейно..."
Слово "открывание" - видно, слова "поиск" - не видно.
Вы уж определитесь, чего там у Вас тормозит, а то вдруг завтра выяснится, что это "тормоза растут линейно" еще к чему-нибудь другому относились, а вовсе не к открытию, не к поиску, не к сортировке, и вообще не к файлам :)

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

Где я говорил об ограничениях ФС на нескольких сотнях файлов? Процитируйте. Я говорил о ТОРМОЗАХ, заметных невооруженным глазом на нескольких сотнях фалов.
Здесь:
/topic/351165&pg=1#3285153
"... Не пишите чепухи, "всякие ограничения операционки" в таких задачах наступают очень быстро, в вынь2000 начиная с нескольких сотен файлов уже заметно невооруженным глазом, это мы проверили на своем печальном опыте, тоже сложили картинки в файлы..."
слово "торможение" не видно невооруженным глазом, в отличие от.

Товарищ, 50000 это РАЗМЕР картинки, а картинок - 1 млн в день.
Чуть ниже Вы даже смогли выделить bold\'ом то, что размер картинки - 15Кб. Но прочитать этого Вы видимо были уже не в состоянии

читайте внимательно
Только после Вас, пжалста

И не надо гнилых отмазок лепить. Ну налажали через слово, ну с кем не бывает :)

...

Рейтинг:

0 / 0

24.10.2006, 00:55

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34075577

c127

Гость

ЛП2 с127
Линейный рост тормозов - не в сортировке, а в поиске
О как! А совсем недавно говорили, что при открытии (то бишь сопстна к сортировке, я так понимаю):
/topic/351165&pg=2#3291407
"... Заметны тормоза например в открывании каталогов. У меня относительно медленная машина, на быстрых заметно позже. NTFS я упомянул потому что именно там я заметил тормоза, но это не важно, на других обычных ФС будет то же самое. Больше файлов - большие тормоза, причем тормоза растут линейно..."
Слово "открывание" - видно, слова "поиск" - не видно.

Не прикидывайтесь дурачком, Вы все прекрасно поняли, когда нужно было, только подзабыли:
ЛП Начали с утверждения, что будут тормоза при поиске , а теперь плавно сползли на то, что якобы оно просто не влезет.
/topic/351165&pg=2#3293405

ЛП
Где я говорил об ограничениях ФС на нескольких сотнях файлов? Процитируйте. Я говорил о ТОРМОЗАХ, заметных невооруженным глазом на нескольких сотнях фалов.
Здесь:
/topic/351165&pg=1#3285153
"... Не пишите чепухи, "всякие ограничения операционки" в таких задачах наступают очень быстро, в вынь2000 начиная с нескольких сотен файлов уже заметно невооруженным глазом, это мы проверили на своем печальном опыте, тоже сложили картинки в файлы..."
слово "торможение" не видно невооруженным глазом, в отличие от.
Внимательно читайте.
Утверждается, что:
1) ограничения наступают очень быстро. Это правда, 2 млн файлов создать не удалось, а это для данной задачи немного.
2) в виндовз начиная с нескольких сотен файлов некоторые эффекты ограничений заметны невооруженным глазом. И это правда, я привел пример с фаром.

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

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

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

Теперь задачу решайте.

...

Рейтинг:

0 / 0

24.10.2006, 03:08

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34075588

c127

Гость

Согласен, ошибся, NTFS как-то индексирует файлы, она сама вроде и есть индекс
http://www.easeus.com/data-recovery-ebook/ntfs-index-record-and-contents.htm
Но по-видимому файлы индексируются криво, поскольку тормоза при поиске наблюдались конкретные, из-за чего у нас и вынуждены были разбить хранилище на поддиректории.

...

Рейтинг:

0 / 0

24.10.2006, 03:56

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34075589

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

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

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

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

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

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

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

Так со мной спорить не нужно, Вы меня убедили, что рост даже не линейный, а хуже (при сортировке)
Вау, так Вы по прежнему считаете, что файловая система ничего не индексирует?
Индексирует, с127, еще как индексирует. Используя те же самые деревья, что и в индексах во многих СУБД. Если эти деревья работают в одном случае с удовлетворительной скоростью, то и в другом они тоже будут работать. И наоборот. По крайней мере я не вижу причин, по которым бы это было не так.

...

Рейтинг:

0 / 0

24.10.2006, 03:59

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34075590

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

ЛПВау, так Вы по прежнему считаете, что файловая система ничего не индексирует?
с127Согласен, ошибся, NTFS как-то индексирует файлы, она сама вроде и есть индекс
Слава яйцам... не прошло и недели...

...

Рейтинг:

0 / 0

24.10.2006, 04:01

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34075591

c127

Гость

ЛП ЛПВау, так Вы по прежнему считаете, что файловая система ничего не индексирует?
с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 записей, да еще с полями? А вдруг потребуется индекс на поле? А главное зачем, если именно для этого весь мир использует СУБД и все работает.

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

...

Рейтинг:

0 / 0

24.10.2006, 04:29

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34075595

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 с127
Печальный опыт с большим числом файлов не только у меня.
Северных варваров много.

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

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

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

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

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

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

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

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

...

Рейтинг:

0 / 0

24.10.2006, 05:06

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34075973

c127

Гость

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

ЛПАга. Только вот у DocAI тормозов не наблюдается,
Конечно не наблюдается, просто система валится, до поиска дело не доходит. Поиск DocAI не проверял, не нужно трындеть что тормозов нет, хотя я предлагал проверить тут
/topic/351165&pg=2#3292545

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

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

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

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

...

Рейтинг:

0 / 0

24.10.2006, 10:10

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34076007

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

Да я и сам, собственно, говорю, что я добавлял неправильно, и ФС не подготовлена была, и размер файлов неадекватный. Просто для адекватного теста у меня не было 300 гигового свободного диска, а отсутствие тормозов показал и мой тест, сделанный в два часа ночи на коленке за 10 минут.
При 2 миллионах файлов тормозов файловой системы _НЕТ_! Может быть, вы расскажете подробно, о каких именно тормозах вы речь ведёте? Всё ж таки, два миллиона файлов при десятке тысяч в каждой из поддиректорий -- это таки никак не меньше "нескольких сотен файлов".

...

Рейтинг:

0 / 0

24.10.2006, 10:18

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34076188

andrey_anonymous

Участник

Откуда: Москва

Сообщения: 18 719

Рейтинг: 0 / 0

DocAlПри 2 миллионах файлов тормозов файловой системы _НЕТ_! Может быть, вы расскажете подробно, о каких именно тормозах вы речь ведёте?
Люди путаются в понятиях со страшной силой.
Тест "тормозов поиска" Far-ом некорректен по определению - это скорее тест процедуры сортировки имен файлов , реализованной в FAR.
Можно заменить на тест производительности перечисления (enumeration), если установить свойство панели FAR "unsorted".
Время же поиска и открытия файла с помощью FAR можно проверить только кнопкой F3 :)

...

Рейтинг:

0 / 0

24.10.2006, 11:03

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34076416

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

В винде нет встроенных утилит, которые позволили бы померять эти "тормоза" объективно. В FreeBSD я измерял время доступа к реальным файлам реального набора изображений, в среднем оно составляло 12мс с незначительными отклонениями.
Для "нескольких сотен файлов" на винде нам грозились "жуткими тормозами", на двух миллионах, разложенных в поддиректории по десять тысяч в каждой, тормоза не обнаружены. Конкретного описания тормозов не указано.

...

Рейтинг:

0 / 0

24.10.2006, 11:55

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34076953

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

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

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

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

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

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

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

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

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

Если все так плохо, как c127 пытается рассказать, то как же винда сама работает, и не покрывается жестью? У неё ж тысячи файлов в каталогах, а вовсе не сотни.
Как поверх этой якобы покрывшейся жестью винды еще и какие-то эскюэль сервера умудряются жить - совсем неясно.

...

Рейтинг:

0 / 0

24.10.2006, 13:47

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34077120

SergSuper

Участник

Откуда: SPb

Сообщения: 5 995

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

24.10.2006, 14:21

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34077131

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

фсе, баюс, баюс

тока не бросай нас ф терновый куст :)

...

Рейтинг:

0 / 0

24.10.2006, 14:23

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34077385

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

Все ясно.
ЛП - сумасшедший.

...

Рейтинг:

0 / 0

24.10.2006, 15:19

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34078675

c127

Гость

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

/topic/351165&pg=1#3285273
/topic/351165&pg=1#3285296

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

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

...

Рейтинг:

0 / 0

25.10.2006, 01:11

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34078679

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 с127
Продолжайте и дальше болтать языком в том же духе.
Товарисч с127, а Вы продолжайте и дальше не замечать уже трижды написанного - обещанных тормозов в Вашем любимом фаре не наблюдалось :))
Ни на "нескольких сотнях файлов" (с) с127, ни на нескольких тысячах не наблюдалось "жести" (с) mv, ни даже на десятках тысяч (с) DocAI.

Разумеется, откуда ж им взяться, ведь тест на выбор файлов так и не проведен.
Кажется Вы тоже молча замолчали вопрос "Какие Ваши цифры", но тем не менее с жизнерадостностью дибила продолжаете утверждать, что "будут тормоза, вах, абасраццо и не жить будут тормоза" :)

...

Рейтинг:

0 / 0

25.10.2006, 01:17

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34078716

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

Кстати, с127, меня почему-то преследует мысль, что Вы просто врёте. Нагло и банально.

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

Согласитесь, Вам показать видные невооруженным глазом тормоза на нескольких сотнях файлов - гораздо проще, чем мне или DocAI продемонстрировать отсутствие тормозов на ста восьмидесяти миллионах файлов.

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

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

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

Чтоб не выглядеть аналогичным Вам звездоболом, решил таки свой винт изнасиловать. Правда у меня места совсем мало, 5 Гб всего свободно (было), поэтому я ограничился миллионом трехкилобайтовых файлов в одной директории.

Тестовые скрипты (запускать из какого-нибудь ворда/экселя/аксеса):

Код: 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.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.

Private Const strRoot = "e:\test\"

Public Function Test()
    Dim lngMaxFiles As Long: lngMaxFiles =  1 
    Dim lngCurrentFileNumber As Long: lngCurrentFileNumber =  1 
    
    Dim tTotalStart As Single, tTotalEnd As Single
    Dim tStepStart As Single, tStepEnd As Single
    
    tTotalStart = Timer
    
    ' создаем кучу файлов
    Dim i As Long: i =  0  ' степени десятки (кол-во файлов)
    For i =  0  To  6 
        Debug.Print "Step " & i +  1 ;
        tStepStart = Timer
        
        While lngCurrentFileNumber <= lngMaxFiles
            Dim strFileName As String
            strFileName = strRoot & Format(lngCurrentFileNumber, "0000000") & ".txt"
            Open strFileName For Output As # 1  ' создаем файл
                Dim j As Long
                For j =  1  To  300  ' записываем в него 3Кб текста
                    Print # 1 , "0123456789";
                Next j
            Close # 1 
            lngCurrentFileNumber = lngCurrentFileNumber +  1 
        Wend
        
        tStepEnd = Timer
        Debug.Print , "Files: ", , lngMaxFiles
        Debug.Print , "Create time (total, sec): ", tStepEnd - tStepStart
        ' проверяем время поиска
        Debug.Print , "Random seek (avg, sec):", TestSeek(lngMaxFiles)
        
        lngMaxFiles = lngMaxFiles *  10 
    Next i
    
    tTotalEnd = Timer
    Debug.Print "========================="
    Debug.Print "Total time:", tTotalEnd - tTotalStart
    Debug.Print "========================="
    Debug.Print "c127 - пяздун"
End Function

Public Function TestSeek(lngMaxFiles As Long) As Single

    Dim tStart As Single, tEnd As Single, tTotal As Single
    
    Dim i As Long
    For i =  1  To  1000 
        Dim strFileName As String
        ' рандомный файл
        strFileName = strRoot & Format(Int(Rnd( 1 ) * lngMaxFiles) +  1 , "0000000") & ".txt"
        
        tStart = Timer
        Open strFileName For Input As # 2  ' Нашли и открыли
            Dim c As Byte
            c = Input( 1 , # 2 ) ' на фсяк случай прочитали аж целый байт
        Close # 2 
        tEnd = Timer
        
        tTotal = tTotal + (tEnd - tStart)
    Next i
    
    TestSeek = tTotal /  1000 
End Function

Результаты:

Код: 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.

Step  1         Files:                        1  
              Create time (total, sec):     0  
              Random seek (avg, sec):       4 ,6875E- 05  
Step  2         Files:                        10  
              Create time (total, sec):     1 ,660156E- 02  
              Random seek (avg, sec):       4 ,6875E- 05  
Step  3         Files:                        100  
              Create time (total, sec):     0 , 046875  
              Random seek (avg, sec):       7 ,8125E- 05  
Step  4         Files:                        1000  
              Create time (total, sec):     0 , 421875  
              Random seek (avg, sec):       4 ,6875E- 05  
Step  5         Files:                        10000  
              Create time (total, sec):     12 , 88965  
              Random seek (avg, sec):       0 , 0000625  
Step  6         Files:                        100000  
              Create time (total, sec):     133 , 6416  
              Random seek (avg, sec):       9 ,202149E- 03  
Step  7         Files:                        1000000  
              Create time (total, sec):     1316 , 548  
              Random seek (avg, sec):       0 , 0381875  
=========================
Total time:     1511 , 251  
=========================
c127 - пяздун

...

Рейтинг:

0 / 0

25.10.2006, 05:15

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34082005

c127

Гость

ЛППосудите сами. Топику уже неделя. За это время можно было сто раз написать простейший тест, который бы показал, что (например) поиск в ста файлах - секунда, поиск в двухстах файлах - две секунды, поиск в трехстах файлах - три секунды, и т.д., и т.п. Ну типа чтобы проиллюстрировать Ваши же слова о том, что дескать тормоза заметны невооруженным глазом, и растут эти тормоза при поиске линейно.
Зачем, в нашей фирме этот тест провели еще в 2000-2001 году, нельзя же постоянно проводить одни и те же тесты, файловая система не поменялась. Выяснили, что тормоза растут быстро, много файлов в такой задаче в одной директории хранить нельзя, я об этом сказал.

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

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

Невооруженным глазом видны тормоза при открывании больших директорий фаром и при поиске из фара и виндовз експлорера, я об этом тоже сказал в явном виде тут
/topic/351165&pg=2#3292545

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

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

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

...

Рейтинг:

0 / 0

26.10.2006, 01:39

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34082019

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 c127
Зачем, в нашей фирме этот тест провели еще в 2000-2001 году
Я Вам не верю. Либо Вы врёте, либо же Вам самому наврали, Вы поверили, и теперь уже других па-децки пытаетесь дезинформировать.
Типа "зуб даю, видел Лох-Несское чудовище в двухтысячном году... линейно растущее... ну не я видел... но с моей фирмы человек видел... ну не видел, а только нюхал... но зуб даю, 220%, говном пахло"

Циферки, с127, циферки в студию. Тем более что "файловая система не поменялась"

Выяснили, что тормоза растут быстро
Опа! Чуть раньше было "линейно". Куда-то Ваша точность высказываний делась :)

много файлов в такой задаче в одной директории хранить нельзя, я об этом сказал.
Ну да, Вы сказали.
Ку.
А DocAI показал, что можно. Я проверил - действительно можно.

Тормоза росли бы линейно в случае отсутствия индексации
Надо же, вчера был День Знаний, теперь день сомнений в собственных силах?
Когда это "бы" появилось в Ваших высказываниях? Раньше было всё гораздо более категорично. Все проверили, не работает, хранить нельзя, не то чтобы искать, не прикидывайтесь дурачком, теста не провели, не болтайте языком, продолжайте болтать языком, и прочие бездарные сопли. У ЧАЛа научились методике ведения споров? Убейте себя ап стену.

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

Но не нужно врать, я нигде не говорил, что линейный рост времени поиска был зафиксирован в эксперименте при поиск или сортировке. Или процитируйте где я это говорил.
Ааа... Так Вы таки вообще экспериментов по замеру тормозов не проводили, даже на глаз, а про линейный рост тормозов при поиске просто так спизднули, для красного словца? (причем спизднули как минимум дважды?) Флаг в руки. Моя оценка Вам - в последней строчке представленных результатов проведенных тестов.

Невооруженным глазом видны тормоза при открывании больших директорий фаром и при поиске из фара и виндовз експлорера, я об этом тоже сказал в явном виде тут
Линейные тормоза? Как Вы упомянули тут, после этого поменяв "поиск" на "сортировку" (или наоборот, я запутался)? Впрочем, неважно, поиск это был или сортировка, ведь Вы уже чуть выше убедили меня в том, что эксперимента не было :)

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

Важно что от этого ничего не меняется
Само собой. Лжец остается лжецом, от каких-либо высказываний в форуме не меняется ровным счетом ничего.

...

Рейтинг:

0 / 0

26.10.2006, 02:26

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34082033

c127

Гость

ЛПЦиферки, с127, циферки в студию.
Никаких проблем, вот они:

Код: plaintext

\nфайлов   время_поиска\n 10000      6 .250000E- 05       \n 100000     9 .202149E- 03     ( 6 .25E- 04  должно быть при линейном росте, замедление в  147  раз вместо  10 )\n 1000000    3 .818750E- 02     ( 6 .25E- 03  должно быть при линейном росте, замедление в  608  раз вместо  100 )\n

http://www.sql.ru/forum/actualthread.aspx?tid=351165&pg=4#3305384

Я ошибся, когда сказал, что результаты другие, виноват, невнимательно посмотрел. Похоже что резульаты ЛП подтверждают мое утверждение о тормозах.

На трех последних точках рост даже хуже чем линейный, что подтверждает, что индексирование если и есть, то очень кривое, как я и говорил тут
/topic/351165&pg=3#3299341
Поправьте если я не прав.

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

ЛПВы - простой лжец. Никогда никаких экспериментов на заданную тему не проводили, не наблюдали ни сами, ни на работе, и воспроизвести результаты не сумеете при всем желании.
Продолжайте в том же духе.

...

Рейтинг:

0 / 0

26.10.2006, 03:30

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34082035

c127

Гость

c127
Причем если я не ошибся с кодом ЛП, файлы ложились последовательно по возрастанию имен, при случайных именах будет еще хуже.
В этой фразе речь идет об абсолютном времени поиска и только если индекс действительно присутствует и используется.

...

Рейтинг:

0 / 0

26.10.2006, 03:35

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34082040

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 с127
с127, ну Вы понимаете, что я еще мышью куда-то кликал в ходе эксперимента? По интернету ползал, диск смотрел, почту читал... Если не понимаете, то просто поверьте

Если что-то из этих операций дало изменение среднего времени поиска на тысячные доли секунды, при небольшом в общем-то количесте тестовых поисков - ну типа я не удивлюсь :)

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

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

Причем если я не ошибся с кодом ЛП, файлы ложились последовательно по возрастанию имен, при случайных именах будет еще хуже.
Хосспадя, да не вопрос. Скрипты все выложены, путем небольших модификаций можете повторить тест для случайной последовательности имён файлов. Типо Ваша очередь. Будет интересно посмотреть, тем более что я с ходу не сильно понимаю - почему при рандомном поиске результат должен быть хуже в случае случайных имен. На времени создания файлов еще как-то может сказаться, на времени поиска - чет не верится.

...

Рейтинг:

0 / 0

26.10.2006, 03:52

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34082046

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

26.10.2006, 04:18

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34082048

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

Ну и на всяк случай еще
Создал 10000 файлов, после чего 50 раз запустил свой TestSeek(10^4)
Получил колебания среднего времени поиска от 9.18Е-05 до 1.0Е-02
Создал 100000 файлов, после чего 50 раз запустил TestSeek(10^4)
Получил колебания среднего времени поиска от 4,313Е-03 до 7.34Е-03

с127, о каких таких "замедлениях в 608 раз" Вы говорите, когда на одном и том же наборе файлов один и тоже же рандомный поиск по среднему времени колеблется вплоть до стократных расхождений?

миллисекунды - это в пределах погрешности измерений. аська запустилась - поиск замедлился, system idle занял 100% проца - поиск убыстрился, MFT закешировалось - совсем быстро стало.

я уж молчу про "на глаз заметно".

...

Рейтинг:

0 / 0

26.10.2006, 04:53

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34082050

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

Создал 100000 файлов, после чего 50 раз запустил TestSeek(10^4)
Пардон, неудачно опечатался, во втором случае 10^5

...

Рейтинг:

0 / 0

26.10.2006, 04:55

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34082614

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

ЛПя ограничился миллионом трехкилобайтовых файловКаждый из которых целиком ложится в один кластер ntfs. Сдаётся мне - они будут целиком лежать в mft. Не показательный тест

...

Рейтинг:

0 / 0

26.10.2006, 11:01

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34083078

Гость

hvlad ЛПя ограничился миллионом трехкилобайтовых файловКаждый из которых целиком ложится в один кластер ntfs. Сдаётся мне - они будут целиком лежать в mft. Не показательный тест
Во-первых,
Ultrinкартинки эдак так под 50000 (каждая размером под 15 киолбайт)
15 кб тоже ложится в один стандартный кластер ntfs. Показательный тест.
Во-вторых, что важнее :), размер размер файла не влияет на скорость его поиска никак.

...

Рейтинг:

0 / 0

26.10.2006, 12:28

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34083136

Гость

да, вышеприведенный тест запускался при включенном индексировании, кстати?

...

Рейтинг:

0 / 0

26.10.2006, 12:38

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34083718

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

ы15 кб тоже ложится в один стандартный кластер ntfs. Показательный тест.
Во-вторых, что важнее :), размер размер файла не влияет на скорость его поиска никак.а) стандартный кластер (тот, который по-умолчанию для раздела указанного размера), таки 4К
б) кому нужно просто искать файлы, тот один раз распечатывает вывод команды dir :) файлы обычно читают, после того как находят, так что р-р файла будет иметь значение
в) посмотрите как сама MS работает с большим кол-вом файлов - на примере файлового устройства кеша IE

...

Рейтинг:

0 / 0

26.10.2006, 14:21

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34083826

Гость

hvlad
a) таки да. Беру свои слова обратно
б) в данном случае речь идет о скорости поиска. Для того чтобы найти файл по имени, не нужно читать содержимое ни его самого, ни его соседей
в) а что я должын там увидеть?

...

Рейтинг:

0 / 0

26.10.2006, 14:40

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34084510

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

26.10.2006, 16:51

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34084664

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 hvlad
ЛПя ограничился миллионом трехкилобайтовых файловКаждый из которых целиком ложится в один кластер ntfs.
Ну да, ложаться в кластер. Проводился бы эксперимент более близкий к реальным условиям (т.е. 180 млн 15-тикилобайтных файлов) - я бы порекомендовал кластер до 16Кб увеличить, дабы оно опять таки в кластер влезло. Оно не критично, но поприятнее жить будет.

Сдаётся мне - они будут целиком лежать в mft.
Я по-моему уже говорил, что целиком в MFT ложаться файлы с характерным размером в сотню байт (и меньше). Т.е. в тесте DocAI они таки в MFT лежали, в моём - нет.

в) уж никак не один каталог с тысячами файлов
Еще раз - откройте каталог Windows\system32
Увидьте там тысячи файлов.
Прекратите пугать людей сотнями и тысячами файлов :). Не те это цифры.

это о чём-то говорит, не так ли ?
О чем? Может о том, что поиск по небольшой директории выполняется быстрее, чем поиск по большой? Но с этим никто и не спорит.

2 ы
да, вышеприведенный тест запускался при включенном индексировании, кстати?
Хрен его знает :)
Я по примеру DocAI играл в северного варвара, ничего нигде не настраивал и не менял. Вряд ли индексация содержимого файлов была включена, но зуб не дам. Вечером смогу сказать.

...

Рейтинг:

0 / 0

26.10.2006, 17:26

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34084821

Гость

hvladб) в реальной прикладной задаче речь шла о хранении картинок в блобах\файлах. просто искать эти картинки без их чтения бессмысленно в данном контексте :)
в) уж никак не один каталог с тысячами файлов - это о чём-то говорит, не так ли ?
б) может мы о разных вещах говорим? Я прочитал вопрос так: "программа ... должна быстро получить по индексу (имени) <одну> картинку". Для поиска одной картинки по имени не важен ни ее размер, ни размер других картинок, лежащих рядом с ней в каталоге (или в базе). Причем это равно справедливо и для fat, и для ntfs. Правда, со второй системой я знаком поверхностно :( (надо исправиться), но список файлов в папке, насколько я помню, там хранится почти так же, как и в первой.

в) кстати, в опере кэш живет в одной папке. Это о чем-то говорит? За неделю жизни свежеустановленной системы у меня там накопилось 13'000 файлов. Опера как работала, так и работает. И будет работать еще с полгода, до следующей переустановки виндовса.

Не нужно ссылаться на корявую работу с миллионом файлов в одной папке программ, которые для такой работы не предназначены. Это не вам, это про far и Co. Еще бы пузырьком список файлов сортировать начали (с) не мой :)

...

Рейтинг:

0 / 0

26.10.2006, 17:59

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34085559

c127

Гость

ЛП
с127, ну Вы понимаете, что я еще мышью куда-то кликал в ходе эксперимента? По интернету ползал, диск смотрел, почту читал... Если не понимаете, то просто поверьте

Если что-то из этих операций дало изменение среднего времени поиска на тысячные доли секунды, при небольшом в общем-то количесте тестовых поисков - ну типа я не удивлюсь :)

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

Не пубилкуйте таких результатов, или думайте до публикации результатов, а не после, не нужно будет выкручиваться, рассказывя о чтении почты. Если Вы проведете аналогичный эксперимент с поиском на РСУБД при нормальной индексации, то скорее всего увидите, что никакого 600 кратного замедления при переходе от 10000 к 1000000 записей не наблюдается, даже если в это время немного покликать мышкой. При B-tree индексе замедление должно быть где-то в районе 2, но зависит от индекса. Даже если индекса нет то будет примерно 100 кратное замедление, а у Вас 600. Быстро кликали мышкой наверное.

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

ЛП
Кстате, с127, а почему вы не обратили внимание на нулевой (и даже на одном из шагов отрицательный) прирост времени поиска на тех самых пресловутых сотнях файлов (вплоть до тысячи)?
Обратил. Но потом прочитал Вашу фразу:
ЛП> миллисекунды - это в пределах погрешности измерений.
http://www.sql.ru/forum/actualthread.aspx?tid=351165&pg=4#3311801
и решил что обсуждать величины, которые по словам самого автора эксперимента с большим запасом в пределах погрешности измерений, бессмысленно.

О видимом на глаз приросте времени поиска на сотнях файлов начали говорить Вы, я такого не говорил. Ну если очень хотите, то считайте что я тоже в это время еще и "По интернету ползал, диск смотрел, почту читал..." ((С) ЛП).

А вот как это выглядит на графике, горизонтальная ось в логарифмическом масштабе по основанию 10. B-tree индекс, который якобы используется в NTFS, дает логарифмическое время поиска, поэтому график должен был бы быть близким к прямой. Но что вышло то вышло.

...

Рейтинг:

0 / 0

27.10.2006, 01:58

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34085604

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 c127
Непонятно зачем публиковать данные эксперимента, а потом на следующий день самому же на протяжении трех постов доказывать что он некорректен.

Следующий день - это сегодня, с127. Если у Вас проблемы с восприятием времени, то сходите к доктору :)

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

Характер зависимости времени поиска от кол-ва файлов я не особо старался определить, и с этой точки зрения готов признать, что эксперимент совсем не корректен. Но уж тем более я не предполагал, что по шести точкам с погрешностью плюс-минус десять тысяч процентов кто-то попробует графики рисовать :). Если бы старался или предполагал, то провел бы немножно другой эксперимент, по-крайней мере с бОльшим количеством точек, и соответственно меньшим шагом.

Кстате, вот результаты (время поиска, кол-во файлов):

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.

 4 ,69E- 05 	 1 
 4 ,79E- 05 	 2 
 6 ,15E- 05 	 4 
 6 ,35E- 05 	 8 
 2 ,93E- 05 	 16 
 4 ,88E- 05 	 32 
 6 ,15E- 05 	 64 
 4 ,69E- 05 	 128 
 4 ,69E- 05 	 256 
 6 ,15E- 05 	 512 
 4 ,69E- 05 	 1024 
 7 ,81E- 05 	 2048 
 6 ,35E- 05 	 4096 
 6 ,15E- 05 	 8192 
 6 ,35E- 05 	 16384 
 1 ,25E- 04 	 32768 
 7 ,91E- 05 	 65536 
 7 ,81E- 05 	 131072 
 0 , 0000625 	 262144 
 5 ,09E- 03 	 524288 
 1 ,16E- 02 	 1048576

Тест практически такой же, только открытие файла и чтение из него одного байта я убрал, оставив сопстна его поиск. Т.е. в процедуре TestSeek теперь такой кусок кода:

Код: plaintext

1.
2.

        tStart = Timer
            Dir strFileName
        tEnd = Timer

Ну и основная тестовая процедура по степеням двойки идет, а не по степеням десятки.

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

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

ЛП
Кстате, с127, а почему вы не обратили внимание на нулевой (и даже на одном из шагов отрицательный) прирост времени поиска на тех самых пресловутых сотнях файлов (вплоть до тысячи)?
Обратил. Но потом прочитал Вашу фразу:
Хммм... вообще-то Вы сначала опубликовали свои выводы, а уже потом последовала моя фраза, которую вы могли прочитать. Сопстна вопрос - Вы сначала обратили внимание, потом опубликовали свои результаты, и уже потом прочитали мою фразу, или же сначала опубликовали свои результаты, потом обратили внимание, и уже потом прочитали мою фразу?

Если сначала опубликовали, потом обратили, потом прочитали, то значит не обратили внимание раньше (до того, как опубликовали). И, стало быть, таки обладаете умением замечать лишь то, что Вам хочеццо замечать.

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

Как не крути, а в итоге Вы по уши в говне :).

...

Рейтинг:

0 / 0

27.10.2006, 04:15

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34085615

ChA

Участник

Откуда: Москва

Сообщения: 10 913

Рейтинг: 0 / 0

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

P.S. Впрочем, дело, разумеется, Ваше, это было всего лишь мнение стороннего наблюдателя.

...

Рейтинг:

0 / 0

27.10.2006, 06:07

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34085619

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

дык ведь и я про то же

впрочем, уже пишу новые данные для красявыхх графикофф с127 :)

...

Рейтинг:

0 / 0

27.10.2006, 06:12

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34085992

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

Если несложно, график опубликуйте в .gif или .png, jpeg для этого не очень подходит.( Заранее спасибо.)

...

Рейтинг:

0 / 0

27.10.2006, 10:30

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34087605

Гость

Приходится признать, что в споре c127 и ЛП победил с127.
См. график

...

Рейтинг:

0 / 0

27.10.2006, 16:08

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34087675

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

Приходится признать, что в споре c127 и ЛП победил с127.
Да что Вы говорите

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

Могу выложить результат того же самого, но с 1000 замеров.

...

Рейтинг:

0 / 0

27.10.2006, 16:27

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34087852

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

Все же файловую систему для хранения неструктурированных файлов (картинок и
проч безобразия) очень даже удобно.
Аргументы: если используется какая-нибудь убогая СУБД (например, VFP или
Access) - то не нужно переучиваться.

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

27.10.2006, 17:21

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34087994

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

mv
Все же файловую систему для хранения неструктурированных файлов (картинок и
проч безобразия) очень даже удобно.
Аргументы: если используется какая-нибудь убогая СУБД (например, VFP или
Access) - то не нужно переучиваться.

К сожалению, использующие "убогие СУБД" - тоже умудряются хранить картинки в базе (не в таких объемах, конечно же).

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

...

Рейтинг:

0 / 0

27.10.2006, 18:16

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088034

andrey_anonymous

Участник

Откуда: Москва

Сообщения: 18 719

Рейтинг: 0 / 0

ЛПА потом возникают топики типа "а как бы мне картинки, хранящиеся в базе, однотипно обработать?". Тривиальные ответы типа "пакетно прогони всю директорию через фотошоповский фильтр" очевидно не подходят, не умеет фотошоп картинки из базы доставать.
Справедливости ради следует отметить, что некоторые СУБД умеют предоставлять доступ к хранимым файлам по ftp, http, nfs, smb и т.д., что позволяет обработать их обычным для файлов способом.

...

Рейтинг:

0 / 0

27.10.2006, 18:31

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088064

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

27.10.2006, 18:40

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088118

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

andrey_anonymous
Справедливости ради следует отметить, что некоторые СУБД умеют предоставлять доступ к хранимым файлам по ftp, http, nfs, smb и т.д., что позволяет обработать их обычным для файлов способом.
Вот это и называется, преодолевать трудности, не взирая...

Что интересно, файловая система также умеет предоставлять доступ к хранимым файлам по ftp, http, nfs, smb и т.д., либо встроенными средствами ОС, либо распространёнными дополнительными сервисами.

...

Рейтинг:

0 / 0

27.10.2006, 19:06

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088265

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

ЛП
....
А потом возникают топики типа "а как бы мне картинки, хранящиеся в базе,
однотипно обработать?". Тривиальные ответы типа "пакетно прогони всю
директорию через фотошоповский фильтр" очевидно не подходят, не умеет
фотошоп картинки из базы доставать.

Ваши слова вызывают только жалость.

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

27.10.2006, 21:47

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088312

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

mvВаши слова вызывают только жалость.
Здоровое "бу-га-га" будет ответом Вам

...

Рейтинг:

0 / 0

27.10.2006, 22:48

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088373

c127

Гость

ЛП
Ну и что изменилось в Вашем последнем эксперименте по сравнению с предыдущим? Тормоза как были так и остались, причем тормоза ну очень большие. Я Вам об этом и говорил, а Вы не верили. График сами нарисовали без меня, в сравнении с предыдущим ничего существенно не изменилось, могу повторить если хотите.

ЛП
Вам так нравится рисовать графики по чужим данным? Сделайте одолжение, нарисуйте еще один :)
Проблема сразу очень хорошо обрисовывается, что в общем-то и не удивительно. Как с этой проблемой побороться я уже говорил - перенастроить MFT на большее кол-во файлов. Ну и мышкой не кликать, разумеется :).
Так проблема обрисовалась уже в предыдущем эксперименте, и проблема эта в тормозах. Как с ней бороться это все Ваши теоретизирования, может сработать, может нет.

И на основной ворос вразумительного ответа так и нет: а зачем вообще с чем-то бороться, если есть нормальное решение на базе РСУБД. Отмазка что "Например на тот хрен, что NTFS у меня есть, и кушать не просит, а вот DB2 у меня нету, " ( /topic/351165&pg=3#3301876 ) не проходят. Как выяснилась NTFS есть, да не совсем та, что нужно, чтоб стала та нужно MFT перенастроить и еще что-то там подкрутить, но всего этого ЛП делать не хочет, поскольку это очень проблемно. Правильно, проблемно, как говорит DocAl:"Вот это и называется, преодолевать трудности, не взирая..."

Так по-моему бесплатную ДБ2, постгре или МуСКЛ скачать легче или же взять МССКЛ, оракл или что-то другое коммерческое, если они уже есть в фирме.

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

Читаем следующие последовательные посты:
с127Не пишите чепухи, "всякие ограничения операционки" в таких задачах наступают очень быстро, в вынь2000 начиная с нескольких сотен файлов уже заметно невооруженным глазом, это мы проверили на своем печальном опыте, тоже сложили картинки в файлы. Файлы в каталогах в NTFS не индексируются, если Вы понимаете о чем я. Последующая неизбежная борьба со "всякими ограничениями", типа организации дополнительных подкаталогов, а их тоже не должно быть много, очень неприятна займет кучу времени. Это тоже проверено.
/topic/351165&pg=1#3285153
По видимому сформулировано не очень понятно, поэтому ЛП уточняет:
ЛПА можно поподробнее - что именно заметно невооруженным глазом ?
/topic/351165&pg=1#3285215
Я отвечаю совершенно однозначно:
с127
Заметны тормоза например в открывании каталогов . У меня относительно медленная машина, на быстрых заметно позже. NTFS я упомянул потому что именно там я заметил тормоза, но это не важно, на других обычных ФС будет то же самое. Больше файлов - большие тормоза, причем тормоза растут линейно.
/topic/351165&pg=2#3291407
Тормоза заметны невооруженным глазом при открывании каталогов, смотрим выделенный текст. Ясно что то, что рост линейный, на глаз определить невозможно, это уже будет не "на глаз". Линейный рост тормозов это я ошибся, я уже признал что думал что файлы не индексируются ( /topic/351165&pg=3#3299341 ). Как видно я не утверждал, что наблюдал линейное замедление невооруженным глазом в нескольких сотнях файлов, как мне приписывает ЛП. Хота на практике оказалось что замедление получается даже большее, чем без индекса.
Едем дальше.
Пьяный ЛохЫть пардон - что такое "открывание каталогов"?
Чем открывание?
Консервным ключом, али виндоуз експлорером? И даже если там проблемы - не проблемы ли это консервного ключа?
Давайте фсе-таке уточнять, а?
/topic/351165&pg=2#3291415
Возможно что "Пьяный Лох"!=ЛП, но я пока предполагаю, что это одно и то же. Тут видно, что ЛП сначала прекрасно понимал о чем идет речь, спрашивает не о поиске на нескольких сотнях файлов, а об открывании каталогов. Это теперь он корчит дурочку.
с127Фаром. Поиск фаровский и виндовзный тоже явно тормозят, когда натыкаются на большую диреркторию.
/topic/351165&pg=2#3292545
Фар действительно тормозит, это видно, линейно или нет не знаю, кто же такие вещи на глаз определяет.

Ну и где я был не прав? Только с индексом ошибся, но давно это признал. Но на деле ситуация с поиском оказала даже гораздо хуже чем я ожидал. Тормоза есть, я их видел в наших экспериментах в 2000-2001 году, ЛП это подтвердил своими экспериментами, причем заявив при этом: "Никогда никаких экспериментов на заданную тему не проводили, не наблюдали ни сами, ни на работе, и воспроизвести результаты не сумеете при всем желании. ". ( /topic/351165&pg=4#3311754 ) Весь ЛП такой противоречивый, угловатый весь (C), сам все получил и сам же сказал что получить это невозможно.

В результате подтвердили, что много файлов в одной директории хранить и искать практически нельзя, а 1 млн по постановке задачи это немного, там требуется как минимум 18 млн. Все правильно, все что я говорил с самого начала по сути дела - подтвердилось. 18 млн файлов в одном каталоге NTFS с поискам по ним это явный признак проблем с головой у архитектора системы.

...

Рейтинг:

0 / 0

28.10.2006, 00:10

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088391

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

читал с конца...

"... В результате подтвердили, что много файлов в одной директории хранить и искать практически нельзя..."

все, это уже даже не смешно.
SQL бесполезен для доступа к данным.
Каждый, кого укусит ЧАЛ - становится ЧАЛом. Даже с127.

Зобаньте меня нах...

...

Рейтинг:

0 / 0

28.10.2006, 00:54

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088397

Гость

ух ты. 50000 картинок в день по 15 кб = 18 млн картинок в год, которые нельзя хранить в папке, а надо хранить в базе. А что, "бесплатные ДБ2, постгре или МуСКЛ" умеют работать с базами 250 Гб (гигабайт) размером? Или одна сотая секунды на поиск файла - это настолько катастрофически много, что есть причина для спора?

...

Рейтинг:

0 / 0

28.10.2006, 00:58

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088398

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

ыА что, "бесплатные ДБ2, постгре или МуСКЛ" умеют работать с базами 250 Гб (гигабайт) размером?
Бесплатная ДБ2 умеет.
Остальные тоже умеют, но лучше не стоит (как говорят сами поклонники).

Или одна сотая секунды на поиск файла - это настолько катастрофически много, что есть причина для спора?
Много или не много - непонятно, это одному автору топика известно, но вот от поклонников ДБ2 пока не было продемонстрированно и таких результатов.

...

Рейтинг:

0 / 0

28.10.2006, 01:04

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088401

Гость

ну если умеет, тогда результаты определенно должны быть лучше.

...

Рейтинг:

0 / 0

28.10.2006, 01:10

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088402

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

ыну если умеет, тогда результаты определенно должны быть лучше.
Откуда следует?
Ты на ДБ2 сумеешь получить 10^-5 секунды на поисковый запрос по полумиллиону записей, например?

...

Рейтинг:

0 / 0

28.10.2006, 01:16

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088411

Гость

при наличии индекса я это в акцессе сумею получить (не тестировал, а то вдруг 10^-4 получится, и я вроде как наврал тогда:)

...

Рейтинг:

0 / 0

28.10.2006, 01:28

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088413

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

ыпри наличии индекса я это в акцессе сумею получить (не тестировал, а то вдруг 10^-4 получится, и я вроде как наврал тогда:)
а ыть ты получи, не стесняйся

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

...

Рейтинг:

0 / 0

28.10.2006, 01:30

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088436

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

уххх...
решил диапазон от полумиллиона до миллиона файлов проверить

ужоснах
совсем ужос нах
такого даже я не могу объяснить.

единственное отличие от всех предыдущих тестов - перед выполнением этого я ненароком в коде ошибся, и забил таки диск до состояния "Disk full", потом все удалил и перезапустил с начала. на что это могло повлиять - хер знает :)

Шкала линейная по обоим осям, по оси Х - от 500000 до 1000000 файлов с шагом 500.

...

Рейтинг:

0 / 0

28.10.2006, 03:28

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088532

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

2ЛП, неплохо бы указывать единицы измерения на осях.
Я, конечно, понимаю, что по иксу тысячи файлов, а по игреку время в секундах, но, раз с127 так упорно твердит о тормозах, видимо, он в них видит что-то другое.)

...

Рейтинг:

0 / 0

28.10.2006, 11:59

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088790

Пьяный Лох

Участник

Сообщения: 3 712

Рейтинг: 0 / 0

DocAlЯ, конечно, понимаю, что по иксу тысячи файлов, а по игреку время в секундах
Не совсем так. По иску - номер шага. Шли от 500000 файлов до 1000000 с шагом 500.

...

Рейтинг:

0 / 0

28.10.2006, 19:36

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088929

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

Ну вы ещё подеритесь, горячие финские парни...

2с127: а какие аргументы-то вам нужны? Мы можете показать тормоза, измеряющиеся не сотыми долями секунды? Пока сколько ни пытались, такие тормоза не обнаружили. А сотые доли секунды -- они не то что в пределах -- пренебрежимо малы по сравнению с погрешностью измерений.

...

Рейтинг:

0 / 0

28.10.2006, 23:18

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34088937

ChA

Участник

Откуда: Москва

Сообщения: 10 913

Рейтинг: 0 / 0

DocAlНу вы ещё подеритесь, горячие финские парни..."Звездные войны: Войны клонов"

...

Рейтинг:

0 / 0

28.10.2006, 23:35

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34089037

c127

Гость

ыух ты. 50000 картинок в день по 15 кб = 18 млн картинок в год, которые нельзя хранить в папке, а надо хранить в базе. А что, "бесплатные ДБ2, постгре или МуСКЛ" умеют работать с базами 250 Гб (гигабайт) размером? Или одна сотая секунды на поиск файла - это настолько катастрофически много, что есть причина для спора?
Одна сотая может быть мало или много в зависимости от задачи. Автор топика не уточнил сколько ему надо, сказал только чтобы "быстро".

Но были абсолютно однозначно обнаружены следующие серьезные проблемы.
1) Виндовз не смог добавить 2 млн файлов в одну директорию.
/topic/351165&pg=1#3285273
Правда сказали что файлы неправильные. Что будет на требуемых по ТЗ 18 млн никто не знает.
2) Тенденция замедления. При возрастании числа файлов с 10000 до 1 млн время поиска увеличилось в 600 раз.
/topic/351165&pg=4#3305384
/topic/351165&pg=4#3311780
Говорят если поплясать с бубном вокруг компьютера тоже можно подправить, но наверняка опять же никто не знает.

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

DocAl2с127: а какие аргументы-то вам нужны? Мы можете показать тормоза, измеряющиеся не сотыми долями секунды?
Откуда Вы можете знать, что сотые доли это мало? Если от системы требуется выполнять 200 запросов в секунду, то сотые это много. Сколько нужно мы не знаем.

Важна тенденция, посмотрите на графики, куда они лезут и с какой сокростью. Отставание от самого плохого моего прогноза в 6 раз. Я сказал, что будет существенное замедление, Вы его имеете. Смотрите графики. Замедление в 600 раз это много, если теоретически при наличии индекса должно быть в районе 2-3, и даже без индекса, как я думал в начале, должно быть 100.

DocAlПока сколько ни пытались, такие тормоза не обнаружили.
Сказать "я ничего не вижу" можно в любой ситуации.

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

...

Рейтинг:

0 / 0

29.10.2006, 02:33

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34089065

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

эхххх... ну до чего ж все-таки весело... так и стоят перед глазами "беседы с ЧАЛом"
- В РСУБД невозможно получить первую запись!
- Как это невозможно? Вот вам селект топ один
...
- Как уже неоднократно было показано, в РСУБД невозможно получить первую запись.

Пока с127 рассказывал детские страшилки про то, что много файлов в одной директории хранить нельзя, DocAI взял да и положил два миллиона файлов в одну директорию. И вот на тебе, "Но были абсолютно однозначно обнаружены следующие серьезные проблемы. 1) Виндовз не смог добавить 2 млн файлов в одну директорию."

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

Одна сотая может быть мало или много в зависимости от задачи. Автор топика не уточнил сколько ему надо, сказал только чтобы "быстро".
...
Откуда Вы можете знать, что сотые доли это мало? Если от системы требуется выполнять 200 запросов в секунду, то сотые это много. Сколько нужно мы не знаем.
Ога, ога. Много или мало - мы не знаем, насколько нужно быстро - снова не знаем, сколько будет - опять таки не знаем, и это все незнание ничуть не мешает с127 с жизнерадостной улыбкой продолжать говорить про то, что будут тормоза.

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

c127Но я думаю, что Вы ошибаетесь насчет погрешности. Как Вы определяете погрешность расскажите пожалуйста.
с127, на протяжении этого топика ошибаетесь исключительно Вы. К сожалению, DocAI не ошибся насчет погрешности измерений. Как случайно выяснилось при совместном с ы разборе полётов, используемая ф-ция Timer возращает время с точностью до сотых долей секунды (а под макинтошем так и вообще с точностью до целой секунды). Так что получается, что измерялось лишь то, сколько раз (из контрольной тысячи замеров) время поиска по каким-либо причинам превысило одну сотую секунды.

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

...

Рейтинг:

0 / 0

29.10.2006, 07:08

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34089905

c127

Гость

ЛП
Пока с127 рассказывал детские страшилки про то, что много файлов в одной директории хранить нельзя, DocAI взял да и положил два миллиона файлов в одну директорию. И вот на тебе, "Но были абсолютно однозначно обнаружены следующие серьезные проблемы. 1) Виндовз не смог добавить 2 млн файлов в одну директорию."

А вот как это было на самом деле:
DocAlОбновление: я таки решил дождаться, и где-то в районе 2 000 000 файлов винда дошла до состояния практически полного нестояния и сказала "кря". Предложила запустить chkdsk.exe, но запустить не смогла, т.к. не смогла открыть необходимые библиотеки. Причём ни создать новый файл, ни открыть старый стало невозможно.
.....
Антивирус забавно плющит... У меня Avira Antivir, с зонтиком, так он в трее этим зонтиком теперь хлопает постоянно, то откроет, то закроет...) И буфер обмена не работает. В общем, вполне себе способ создать забавные глюки на компе, причём можно использовать и не системный раздел.)
/topic/351165&pg=1#3285273
/topic/351165&pg=1#3285296

Хотя конечно может оказаться что для кого-то это норма, как говорится кому и кобыла невеста. (С)

...

Рейтинг:

0 / 0

30.10.2006, 05:22

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34089936

aZm

Участник

Откуда: 3й рим

Сообщения: 2 227

Рейтинг: 0 / 0

вот жеж комуто делать некуй))))

мои 5 копеек флуда:
если картинка существует как "вещь в себе", без дополнительных характеристик и атрибутов, и доступ можно организовать просто по имени/каталогу - субд в принципе особо не нужна. если же у картинки есть какие то дополнительные характеристики, не исчерпывающиеся именем, то - тут уже прямая дорога в субд)

...

Рейтинг:

0 / 0

30.10.2006, 07:30

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34090033

c127

Гость

aZmвот жеж комуто делать некуй))))

мои 5 копеек флуда:
если картинка существует как "вещь в себе", без дополнительных характеристик и атрибутов, и доступ можно организовать просто по имени/каталогу - субд в принципе особо не нужна. если же у картинки есть какие то дополнительные характеристики, не исчерпывающиеся именем, то - тут уже прямая дорога в субд)
Да есть там атрибуты, даже хуже, записи в точно неизвестном количестве, примерно по 20 штук на картинку:
"в день добавляются примерно 1000000 (лимон) записей типа (индекс, строка(под 10 символов)) да плюс еще картинки эдак так под 50000 (каждая размером под 15 киолбайт)."
/topic/351165&pg=1#3274048

ЛП как партизан молчит, не колется как он собирается все это складывать в файловую систему. Можно конечно придумать как и этот миллион записей в день сложить в файловую систему, в процессе складывания упорно плясать с бубном возле компьютера и в результате это все может быть (но не наверняка) со скрипом и проблемами заработает. Но зачем, если проще использовать СУБД. На этот вопрос ЛП тоже упорно не отвечает.

...

Рейтинг:

0 / 0

30.10.2006, 09:10

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34091159

ё1234

Гость

ЛП К сожалению, DocAI не ошибся насчет погрешности измерений. Как случайно выяснилось при совместном с ы разборе полётов, используемая ф-ция Timer возращает время с точностью до сотых долей секунды (а под макинтошем так и вообще с точностью до целой секунды). Так что получается, что измерялось лишь то, сколько раз (из контрольной тысячи замеров) время поиска по каким-либо причинам превысило одну сотую секунды."проблема" с толчностью таймера лихко решаицца. Увеличением числа поисков внутри диапазона замеров. К сожалению, результат неутешителен для ЛП :)

(количество замеров 10000, файлы по 10 байт (на прошлой недели прогонял с 9-ти килобайтными, но с 1000 замеров - картина та же. но лома загаживать диск)

Код: 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.

Step 1        Files:                       1 
              Create time (total, sec):    0.015625 
              Random seek (avg, sec):      0.000075 
Step 2        Files:                       10 
              Create time (total, sec):    0 
              Random seek (avg, sec):      7.65625E-05 
Step 3        Files:                       100 
              Create time (total, sec):    0.03125 
              Random seek (avg, sec):      0.00008125 
Step 4        Files:                       1000 
              Create time (total, sec):    0.40625 
              Random seek (avg, sec):      0.00008125 
Step 5        Files:                       10000 
              Create time (total, sec):    5.625 
              Random seek (avg, sec):      0.0001 
Step 6        Files:                       100000 
              Create time (total, sec):    87.78125 
              Random seek (avg, sec):      0.00900625 
Step 7        Files:                       1000000 
              Create time (total, sec):    618.9375 
              Random seek (avg, sec):      0.02238594 
=========================
Total time:    1031.703 
=========================

(нолик приписал руками, - поскоку забыл поделить на 10000:)

Резюма (имхо) - способ индексации файлов в нтфс устроен как-то кривоватисто. например можно предполагать какие-нто хеш таблички с "малым" размером (полагаю - ~64к). при выходе за n*10**4 файлов время поиска начинает расти по другому закону (с другим основанием, даже если энто остаецца логарифмом).
Можно проверить еще и с автоматическим созданием поддиректорий емкостью n*10**4. могабыть спасет.

...

Рейтинг:

0 / 0

30.10.2006, 14:05

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34091550

ChA

Участник

Откуда: Москва

Сообщения: 10 913

Рейтинг: 0 / 0

Кто-нибудь серьезно изучал, тестировал или пользовал Indexing Service в Windows ? Результаты, выводы ?

...

Рейтинг:

0 / 0

30.10.2006, 15:27

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34091860

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 aZm
если картинка существует как "вещь в себе", без дополнительных характеристик и атрибутов, и доступ можно организовать просто по имени/каталогу - субд в принципе особо не нужна. если же у картинки есть какие то дополнительные характеристики, не исчерпывающиеся именем, то - тут уже прямая дорога в субд)
Блин, ну еще раз говорю - если у картинки есть какие-то дополнительные атрибуты, то и положите их в дополнительные атрибуты файла. NTFS позволяет сколько угодно каких угодно атрибутов у файла держать. Хотите - в отдельные потоки все сложите, если так удобнее будет, NTFS это тоже позволяет. Чего тут непонятного может быть? Ну ладно с127, он индексацию почти неделю искал...

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

2 с127
А вот как это было на самом деле:
А вот как было на самом деле:
Иван Иванович Иванов скончался в возрасте восьмидесяти лет.
Вопрос - сколько лет было Ивану Ивановичу в тот момент, когда он скончался?

Как только на этот вопрос сумеете ответить, так сразу и приступайте к ответу на вопрос - сколько файлов было в каталоге, если "где-то в районе 2 000 000 файлов винда сказала кря".

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

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

количество замеров 10000, файлы по 10 байт
Ну говорилось же уже, что файлы по 10 байт - плохо моделируют нагрузку...
Даже если результаты похожие - совсем другое меряется.

например можно предполагать какие-нто хеш таблички с "малым" размером (полагаю - ~64к). при выходе за n*10**4 файлов время поиска начинает расти по другому закону (с другим основанием, даже если энто остаецца логарифмом).
Да я как-то и не против ни хеш-табличек, ни логарифмов с другим основанием.
Только давайте все-таки по трем точкам не будем строить логарифмы, а?
а по тясячи точкам от 500000 до 1000000 файлов у меня почему-то получился совсем не логарифмический рост, а очень даже резкое уменьшение, и этот факт любители строить графики почему-то обходят стороной

И, в конце то концов, если уж беретесь рассуждать о немерянных миллионах файлов - таки научитесь резервировать место под MFT (она по умолчанию под небольшое кол-во файлов расчитана).
(последний абзац не к ё1234, а абстракно в воздух)

...

Рейтинг:

0 / 0

30.10.2006, 16:31

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34091933

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

ChAКто-нибудь серьезно изучал, тестировал или пользовал Indexing Service в Windows ? Результаты, выводы ?
Если я правильно понимаю, то это что-то типа навороченного полнотестового поиска по содержимому документов. Не совсем ясно, как оно в контексте данного топика может пригодится. Полнотекстовый поиск по картинками устраивать?
Ну разве что эта самая служба индексирования еще вроде бы часть кастомных пропертей умеет индексировать (вроде бы), но этого по задаче тож не требовалось.

...

Рейтинг:

0 / 0

30.10.2006, 16:53

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092082

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

ё1234
Step 3 Files: 100
Create time (total, sec): 0.03125
Random seek (avg, sec): 0.00008125
Step 4 Files: 1000
Create time (total, sec): 0.40625
Random seek (avg, sec): 0.00008125
Step 5 Files: 10000
Create time (total, sec): 5.625
Random seek (avg, sec): 0.0001

c127
начиная с нескольких сотен файлов уже заметно невооруженным глазом

По доброму завидую зрению с127, воистину, глаз-алмаз: не только различает 0.00008125 сек и 0.0001 сек, но и различает 0.00008125 сек одной сотни файлов от 0.00008125 сек десятка сотен файлов...

...

Рейтинг:

0 / 0

30.10.2006, 17:37

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092147

ChA

Участник

Откуда: Москва

Сообщения: 10 913

Рейтинг: 0 / 0

ЛПВ принципе - да, упомянутый сервис не совсем по теме. Здесь, скорее, а вот есть така фича, которая якобы дает некоторые дополнительные возможности по поиску файлов. Просто тема, IMHO, выдохлась, с127 не готов признать, что он не совсем прав, и тут ни ругань, ни результаты экспериментов уже не помогут.
По сути, даже поверхностное изучение топиков на тему говорит, что определенный потенциал у NTFS есть, если поставить задачу его отыскать. Особенно, если потратить определенные усилия на ее оптимизацию, включая как физические характеристики HDD, пользуя высокооборотные с хорошим кэшем и контроллером, так и планирование самой FS под задачу, включая размер кластеров, MFT и прочая мелочь, типа метки доступа, добавление памяти под системный кэш OS. Полагаю, что результаты могут оказаться намного лучше, чем тестирование на стандартном разделе домашней машины.
Другой вопрос, стоят ли эти усилия конечной цели - это раз. Второе, неизвестно, насколько будет высока цена за конкурентность. Если одновременно будет обращаться эээ сотни пользователей, то нет полной уверенности, что с такой ситуацией FS справиться лучше, чем DBMS, тем более, что некоторые вполне способны работать с RAW-разделами. Кроме того, при работе с FS для возврата результата OS должен открыть файл, считать и передать данные запрашивающему процессу, закрыть файл, это тоже издержки, которые, скорее всего, выше, чем возврат содержимого BLOB-а. Короче говоря, вопросов все равно горазда больше, чем ответов. Ваши эксперименты показывают проблему лишь с одной стороны, ровно с той, сомнения в которой были высказаны с127, но они не отвечают полностью на вопрос о целесообразности использования FS при решении упомянутой в первом топике задачи.

P.S. Желающих выполнять все эти эксперименты немного, это требует много времени, затрат на оборудование, достаточно нудной работы, и, соответственно, оплаты :)

...

Рейтинг:

0 / 0

30.10.2006, 17:56

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092233

ё1234

Гость

ЛП2 ё1234
"проблема" с толчностью таймера лихко решаицца. Увеличением числа поисков внутри диапазона замеров.
Ну да, решается. Выносом таймера за цикл.
Только вот получится, что в цикле много раз одно и то же ищем, а это не совсем то что нужно, да и сам цикл собьет измерения.
Или можно совсем за пределы всего вынести таймер, т.е. и за пределы получения рандомного имени. Получится, что помимо поиска замерили и цикл, и строковые операции, и математические операции в VBA. Не страшно, но нужно будет не забыть все это компенсировать.и?
если не секрет, какие такие существенные добавки внесет цена пары(пусть - десятков) процессорных операций в оценку времени дисковых?
т.е. процедура вида

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.

Public Function TestSeek(lngMaxFiles As Long) As Single
Const NumTest As Long =  10000 
    Dim tStart As Single, tEnd As Single, tTotal As Single
    
    Dim i As Long
    tStart = Timer
    For i =  1  To NumTest
        Dim strFileName As String
        ' рандомный файл
        strFileName = strRoot & Format(Int(Rnd( 1 ) * lngMaxFiles) +  1 , "000\\0000") & ".txt"
        
        Open strFileName For Input As # 2  ' Нашли и открыли
            Dim c As Byte
            c = Input( 1 , # 2 ) ' на фсяк случай прочитали аж целый байт
        Close # 2 
    Next i
    tEnd = Timer
    tTotal = tTotal + (tEnd - tStart)
    
    TestSeek = tTotal / NumTest
End Function

(это я по поддиректориям по 10000 файлов ищу - соответственно клал так:

Код: plaintext

1.
2.
3.
4.

If lngCurrentFileNumber \  10000  > subDirNum Then
                subDirNum = lngCurrentFileNumber \  10000 
                CreatePath strRoot & Format(subDirNum, "000\\")
            End If
            strFileName = strRoot & Format(lngCurrentFileNumber, "000\\0000") & ".txt"

)

ЛП количество замеров 10000, файлы по 10 байт
Ну говорилось же уже, что файлы по 10 байт - плохо моделируют нагрузку...
Даже если результаты похожие - совсем другое меряется.
??? если предположить, что в натуре имеем индекс, то времена поиска по индексу сюда входят, далее - в случае ловли по индексу места на диске - имеем разницу во времени позиционирования+чтения, в случае если 10 байт лежат в файловой табле - не имеем(этой разницы).
И? Времена-то "поиска в индексе" (ежли оно имеет место) меряются и там и сям.
ЛП например можно предполагать какие-нто хеш таблички с "малым" размером (полагаю - ~64к). при выходе за n*10**4 файлов время поиска начинает расти по другому закону (с другим основанием, даже если энто остаецца логарифмом).
Да я как-то и не против ни хеш-табличек, ни логарифмов с другим основанием.
Только давайте все-таки по трем точкам не будем строить логарифмы, а?
а по тясячи точкам от 500000 до 1000000 файлов у меня почему-то получился совсем не логарифмический рост, а очень даже резкое уменьшение, и этот факт любители строить графики почему-то обходят стороной ну и?

могу предположить, в кач-ве раб. гипотезы, что имеет место кеширование некоей инфы, требуемой для поиска. При первых тестах кэш постепенно заполняется - что и ведет к большим временам - за счет затрат на чтение; далее, поскольку приращения числа файлов по сравнению с их изначальным числом между измерениями невелико, то и потребность читать "стоко же много", как и при первых тестах, по мере продолжения тестов отпадает, что и ведет к некоторому снижению общего времени поиска.
ЛПИ, в конце то концов, если уж беретесь рассуждать о немерянных миллионах файлов - таки научитесь резервировать место под MFT (она по умолчанию под небольшое кол-во файлов расчитана).
(последний абзац не к ё1234, а абстракно в воздух)дык кто же спорить то? вопрос то явно упирается в осевые "механизмы индексации файловой системы". Т.е. в понимание механизмов индексации файловой системы, что покедова тут не озвучивалось. Т.ч. и мы, сирые, занимаемся нефритовыми стержнями и далее.

кстати сказать, разбиение директории на поддиректории не привело к ускорению поиска:

Код: 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.
26.
27.

================================================================
по поддиректориям
================================================================
Test
Step 1        Files:                       1 
              Create time (total, sec):    0 
              Random seek (avg, sec):      7.65625E-05 
Step 2        Files:                       10 
              Create time (total, sec):    0.015625 
              Random seek (avg, sec):      8.125E-05 
Step 3        Files:                       100 
              Create time (total, sec):    0.046875 
              Random seek (avg, sec):      8.59375E-05 
Step 4        Files:                       1000 
              Create time (total, sec):    0.46875 
              Random seek (avg, sec):      9.375E-05 
Step 5        Files:                       10000 
              Create time (total, sec):    5.609375 
              Random seek (avg, sec):      1.109375E-04 
Step 6        Files:                       100000 
              Create time (total, sec):    154.1563 
              Random seek (avg, sec):      1.087344E-02 
Step 7        Files:                       1000000 
              Create time (total, sec):    678.3281 
              Random seek (avg, sec):      2.315625E-02 
=========================
Total time:    1184.063 
=========================

при этом, уже _после_заполнения 1000000, времена поиска файлов:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

?TestSeek(10000)
 1.078125E-04 
 1.078125E-04 
 1.078125E-04 
 1.109375E-04 
 1.21875E-04 
 0.0001375 
 0.0001125 
 1.109375E-04 
 1.296875E-04 
 3.859375E-04 
?TestSeek(100000)
 4.514062E-03 
 4.682812E-03 
?TestSeek(1000000)
 2.682031E-02 
 2.821406E-02 
 3.684688E-02

как видим -и тут наблюдается "спад" при последовательных поисках в одном "диапазоне имен". И "время поиска"(?) растет с увеличением области поиска.

И, кстати сказать, при выполнении "поиска" загрузка проца падает до 0-1% - видимо - сплошные затраты на чтение. Вот токо вопрос: - на чтение тестовой процедурой данных из файлов, или на повторные чтение инфы о размещении файлов :). Если на чтение данных из файлов - то, возможно, нет ничего странного в падении скорости тестовой процедуры. ить разное время - тысячу раз прочитать что-то из кэша, или ту же тысячу - с разных мест диска. т.ч. вопрос о том, что же собсно меряет эта ваша процедура остается открытым.
Если файлов на диске уже миллион, а я их нахожу в подмножестве из 10000 почти так же быстро, как когда их была 10000 - см 1.109375E-04 - при 10000 - в процессе заполнения vs 1.078125E-04 при выборке из 10000 после заполнения - т.е. из уже "наличного мульона" - то что-то не то с интертрепацией результатов (при укладывании в одну директорию видимо будет то же самое) - видимо замеряем мы разный вклад кэширования в тестовые времена, а не "реально разные времена поиска"

...

Рейтинг:

0 / 0

30.10.2006, 18:25

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092237

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 ChA
По сути, даже поверхностное изучение топиков на тему говорит, что определенный потенциал у NTFS есть, если поставить задачу его отыскать. Особенно, если потратить определенные усилия на ее оптимизацию, включая как физические характеристики HDD, пользуя высокооборотные с хорошим кэшем и контроллером, так и планирование самой FS под задачу, включая размер кластеров, MFT и прочая мелочь, типа метки доступа, добавление памяти под системный кэш OS. Полагаю, что результаты могут оказаться намного лучше, чем тестирование на стандартном разделе домашней машины.
Так ведь и на стандартном разделе домашней машины вплоть до полного забития винта не было замечено каких-либо особых проблем (самый первый тест DocAI, повторюсь, это иллюстрация к тому, что северный варвар способен не только сломать свой нефритовый стержень, но и поранить при этом руки).
Ну показали тесты худший результат поиска порядка сотой доли секунды. Без какой-либо оптимизации и тюнинга. Если много - всегда можно оттюнинговать и улучшить. Как - известно. Гуголь полон информации. Только с127 этого в упор не желает видеть, говорит, что это дескать "никому не известно как".

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

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

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

P.S. Желающих выполнять все эти эксперименты немного, это требует много времени, затрат на оборудование, достаточно нудной работы, и, соответственно, оплаты :)
Колхоз - дело добровольное.
Забавно только, когда человек, ваабсче ни одного эксперимента не провёдший, ни с затратами на оборудование, ни без оных - пытается обвинять других в том что "от вас один трёп, экспериментов не ставили, скорость не меряли"

...

Рейтинг:

0 / 0

30.10.2006, 18:28

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092260

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 ё1234
и?
если не секрет, какие такие существенные добавки внесет цена пары(пусть - десятков) процессорных операций в оценку времени дисковых?
Откуда я знаю? Какие бы ни были эти добавки - я бы их отдельно померял и вычел из общего времени. Прогнать еще раз тот же самый цикл, но за вычетом поиска файла - не сложно.

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

...

Рейтинг:

0 / 0

30.10.2006, 18:35

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092376

ChA

Участник

Откуда: Москва

Сообщения: 10 913

Рейтинг: 0 / 0

ЛПКакие усилия? Положить файлы в каталог? Нет тут никаких усилий. Или тюнинговать систему для достижения максимально хороших результатов? Так и сервера баз данных надо тюнить для достижения максимально хороших результатов.Полагал, что из контекста ясно, что подразумевался тюнинг. При этом необходимость тьюнить СУБД "для достижения максимально хороших результатов" ни разу не подвергалась сомнению. Но FS - это таки не DBMS, несмотря на "неонку у ней внутре".
ЛПВо-первых. Откуда взялись сотни пользователей? В исходной задаче их нет.
Во-вторых. Ну что за ёёёё.... Сначала с127 пытался людей убедить в том, что файловая система не подходит для того, для чего она собстенно и предназначена, т.е. для хранения файлов. Теперь Вы будете меня убеждать в том, что файл-серверы не подходят для того, для чего они предназначены, т.е. для обеспечения доступа к файлам "ээээ сотни пользователей"? Ну не смешите, ей богу...Во-первых, автор топика очертил задачу достаточно поверхностно, количество пользователей там просто не фигурирует. Но вряд ли миллион записей и 50000 картинок в день нужны для одного пользователя, даже для десяти многовато. Так что есть вполне резонные подозрения, что пользователей может быть даже не сотни, а тысячи.
Во-вторых, просьба не передергивать, было всего лишь высказано предположение, что DBMS, тем более на RAW, при решении исходной задачи может быть более производительным вариантом, особенно в высоконкурентной ситуации. IMHO, это совсем непохоже на попытку в чем либо Вас или кого-либо еще в чем-то убедить. Кому надо, тот просто берет и тестирует, в том числе проверяя и упомянутое предположение.
ЛПАга, сервер баз данных типа свободен от издержек? Ню-ню... Пятьдесят тысяч запросов в секунду уже пытались получить в соседнем топике, издержки не позволили-с.И опять, было сказано, что нет издержек на операции с файлами, а не отсутствие издержек при работе с БД. Но, в целом, вес этих издержек, как мне, опять же, кажется, будет меньше.
IMHO, это близко к тому, что мы можем сохранить текст либо в одном файле, либо по одной букве на файл, и по запросу надо вернуть только одну N-ю букву. Что-то мне подсказывает, что издержек на возврат n-ой букву из целого и открытого файла меньше, чем из n-го файла, который надо не только найти, что возможно и не очень долго, но и открыть, считать, закрыть.
А 50000 запросов/секунду это совсем из другой оперы, бишь темы, пусть они там и остаются.

...

Рейтинг:

0 / 0

30.10.2006, 19:49

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092385

StalkerS

Участник

Откуда: Nowhere

Сообщения: 1 227

Рейтинг: 0 / 0

Роберт Вьейра. SQL Server 2000 Программирование. Изд. Бином, Глава 24, стр. 940
... Как правило, вам придется использовать BLOB, но намереваемся пойти другим путем. Вместо решения проблемы в лоб, мы будем хранить данные в файлах.
Конечно, некоторые из вас зададут вопрос: "А разве обращение к данным, хранящимся в базе данных, производиться не быстрее, чем через файловую систему ?" Мой ответ будет очень прост: "Нет !". Есть исключения, о которых я еще скажу, но как правило, использование файлов намного быстрее.
...
Во всех операционных системах Windows существует ограничение на количество файлов, хранимых в одной папке. Поэтому вам стоит подумать о том, сколько файлов вы будете хранить. Если их количество будет, скажем, больше 500, тогда вам потребуется создать механизм в объекте, хранящим ваш BLOB, который бы выполнял создание новых папок при необходимости, либо основываясь на каком-то ином логическом критерии.
...
В большинстве случаев данный подход будет работать в 2-3 раза быстрее, чем BLOB. Существуют однако исключения, для которых данный подход не оправдан:
1) Сохраняемые вами BLOB не превышают 64 КВ по объему;
2) для сохраняемых данных или текста существуют фильтры MS Search, и вы можете предпочесть возможность использования полнотекстового поиска в ущерб скорости.
Если размер вашего BLOB постоянно не превышает 64 КВ, то данные помещаются на единственную страницу данных. Благодаря этому, значительно сокращаются все связанные с BLOB накладные расходы. И несмотря на то, что работа с файловой системой все-же быстрее, сравнительное преимущество резко снизиться, и смена подхода не будет иметь большого смысла ...

...

Рейтинг:

0 / 0

30.10.2006, 19:55

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092409

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 ChA
Полагал, что из контекста ясно, что подразумевался тюнинг. При этом необходимость тьюнить СУБД "для достижения максимально хороших результатов" ни разу не подвергалась сомнению. Но FS - это таки не DBMS, несмотря на "неонку у ней внутре".
Тогда я вообще не понял Вашей фразы "стоят ли усилия конечной цели"
Есть файлы, лежат в файловой системе. Какое-то время поиска. Если (вдруг) время поиска неудовлетворительное - можно или тюнить, или не тюнить. Стоят ли усилия по тюнингу "конечной цели"? Да и кто ж его знает.
Есть файлы, лежат в базе данных. Какое-то время поиска. Если (вдруг) время поиска неудовлетворительное - можно или тюнить, или не тюнить. Стоят ли усилия по тюнингу "конечной цели"? Да и кто ж его знает.

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

Во-первых, автор топика очертил задачу достаточно поверхностно, количество пользователей там просто не фигурирует. Но вряд ли миллион записей и 50000 картинок в день нужны для одного пользователя, даже для десяти многовато. Так что есть вполне резонные подозрения, что пользователей может быть даже не сотни, а тысячи.
Может. А может и не быть.
Какой-нибудь веб-сервер, который что для файловой системы, что для СУБД суть один клиент, несмотря на все миллионы картинок. Это так, к примеру.

Во-вторых, просьба не передергивать, было всего лишь высказано предположение, что DBMS, тем более на RAW, при решении исходной задачи может быть более производительным вариантом, особенно в высоконкурентной ситуации.
Ну так я и сказал, что это гммм... не очень хорошее предположение. Имхо разумеется. Файл-сервер специализирован для выполнения таких операций, в отличие от (сервера БД с сааааавсем другой специализацией).
А так, конечно, можно высказать кучу предположений. Хоть бы и предположения о том, что сервер БД будет лучше почту отсылать, чем почтовый сервер.

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

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

...

Рейтинг:

0 / 0

30.10.2006, 20:24

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092420

Гость

кстати
StalkerSВо всех операционных системах Windows существует ограничение на количество файлов, хранимых в одной папке. Если их количество будет, скажем, больше 500, тогда вам потребуется создать механизм в объекте, хранящим ваш BLOB, который бы выполнял создание новых папок при необходимости, либо основываясь на каком-то ином логическом критерии.
непонятно, откуда взята цифра 500?

для FAT-16/32 количество файлов/папок в некорневой папке - это максимальный разрешенный размер файла деленный на размер записи. Т.е. (если отказаться от использования длинных имен) 2^31 / 2^5 = 33'554'432. (столько что ли?). В ntfs количество файлов в одной папке наверняка имеет еще менее достижимое ограничение

...

Рейтинг:

0 / 0

30.10.2006, 20:34

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092441

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

ChA
Другой вопрос, стоят ли эти усилия конечной цели - это раз. Второе, неизвестно, насколько будет высока цена за конкурентность. Если одновременно будет обращаться эээ сотни пользователей, то нет полной уверенности, что с такой ситуацией FS справиться лучше, чем DBMS, тем более, что некоторые вполне способны работать с RAW-разделами. Кроме того, при работе с FS для возврата результата OS должен открыть файл, считать и передать данные запрашивающему процессу, закрыть файл, это тоже издержки, которые, скорее всего, выше, чем возврат содержимого BLOB-а.
Т.е., вы полагаете, что, например, nginx будет сервить картинки из директории медленее и менее масштабируемо, чем apache скриптом будет доставать их из базы? Если нет, то, по крайней мере, в некоторых случаях файловая система будет предпочтительней.

...

Рейтинг:

0 / 0

30.10.2006, 20:58

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092483

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 ы
непонятно, откуда взята цифра 500?
Оттуда же, откуда у с127 взялись ограничения системы, видные невооруженным глазом на сотнях файлов, выражающиеся в тормозах фара при открывании каталога, а так же в линейных тормозах при поиске, обнаруженных в ходе эксперимента, проведенного в прошлом тысячелетии, от которого, впрочем, с127 даже уже и откреститься успел.

То бишь с потолка. Роберт Вьейра подумал, подумал, почесал репу, да и назвал первое пришедшее в голову число.

для FAT-16/32 количество файлов/папок в некорневой папке - это максимальный разрешенный размер файла деленный на размер записи. Т.е. (если отказаться от использования длинных имен) 2^31 / 2^5 = 33'554'432. (столько что ли?).
Не скажу за FAT32, но про FAT16 ты скорее всего ошибся - там максимальное количество файлов в некорневой директории вроде бы 65535. Но зуб не дам.

...

Рейтинг:

0 / 0

30.10.2006, 21:53

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092489

Гость

ЛПНе скажу за FAT32, но про FAT16 ты скорее всего ошибся - там максимальное количество файлов в некорневой директории вроде бы 65535.
гм. Возможно, конечно. У тебя все возможно. Но я такого не видел. И не нагуглил с размаху

...

Рейтинг:

0 / 0

30.10.2006, 22:00

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092504

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

И не нагуглил с размаху
плохо гуглишь
из того, что нагуглилось:
http://www.interface.ru/fset.asp?Url=/microsoft/mcp/3.htm

...

Рейтинг:

0 / 0

30.10.2006, 22:10

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092513

Гость

о. нет. Ого!

Был дурак

...

Рейтинг:

0 / 0

30.10.2006, 22:23

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092585

ChA

Участник

Откуда: Москва

Сообщения: 10 913

Рейтинг: 0 / 0

DocAlвы полагаете, что, например, nginx будет сервить картинки из директории медленее и менее масштабируемо, чем apache скриптом будет доставать их из базы?Нас с nginx лично не знакомили, поэтому не понимаю о чем речь, пока не было острой необходимости в знакомстве с семейством unix :)
Не являюсь специалистом в Инет-технологиях, но насколько понимаю, то при доступе через http(apache?) весь поток данных проходит, в любом случае, через http-сервер, и не важно, из файлов мы данные достаем или из БД, в любом случае, наверняка каким-то скриптом или соответствующим слоем. Поэтому фактически нужно сравнивать производительность и мастабируемость получения данных посредством FS или DBMS в чистом виде, потому как издержки на работу промежуточного слоя наверняка одного порядка.
Лично я не уверен, что FS в такой ситуации всегда и безусловно будет выигрывать. Выше уже приводил аналогию с побуквенным доступом, пусть умозрительно, но, надеюсь, логика его вполне понятна. Доказывать что-либо особого желания нет, если кому-то мало моих сомнений, то пусть он сам проверяет и доказывает, что я, мягко говоря, не в теме :)

DocAlпо крайней мере, в некоторых случаях файловая система будет предпочтительней.Да как бы обратного не доказывал. Вполне возможно, что в ряде случаев это так и будет. Например, стоит ли связываться с сервером БД, если задача прекрасно решается только средствами OS и производительность вполне устраивает сейчас и в обозреваемом будущем ? Наверное, нет...

Немного офтопа. Практически все ведущие игроки на рынке DBMS имеют возможность работать с RAW-разделами. Возникает вопрос, а зачем, собственно ? Почему не работать только через FS ? По крайней мере, некоторые заявляют, что таким способом можно поднять производительность от 10% до 25%. А стоит ли овчинка выделки не мне решать, у любых решений всегда есть как плюсы, так и минусы.

...

Рейтинг:

0 / 0

30.10.2006, 23:26

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092617

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 ChA
DocAlпо крайней мере, в некоторых случаях файловая система будет предпочтительней.Да как бы обратного не доказывал.
Как это "никто"? Вам показать пальцем на этого "никто", который утверждал, что "хранить нельзя, не то чтобы искать, ограничения наступают быстро, растут линейно, видны на глаз, на сотнях файлов"?
Показывать не буду, он сам скоро придет.

Немного офтопа. Практически все ведущие игроки на рынке DBMS имеют возможность работать с RAW-разделами. Возникает вопрос, а зачем, собственно ? Почему не работать только через FS ?
Давайте попробую угадать...
Наверное потому, что что файловая система, заточенная под хранение и обработку файлов, предоставление доступа к ним, и т.д, и т.п. - не всегда оптимальна в качестве хранилища для РСУБД, со своими задачами и требованиями? По крайней мере я бы не удивился, если бы это оказалось так.
Зато мне удивительно, почему кому-то еще надо доказывать обратное утверждение, что РСУБД со своими задачами и требованиями - не всегда оптимальна в качестве хранилища файлов.
Не говоря уже про некоторых "никто", по мнению которых так и вообще только РСУБД и подходит для хранения файлов и доступа к ним.

...

Рейтинг:

0 / 0

30.10.2006, 23:48

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092618

c127

Гость

ё1234 ЛП2 ё1234
"проблема" с толчностью таймера лихко решаицца. Увеличением числа поисков внутри диапазона замеров.
Ну да, решается. Выносом таймера за цикл.
Только вот получится, что в цикле много раз одно и то же ищем, а это не совсем то что нужно, да и сам цикл собьет измерения.
Или можно совсем за пределы всего вынести таймер, т.е. и за пределы получения рандомного имени. Получится, что помимо поиска замерили и цикл, и строковые операции, и математические операции в VBA. Не страшно, но нужно будет не забыть все это компенсировать.и?
если не секрет, какие такие существенные добавки внесет цена пары(пусть - десятков) процессорных операций в оценку времени дисковых?
т.е. процедура вида
Да никаких существенных добавок разумеется не будет, это все отмазки. Вы же видите, ЛП вместе с таймером попытался заодно вынести за цикл и формирование имени файла, хотя Вы говорили только о таймере. ЛП по-видимому просто боится измерять время не одного поиска, а серии. В случае увеличения среднего времени, а оно увеличится, у него пропадет последняя зацепка.

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

...

Рейтинг:

0 / 0

30.10.2006, 23:49

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092621

OS/360

Гость

авторНе являюсь специалистом в Инет-технологиях, но насколько понимаю, то при доступе через http(apache?) весь поток данных проходит, в любом случае, через http-сервер, и не важно, из файлов мы данные достаем или из БД, в любом случае, наверняка каким-то скриптом или соответствующим слоем

В простом случае - так.
В более сложных - бывает иначе -
TransmitFile

...

Рейтинг:

0 / 0

30.10.2006, 23:51

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092644

ChA

Участник

Откуда: Москва

Сообщения: 10 913

Рейтинг: 0 / 0

ЛП ChA DocAlпо крайней мере, в некоторых случаях файловая система будет предпочтительней.Да как бы обратного не доказывал. Как это "никто"?ЛП, спокойнЕе, плиз. Где в моей цитате слово "никто" ? Это был не я, его и топчите :) Хотя смысла в этом, IMHO, особого нет, он может и признал бы, что погорячился, но после такого потока эпитетов, какими Вы его наградили, боюсь, это просто невозможно. Неспортивно топтать противника, впрочем не мне Вас судить...
ЛПДавайте попробую угадать...Да зачем гадать-то, все, наверное, кроме "вьюношей бледных", прекрасно понимают, что для решения каждой задачи есть наиболее подходящий инструмент. Причем, что характерно, не всегда даже целевой, но лучше ничего под руками может просто и не быть. Вспоминается фильм с Томом Хэнксом в главной роли, когда он попал на необитаемый остров. У него разболелся зуб и он его выбивал лезвием от фигурного конька. Может и утрированно, но тем не менее... OS/360В более сложных - бывает иначеНу и замечательно, еще один плюс в пользу FS.

...

Рейтинг:

0 / 0

31.10.2006, 00:18

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092647

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 ChA
Где в моей цитате слово "никто" ?
Вах, пардон...
"да как бы обратного не доказывал" на скорости прочитал как "да как бы никто обратного не доказывал"
Был неправ, вел себя недостойно чести советского офицера.

Меня укусил с127, поэтому я потихоньку превращаюсь в ЧАЛа...
Уже начинаю плохо читать...

Это был не я
Я понял. Очень хорошо, что это были не Вы.
Главное, чтобы я Вас не укусил.

...

Рейтинг:

0 / 0

31.10.2006, 00:22

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34092660

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

31.10.2006, 00:50

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34094265

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

Копья ломаются по теме: "файловая система ЭТО сможет!"

Ну, сможет, и сможет. Зашибись.

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

....

NTFS/FAT16/FAT32...
А я вот возьму, и просто размещу СУБД на другом сервере, под другой ОС (Вынь
или Линукс, или еще что - если СУБД не акцесс/MS SQL...). И совершенно
пофиг, есть ли в той ФС индексация кастом-атрибутов. И есть ли они там
вообще. И какие ограничения на число подкаталогов. А вы еби%есь, и
проверяйте.
....
Мля...
Ну что за детсад:
"- этого делать не стоит, потому что оно не для этого..."
Ну, а для чего тогда были созданы блобы?

Может, ЛП проще доказать, что при использовании СУБД будут офуенные
сложности?

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

31.10.2006, 14:17

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34094424

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

2 mv
Копья ломаются по теме: "файловая система ЭТО сможет!"
Нет, копья ломаются по теме "файловая система этого НЕ сможет" :)
Если бы один шибко умный товарисч не начал с перепоя сказок рассказывать про ограничения системы на сотнях файлов, да еще если бы ему не начали подпевать про жесть на тысячах, то все копья остались бы целыми :)

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

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

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

...

Рейтинг:

0 / 0

31.10.2006, 14:46

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34094538

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

ЛП
mv
Ну, а для чего тогда были созданы блобы?

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

А кто сказал-то?

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

31.10.2006, 15:10

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34094563

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

mvА кто сказал-то?
Не поверишь - человек под ником "тупой юзер"

...

Рейтинг:

0 / 0

31.10.2006, 15:14

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34094743

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

ЛП
Не поверишь - человек под ником "тупой юзер"

Ой, блин...
(это про картинка
из камеры ?)
Дело в том, что я на ваш форум раньше "внимательно" не заглядывал.

Действительно, уж лучше в файлах тогда.

....однако, какая колоритная компания!

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

31.10.2006, 15:49

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34096578

и не стыдна?

Гость

ЛП Для примера пожалуй опять вспомню про топик с пятьюдесятью тысячами запросов в секунду. Сможете пятьдесят тысяч раз в секунду картинку из базы достать? Когда сможете, тогда и приходите, раскажу, как винт отформатировать, чтоб система с такой скоростью файлы из директории доставала.мбля, за езыг же нихто не тянулл.

помидитируйте над понятим "среднее время доступа", а такоже над тем, что 5 милисекунд - вполне хороший показатель для диска, и сообразите, что _при условии_, что большая часть искомых "файлов" находится _вне_ кэша, вы получите хорошую оценку времени рендомного "доставания файла из директории" порядка 1/(среднее время доступа) (при одном диске). (это если еще файло небольшое, и читать его стоит мало по сравнению с с.в.д.) т.е. около 200 "доставаний" (с одного диска) в сякунду.

Т.ч. похоже тут нас опядь пытюца попросту наипать.
нихарашо, аднако. - я пачти паверил.
дело не в форматировании диска, а фтом, шобы он ф кеш влезал целиком, по самое нееблуйсо. или в системе должно быть стока дискоф (?пластин? - если позиционирование голов по пластинам независимое (- тут я не фтеме)), скока нада (>~50000/200 - т.е. около 250)

...

Рейтинг:

0 / 0

01.11.2006, 11:06

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34098240

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

ути-пути, цирк уехал

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

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

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

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

я пачти паверил.
Я же говорил - верить нельзя никому, даже мне :)
Экспериментам, правда, с некоторой натяжкой верить можно

...

Рейтинг:

0 / 0

01.11.2006, 16:31

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34098346

DocAl

Участник

Откуда: Оккупирую западный берег

Сообщения: 9 935

Рейтинг: 0 / 0

и не стыдна?
помидитируйте над понятим "среднее время доступа", а такоже над тем, что 5 милисекунд - вполне хороший показатель для диска, и сообразите, что _при условии_, что большая часть искомых "файлов" находится _вне_ кэша, вы получите хорошую оценку времени рендомного "доставания файла из директории" порядка 1/(среднее время доступа) (при одном диске). (это если еще файло небольшое, и читать его стоит мало по сравнению с с.в.д.) т.е. около 200 "доставаний" (с одного диска) в сякунду.
Надо думать, СУБД достаёт данные не с дисков, а из пространственного эфира, и на неё железячные ограничения накопителей не распространяются...

...

Рейтинг:

0 / 0

01.11.2006, 16:52

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34098656

lllllllllll

Гость

ЛППомедитируйте над тем, когда истинна импликация. После этого выделите цветом немного другую часть моей фразы :).можно подумать, что этот выкрутас с ёмпликацией не видно невооруженным глазом. т.ч. эту вашу нечаянную радость попросту опустили, за неинтересностью.

однако даже такая хитропопость не повод обещать глупости. в силу чего я, сопсно, и имел
(честь сделать сообщение).

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

ЛПОга, ога. Двести доставаний.
У меня вот в последних (неопубликованных) тестах
...
...
Экспериментам, правда, с некоторой натяжкой верить можнот.ч. пользуемсо опубликованными: при степ 7 там видим ~.022. Т.е. порядка 50 "доставаний". т.ч. - "продите ф сад"

докаиНадо думать, СУБД достаёт данные не с дисковне знаю, что _вам_ надо думать, а лично мне так кажицца, что "нададумать", что и без субд харашо сели в лужу по железу. и вапрос у миня не к субд и не к фс, а к ЛП: - ежли другим низзя спистеть про кашу, которая чётотам махом, не сморя на железо, так с какого перекуя лоху можно про форматирование.

...

Рейтинг:

0 / 0

01.11.2006, 17:54

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34098705

Участник

Сообщения: 9 039

Рейтинг: 0 / 0

lllllllllll

Есть радикальный способ:
- посадить несогласного гада в столовский котел (такие здоровые, с
гермокрышками), крышку на секунду приоткрыть, и бросить туда две гранаты Ф1.
Крышку быстро закрыть.
А потом поговорить про форматирование, фс, кашу и скорость непрерывной
читки.

Posted via ActualForum NNTP Server 1.3

...

Рейтинг:

0 / 0

01.11.2006, 18:04

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34099048

ЛП

Участник

Сообщения: 3 925

Рейтинг: 0 / 0

... а клоуны остались

2 lllllllllll
однако даже такая хитропопость не повод обещать глупости
Та ни абищал я Вам ничаво, не нервничайте тока :)

а куйню-то зачем писать?
Не вопрос. Не пишете.

причем тут удароустоячивость
А при чем тут среднее время доступа?
Ну есть у винта такая характеристика, дальше то что?
Считаете её определяющей? Да флаг в руки. Тогда на основании этой же характеристики можно точно так же сделать вывод, что например РСУБД не сможет больше двухсот запросов в секунду сделать к сколь-нибудь большому объёму данных. Однако ж оно могёт. Даже тупой аксес с такой скоростью могёт в гигабайтном файлике по большой табличке бегать и инфу искать (если мне не изменяет мой склероз, зуб не дам).
Можете характеристику винта распечатать на бумажку и повесить на стенку, патамушта не та эта характеристика.

и чо, оно рази не есть скорость непрерывной читки? ( т.е. подряд, без позиционирования, (или - с редким п. - из за сегментации), и, сл-но, плохо отвечает ситуации рендомного доступа)
Хосспадя, Вам всё разжевывать надо перед тем как в рот положить? Я Вам пальцем показал на ту характеристику (пожалуй что единственную), однозначно указывающую на то, что писят тыщ пятнадцатикилобайтовых картиной действительно не могут быть выбраны (с имеющегося у меня винта), даже при последовательном доступе. Они просто не пролезут в кабель. Что тут непонятного?

т.ч. пользуемсо опубликованными: при степ 7 там видим ~.022. Т.е. порядка 50 "доставаний". т.ч. - "продите ф сад"
Раньше в этом топике строили графики и делали какие-то мудрые выводы по трем точкам с погрешностью плюс-минус паравоз, теперь какие-то выводы уже по одной точке :)
Браво, маразм крепчал :))
Если так хотите "опубликованных" данных - не вопрос, доберусь только до них. Хотя, конечно, любители делать выводы по одной точке - и там сумеют найти хотя бы одну точку, или хотя бы одну последовательность точек, которая бы подтвердила их самые бредовые гипотезы.

и вапрос у миня не к субд и не к фс, а к ЛП: - ежли другим низзя спистеть про кашу, которая чётотам махом, не сморя на железо, так с какого перекуя лоху можно про форматирование.
С такого перекуя. В контексте спора "СУБД vs ФС" был вопрос насчет "офуенных сложностей при использовании СУБД". В ответ был сравнительно недавний пример, где эти "офуенные сложности" у РСУБД будут, причем возникнут задолго до того, как к железячным (винчестерным) пределам подойдем (т.е. когда возникнут проблемы у ФС). Что-то непонятно?

...

Рейтинг:

0 / 0

01.11.2006, 20:41

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34099282

c127

Гость

ЛПРаньше в этом топике строили графики и делали какие-то мудрые выводы по трем точкам с погрешностью плюс-минус паравоз, теперь какие-то выводы уже по одной точке :)
Браво, маразм крепчал :))
Маразм действительно крепчает. Сначала ЛП проводит эксперименты, радостно размахивает результатами, якобы однозначно подтвердившими его правоту. Когда его тычут носом в то, что его результаты его же и опровергают, он начинает с такой же убежденностью доказывать что эексперименты совершенно некорректны и результаты никакой ценности не имеют, потому что NTFS неправильно установлена и вообще погрешность превосходит результат на два порядка. Но и это еще не все, периодически ЛП все еще вскрикивает, что результаты все-таки что-то доказали.

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

Строить графики по трем точкам тоже вроде никто не запрещал, количество точек зависит от того, что мы хотим выяснить. То что мы хотим выяснить видно и по двум точкам, смотрите хотя бы свои же графики.
/topic/351165&pg=4#3322254

...

Рейтинг:

0 / 0

02.11.2006, 00:36

| Ответить | Цитировать | Написать

Выбор сервера, чтобы не тормозило ...

#34099816

SergSuper

Участник

Откуда: SPb

Сообщения: 5 995

Рейтинг: 0 / 0

Закрываем нахрен. Надо было раньше закрыть. Если вовремя не закрыть обязательно найдётся какой-нибудь урод(по IP это не с127), кторый будет писать под чужими никами, думая что это остроумно.

Спецально для ЛП: с127 просто хронически не любит MS и ничего с этим не сделаешь :)

...

Рейтинг:

0 / 0

02.11.2006, 10:34

| Ответить | Цитировать | Написать

163 сообщений из 163, показаны все 7 страниц

все

Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор сервера, чтобы не тормозило ...

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=35&tid=1553452]:	0ms
get settings:	9ms
get forum list:	11ms
check forum access:	3ms
check topic access:	3ms
track hit:	44ms
get topic data:	9ms
get forum data:	2ms
get page messages:	159ms
get tp. blocked users:	2ms
others:	207ms

total:	449ms