<HTML><BODY><br><br><br>Tue, 9 Oct 2012 13:36:56 +0400 от Vladimir Timofeev <vovkasm@gmail.com>:<br>
<blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;" class="mailru-blockquote">
<div id=""><div class="js-helper js-readmsg-msg">
<style type="text/css"></style>
<div id="style_13497754430000000750" class="mr_read__body">
<base target="_self" href="https://e.mail.ru/cgi-bin/">
<div id="style_13497754430000000750_BODY">9 октября 2012 г., 12:59 пользователь Михаил Монашёв<br>
<<a href="sentmsg?compose&To=postmaster@softsearch.ru">postmaster@softsearch.ru</a>> написал:<br>
> Здравствуйте, Dmitry.<br>
><br>
snip...<br>
> Я бы здесь обсудил, ибо это удобнее. Идти куда-то не хочется. А<br>
> сказать мне есть что. Например, в языках программирования для<br>
> увеличения скорости работы с большими объектами используют указатели<br>
> на объекты. Так и у тебя можно: файлы лежат в хранилище неподвижно, а<br>
> работаешь ты только с описаниями этих файлов, содержащих всю<br>
> необходимую инфу о файле, включая его местоположение в хранилище. C<br>
> хранилищем работать можно через WebDAV.<br>
<br>
Меня тоже занимает эта проблема в основном в свете конкретных<br>
плюсов/минусов хранения блобов в БД.<br>
Сейчас у меня мысли следующие:<br>
1. Если строить архитектуру так, что хранить файлы в FS, а в БД только<br>
мета-инфу о них.<br>
+ надежно, проверенно временем<br>
- сложно, нужны механизмы синхронизации мета-информации с контентом,<br>
обо всем этом надо задумываться<br>
* а если файл удалили в FS?<br>
* а как написать код, который, если не получилось сохранить файл не<br>
запишет в БД мета-инфу и наоборот...<br>
* а что с расширяемостью? с миграцией файлов? и т.д. и т.п.<br>
- сложно организовать контроль доступа<br>
2. Если держать в БД целиком все, вместе с контентом<br>
+ многие вещи упрощаются, логически единый интерфейс, транзакционность<br>
- стремно, как современные БД себя при этом ведут, что у них с расширяемостью<br>
- а что с производительностью, придется контент гонять не<br>
супер-оптимизированным решением fs->front->user, а странным<br>
bd->backend->front->user, страшновато<br>
+ контроль доступа реализуется "на ура", т.к. все через бэк гонится<br>
<br>
Есть более контретные мысли?<br>
<br>
<br>
-- <br>
Vladimir Timofeev <<a href="sentmsg?compose&To=vovkasm@gmail.com">vovkasm@gmail.com</a>><br>
-- <br>
Moscow.pm mailing list<br>
<a href="sentmsg?compose&To=moscow%2dpm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</div>
<base target="_self" href="https://e.mail.ru/cgi-bin/">
</div>
</div>
</div>
</blockquote>
Ну, во-первых: Доступ через <a href="http://labs.frickle.com/nginx_ngx_postgres/" data-mce-href="http://labs.frickle.com/nginx_ngx_postgres/">http://labs.frickle.com/nginx_ngx_postgres/</a> будет быстрым.<br>Во-вторых: Если все хранить в базе, то рано или поздно, как тут уже говорили, будет шардинг и паралелелизм...<br>Шардинг в Пг делается руками (сори), но не требует изменения приложения.<br><br>Если обсуждаем шардинг с паралелелизмом и многими нодами, то:<br>1) Мастер сервер, который управляет мета информацией.<br>В него идут запросы на поиск файла и т.д. Результатом работы - данные, которые позволят создать ссылку на конкретную ноду, где хранится фаил (ее отрабатывает уже nginx)<br>Сам мастер сервер умеет коннектится ко всем шардам (через dblink и через async_select выбирать данные), таким образом время поиска разбивается на все ноды.<br>2) Нода Это или 1 сервер или группа серверов, объединенных через pg_bouncer. Возьмем 2-й вариант:<br>В ноде есть мастер сервер, куда идут апдейты (про них позже) и сервера, на которые идут реплика. С них можно читать. Эта схема реализуется Пг из коробки (маны в соотв. месте).<br>На ноду вещается nginx (или отдельный сервер или рядом с мастером... Зависит от нагрузок), который отдает файлы.<br><br>Теперть про апдейты: К сожалению 2-хфазного коммита в Пг еще нету, однако последовательности атомарны, поэтому сначала вытаскиваем следующий id, а потом по нему или с приложухи коннектимся к необходимой ноде или прям из мастера, но хранимкой, которая сама разберется куда ей надо.<br><br>Это что касается архитектуры железа.<br>Архитектура хранения... Их вообще много:<br>1) Все в одной табличке.<br>Это делают только альтернативно одаренные люди, коих тут, я надеюсь, нету. <br>Минусы:<br>- Большое количество записей, большие индексы, таблица большая и требует поднимать данные в кеш.<br> Дело в том, что в Пг первые что-ли 250 байт от блоба (а строки тут работают так-же как и блобы) хранится в самой записи.<br>- Апдейт - это страшно.<br> Дело в том, что в Пг апдейт происходит по принципу INSERT/DELETE... А это коипрование всего блоба.<br>- Еще дофига всего<br>2) Мета отдельно, файлы отдельно.<br>Уже лучше. Более того, мету можно партицировать. Все зависит от количества данных в мете.<br>Плюсы:<br>- Изменение мета-информации довольно быстрое.<br>- Если пользуется партицирование, то и индексы в кеше сидят, что ускоряет запросы.<br>Минусы:<br>- Пока не нашел.<br><br>Как-то так.<br></BODY></HTML>