Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7   вперед  Ctrl      все
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ё1234
Guest
ЛП
К сожалению, DocAI не ошибся насчет погрешности измерений. Как случайно выяснилось при совместном с ы разборе полётов, используемая ф-ция Timer возращает время с точностью до сотых долей секунды (а под макинтошем так и вообще с точностью до целой секунды). Так что получается, что измерялось лишь то, сколько раз (из контрольной тысячи замеров) время поиска по каким-либо причинам превысило одну сотую секунды.
"проблема" с толчностью таймера лихко решаицца. Увеличением числа поисков внутри диапазона замеров. К сожалению, результат неутешителен для ЛП :)

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

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. могабыть спасет.
30 окт 06, 14:05    [3329729]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
Кто-нибудь серьезно изучал, тестировал или пользовал Indexing Service в Windows ? Результаты, выводы ?
30 окт 06, 15:27    [3330537]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 aZm
если картинка существует как "вещь в себе", без дополнительных характеристик и атрибутов, и доступ можно организовать просто по имени/каталогу - субд в принципе особо не нужна. если же у картинки есть какие то дополнительные характеристики, не исчерпывающиеся именем, то - тут уже прямая дорога в субд)

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

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

2 с127
А вот как это было на самом деле:

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

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

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

2 ё1234
"проблема" с толчностью таймера лихко решаицца. Увеличением числа поисков внутри диапазона замеров.

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

количество замеров 10000, файлы по 10 байт

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

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

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

И, в конце то концов, если уж беретесь рассуждать о немерянных миллионах файлов - таки научитесь резервировать место под MFT (она по умолчанию под небольшое кол-во файлов расчитана).
(последний абзац не к ё1234, а абстракно в воздух)
30 окт 06, 16:31    [3331122]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
ChA
Кто-нибудь серьезно изучал, тестировал или пользовал Indexing Service в Windows ? Результаты, выводы ?

Если я правильно понимаю, то это что-то типа навороченного полнотестового поиска по содержимому документов. Не совсем ясно, как оно в контексте данного топика может пригодится. Полнотекстовый поиск по картинками устраивать?
Ну разве что эта самая служба индексирования еще вроде бы часть кастомных пропертей умеет индексировать (вроде бы), но этого по задаче тож не требовалось.
30 окт 06, 16:53    [3331259]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
ё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 сек десятка сотен файлов...
30 окт 06, 17:37    [3331671]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ChA
Member

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

P.S. Желающих выполнять все эти эксперименты немного, это требует много времени, затрат на оборудование, достаточно нудной работы, и, соответственно, оплаты :)
30 окт 06, 17:56    [3331813]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ё1234
Guest
ЛП
2 ё1234
"проблема" с толчностью таймера лихко решаицца. Увеличением числа поисков внутри диапазона замеров.

Ну да, решается. Выносом таймера за цикл.
Только вот получится, что в цикле много раз одно и то же ищем, а это не совсем то что нужно, да и сам цикл собьет измерения.
Или можно совсем за пределы всего вынести таймер, т.е. и за пределы получения рандомного имени. Получится, что помимо поиска замерили и цикл, и строковые операции, и математические операции в VBA. Не страшно, но нужно будет не забыть все это компенсировать.
и?
если не секрет, какие такие существенные добавки внесет цена пары(пусть - десятков) процессорных операций в оценку времени дисковых?
т.е. процедура вида
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 файлов ищу - соответственно клал так:
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, а абстракно в воздух)
дык кто же спорить то? вопрос то явно упирается в осевые "механизмы индексации файловой системы". Т.е. в понимание механизмов индексации файловой системы, что покедова тут не озвучивалось. Т.ч. и мы, сирые, занимаемся нефритовыми стержнями и далее.

