Блог компании Postgres Professional
PostgreSQL
Комментарии 31
0
Интересно попробовать json(b)_to_tsvector.

Не вошли в новую версию большие патчи с функциями для работы с JSON/JSONB.
А что там будет? Где можно почитать? К 11.1 подтянут?
0
Как это соотносится с моим вопросом?! :) Статистические данные телеметрии, хранящиеся в сложном разнородном формате. Возможно json(b)_to_tsvector() упростит запросы к JSONB, а может и нет.
+1
Ну просто по конкретным ключам в jsonb и сейчас можно строить индексы и искать по ним, а to_tsvector() — это функции для полнотекстового поиска (просто много работал с этим) для построения лексем из текста. Вот я и удивился немного, что за данные вы храните в таком формате, где нужно строить лексемы.
0
Я понял. Значит это совсем мне не нужно, спасибо. Интересно, что это за функции для работы с jsonb добавят?
-1
Плохого? Это не то, чтобы плохо, а скорее узкое место. Если вы хотите хранить разные тексты в данном формате, то вы должны позаботится о том, что при полнотекстовом поиске у вас существуют нужные ключи с текстами. Иначе словите эксепшн. А значит вам придется делать какие-то проверки и валидаторы. А если так, то теряется основное назначение данного формата — хранение несогласованных и необязательных данных, утеря которых не приведет к падению приложения. Например, есть у вас текст «Описание к товару». Если он у вас обязателен, то его лучше хранить в отдельном текстовом поле. Сама база будет заставлять вас заполнить это поле. В случае с jsonb — это не так. И потерять в этом формате один из ключей с вашим текстом проще паренной репы на любом этапе сохранения данных в это поле.

Выбирать формат хранения данных нужно не по модности/новаторству и т.д., а с умом, предполагая все возможные последствия данного выбора.

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

Плюс не забываем о том, что ваше приложение может легко и не принуждено изменить структуру сохраняемых данных в jsonb, которому плевать что в себе хранить, например, после рефакторинга какого-то куска кода. А другой, старый код, пытается получить данные со старой структурой, которых там уже нет. Вот вы и поимели геморрой.
0
Если он у вас обязателен, то его лучше хранить в отдельном текстовом поле. Сама база будет заставлять вас заполнить это поле. В случае с jsonb — это не так.

Лукавите. База будет заставлять в том случае, если задан constrain. Ничто не мешает завести ограничения для документа: Как использовать ограничения JSON при работе с PostgreSQL

0
Мне JSON интересен в случае, когда данные могут иметь разную структуру. Если поле одно, то это совсем не интересно и в JSON его действительно хранить смысла немного, хоть оно обязательное, хоть нет. А вот если у нас таблица с товарами, у которых есть характеристики, причём у разных типов товаров могут быть разный набор характеристик, например у процессоров это поколение, частота, размеры кешей, у жёстких дисков это размер, скорость вращения дисков и тд, да к тому же ещё и конфигурируемые пользователем но в то же время может быть желание иметь полнотекстовый поиск по определённым полям (пусть даже это будет конфигурироваться администратором БД, не суть), то хранение в JSON может быть привлекательным вариантом и полнотекстовый поиск по полям внутри этого JSON может быть нужной фичей.
0
Да, jsonb отличная штука для хранения неопределенных данных. Но вот с полнотекстовым поиском по ним у меня большой вопрос. Как и из чего конкретно будут строиться лексемы? Из всех ключей в хэше? Если это так, то мы поимеем кучу лишнего мусора при поиске. Если у нас есть конкретные текстовые поля с постоянными ключами, то можно именно на них навесить поиск, но потеряется гибкость. Кстати сейчас делать полнотекстовый поиск по ключам в jsonb тоже ничего не мешает. Удобно построить отдельную таблицу с лексемами, куда при сохранении сущности сохранять текст переводя его в to_tsvector. И уже делать поиск по этим полям. Но опять таки, теряется гибкость. В итоге мы пытаемся использовать реляционный подход к noSQL базам, что в корне неверно.

