jsonb и первичные / внешние ключи: что лучше работает в PostgreSQL?

Question

jsonb и первичные / внешние ключи: что лучше работает в PostgreSQL?

Я рассматриваю использование типа столбца PostgreSQL jsonb для нового бэкэнд-проекта, который в основном будет служить в качестве REST-ful JSON API. Я считаю, что PostgreSQL jsonb будет хорошо подходить для этого проекта, поскольку он даст мне объекты JSON без необходимости преобразования на бэкэнде.

Однако я прочитал, что тип данных jsonb замедляется по мере добавления ключей, и моя схема будет нуждаться в использовании первичных ключей и ссылок на внешние ключи.

Мне было интересно, если иметь первичный ключи / внешние ключи в своих собственных Столбцах (в стандартной реляционной базе данных), а затем иметь столбец jsonb для остальных данных было бы полезно, или это вызовет проблемы (будь то сейчас или в будущем)?

Короче говоря, будет:

table car(id int, manufacturer_id int, data jsonb)

Лучше или хуже, чем:

table car(data jsonb)

Особенно при частом поиске внешних ключей?

Будут ли у первого из них недостатки, с точки зрения производительности или схемы?

702 2

postgresql database-design foreign-keys jsonb

2 ответов:

Comments

Ничего не найдено.

Erwin Brandstetter · Accepted Answer · 2017-05-23 15:17:42

Все значения, участвующие в a PRIMARY KEY или FOREIGN KEY ограничение должен храниться в виде выделенных столбцов (лучше всего в нормализованном виде). Ограничения и ссылки не работают для значений, вложенных внутри a json / jsonb колонна.

Что касается остальных данных: это зависит от того,. Наличие их внутри значения jsonb (предпочтительно) несет в себе хорошо известные преимущества и недостатки хранения неструктурированного типа документа. данные.

Для атрибутов, которые присутствуют для всех или большинства строк, скорее всего, будет лучше (быстрее, чище, меньше памяти) хранить их в виде отдельных столбцов. Более простая индексация и более простые запросы тоже. Несмотря на то, что новый jsonb имеет удивительные возможности индексирования, индексирование выделенных столбцов все еще проще / быстрее.

Для редко используемых или динамически появляющихся атрибутов, или если вы хотите хранить и извлекать значения JSON без большой обработки внутри БД, посмотрите к jsonb.

Для базовых структур EAV с главным образом символьными данными, без вложенности и без связи с JSON я бы рассмотрел hstore. Есть также xml (более сложные и подробные) иjson типы данных (в основном заменяются jsonb), которые теряют свои позиции.

Pavel Stehule · Accepted Answer · 2014-12-31 09:17:25

Какие лучше работают? Зависит от использования. Это тот же вопрос, когда вы сравниваете базы данных SQL (relational) и NoSQL (KeyValue или Document). Для некоторых случаев использования базы данных NoSQL работают очень хорошо, для других-нет.

Реляционная концепция (нормализованная схема) оптимизирована для типичного использования OLTP - 70% чтения/30% записи, многопользовательского режима, большого количества обновлений, расчета отчетов, некоторых специальных запросов. Реляционное понятие является относительно широким общим понятием .. с очень широким использованием (доказательства, Бухгалтерский учет, поддержка обработки, ...). Обычно это не так уж плохо везде.

Понятно, что специализированные базы данных (Document, KeyValue, Graph) могут быть значительно лучше (на порядок быстрее) в специализированных случаях использования. Но их использование значительно уже. Когда у вас нет оптимизированного варианта использования, производительность может быть плохой.

Другой вопрос-размер базы данных-номера записей. Разница в производительности на производственных базах данных может быть значительной в сотни тысяч строк. Для некоторых меньшие базы данных влияние может быть не значительным.

Postgres-это реляционная база данных, и я предпочитаю использовать нормализованную схему для всех важных данных в базе данных. Когда вы используете его хорошо, это ужасно быстро. Non relation types идеально подходит для некоторых нечетких данных (HStore, JSON, XML, Jsonb) - это значительно лучше, чем схема EAV (хуже работает с большими данными).

Если вам нужно сделать какое-то важное решение, подготовьте прототип, заполните его ожидаемыми данными (3 года) и проверьте скорость выполнения некоторых важных запросов для вашей системы. Внимание: сильное влияние на эти показатели используются гв, ток нагрузки, ток ео.