кстати сказать, разбиение директории на поддиректории не привело к ускорению поиска:
================================================================
по поддиректориям
================================================================
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, времена поиска файлов:
?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 после заполнения - т.е. из уже "наличного мульона" - то что-то не то с интертрепацией результатов (при укладывании в одну директорию видимо будет то же самое) - видимо замеряем мы разный вклад кэширования в тестовые времена, а не "реально разные времена поиска"
30 окт 06, 18:25    [3332011]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 ChA
По сути, даже поверхностное изучение топиков на тему говорит, что определенный потенциал у NTFS есть, если поставить задачу его отыскать. Особенно, если потратить определенные усилия на ее оптимизацию, включая как физические характеристики HDD, пользуя высокооборотные с хорошим кэшем и контроллером, так и планирование самой FS под задачу, включая размер кластеров, MFT и прочая мелочь, типа метки доступа, добавление памяти под системный кэш OS. Полагаю, что результаты могут оказаться намного лучше, чем тестирование на стандартном разделе домашней машины.

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

Другой вопрос, стоят ли эти усилия конечной цели - это раз.

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

Второе, неизвестно, насколько будет высока цена за конкурентность. Если одновременно будет обращаться эээ сотни пользователей, то нет полной уверенности, что с такой ситуацией FS справиться лучше, чем DBMS, тем более, что некоторые вполне способны работать с RAW-разделами

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

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

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

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

Колхоз - дело добровольное.
Забавно только, когда человек, ваабсче ни одного эксперимента не провёдший, ни с затратами на оборудование, ни без оных - пытается обвинять других в том что "от вас один трёп, экспериментов не ставили, скорость не меряли"
30 окт 06, 18:28    [3332024]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 ё1234
и?
если не секрет, какие такие существенные добавки внесет цена пары(пусть - десятков) процессорных операций в оценку времени дисковых?

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

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

Если файлы хранятся в MFT, то и поплохеет этой MFT быстрее (я так думаю). А "не расширенная" MFT скорее всего является узким местом в данном случае. Поэтому и тогось... некошерный эксперимент.
30 окт 06, 18:35    [3332069]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
ЛП
Какие усилия? Положить файлы в каталог? Нет тут никаких усилий. Или тюнинговать систему для достижения максимально хороших результатов? Так и сервера баз данных надо тюнить для достижения максимально хороших результатов.
Полагал, что из контекста ясно, что подразумевался тюнинг. При этом необходимость тьюнить СУБД "для достижения максимально хороших результатов" ни разу не подвергалась сомнению. Но FS - это таки не DBMS, несмотря на "неонку у ней внутре".
ЛП
Во-первых. Откуда взялись сотни пользователей? В исходной задаче их нет.
Во-вторых. Ну что за ёёёё.... Сначала с127 пытался людей убедить в том, что файловая система не подходит для того, для чего она собстенно и предназначена, т.е. для хранения файлов. Теперь Вы будете меня убеждать в том, что файл-серверы не подходят для того, для чего они предназначены, т.е. для обеспечения доступа к файлам "ээээ сотни пользователей"? Ну не смешите, ей богу...
Во-первых, автор топика очертил задачу достаточно поверхностно, количество пользователей там просто не фигурирует. Но вряд ли миллион записей и 50000 картинок в день нужны для одного пользователя, даже для десяти многовато. Так что есть вполне резонные подозрения, что пользователей может быть даже не сотни, а тысячи.
Во-вторых, просьба не передергивать, было всего лишь высказано предположение, что DBMS, тем более на RAW, при решении исходной задачи может быть более производительным вариантом, особенно в высоконкурентной ситуации. IMHO, это совсем непохоже на попытку в чем либо Вас или кого-либо еще в чем-то убедить. Кому надо, тот просто берет и тестирует, в том числе проверяя и упомянутое предположение.
ЛП
Ага, сервер баз данных типа свободен от издержек? Ню-ню... Пятьдесят тысяч запросов в секунду уже пытались получить в соседнем топике, издержки не позволили-с.
И опять, было сказано, что нет издержек на операции с файлами, а не отсутствие издержек при работе с БД. Но, в целом, вес этих издержек, как мне, опять же, кажется, будет меньше.
IMHO, это близко к тому, что мы можем сохранить текст либо в одном файле, либо по одной букве на файл, и по запросу надо вернуть только одну N-ю букву. Что-то мне подсказывает, что издержек на возврат n-ой букву из целого и открытого файла меньше, чем из n-го файла, который надо не только найти, что возможно и не очень долго, но и открыть, считать, закрыть.
А 50000 запросов/секунду это совсем из другой оперы, бишь темы, пусть они там и остаются.
30 окт 06, 19:49    [3332277]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1345
Роберт Вьейра. SQL Server 2000 Программирование. Изд. Бином, Глава 24, стр. 940

