Добрый день!

Начинаем новый проект в котором данные должны храниться в базе данных. Данные это в основном информация о пользователях и устройствах, которые используются пользователями. По идее здесь идеально подходит реляционная база данных, остановились на PosgreSQL. Но есть одна загвоздка: помимо данных о пользователе, ещё нужно хранить документы (pdf и ppt файлы), которые принадлежат этим пользователям и также фото самих пользователей. Вроде PostgreSQL для этого не совсем подходит. Вопрос как это лучше организовать, чтобы не было потом проблем? Прикручивать ещё одну NOSQL BD и организовывать там хранилище документов? Или есть другой элегантный способ?

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

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

I>Добрый день!

I>Начинаем новый проект в котором данные должны храниться в базе данных. Данные это в основном информация о пользователях и устройствах, которые используются пользователями. По идее здесь идеально подходит реляционная база данных, остановились на PosgreSQL. Но есть одна загвоздка: помимо данных о пользователе, ещё нужно хранить документы (pdf и ppt файлы), которые принадлежат этим пользователям и также фото самих пользователей. Вроде PostgreSQL для этого не совсем подходит. Вопрос как это лучше организовать, чтобы не было потом проблем? Прикручивать ещё одну NOSQL BD и организовывать там хранилище документов? Или есть другой элегантный способ?

I>Заранее спасибо
Элегантных способов вагон. Практически любая современная СУБД поддерживает хранение двоичных объектов(фото/видео и прочая музыка)

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

Элегантных способов вагон. Практически любая современная СУБД поддерживает хранение двоичных объектов(фото/видео и прочая музыка)

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

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

I>Добрый день!

I>Начинаем новый проект в котором данные должны храниться в базе данных. Данные это в основном информация о пользователях и устройствах, которые используются пользователями. По идее здесь идеально подходит реляционная база данных, остановились на PosgreSQL. Но есть одна загвоздка: помимо данных о пользователе, ещё нужно хранить документы (pdf и ppt файлы), которые принадлежат этим пользователям и также фото самих пользователей. Вроде PostgreSQL для этого не совсем подходит. Вопрос как это лучше организовать, чтобы не было потом проблем? Прикручивать ещё одну NOSQL BD и организовывать там хранилище документов? Или есть другой элегантный способ?

I>Заранее спасибо

Зачем прикручивать какое то nosql для хранения файлов? Если уж постгрес по каким то причинам не устроит, чем файловая система может не устраивать? Самый, что ни на есть, NoSQL для хранения файлов

А вообще вроде нормально в постгресе файлы хранятся. Не знаю, какие могут быть проблемы. Проведите тесты. Если аккуратно всё писать, думаю всё нормально будет работать.

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

Зачем прикручивать какое то nosql для хранения файлов? Если уж постгрес по каким то причинам не устроит, чем файловая система может не устраивать? Самый, что ни на есть, NoSQL для хранения файлов

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

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

I>Это понятно. Только дело в том, что не всегда это рекомендуется делать. Насколько я слышал, при больших обьёмах бинарных данных, падает быстродействие самой СУБД. Насколько это верно не знаю, поэтому здесь и спрашиваю.

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

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

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

I>

I>Зачем прикручивать какое то nosql для хранения файлов? Если уж постгрес по каким то причинам не устроит, чем файловая система может не устраивать? Самый, что ни на есть, NoSQL для хранения файлов

I>Файловая система не подходит по тем причинам, что пишеться сетевое приложение со множеством клиентов на различных платформах. Основной клиент на Андроиде. Плюс нужно регулировать доступ к файлам.

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

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

I> Но есть одна загвоздка: помимо данных о пользователе, ещё нужно хранить документы (pdf и ppt файлы), которые принадлежат этим пользователям и также фото самих пользователей.

А сколько таких файлов планируется, их объем, как часто они будут меняться/запрашиваться?

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

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

Интересно было бы почитать на эту темую. Я только слышал, что реляционная база данных не совсем подходит для сохранение бинарных данных (файлов) и использование реляционной БД как хранилища документов в последствии приводит к "раздуванию" базы данный и к потере производительности.

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

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

Тут мы тоже пока не опредились как будем делать. Рассматриваем три варианта:
1) Раздача через FTP Сервер:
Пункты "против"
— Дополнительная установка FTP сервера.
— Прекручивание FTP клиента на приложениях
2)Раздача через Web сервер
Пункты "против"
— Дополнительная установка Web сервера
— Общий доступ к документам для всех клиентов без авторизации
3) Раздача через сервер, который служит для управления приложениями
Пункты "против"
— Расширение протокола, имплементация передачи документов

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

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

I>

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

I>Интересно было бы почитать на эту темую. Я только слышал, что реляционная база данных не совсем подходит для сохранение бинарных данных (файлов) и использование реляционной БД как хранилища документов в последствии приводит к "раздуванию" базы данный и к потере производительности.

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

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

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

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

