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

[Warstone@list.ru]

Tue, 9 Oct 2012 13:36:56 +0400 от Vladimir Timofeev <vovkasm на gmail.com>:
>	
>
>
	
	
>
		
		
			
>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 mailing list
>moscow-pm на pm.org | 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) Мета отдельно, файлы отдельно.
Уже лучше. Более того, мету можно партицировать. Все зависит от количества данных в мете.
Плюсы:
- Изменение мета-информации довольно быстрое.
- Если пользуется партицирование, то и индексы в кеше сидят, что ускоряет запросы.
Минусы:
- Пока не нашел.

Как-то так.
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20121009/8fe481a2/attachment-0001.html>