LINUX.ORG.RU

Что использовать для создания удаленного файлового хранилища в локальной сети


0

1

Доброе утро!

Хочется посоветоваться по поводу создания файлового хранилища.

На данный момент есть самописное ПО, работающее внутри организации и использующее в качестве СУБД PostgreSQL. Возникла необходимость хранить файлы, которые привязаны к сущностям БД. Так как хранить файлы в БД - не комильфо, было решено хранить файлы в ФС, а в БД хранить только URI(путь до файла). Хранилище должно обеспечивать возможность гибкого разграничения прав доступа, т.е. права должны проверяться с помощью специально созданных таблиц в БД. Клиентcкое ПО написано на Delphi и работает под виндой.

На данный момент есть такая идея:

  • Ставим веб-сервер, который будет заниматься хранением и отдачей файлов после проверки прав доступа.
  • Загрузка файлов на сервер происходит по протоколу FTP во временный каталог (HTTP не самое лучшее решение для загрузки больших файлов).
  • Получение файлов происходит при переходе по ссылке вида http://srv.local/getfile.php?id=a337bc2622e4734baf
  • Ссылка генерируется при обращении к БД и наличии необходимых прав и является временной

Вроде все устраивает, но хочется реализовать следующее: После того как пользователь загрузил файл, отредактировал его, например в Word'e и сохранил, необходимо что-бы новая версия файла автоматически попала на сервер. Нечто типа WebDAV, но там, к сожалению не очень гибкая система разграничения прав и с помощью кода я не смогу рулить правами доступа к файлам (если я правильно все понял).

На какие технологии/библиотеки стоит обратить внимание? И как это лучше сделать?

Заранее спасибо!

> Так как хранить файлы в БД - не комильфо

SciDB же: http://www.opennet.ru/opennews/art.shtml?num=30983

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

Evgueni ★★★★★
()

> После того как пользователь загрузил файл, отредактировал его, например в Word'e и сохранил, необходимо что-бы новая версия файла автоматически попала на сервер

хм, мне кажется, или вы свою CVS пытается завелосипедить ?

x905 ★★★★★
()
Ответ на: комментарий от Evgueni

А вообще не вижу ни одной причины хранить файлы не в БД.

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

А вот по поводу причин хранения файлов не в БД:

  • Бэкапить БД размером 25Gb и файлы 2Tb сильно проще, чем БД размером 2.025Tb
  • БД не занимается не свойственной ей работой - отдача файлов. (в кэш не попадает всякий мусор)
  • Отдача файлов из БД в любом случае будет медленнее, чем из ФС (разве что файлов много и они мелкие)
  • Огромное количество способов организации файлового хранилища(куча протоколов, распределенные хранилища, куча ФС) в случае хранения файлов вне БД.

В PostgreSQL ранее была возможность хранить только ссылки на файлы, но потом они от этого отказались.

Вы про large object? Если да, то они и не думали отказываться, более того в 9 появилась возможность давать права на LO.

mongol1986
() автор топика
Ответ на: комментарий от x905

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

Вопрос в том - как автоматически после изменения файла пользователем обновить этот файл на сервере? В alfresco же работает как-то :(

mongol1986
() автор топика
Ответ на: комментарий от mongol1986

> Вы про large object? Если да, то они и не думали отказываться, более того в 9 появилась возможность давать права на LO.

large object в PostreSQL хранятся в БД вообще-то. Не в БД они хранились оооочень давно. Ну и сейчас, если я правильно понимаю blobы — это прошлый век. Правда бинарный тип данных больше пары гигобайт хранить пару лет назад не позволял

Бэкапить БД размером 25Gb и файлы 2Tb сильно проще, чем БД размером 2.025Tb

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

По остальным пунктам SciDB же. Плюс от БД — это возможность организовать единый доступ везде и относительное спокойствие за сохранность данных. А скорость тебе по ходу совершенно не важна.

Evgueni ★★★★★
()
Ответ на: комментарий от mongol1986

может морду к CVS написать, которая автоматом будет коммитить ?
или опиши подробнее какая задача решается этим набором софта

x905 ★★★★★
()
Ответ на: комментарий от mongol1986

> Боитесь появления мертвых ссылок?

да, например их
+ какой то механизм отсылки файлов на сервер )

В нормально написанной системе их не будет.


нормально написанную систему еще создать нужно и оттестировать
а такая система уже есть, называется СУБД )