... Как правило, вам придется использовать BLOB, но намереваемся пойти другим путем. Вместо решения проблемы в лоб, мы будем хранить данные в файлах.
Конечно, некоторые из вас зададут вопрос: "А разве обращение к данным, хранящимся в базе данных, производиться не быстрее, чем через файловую систему ?" Мой ответ будет очень прост: "Нет !". Есть исключения, о которых я еще скажу, но как правило, использование файлов намного быстрее.
...
Во всех операционных системах Windows существует ограничение на количество файлов, хранимых в одной папке. Поэтому вам стоит подумать о том, сколько файлов вы будете хранить. Если их количество будет, скажем, больше 500, тогда вам потребуется создать механизм в объекте, хранящим ваш BLOB, который бы выполнял создание новых папок при необходимости, либо основываясь на каком-то ином логическом критерии.
...
В большинстве случаев данный подход будет работать в 2-3 раза быстрее, чем BLOB. Существуют однако исключения, для которых данный подход не оправдан:
1) Сохраняемые вами BLOB не превышают 64 КВ по объему;
2) для сохраняемых данных или текста существуют фильтры MS Search, и вы можете предпочесть возможность использования полнотекстового поиска в ущерб скорости.
Если размер вашего BLOB постоянно не превышает 64 КВ, то данные помещаются на единственную страницу данных. Благодаря этому, значительно сокращаются все связанные с BLOB накладные расходы. И несмотря на то, что работа с файловой системой все-же быстрее, сравнительное преимущество резко снизиться, и смена подхода не будет иметь большого смысла ...
30 окт 06, 19:55    [3332289]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 ChA
Полагал, что из контекста ясно, что подразумевался тюнинг. При этом необходимость тьюнить СУБД "для достижения максимально хороших результатов" ни разу не подвергалась сомнению. Но FS - это таки не DBMS, несмотря на "неонку у ней внутре".

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

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

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

Может. А может и не быть.
Какой-нибудь веб-сервер, который что для файловой системы, что для СУБД суть один клиент, несмотря на все миллионы картинок. Это так, к примеру.

Во-вторых, просьба не передергивать, было всего лишь высказано предположение, что DBMS, тем более на RAW, при решении исходной задачи может быть более производительным вариантом, особенно в высоконкурентной ситуации.

Ну так я и сказал, что это гммм... не очень хорошее предположение. Имхо разумеется. Файл-сервер специализирован для выполнения таких операций, в отличие от (сервера БД с сааааавсем другой специализацией).
А так, конечно, можно высказать кучу предположений. Хоть бы и предположения о том, что сервер БД будет лучше почту отсылать, чем почтовый сервер.

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

И было отвечено, что зато хватает своих собственных издержек. Что-то непонятно? Постараюсь яснее излагать мысли, извините.

Но, в целом, вес этих издержек, как мне, опять же, кажется, будет меньше

Откуда следует? Просто так, кажется и все тут? Не вопрос. Мало ли кому чего кажется.
30 окт 06, 20:24    [3332330]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ы
Guest
кстати
StalkerS
Во всех операционных системах Windows существует ограничение на количество файлов, хранимых в одной папке. Если их количество будет, скажем, больше 500, тогда вам потребуется создать механизм в объекте, хранящим ваш BLOB, который бы выполнял создание новых папок при необходимости, либо основываясь на каком-то ином логическом критерии.