Я бы поправил, что почти "Всегда можно нужно вынести хранение бинарных данных в отдельную таблицу"
I>Интересно было бы почитать на эту темую.
Что мешает почитать?

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

I>> Но есть одна загвоздка: помимо данных о пользователе, ещё нужно хранить документы (pdf и ppt файлы), которые принадлежат этим пользователям и также фото самих пользователей.

AB>А сколько таких файлов планируется, их объем, как часто они будут меняться/запрашиваться?

Всё зависит как клиент будет использовать систему. Система разрабатывается для управления конференциями. Для одной конференции может быть загружено от 2 до 20 файлов. Конференции могут быть раз в неделю, а могут буть каждый день.

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

I>>Интересно было бы почитать на эту темую.
P>Что мешает почитать?

Ничего не мешает. Главное знать только где. Если кинете ссылку буду признателен.

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

I>Интересно было бы почитать на эту темую. Я только слышал, что реляционная база данных не совсем подходит для сохранение бинарных данных (файлов) и использование реляционной БД как хранилища документов в последствии приводит к "раздуванию" базы данный и к потере производительности.

В наши дни некоторые реляционные СУБД позволяют использовать альтернативные варианты хранения неструктурированных данных. Например, Microsoft реализовала технологию FileTable, которая базируется на атрибуте FileStream. Преимуществом данного подхода по сравнению с обычным хранением данных в таблице или на диске + метаданные в таблице является:

• Возможность нетранзакционного доступа через файловую систему Windows
  
• Данные, не кэшируются в буферном кэше SQL Server, а кэшируются в системном кэше ОС Windows
  
• Размер BLOB файла ограничивается размерами самой файловой системы
  
• Возможность использовать транзакционный доступ с помощью инструкций insert, update, delete, select
  
• Доступны встроенные средства безопасности, резервного копирования/восстановления, полнотекстовый поиск и т.п.

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

I>Добрый день!

I>Начинаем новый проект в котором данные должны храниться в базе данных. Данные это в основном информация о пользователях и устройствах, которые используются пользователями. По идее здесь идеально подходит реляционная база данных, остановились на PosgreSQL. Но есть одна загвоздка: помимо данных о пользователе, ещё нужно хранить документы (pdf и ppt файлы), которые принадлежат этим пользователям и также фото самих пользователей. Вроде PostgreSQL для этого не совсем подходит.

Почему же, вполне себе подходит. BLOB-ы есть везде.
Кроме того, можно хранить бинарные документы вовне БД, а в БД хнанить на них только сссылки (URI).

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

I>Это понятно. Только дело в том, что не всегда это рекомендуется делать.

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

I> Насколько я слышал, при больших обьёмах бинарных данных, падает быстродействие самой СУБД. Насколько это верно не знаю, поэтому здесь и спрашиваю.

Это не так. Обычно все BLOB-ы хранятся физически отдельно от основных данных таблиц, их можно даже выносить на физически отдельные диски, если
СУБД это позволяет (обычно позволяют).

Производительность доступа к нормальным реляционным данным при этом не страдает.

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

I>Заранее спасибо

Для начала рекомендую ознакомиться со следующим документом — http://research.microsoft.com/pubs/64525/tr-2006-45.pdf . Он позволит вам понять все плюсы и минусы, анализ общий не только для SQL Server.

Коротко по делу: я считаю хранение blob в db плохой практикой для web app. Просто потому что in fact это статика и therefore для ее раздачи современные веб-серверы используют очень быстрые методы раздачи (напр. nginx). Это конечно невозможно в случае если вы фетчите blobs from database.
Поэтому храните как файлы с привязкой к db по линкам/идентификаторам.

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

Спасибо за документ.

Коротко по делу: я считаю хранение blob в db плохой практикой для web app. Просто потому что in fact это статика и therefore для ее раздачи современные веб-серверы используют очень быстрые методы раздачи (напр. nginx). Это конечно невозможно в случае если вы фетчите blobs from database.
Поэтому храните как файлы с привязкой к db по линкам/идентификаторам.

Да, в принципе использование БД для раздачи магобайтных файлов может увеличить время обработки SQL запросов. Поэтому скорее всего надо для раздачи файлов использовать дополнительный ресурс (Web, Ftp ..). Минус — в системе появляется ещё один сервер.

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

Это не так. Обычно все BLOB-ы хранятся физически отдельно от основных данных таблиц, их можно даже выносить на физически отдельные диски, если
СУБД это позволяет (обычно позволяют).

Производительность доступа к нормальным реляционным данным при этом не страдает.

Здесь я с вами не соглашусь. Если СУБД будет подгружена раздачей файлов, то и реакция на SQL запросы будет замедленной из-за параллельной работы (раздача и обработка запросов).