[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