непонятно, откуда взята цифра 500?

для FAT-16/32 количество файлов/папок в некорневой папке - это максимальный разрешенный размер файла деленный на размер записи. Т.е. (если отказаться от использования длинных имен) 2^31 / 2^5 = 33'554'432. (столько что ли?). В ntfs количество файлов в одной папке наверняка имеет еще менее достижимое ограничение
30 окт 06, 20:34    [3332347]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

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

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

Т.е., вы полагаете, что, например, nginx будет сервить картинки из директории медленее и менее масштабируемо, чем apache скриптом будет доставать их из базы? Если нет, то, по крайней мере, в некоторых случаях файловая система будет предпочтительней.
30 окт 06, 20:58    [3332388]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 ы
непонятно, откуда взята цифра 500?

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

То бишь с потолка. Роберт Вьейра подумал, подумал, почесал репу, да и назвал первое пришедшее в голову число.

для FAT-16/32 количество файлов/папок в некорневой папке - это максимальный разрешенный размер файла деленный на размер записи. Т.е. (если отказаться от использования длинных имен) 2^31 / 2^5 = 33'554'432. (столько что ли?).

Не скажу за FAT32, но про FAT16 ты скорее всего ошибся - там максимальное количество файлов в некорневой директории вроде бы 65535. Но зуб не дам.
30 окт 06, 21:53    [3332471]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ы
Guest
ЛП
Не скажу за FAT32, но про FAT16 ты скорее всего ошибся - там максимальное количество файлов в некорневой директории вроде бы 65535.

гм. Возможно, конечно. У тебя все возможно. Но я такого не видел. И не нагуглил с размаху
30 окт 06, 22:00    [3332483]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
И не нагуглил с размаху

плохо гуглишь
из того, что нагуглилось:
http://www.interface.ru/fset.asp?Url=/microsoft/mcp/3.htm
30 окт 06, 22:10    [3332503]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ы
Guest
о. нет. Ого!

Был дурак
30 окт 06, 22:23    [3332516]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
DocAl
вы полагаете, что, например, nginx будет сервить картинки из директории медленее и менее масштабируемо, чем apache скриптом будет доставать их из базы?
Нас с nginx лично не знакомили, поэтому не понимаю о чем речь, пока не было острой необходимости в знакомстве с семейством unix :)
Не являюсь специалистом в Инет-технологиях, но насколько понимаю, то при доступе через http(apache?) весь поток данных проходит, в любом случае, через http-сервер, и не важно, из файлов мы данные достаем или из БД, в любом случае, наверняка каким-то скриптом или соответствующим слоем. Поэтому фактически нужно сравнивать производительность и мастабируемость получения данных посредством FS или DBMS в чистом виде, потому как издержки на работу промежуточного слоя наверняка одного порядка.
Лично я не уверен, что FS в такой ситуации всегда и безусловно будет выигрывать. Выше уже приводил аналогию с побуквенным доступом, пусть умозрительно, но, надеюсь, логика его вполне понятна. Доказывать что-либо особого желания нет, если кому-то мало моих сомнений, то пусть он сам проверяет и доказывает, что я, мягко говоря, не в теме :)

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

Немного офтопа. Практически все ведущие игроки на рынке DBMS имеют возможность работать с RAW-разделами. Возникает вопрос, а зачем, собственно ? Почему не работать только через FS ? По крайней мере, некоторые заявляют, что таким способом можно поднять производительность от 10% до 25%. А стоит ли овчинка выделки не мне решать, у любых решений всегда есть как плюсы, так и минусы.
30 окт 06, 23:26    [3332622]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 ChA
DocAl
по крайней мере, в некоторых случаях файловая система будет предпочтительней.
Да как бы обратного не доказывал.

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

Немного офтопа. Практически все ведущие игроки на рынке DBMS имеют возможность работать с RAW-разделами. Возникает вопрос, а зачем, собственно ? Почему не работать только через FS ?