Я с JSONb очень много работал на огромном портале недвижимости. Очень много чего мы туда позапихивали и радовались, ровно до тех пор, пока бизнес не стал ставить задачи по агрегациям и вычислениям, с кучей пересечений по другим json полям. Запросы тогда реально превращались в десятиэтажных монстров. В итоге, часть полей пришлось переписать в отдельные таблицы со своими строгими полями. Этот формат очень крут и удобен, но нужно осторожно с ним работать, так как в будущем может понадобиться что-то сложное делать с данными и тогда работа превратится в огромную проблему.
+1
Спасибо, я тут больше теоретик, сама идея JSON мне очень нравится, т.к. обычно люди тупо сериализуют Java-объект и кладут в базу какую-то байтовую кашу-малашу или придумывают свои доморощенные разделённые запятыми форматы, конечно же обрабатывая это всё в приложении или в километрах хранимок, но на практике пока применять не приходилось, всё жду. Вот недавно почти посоветовал, но там хипсторы на Mongo решили всё делать, сдалась им эта монга.
+3
Монга штука хорошая, но опасная. Завтра бизнес скажет, а я хочу иметь всю сводную статистику по запросам к странице, по закачке данных, по кликам на баннера и т.д. И прогеры почешут репу, и начнут разбегаться кто куда.

Поэтому постгрес очень подходящая база для разных смешанных типов данных. Я до сих пор вижу, как народ мучается с построением деревьев с помощью кучи библиотек и костылей, хотя у постгреса есть отличный фомат ltree. Народ до сих пор строит какие-то решения из говна и палок для работы с географией, хотя у постгреса мощный функционал для работы с локациями и.т. Да, постгес после mySQL кажется громадным и сложным монстром, но для энтерпрайз проектов он решает громадное количество задач на уровне самой базы, а не кода. А монга — это что-то хипстерское, на которую был в одно время огромный спрос, который стал сходить на нет, так как многие уже наобжигались с ней. Особенно, когда работали с заказчиком по agile. Сегодня одни требования (точно, при точно), а завтра все переигралось (бизнес платит деньги, поэтому поджали яйца, делаем, что вам говорят).
0
Вообще по JSON/JSONB давно написаны 3 больших патча:
SQL/JSON: jsonpath
SQL/JSON: functions
SQL/JSON: JSON_TABLE
но их никак не закоммитит сообщество. О них есть вот здесь: obartunov.livejournal.com/200076.html
0
а если можно будет передавать секцию от одной таблицы к другой то будет вообще замечательно
0
А что там нового в области бэкапа и ресторе? Можно уже делать восстановление отдельных tablespace?
-4
Релизы PostgreSQL все унылее и унылее, зато на конференциях любят сообщать, что скоро захватят мир и круче нас никого нет. На деле получаем что-то непонятное и это видимо то, с чем хотели поиграться разработчики сообщества больше всего.
Очень напомнило релиз Angular 7, где сообщество опять прокатили с нужными фичами
0
Не знаю как вы, а лично я ждал секционирования по хешу с возможностью смены секции для строки во время апдейта.
0
В инсталляторе 11 версии от BigSQL лежит pgAdmin 3, который, внезапно, не работает с 11 версией.
0
Оригинальный, возможно, не работает. Ребята из BigSQL же делают свою LTS-версию, которая поставляется в комплекте и по определению работать должна. Но в этот раз что-то пошло не так…
0
Оригинальный заявлено что не работает с 10кой, но при этом с небольшой руганью он работает. А в чем выражается что не работает с 11ой?
0
Igor_Le В сообществе есть идеи по выводу в логи рекомендательных сообщений по оптимизации PostgreSQL?
Например:
PostgreSQL упирается в диск — нужно установить диск/хранилище побыстрее
PostgreSQL не хватает памяти work_mem — нужно увеличить work_mem
Структура вашей таблицы/бд неоптимальна — лучше примените другую структуру
и т.п. и т.д.
0
Насколько мне известно, пока лишь робкие попытки поднять этот вопрос. В ближайшее время вряд ли что изменится.
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.