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

Продукт
Разработчики: RedSys (Редсис)
Технологии: СХД

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

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

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

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

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

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

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

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



Распределение вендоров по количеству проектов внедрений (систем, проектов) с учётом партнёров

За всю историю
2021 год
2022 год
2023 год
Текущий год

  SAP SE (1, 101)
  NetApp (25, 66)
  Рэйдикс (Raidix) (19, 50)
  IBM (30, 43)
  Dell EMC (68, 32)
  Другие (676, 337)

  SAP SE (1, 8)
  NetApp (5, 7)
  Aerodisk (Аеро Диск) (5, 6)
  Lenovo (1, 6)
  Lenovo Data Center Group (1, 6)
  Другие (18, 19)

  Aerodisk (Аеро Диск) (3, 2)
  Hewlett Packard Enterprise (HPE) (1, 1)
  Lenovo Data Center Group (1, 1)
  NetApp (1, 1)
  КНС Групп (Yadro) (1, 1)
  Другие (6, 6)

  КНС Групп (Yadro) (1, 1)
  Synology (SLMP PTE) (1, 1)
  Другие (0, 0)

Распределение систем по количеству проектов, не включая партнерские решения

За всю историю
2021 год
2022 год
2023 год
Текущий год