Здравствуйте, eao197, Вы писали:

E>При дейсвительно маленьких файлах (намного меньше, чем одна логическая единица аллокации в файловой системе (сектор))

Сектор это единица аллокации на физическом диске (поэтому, собственно, и сектор). Единица аллокации ФС называется кластер, и обычно состоит из нескольких секторов (потому, собственно, и кластер).

E>Потребуется полнотекстовый поиск в файлах? Если вся информация хранится в текстовых файлах, то эффективный поиск по ним можно организовать даже подручными средствами (простейший (f)grep или системы ht://Dig). В случае СУБД потребуется связываться с действительно серьезными СУБД, предоставляющими возможности полнотекстового поиска (в PostgreSQL, насколько помню, есть что-то подобное).

Либо прикручивать готовый движек.

E>Какие требования к развертыванию/администрированию/сопровождению? Если задумывается продукт a-la почтового клиента или персональной настольной wiki системы, то использование полноценной тяжеловесной СУБД (типа MSSQL или PostgreSQL) может стать серьезным препятствием (хотя бы из-за размера дистрибутива). В этом случае решение на базе файловой системы может оказаться гораздо привлекательнее

Если забыть про embedded-версии СУБД.

Здравствуйте, eao197, Вы писали:
E>По идее, tar будет распаковывать файлы сразу, как только они окажутся полностью распакованны gunzip-ом.
Не, ребята, tar меня не интересует. Меня интересует ФС с поддержкой ACID.

Здравствуйте, Sinclair, Вы писали:

S>Не, ребята, tar меня не интересует. Меня интересует ФС с поддержкой ACID.

Я такой не знаю (чтобы в ACID входила модификация нескольких файлов или даже несколько отдельных модификаций одного файла).

Sinclair wrote:
> E>По идее, tar будет распаковывать файлы сразу, как только они окажутся
> полностью распакованны gunzip-ом.
> Не, ребята, tar меня не интересует. Меня интересует ФС с поддержкой ACID.
Reiser4FS — http://www.namesys.com/v4/v4.html

Reiser4 is an atomic filesystem, which means that your filesystem
operations either entirely occur, or they entirely don't, and they don't
corrupt due to half occuring. We do this without significant performance
losses, because we invented algorithms to do it without copying the data
twice.

Это буква "A", "C" обеспечивается журналированием, про "D" все понятно,
"I" — есть, но неполный.

Здравствуйте, eao197, Вы писали:

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

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

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

ФС как будто не представляют .

Здравствуйте, Quintanar, Вы писали:

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

Могут. Только я сильно удивлюсь, если производительность по доступу к файлам в каталоге с 1M файлов будет такой же, как и в каталоге с 1000 файлов.

E>>Будут ли обращения к файлам идти из одного приложения (даже если это приложение будет обслуживать нескольких пользователей) или из разных приложений?

Q>ФС как будто не представляют

Это вроде ручных блокировок (всего файла или его региона)?

eao197 wrote:
> Q>Ну что за дремучие представления о ФС. Не судите все их по уродцам
> типа ФАТ, да и NTFS не далеко ушла. Представьте себе, некоторые ФС могут
> и миллионы файлов в каталоге позволять иметь и хранить мелкие файлы по
> юолее эффективным схемам.
> Могут. Только я сильно удивлюсь, если производительность по доступу к
> файлам в каталоге с 1M файлов будет такой же, как и в каталоге с 1000
> файлов.
Удивляйся Тестировал Reiser4 — работает _очень_ быстро. Время
обращения к файлу по имени в каталоге на 200000 элементов и 1000 — не
отличается заметно. Поиск тоже очень шустро работает.

> E>>Будут ли обращения к файлам идти из одного приложения (даже если это
> приложение будет обслуживать нескольких пользователей) или из разных
> приложений?
> Q>ФС как будто не представляют
> Это вроде ручных блокировок (всего файла или его региона)?
Да.

Здравствуйте, Cyberax, Вы писали:

C>Удивляйся Тестировал Reiser4 — работает _очень_ быстро. Время
C>обращения к файлу по имени в каталоге на 200000 элементов и 1000 — не
C>отличается заметно. Поиск тоже очень шустро работает.

Точные бенчмарки можно в студию?

>> Это вроде ручных блокировок (всего файла или его региона)?
C>Да.

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

Здравствуйте, Cyberax, Вы писали:
>> Не, ребята, tar меня не интересует. Меня интересует ФС с поддержкой ACID.
C>Reiser4FS — http://www.namesys.com/v4/v4.html
А, отлично. Вот вам и ответ — если вы выбираете между файлухой и RDBMS, то выбирайте между RDBMS и ReiserFS v4. Все остальное будет плохо работать для всех случаев, кроме работы на уровне отдельных несвязанных файлов.

eao197 wrote:
> C>Удивляйся Тестировал Reiser4 — работает _очень_ быстро. Время
> C>обращения к файлу по имени в каталоге на 200000 элементов и 1000 — не
> C>отличается заметно. Поиск тоже очень шустро работает.
> Точные бенчмарки можно в студию?
Точные замеры делать лень Вот есть на их сайте:
http://www.namesys.com/benchmarks.html

В качестве примера реальной работы — поиск несуществующего файла в нашей
файлопомойке занимает 30 секунд в первый раз и 1.2 секунды во второй раз
(из кэша). В файлопомойке 522326 файлов и 14213 каталогов.

>> > Это вроде ручных блокировок (всего файла или его региона)?
> C>Да.
> Этот механизм еще вручную придется докручивать под свои нужды.
> Особенно, если возиться придется с регионами.
Согласен. Обычно нет смысла возиться с файлами, однако файлы — это самый
хороший способ работы с большими неструктурироваными (с точки зрения БД)
объемами информации.

Здравствуйте, kryl, Вы писали:
K>Я как раз сейчас занимаюсь этой темой. В системе, которую я обслуживаю, документы MS Office (в основном) хранятся в БД MSSQL-Server. Месяц назад обнаружилась проблема: при достижении 12000 документов начал проявляться эффект "кто-первый-встал-того-и-тапки" — первый процесс, сохранивший документ, блокирует ряд ресурсов, в связи с чем следующие пользователи при попытке сохранения документа вылетают по тайм-ауту. Кроме этого из-за возросшего объема БД ухудшились некоторые ее эксплуатационные характеристики.
Очень интересно. А тюнить БД и исправлять баги не пробовали?
Я кстати не имею опыта с хранением больших количеств больших документов в MS SQL. Хранение миллионов документов размером около 10K — легко. Никаких спецэффектов помимо совершенно привычных блокировок различных уровней гранулярности обнаружено не было, тем более блокирования ряда ресурсов при записи.

Здравствуйте, Cyberax, Вы писали:

C>Точные замеры делать лень Вот есть на их сайте:
C>http://www.namesys.com/benchmarks.html

Ты говорил про замер доступа к файлу в каталоге с 200000 файлов и в каталоге с 1000 файлов. В этой каше бенчмарков я с ходу такого теста не увидел.

C>В качестве примера реальной работы — поиск несуществующего файла в нашей
C>файлопомойке занимает 30 секунд в первый раз и 1.2 секунды во второй раз
C>(из кэша). В файлопомойке 522326 файлов и 14213 каталогов.

Это получается ~38 файлов на каталог. Совсем не много.

Кроме того, почему-то не принимается во внимание, что ReiserFS v4 может быть и не доступна (если продукт под Windows или BSD разрабатывается, да и не все Linux-оиды ReiserFS уважают).

C>Согласен. Обычно нет смысла возиться с файлами, однако файлы — это самый
C>хороший способ работы с большими неструктурироваными (с точки зрения БД)
C>объемами информации.

Это уже другой вопрос.

Merle wrote:
> C>С другой стороны, организовать в БД доступ к нструктурированым (с точки
> C>зрения БД) бинарным данным — получается плохо.
> Или получается плохо объяснить БД, что эти данные на самом деле
> структурированы...
Ну это я и имею в виду в словах "с точки зрения БД".

> C>Блобы работают в разы медленнее файлов в FS
> Смотря что с этими блобами делать, чтобы в разу получить, надо очень
> напрячься, лучше с помощником.
Да элементарно. Например, на записи большого объема данных это заметно.
Или на многочисленных seek'ах.

> C> и не поддерживают MM.
> Вот дались тебе эти ММ, тебеже уже дважды сказали, что ММ это конкретный
> способ работы с ФС, у БД есть свои конкретные способы для своих
> конкретных задач. Дело в задаче, а не в том как ты ее будешь решать.
MM — это не "конкретный способ работы", а фундаментальное преимущество
ФС. При использовании MM у нас может достигается zero-copy — данные
вообще не копируются в памяти, контроллер диска может их напрямую писать.

Реальные БД все же вносят значительный оверхед.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Теперь немножко законкретизируем это дело. Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные.

Все известные мне почтовые клиенты используют в качестве хранилища базы собственного формата. Т.е. не стандартные БД, а что-то своё, оптимизированное под задачу. The Bat! позволяет отдельно хранить аттачменты, что довольно удобно. Хранить каждое сообщение в отдельном файле в данном случае мне не кажется разумным по причине возможного количества сообщений. Я, например, свою почту никогде не удаляю (кроме спама, конечно). Если я на что-то подписан или участвую в какой-нибудь группе, то количество сообщений может запросто достигать нескольких десятков тысяч. Могут начаться тормоза, да и бэкапить это всё не фонтан.

Если речь идёт о почтовом сервере, то здесь по разному. В идеале сервер не хранит долго сообщения и работает в режиме постоянного добавления удаления данных. Если всё хранить в одном файле собственного формата, то очень быстро встанет проблема дефрагментации. Хранить в отдельных файлах, полагаясь на идеальный случай, когда пользователь всё прилежно выкачивает, тоже не надёжно. Проблема на RSDN, о которой я говорил, как раз и была связана с тем, что в ящике forum_сабака_rsdn.ru скопилось больше 100к писем с уведомлениями о проблемах e-mail'ов подписчиков форумов.

С другой стороны, на самом RSDN количество сообщений в БД превышает полтора миллиона, размер БД несколько гигабайт (точно не помню, около пяти), сообщения занимают больше 90% места в БД и вроде проблем больших именно с текстом нет.

Здравствуйте, eao197, Вы писали:

E>Ты говорил про замер доступа к файлу в каталоге с 200000 файлов и в каталоге с 1000 файлов. В этой каше бенчмарков я с ходу такого теста не увидел.

Там используется стандартная схема с Б-деревьями и хешем по имени. Это означает, что время поиска есть логарифм (причем с большим основанием) от числа файлов. 1.000.000 файлов в этом случае — это всего-то 5-6 чтений блока с диска в худшем случае. Только совсем уж древние ФС не используют эту схему, а используют линейный поиск.

Здравствуйте, Quintanar, Вы писали:


Q>Там используется стандартная схема с Б-деревьями и хешем по имени. Это означает, что время поиска есть логарифм (причем с большим основанием) от числа файлов. 1.000.000 файлов в этом случае — это всего-то 5-6 чтений блока с диска в худшем случае. Только совсем уж древние ФС не используют эту схему, а используют линейный поиск.
А по маске типа с ведущим * ???

Serginio1 wrote:

> Q>Там используется стандартная схема с Б-деревьями и хешем по имени. Это
> означает, что время поиска есть логарифм (причем с большим основанием)
> от числа файлов. 1.000.000 файлов в этом случае — это всего-то 5-6
> чтений блока с диска в худшем случае. Только совсем уж древние ФС не
> используют эту схему, а используют линейный поиск.
> А по маске типа с ведущим * ???
А что? СУБД будет себя лучше вести?
Говорилось же об обращении по точному имени. В FAT поиск линейный будет в любом случае, в отличие от.

Здравствуйте, IT, Вы писали:

ЗХ>>Теперь немножко законкретизируем это дело. Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные.

IT>Все известные мне почтовые клиенты используют в качестве хранилища базы собственного формата. Т.е. не стандартные БД, а что-то своё, оптимизированное под задачу.

Ммммм...

А так

Автор: Зверёк Харьковский
Дата: 27.02.06

, вот так

Автор: c-smile
Дата: 27.02.06

, и вот так

Автор: kan_izh
Дата: 27.02.06

? Ну и вот так еще, до кучи.

Здравствуйте, Зверёк Харьковский, Вы писали:

IT>>Все известные мне почтовые клиенты используют в качестве хранилища базы собственного формата. Т.е. не стандартные БД, а что-то своё, оптимизированное под задачу.

ЗХ>Ммммм...

ЗХ>А так

Автор: Зверёк Харьковский
Дата: 27.02.06

, вот так

Автор: c-smile
Дата: 27.02.06

, и вот так

Автор: kan_izh
Дата: 27.02.06

? Ну и вот так еще, до кучи.

Ну так и я о том же. Свой формат хранения, один или несколько файлов. Можно как The Bat! иметь пару файлов на каждую папку, файлы с сообщениями и индексами.

Здравствуйте, Зверёк Харьковский, Вы писали:

Не собираясь участвовать в дискуссии по существу (все уже сказали, что стоит), хочу лишь одно отметить — ИМХО высказанные мнения вполне подтверждают правильность идеи MS об интеграции FS и DB.

Один только вопрос — что из этой интеграции получится ? Будем надеяться, что не гибрид ужа с ежом.