Как стать автором
Обновить

Комментарии 31

Сегодня уже обновился. Спасибо за websearch_to_tsquery!
Интересно попробовать json(b)_to_tsvector.

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

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

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

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

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

НЛО прилетело и опубликовало эту надпись здесь
Да, jsonb отличная штука для хранения неопределенных данных. Но вот с полнотекстовым поиском по ним у меня большой вопрос. Как и из чего конкретно будут строиться лексемы? Из всех ключей в хэше? Если это так, то мы поимеем кучу лишнего мусора при поиске. Если у нас есть конкретные текстовые поля с постоянными ключами, то можно именно на них навесить поиск, но потеряется гибкость. Кстати сейчас делать полнотекстовый поиск по ключам в jsonb тоже ничего не мешает. Удобно построить отдельную таблицу с лексемами, куда при сохранении сущности сохранять текст переводя его в to_tsvector. И уже делать поиск по этим полям. Но опять таки, теряется гибкость. В итоге мы пытаемся использовать реляционный подход к noSQL базам, что в корне неверно.

Я с JSONb очень много работал на огромном портале недвижимости. Очень много чего мы туда позапихивали и радовались, ровно до тех пор, пока бизнес не стал ставить задачи по агрегациям и вычислениям, с кучей пересечений по другим json полям. Запросы тогда реально превращались в десятиэтажных монстров. В итоге, часть полей пришлось переписать в отдельные таблицы со своими строгими полями. Этот формат очень крут и удобен, но нужно осторожно с ним работать, так как в будущем может понадобиться что-то сложное делать с данными и тогда работа превратится в огромную проблему.
НЛО прилетело и опубликовало эту надпись здесь
Монга штука хорошая, но опасная. Завтра бизнес скажет, а я хочу иметь всю сводную статистику по запросам к странице, по закачке данных, по кликам на баннера и т.д. И прогеры почешут репу, и начнут разбегаться кто куда.

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