Самый эффективный способ хранить неиспользуемый кусок данных в PostgreSQL - PullRequest
Новая
       17

Самый эффективный способ хранить неиспользуемый кусок данных в PostgreSQL

0 голосов
/ 12 марта 2019

В таблице несколько столбцов и более 100 столбцов данных, которые необходимо сохранить только для последующего экспорта в другие источники.

Эти данные (кроме первых нескольких упомянутых столбцов) не нужно индексировать / фильтровать или каким-либо образом манипулировать. Нет запросов, которые могут проверить эти данные любым способом.

Единственное, что прикладной уровень может извлечь всю строку с дополнительной неиспользованной рабочей нагрузкой и десериализовать ее для дальнейшего преобразования во внешний формат.

Была идея сериализовать весь класс в это поле, но позже мы поняли, что это огромные накладные расходы на размер данных (из-за дополнительных метаданных java-класса). Итак, это простые данные значения ключа (набор ключей является статическим, как предполагает реляционная модель).

Каков правильный способ и тип данных для хранения этих дополнительных неиспользуемых данных в PostgreSQL с точки зрения производительности БД (объем хранилища более 50 ТБ)? Возможно, стоит пропустить ключевые данные и хранить только значения в виде массива (поскольку ключи являются статическими) и получать значения после десериализации по индексу на прикладном уровне (с точки зрения производительности БД на первом месте)?

1 Ответ

0 голосов
/ 02 июня 2019

a_horse_with_no_name , большое спасибо, но jsonb действительно сложный тип данных.

С точки зрения необходимого количества байтов для одного кортежа, который содержит jsonb, необходимовсегда имейте в виду - размер key имен в формате json.Таким образом, если кто-то захочет заново изобрести колесо и сохранить большие key имена как отдельные byte индексы - это уменьшит общий размер кортежа, но это не лучше, чем хранить все данные как типичные поля реляционных таблиц, потому что TOAST алгоритм применяется для обоих случаев.

Другой способ - использовать EXTERNAL метод хранения для одного поля jsonb.В этом случае PostgreSQL будет хранить больше кортежей в кэше, так как нет необходимости хранить все данные jsonb в памяти.

В любом случае, я получил комбинацию protobuf + zlib вbytea тип поля (поскольку в нашей системе нет необходимости запрашивать данные в поле bytea):

Uber исследование для protobuf + zlib

...