Господа, всем высказавшимся спасибо огромное, вроде бы поумнел немножко (личное спасибо IT и Владу, поскольку это ближе всего к тому что хотел услышать)

Теперь немножко законкретизируем это дело. Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные. Мое чувство прекрасного почему-то подсказывает мне схему "БД с метаданными + каждое сообщение в отдельном файле". Честно говоря, логично обосновать такую схему мне тяжело (кроме как уже упомянутым "чувством прекрасного" и некоторым соображениями о независимости сущностей-сообщений друг от друга и от базы: типа, даже если БД удалить или программу снести, информация останется доступна). Очень ли это глупо?

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

ЗХ>Теперь немножко законкретизируем это дело. Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные. Мое чувство прекрасного почему-то подсказывает мне схему "БД с метаданными + каждое сообщение в отдельном файле". Честно говоря, логично обосновать такую схему мне тяжело (кроме как уже упомянутым "чувством прекрасного" и некоторым соображениями о независимости сущностей-сообщений друг от друга и от базы: типа, даже если БД удалить или программу снести, информация останется доступна). Очень ли это глупо?

Одно из двух: либо очень глупо, либо ты чего-то недоговариваешь о требованиях.

Здравствуйте, Quintanar, Вы писали:
Q>Это и ФС умеют, хотя сочетания всех этих качеств сейчас, может, и не найти, такая ФС не за горами.
Гм. А можно мне показать FS, в которой я могу атомарно изменить несколько файлов? А то у меня вечная с этим проблема — всякие частичные аплоады и прочая муть. Ну или хотя бы изменить один файл, но атомарно — то есть чтобы я начал запись, изменил произвольный объем, а потом у меня exception вылетел и я сделал rollback. Который бы изменил состояние обратно на то, которое было перед транзакцией.

Sinclair,

S>Гм. А можно мне показать FS, в которой я могу атомарно изменить несколько файлов?

Удивительная вещь: на ext3 я разархивировал большой архив, затем этот процесс был убит во время разархивации. После этого посмотрел содержимое диска — как будто ничего не разархивировал.

Эксперимент повторил несколько раз — результат стабильный.

Это то, о чём ты говоришь?

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

C>AndrewVK wrote:
>> C>Еще FS очень хорошо работает с кусками бинарных данных. Покажите мне как
>> C>сделать memory mapped file в БД.
>> А зачем? MMF это уже конкретное решение, а не задача.
C>Тем не менее, это один из самых быстрых и удобных методов работы с
C>файлами. С БД такое уже не проходит.
Смотря какая БД. Если говорить о встроенных БД то никаких ограничений нет. ООБД, навигационный доступ итд.
Все зависит от величины абстракции и применяемых подходов для более оптимального хранения информации и более быстрого доступа , SQL для большинства задач просто неподходит,

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

LCR>Это то, о чём ты говоришь?
Да-да. Именно оно. Очень надо. А это работает правильно даже при переписывании файлов? Ну то есть был у меня каталог версии 1.0, я поверх него начал накатывать версию 1.2 (кто-то добавился, кто-то изменился), а потом раз — и прибил процесс посередине. К версии 1.0 откатит?

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

ЗХ>Господа, всем высказавшимся спасибо огромное, вроде бы поумнел немножко (личное спасибо IT и Владу, поскольку это ближе всего к тому что хотел услышать)

ЗХ>Теперь немножко законкретизируем это дело. Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные. Мое чувство прекрасного почему-то подсказывает мне схему "БД с метаданными + каждое сообщение в отдельном файле". Честно говоря, логично обосновать такую схему мне тяжело (кроме как уже упомянутым "чувством прекрасного" и некоторым соображениями о независимости сущностей-сообщений друг от друга и от базы: типа, даже если БД удалить или программу снести, информация останется доступна). Очень ли это глупо?
Мой опыт показывает, что для конкретно такой ситуации СУБД как минимум справляется. Почтовик на java+ms sql разгребал порядка миллиона писем в сутки без особого напряга. Машинка была послабже чем у меня сейчас рабочий комп. Конкретно мой опыт был еще и в том, что альтернативная софтина, построенная чисто поверх файлухи, сливала со страшной силой, но возможно там кривые руки авторов повлияли, а не сама файлуха.
Если БД удалить, то файлы автоматически станут мусором — без метаданных они мертвы. Кроме того, тебе всегда придется мучиться вопросом, что произойдет, если какой-нибудь шустрый антивирус решит убить файл без твоего ведома. Появятся фантомы в базе. Опять же, тебе придется мучиться с реализацией транзакции, распределенной поверх СУБД и файлухи (даже если сама файлуха это поддерживает). Ну или ты встрянешь в долговременную борьбу с косяками в базе: будешь писать Recovery Tool, хранить избыточную информацию, подписываться на оповещения об изменениях файлов, и т.п.

