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

Вт Окт 9 04:42:14 PDT 2012

Цитирую, собственно, true-way от постгреса. Специально для доклада мы
перевели статью http://wiki.postgresql.org/wiki/BinaryFilesInDB. Вот
перевод:

%%%%%%%%%%%%%%%%%%%%%%%%%%
Хранение больших бинарных файлов, как неструктурированный поток данных в БД
===========================================================================

Объект для хранения бинарных данных типа BLOB Поддержка LargeObjects
Плюсы
* Лимиты в 2Gb на 1 запись и макс. 4 млн записей в базе
* Доступен стриминг данных, можно передавать потоком, и позиционироваться
* нет необходимости в (де)кодировании информации

Минусы
* must use different interface from what is normally used to access BLOBs.
* Need to track OID. Normally a separate table with addition meta data
is used to describe OID
* (8.4 or older) No access controls in database.

Хранение данных, используя тип bytea или text
Плюсы
* Хранение и Доступ к данных осуществляется точно так же, как и к
любым другим данным в базе.
* Нет необходимости следить за OID

Минусы
* bytea и text типы данных используют TOAST (лимит в 1 GB на запись,
Максимум 4 млн. записей на таблицу)
* Необходимо кодировать / декодировать данные при записи / чтении данных
* Может быть восокое требование к RAM даже при необольшом количестве данных

Плюсы для всех способов
* Контроль доступа и безопасности значительно упрощается
* Доступна версионность данных
* ACID (Атомарность Согласованность Изолированность Долговечность)
* Упращённое резервное копирование.

Минусы для всех способов
* На слабых системах упадёт производительность при хранении данных в базе.
* Для хранения данных в базе нужно немнло оперативной памяти.
* Резервное копирование может занять много времени.
* Усложняется доступ к файлам сторонних приложений. Обычно приходится
сперва скопировать файл на ФС, поправить его, а после залить обратно.

Хранение метаданных и символических ссылок в базе данных
========================================================

Плюсы
* Производительность доступа к файлам зависит от скорости доступа к БД
* Количество хранимых файлов ограничивается только системными лимитами
* Максимальный размер файла тоже ограничен исключительно системой

Минусы
* Необходимо разработать интерфейс для отслеживания внешних файлов
* Внешние файлы и база данных с информцией о них могут выйти из
синхронизации (бинарные файлы не будут иметь записией в БД; БД хранит
данные о файлах, что были удалены или перемещены вручную или другим
ПО, без фиксации имзенения в БД)
* Настройки безопасности ФС и файловой системы являются независимымит
друг от друга.
* В зависимости от сложности сети может быть несколько оточек отказа.

%%%%%%%%%%%%%%%%%%%%%%%%%%

Подробнее о своей реализации мы расскажем в тестовом прогоне. Тестовый
прогон (он пройдёт в виде вебинара) нужен для последней обкатки всех
тех шероховатостей, которые мы ещё не учли. Скажу сразу, наша
реализация прочно легла именно на нашу инфраструктуру, когда мы
ограничены в качестве железа. Одно из названий доклада "Спусти 7
миллионов файлов в условиях полного Хецнера" ;)

Если кто и не сталкивался, то как минимум слыша, что с оборудованием
Хецнера не всё так просто. Чего стоят одни разлетающиеся при первом
чихе рейды (минус 24 часа даунтайма Setup.Ru) или, скажем, свичи
(минус 12 часов из жизни всей команды админов Setup.Ru).

Последним писком моды была попытка списать дважды ежемесячный платёж с карты :)

В общем проблем, которыми мы готовы поделиться (а также их решением)
хватает. Всех кому интересно, как выживать большому проекту в условиях
полного хецнера, приглашаю на тестовый прогон! Записывайтесь :)

---
Dmitriy V. Simonov,
Perl & Python programmer

2012/10/9 Warstone на list.ru <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) Мета отдельно, файлы отдельно.
> Уже лучше. Более того, мету можно партицировать. Все зависит от количества
> данных в мете.
> Плюсы:
> - Изменение мета-информации довольно быстрое.
> - Если пользуется партицирование, то и индексы в кеше сидят, что ускоряет
> запросы.
> Минусы:
> - Пока не нашел.
>
> Как-то так.
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>