2016-12-05 4 views
4

При включении ключа от объекта, хранящегося в моем body поля JSONB запрос выполняется ~ 100ms медленнее, чем без поля в избранном:Postgresql запрос очень медленно при выборе ключа из поля объекта JSONB

SELECT id, 
     title, 
     body->'_stats' AS stats 
    FROM items 

Это занимает около 105 мс по сравнению с 5 мс, если в комплект не входит stats. Кажется, не имеет значения, какой ключ я возвращаю из объекта JSONB body, все они значительно замедляют запрос. Существуют другие ключи из объекта тела, которые я хотел бы включить в этот запрос, но каждый из них, который я добавляю, увеличивает общее время запроса на ~ 50 мс.

Поле body имеет индекс gin, и я вижу поведение в обоих PG v9.5x и v9.6.1

Любые предложения по альтернативным способам возвращения данных объекта jsonb более эффективно?

ответ

-2

The first line in the Introduction of the JSON standard читает (курсив мой):

JSON это текстовый формат, который облегчает Структурированные обмена данными между всеми языками программирования.

Короче говоря, JSON хорош для отправки и получения информации в/из других компонентов приложения, но это не формат родной для баз данных в целом и полностью чуждо реляционной модели данных и, следовательно, не особенно быстро однако вы хотите приблизиться к нему.

Если вы просто храните и загружаете полные документы JSON, тогда нет проблем, но как только вы начнете манипулировать документами JSON в СУБД, а скорость - проблема, вы должны нормализовать данные json.

+0

Прошу прощения, но покровительственный ответ никому не помогает ... У меня есть очень веские причины использовать поле jsonb для хранения неструктурированных данных - это не причина для вопроса. Удивительное замедление запроса может быть связано с тем, что механизм запроса загружает все поле тела перед извлечением определенных ключей. Материализованное представление для полного запроса может быть обходным, я попробую в ближайшее время. – subblue

+0

Я понимаю ваше разочарование, но ответ не предназначен для покровительства вообще. Вы хотите анализировать _структурированные данные (еще один термин из стандарта) в среде, оптимизированной для _deconstructed_ данных. JSON является чистым 1NF, а современные СУБД наиболее эффективно работают на моделях данных 3NF. Это различие - это то, что более чем несколько программистов просто игнорируют, поэтому я вижу ценность, указывая на это. – Patrick