Sinclair,

S>Да-да. Именно оно. Очень надо. А это работает правильно даже при переписывании файлов?

Проверю ближе к вечеру. Сейчас нужно поработать под виндой.

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

ЗХ>Господа, всем высказавшимся спасибо огромное, вроде бы поумнел немножко (личное спасибо IT и Владу, поскольку это ближе всего к тому что хотел услышать)

ЗХ>Теперь немножко законкретизируем это дело. Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные. Мое чувство прекрасного почему-то подсказывает мне схему "БД с метаданными + каждое сообщение в отдельном файле". Честно говоря, логично обосновать такую схему мне тяжело (кроме как уже упомянутым "чувством прекрасного" и некоторым соображениями о независимости сущностей-сообщений друг от друга и от базы: типа, даже если БД удалить или программу снести, информация останется доступна). Очень ли это глупо?

Ага, теперь можно законкретизировать ответ...

"почтовики" хранят свою информацию в последовательных файлах
например в unix это mbox.
Отдельно (в отдельных файлах) хранятся индексы. И в этом есть великий смысл.

В качестве реального решения я бы порекомендовал движки на базе dBase III/IV
например http://linux.techass.com/projects/xdb/

Для сэбэ я бы сделал это на dybase от сам знаешь кого — для твоей задачи это оно.

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

LCR>Удивительная вещь: на ext3 я разархивировал большой архив, затем этот процесс был убит во время разархивации. После этого посмотрел содержимое диска — как будто ничего не разархивировал.

LCR>Эксперимент повторил несколько раз — результат стабильный.

Какой был архив (tar.gz (tar.bz2))? На какой стадии произошло убийство?

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

CS>Ага, теперь можно законкретизировать ответ...

CS>"почтовики" хранят свою информацию в последовательных файлах
CS>например в unix это mbox.

Но и Maildir имеет место быть. Говорят, второй по распространенности на nix-системах.

CS>Отдельно (в отдельных файлах) хранятся индексы. И в этом есть великий смысл.

Ну, это-то понятно.

eao197,

LCR>>Эксперимент повторил несколько раз — результат стабильный.

E>Какой был архив (tar.gz (tar.bz2))? На какой стадии произошло убийство?

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

Всё возможно.

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

ЗХ>Теперь немножко законкретизируем это дело. Предположим некоторую систему вроде почтовика или Януса — хранится большое количество относительно коротких текстов + их метаданные. Мое чувство прекрасного почему-то подсказывает мне схему "БД с метаданными + каждое сообщение в отдельном файле". Честно говоря, логично обосновать такую схему мне тяжело (кроме как уже упомянутым "чувством прекрасного" и некоторым соображениями о независимости сущностей-сообщений друг от друга и от базы: типа, даже если БД удалить или программу снести, информация останется доступна). Очень ли это глупо?

Опять же, все зависит от множества факторов.

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

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

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

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

Какие требования к развертыванию/администрированию/сопровождению? Если задумывается продукт a-la почтового клиента или персональной настольной wiki системы, то использование полноценной тяжеловесной СУБД (типа MSSQL или PostgreSQL) может стать серьезным препятствием (хотя бы из-за размера дистрибутива). В этом случае решение на базе файловой системы может оказаться гораздо привлекательнее (и примеры таких решений можно по(д)смотреть в открытых почтовиках KMail, Sylpheed или Thunderbird, а так же в DBMS-less Wiki системах, вроде MoinMoin или Instiki). Если же планируется server-side продукт, то преимущества тяжеловесных СУБД могут значительно перевешивать их недостатки (см. выше). Хотя тогда могут возникать вопросы с переносимости решения (как на разные платформы, так и на разные СУБД).

