[Moscow.pm] Доклад на хайлоад: psql fs

Vladimir Timofeev vovkasm на gmail.com
Вт Окт 9 02:36:56 PDT 2012


9 октября 2012 г., 12:59 пользователь Михаил Монашёв
<postmaster на softsearch.ru> написал:
> Здравствуйте, Dmitry.
>
snip...
> Я  бы  здесь  обсудил,  ибо  это  удобнее.  Идти куда-то не хочется. А
> сказать   мне  есть  что.  Например,  в  языках  программирования  для
> увеличения  скорости  работы с большими объектами используют указатели
> на  объекты. Так и у тебя можно: файлы лежат в хранилище неподвижно, а
> работаешь   ты   только  с  описаниями  этих  файлов,  содержащих  всю
> необходимую  инфу  о  файле, включая его местоположение в хранилище. C
> хранилищем работать можно через WebDAV.

Меня тоже занимает эта проблема в основном в свете конкретных
плюсов/минусов хранения блобов в БД.
Сейчас у меня мысли следующие:
1. Если строить архитектуру так, что хранить файлы в FS, а в БД только
мета-инфу о них.
+ надежно, проверенно временем
- сложно, нужны механизмы синхронизации мета-информации с контентом,
обо всем этом надо задумываться
  * а если файл удалили в FS?
  * а как написать код, который, если не получилось сохранить файл не
запишет в БД мета-инфу и наоборот...
  * а что с расширяемостью? с миграцией файлов? и т.д. и т.п.
- сложно организовать контроль доступа
2. Если держать в БД целиком все, вместе с контентом
+ многие вещи упрощаются, логически единый интерфейс, транзакционность
- стремно, как современные БД себя при этом ведут, что у них с расширяемостью
- а что с производительностью, придется контент гонять не
супер-оптимизированным решением fs->front->user, а странным
bd->backend->front->user, страшновато
+ контроль доступа реализуется "на ура", т.к. все через бэк гонится

Есть более контретные мысли?


-- 
Vladimir Timofeev <vovkasm на gmail.com>


Подробная информация о списке рассылки Moscow-pm