Давайте попробую угадать...
Наверное потому, что что файловая система, заточенная под хранение и обработку файлов, предоставление доступа к ним, и т.д, и т.п. - не всегда оптимальна в качестве хранилища для РСУБД, со своими задачами и требованиями? По крайней мере я бы не удивился, если бы это оказалось так.
Зато мне удивительно, почему кому-то еще надо доказывать обратное утверждение, что РСУБД со своими задачами и требованиями - не всегда оптимальна в качестве хранилища файлов.
Не говоря уже про некоторых "никто", по мнению которых так и вообще только РСУБД и подходит для хранения файлов и доступа к ним.
30 окт 06, 23:48    [3332689]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
c127
Guest
ё1234
ЛП
2 ё1234
"проблема" с толчностью таймера лихко решаицца. Увеличением числа поисков внутри диапазона замеров.

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

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

Приращение переменной цикла и проверки выполняются ничтожное время по сравнению с поиском файлов. Имя файла тоже по-видимому формируется быстро, для проверки можно запустить цикл без поиска, в этом случае даже файлы не нужны. Потом при желании это время можно вычесть, хотя я думаю что на результат это уже принципиально не повлияет.
30 окт 06, 23:49    [3332690]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
OS/360
Guest
автор
Не являюсь специалистом в Инет-технологиях, но насколько понимаю, то при доступе через http(apache?) весь поток данных проходит, в любом случае, через http-сервер, и не важно, из файлов мы данные достаем или из БД, в любом случае, наверняка каким-то скриптом или соответствующим слоем


В простом случае - так.
В более сложных - бывает иначе -
TransmitFile
30 окт 06, 23:51    [3332693]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
ЛП
ChA
DocAl
по крайней мере, в некоторых случаях файловая система будет предпочтительней.
Да как бы обратного не доказывал.
Как это "никто"?
ЛП, спокойнЕе, плиз. Где в моей цитате слово "никто" ? Это был не я, его и топчите :) Хотя смысла в этом, IMHO, особого нет, он может и признал бы, что погорячился, но после такого потока эпитетов, какими Вы его наградили, боюсь, это просто невозможно. Неспортивно топтать противника, впрочем не мне Вас судить...
ЛП
Давайте попробую угадать...
Да зачем гадать-то, все, наверное, кроме "вьюношей бледных", прекрасно понимают, что для решения каждой задачи есть наиболее подходящий инструмент. Причем, что характерно, не всегда даже целевой, но лучше ничего под руками может просто и не быть. Вспоминается фильм с Томом Хэнксом в главной роли, когда он попал на необитаемый остров. У него разболелся зуб и он его выбивал лезвием от фигурного конька. Может и утрированно, но тем не менее...
OS/360
В более сложных - бывает иначе
Ну и замечательно, еще один плюс в пользу FS.
31 окт 06, 00:18    [3332743]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
ЛП
Guest
2 ChA
Где в моей цитате слово "никто" ?

Вах, пардон...
"да как бы обратного не доказывал" на скорости прочитал как "да как бы никто обратного не доказывал"
Был неправ, вел себя недостойно чести советского офицера.

Меня укусил с127, поэтому я потихоньку превращаюсь в ЧАЛа...
Уже начинаю плохо читать...

Это был не я

Я понял. Очень хорошо, что это были не Вы.
Главное, чтобы я Вас не укусил.
31 окт 06, 00:22    [3332753]     Ответить | Цитировать Сообщить модератору
 Re: Выбор сервера, чтобы не тормозило ...  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
ChA
Доказывать что-либо особого желания нет, если кому-то мало моих сомнений, то пусть он сам проверяет и доказывает, что я, мягко говоря, не в теме :)

Просто для справки, по такому немаловажному параметру, как соотношение расхода памяти на запрос, различие будет в разы и порядки.
31 окт 06, 00:50    [3332794]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить