Tue, 9 Oct 2012 13:36:56 +0400 от Vladimir Timofeev <[email protected]>: > > > > >9 октября 2012 г., 12:59 пользователь Михаил Монашёв > <[email protected]> написал: > > Здравствуйте, Dmitry. > > > snip... > > Я бы здесь обсудил, ибо это удобнее. Идти куда-то не хочется. А > > сказать мне есть что. Например, в языках программирования для > > увеличения скорости работы с большими объектами используют указатели > > на объекты. Так и у тебя можно: файлы лежат в хранилище неподвижно, а > > работаешь ты только с описаниями этих файлов, содержащих всю > > необходимую инфу о файле, включая его местоположение в хранилище. C > > хранилищем работать можно через WebDAV. > > Меня тоже занимает эта проблема в основном в свете конкретных > плюсов/минусов хранения блобов в БД. > Сейчас у меня мысли следующие: > 1. Если строить архитектуру так, что хранить файлы в FS, а в БД только > мета-инфу о них. > + надежно, проверенно временем > - сложно, нужны механизмы синхронизации мета-информации с контентом, > обо всем этом надо задумываться > * а если файл удалили в FS? > * а как написать код, который, если не получилось сохранить файл не > запишет в БД мета-инфу и наоборот... > * а что с расширяемостью? с миграцией файлов? и т.д. и т.п. > - сложно организовать контроль доступа > 2. Если держать в БД целиком все, вместе с контентом > + многие вещи упрощаются, логически единый интерфейс, транзакционность > - стремно, как современные БД себя при этом ведут, что у них с расширяемостью > - а что с производительностью, придется контент гонять не > супер-оптимизированным решением fs->front->user, а странным > bd->backend->front->user, страшновато > + контроль доступа реализуется "на ура", т.к. все через бэк гонится > > Есть более контретные мысли? > > > -- > Vladimir Timofeev <[email protected]> > -- > Moscow.pm mailing list >[email protected] | http://moscow.pm.org > Ну, во-первых: Доступ через http://labs.frickle.com/nginx_ngx_postgres/ будет быстрым. Во-вторых: Если все хранить в базе, то рано или поздно, как тут уже говорили, будет шардинг и паралелелизм... Шардинг в Пг делается руками (сори), но не требует изменения приложения. Если обсуждаем шардинг с паралелелизмом и многими нодами, то: 1) Мастер сервер, который управляет мета информацией. В него идут запросы на поиск файла и т.д. Результатом работы - данные, которые позволят создать ссылку на конкретную ноду, где хранится фаил (ее отрабатывает уже nginx) Сам мастер сервер умеет коннектится ко всем шардам (через dblink и через async_select выбирать данные), таким образом время поиска разбивается на все ноды. 2) Нода Это или 1 сервер или группа серверов, объединенных через pg_bouncer. Возьмем 2-й вариант: В ноде есть мастер сервер, куда идут апдейты (про них позже) и сервера, на которые идут реплика. С них можно читать. Эта схема реализуется Пг из коробки (маны в соотв. месте). На ноду вещается nginx (или отдельный сервер или рядом с мастером... Зависит от нагрузок), который отдает файлы. Теперть про апдейты: К сожалению 2-хфазного коммита в Пг еще нету, однако последовательности атомарны, поэтому сначала вытаскиваем следующий id, а потом по нему или с приложухи коннектимся к необходимой ноде или прям из мастера, но хранимкой, которая сама разберется куда ей надо. Это что касается архитектуры железа. Архитектура хранения... Их вообще много: 1) Все в одной табличке. Это делают только альтернативно одаренные люди, коих тут, я надеюсь, нету. Минусы: - Большое количество записей, большие индексы, таблица большая и требует поднимать данные в кеш. Дело в том, что в Пг первые что-ли 250 байт от блоба (а строки тут работают так-же как и блобы) хранится в самой записи. - Апдейт - это страшно. Дело в том, что в Пг апдейт происходит по принципу INSERT/DELETE... А это коипрование всего блоба. - Еще дофига всего 2) Мета отдельно, файлы отдельно. Уже лучше. Более того, мету можно партицировать. Все зависит от количества данных в мете. Плюсы: - Изменение мета-информации довольно быстрое. - Если пользуется партицирование, то и индексы в кеше сидят, что ускоряет запросы. Минусы: - Пока не нашел. Как-то так.
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