x905 ★★★★★
()
Ответ на: комментарий от x905

>нормально написанную систему еще создать нужно и оттестировать

а такая система уже есть, называется СУБД )

Ну если файлов на 5GB, то можно не заморачиваться и хранить все в БД. Хотя я и не вижу особых проблем в написании функционала, который позволял бы хранить файлы на ФС.

Бэкапить в любом случае надо.

Вот именно, только сколько времени займет бэкап базы размером 2Tb? И сколько по времени будет занимать восстановление из дампа?

Организуй два живых сервера и постоянную репликацию между ними.

Сделать то можно без проблем, вот только это не отменяет необходимости в бэкапах. Да и зачем загружать сервер БД отдачей файлов? Пусть этим занимается файловое хранилище, к тому же файловое хранилище при надобности легко масштабировать. Да и стратегии резервного копирования могут быть раздельные. Базу можно и каждые 6 часов бэкапить. К тому же можно использовать разные уровни RAID-массивов и разные по производительности диски для файлов и для данных БД. Для БД RAID10 из X-дисков 15Krpm, а для файлов RAID5,6 из 7200rpm дисков.

По остальным пунктам SciDB же.

Надо будет почитать про нее.

А скорость тебе по ходу совершенно не важна.

С чего вы это взяли? Это вам видимо на нее плевать, если предлагаете 2Tb файлов загрузить в БД.

mongol1986
() автор топика
Ответ на: комментарий от mongol1986

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

почему, например, не нужно бэкапить файлы, которые связаны с сущностями в БД - почему они не так важны ?

x905 ★★★★★
()

так как никаких привязок к используемым языкам озвучено небыло, предложу java content repository c mixin:versionable

aol ★★★★★
()
Ответ на: комментарий от x905

всё же неплохо описать приблизительно задачу, решаемую системой

т.к. возможно более конкретно чтото сказать будет

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

  • Пользователь видит через клиентское ПО список файлов
  • Скачивает файл
  • Редактирует его, например в ворде
  • Сохраняет
  • После закрытия ворда файл должен автоматически обновиться на сервере

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

почему, например, не нужно бэкапить файлы, которые связаны с сущностями в БД - почему они не так важны ?

С чего Вы взяли, что бэкапить файлы не надо? Обязательно надо.

так как никаких привязок к используемым языкам озвучено небыло, предложу java content repository c mixin:versionable

Клиентское ПО написано на Delphi

mongol1986
() автор топика
Ответ на: комментарий от mongol1986

> С чего Вы взяли, что бэкапить файлы не надо? Обязательно надо.

сорри, скосоглазил на чужой пост

мне думается, что клиентское ПО, написанное на Delphi, и должно отсылать файлы туда и обратно, например по сокетам (тут придется дописать демон на стороне сервера) или же через LO объекты постгреса (мне это вариант больше нравиться)

x905 ★★★★★
()
Ответ на: комментарий от Evgueni

По остальным пунктам SciDB же.

SciDB не похожа на классические СУБД и в ущерб поддержке некоторых привычных возможностей оптимизирована для обработки и анализа «сырых» данных, которые интенсивно читаются, но почти не изменяются. СУБД не рассчитана на обработку транзакций в реальном времени (OLTP), не поддерживает ACID (атомарность, непротиворечивость, изоляция, долговечность) и журналирование, обеспечивая транзакции лишь на минимальном уровне.

Эта СУБД еще подходит для хранения файлов, но у нас то PostgreSQL. И когда я говорил про хранение файлов в БД, то в качестве СУБД имел ввиду PostgreSQL.

И в чем преимущество хранения файлов в SciDB по сравнению с хранением в ФС? От всего функционала SciDB мне понадобится только запись и чтение файла + есть некий версионный контроль. У меня не научные данные, мне не надо проводить обработку этих данных в БД.

mongol1986
() автор топика
Ответ на: комментарий от x905

>мне думается, что клиентское ПО, написанное на Delphi, и должно отсылать файлы туда и обратно, например по сокетам (тут придется дописать демон на стороне сервера) или же через LO объекты постгреса (мне это вариант больше нравиться)

С самой отсылкой данных проблем нет. Проблема в том, как отловить момент, когда нужно отсылать данные назад на сервер.

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

mongol1986
() автор топика
Ответ на: комментарий от mongol1986

> Проблема в том, как отловить момент, когда нужно отсылать данные назад на сервер

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

x905 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.