Какой характер (мета)информации предполагается хранить и какие способы обработки? Если планируются частые операции выборки/поиска по разным критериям, тогда РСУБД будут вне конкуренции (это их вотчина). С другой стороны, если речь идет о чем-то вроде Wiki, с иерархической структурой информации, то можно вообще обходиться без СУБД и даже метаинформацию хранить в самих файлах (по аналогии с заголовками http-запросов). С иерархической информацией связан еще один вопрос: нужно будет перепривязывать узлы? Например, был projects/super/puper/cool.txt, а потребовалось puper/cool.txt переместить в soap_bubble/bums/puper/cool.txt. В некоторых случаях решение на файлах может быть проще, а может и сложнее. И здесь еще один вопрос -- ссылочная целостность. Но это вообще отдельная песня.

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

---

Не об очередой ли Wiki системе идет речь?

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

ЗХ> Мое чувство прекрасного почему-то подсказывает мне схему "БД с метаданными + каждое сообщение в отдельном файле".
Ну, вообщем-то все уже описал Синклер, но в качестве проверки предлагаю задать своему чувству прекрасного следующие вопросы:
— Каким образом будет происходить бакап файлов и восстановление их после какого-нибудь сбоя так, чтобы это не разъехалось с БД?
— Каким образом будет обеспечиваться согласованность при работе с файлами и согласованность файлов и метаданных в БД?
Если чувство прекрасного даст четкий и внятный ответ на эти вопросы, то можешь смело приступать к реализации..

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

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

Нет, просто tar.gz (tar.bz2) -- это реально два архива. Сжатый файловый архив. Сначала идет распаковка tar-файла, а затем извлечение из tar-а самих файлов. Могло быть так, что tar не разворачивал свой архив до тех пор, пока не распаковался gz(bz2) образ.

Ты для эксперимента попробуй сначала отдельно распаковать gz (bz2) в tar, а затем уже прерывай работу tar-а.

eao197, Синклер, и остальные.

Прошу прощения за дезу. Только что проверил на rar-е, фича не воспроизводится. (*здесь должна быть иконка харакири*)

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

LCR>Прошу прощения за дезу. Только что проверил на rar-е, фича не воспроизводится. (*здесь должна быть иконка харакири*)

Можешь на tar-е через конвейер проверить, что-то вроде (с опциями команд могу ошибаться):

gunzip some_archive.tar.gz | tar x

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

Зверёк Харьковский wrote:

> CS>"почтовики" хранят свою информацию в последовательных файлах
> CS>например в unix это mbox <http://en.wikipedia.org/wiki/Mbox&gt;.
>
> Но и Maildir <http://en.wikipedia.org/wiki/Maildir&gt; имеет место быть.
> Говорят, второй по распространенности на nix-системах.

И притом рекомендуется использовать именно Maildir, т.к. он более устойчив к сбоям.
mbox — deprecated.

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

ЗХ>Если у кого-то есть свои мысли поделиться — тоже интересно; но в первую очередь — "уже готовое".

Я как раз сейчас занимаюсь этой темой. В системе, которую я обслуживаю, документы MS Office (в основном) хранятся в БД MSSQL-Server. Месяц назад обнаружилась проблема: при достижении 12000 документов начал проявляться эффект "кто-первый-встал-того-и-тапки" — первый процесс, сохранивший документ, блокирует ряд ресурсов, в связи с чем следующие пользователи при попытке сохранения документа вылетают по тайм-ауту. Кроме этого из-за возросшего объема БД ухудшились некоторые ее эксплуатационные характеристики.
Поскольку:
1) мне идея хранить файлы в БД с самого начала не нравилась (был опыт эксплуатации системы с подобным подходом),
2) начальник уклончиво-против перейти на хранение файлов в файловой системе;
я пришел к "оригинальному" решению: хранить и там и там. Так сказать, использовать преимущество обоих подходов. Основное хранение файлов — в FS, в БД хранятся их зазипованные версии.
Ссылок дать не могу по причине их отсутствия, однако можно посотрудничать на взаимовыгодной основе, учитывая мой опыт эротических взаимоотношений с этим хозяйством. Я, например, в текущий момент подбираю алгоритм сжатия: с одной стороны чтоб хорошо сжимал документы Office, а с другой, чтоб декомпрессор можно было бы полегче переписывать в среде VBA.

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

CS>например в unix это mbox.

В унихах это так вследствии тяжелого наследия UUCP.