RS: Хранилище данных

Хранение бинарных объектов в таблицах реляционной базы данных — это реальность, с которой часто приходится сталкиваться при сопровождении, модификации и эксплуатации систем. Чаще всего бинарные данные (сканированные образы документов, фотографии товара, etc) хранятся в тех же таблицах, что и объекты учёта. Так получается по разным причинам. Иногда недостаточное понимание последствий такого решения, т.е. издержек, которые возникнут в связи с таким хранением, становится причиной того, что база на 70% состоит из бинарных объектов. Причиной может быть и взрывной рост объёма операций (количества записей), на который никто не рассчитывал при начальном проектировании.

Но как бы то ни было, такое хранение становиться настоящей головной болью у тех, кто вынужден поддерживать и развивать систему, которая теперь состоит из огромного статического контента: клонирование базы для детального разбора или экспериментов, резервное копирование, подготовка стенда для разработчиков — всё превращается в кошмар администратора.

Даже когда появляется понимание, как и где должны храниться такие данные, переход к новой архитектуре зачастую не тривиален: скорее всего потребуется изменение прикладного кода, что в унаследованных системах может превратиться в очень долгий и затратный процесс требующий останова и регрессионных тестов всех модулей системы. Кроме того, следует заметить, что перенос бинарных объектов на файловую систему создаст дополнительный «шов» и точку отказа, т.е. кроме базы данных, пусть неповоротливой, у команды эксплуатации теперь появляется «раздел с картинками\документами», который хоть и редко, но меняется, т.е. его также надо включать в процедуру резервного копирования, в систему мониторинга и прочее.

Некоторые СУБД уже решили такие задачи и предлагают свои решения по способам хранения и алгоритмам обработки бинарных объектов — как в выделенных специализированных областях БД (яркий пример — механизм Secure Files в СУБД Oracle), так и способы хранения бинарных объектов в файловой системе и ссылками на соответствующие файлы непосредственно в таблицах.

Как быть, если у вас база данных PostgreSQL, и в вашей системе бинарные объекты хранятся в тех же таблицах, что и объекты учёта, а переделка прикладной части долгая сложная и рискованная операция? При этом хотелось бы получить способы миграции бинарных объектов прямо «на лету», т.е. хотя бы новые объекты должны сохраняться где-то на внешнем хранилище, а у администратора была возможность переносить старые объекты во время минимальной нагрузки, а если при этом для бинарных объектов все операции будут ещё и транзакционны...

Решение RedSys — "RS: Хранилище данных" — использует возможности расширения PostgreSQL при помощи внешних модулей (extension), наше расширение объявляет новый метод доступа, реализует собственный индекс на основе хэш-индекса PostgreSQL. Для внешнего хранения больших бинарных объектов использована файловая система, но также есть возможность сохранять большие объекты в распределённой файловой системе с открытым исходным кодом Ceph.

Ceph — это программно-определяемая распределенная файловая система с открытым исходным кодом, лишенная узких мест и единых точек отказа, которая представляет собой легко масштабируемый до петабайтных размеров кластер узлов, выполняющих различные функции, обеспечивая хранение и репликацию данных, а также распределение нагрузки, что гарантирует высокую доступность и надежность. Система бесплатная, хотя разработчики могут предоставить платную поддержку. Никакого специального оборудования не требуется.

Расширение RedSys доставляет контент из файловой системы или из Ceph в приложение, которое и «знать не знает», что оно работает с удалённым хранилищем или с файловой системой, а работает с бинарным содержимым так, как если бы оно находилось в базе данных. Внутри PostgreSQL расширение предоставляет тип RBYTEA, по аналогии со стандартным типом BYTEA, который используется для хранения бинарных объектов в PostgreSQL. Только в отличии от стандартного типа наш RBYTEA сохраняет в блоках базы данных только дескрипторы небольшого размера (не более 100 байт) каждый такой дескриптор представляет собой описание местонахождения и состояние бинарного объекта. Все операции с новым типом транзакционны, т.е. дескриптор физически удаляется из файлов базы данных вместе с данными из удалённого хранилища или из файловой системы в соответствии с контекстом транзакции и по правилам, определяемыми внутренними механизмами СУБД PostgreSQL. Кроме типа, расширение представляет небольшой набор прикладных функций для просмотра значений дескриптора, его создания и заполнения бинарным содержимым. Теперь можно предусмотреть бесшовную миграцию, создав в таблице с бинарными данными поля «нового» типа и определив правила для заполнения полей. Кроме того, администратор может делать резервную копию или клонировать базу данных — копироваться будут только дескрипторы, которые требуют существенно меньше места.