Ребят, подскажите, у кого был опыт, на каких объемах данных

Question

Ребят, подскажите, у кого был опыт, на каких объемах данных

начинаются проблемы с хранением в БД поля в формате JSON и взаимодействием с этим полем?
Есть желание сохранять в БД ПГ набор информации, но нет желания растягивать таблицу под каждую метрику.
Ожидания от таблицы простые: Выполнять селект по параметрам из json с группировками.
Таблица не большая, в день там в среднем 1-2тыс может появляться. Максимально 30тыс было в день.
Можно как-то просчитать при каких объемах будут тормозить выборки или при таких объемах вообще нет смысла заморачиваться?
Таблица чисто для аналитики, оперативных вычитываний из нее нет.

#backend #devops #pgsql #programming #russian

0

19.10.2023

8 ответов

19 просмотров

Алексей Автор вопроса

Интересно, по поводу 3х кто поставил 👎. Чем плох предложенный вариант?

0

19.10.2023

central hardware

Алексей
Интересно, по поводу 3х кто поставил 👎. Чем плох п...

Второе предложение слегка не к месту имхо

0

19.10.2023

Yaroslav Schekin

central hardware
Второе предложение слегка не к месту имхо

Лично для меня он плох тем, что: . Это уверенный ответ на неведомо какой (очень невнятно сформулированный) вопрос. . Почти всегда jsonb (и ему подобные) в реляционных СУБД проигрывают по большинству параметров (по которым их можно сравнить) реляционной модели тех же данных (неожиданно, правда? ;) ).

0

19.10.2023

Алексей Автор вопроса

central hardware
Второе предложение слегка не к месту имхо

Да, секционирование, я думаю, мне не нужно будет. Вот про тип, надо изучить.

0

19.10.2023

central hardware

Yaroslav Schekin
Лично для меня он плох тем, что: . Это уверенный о...

Если сравнивать json vs jsonb то выбор очевиден, а по поводу неведомых требований вы уже высказались

0

19.10.2023

Ilya Anfimov

Алексей
Интересно, по поводу 3х кто поставил 👎. Чем плох п...

Как план — примерно всем. Во-первых, операцыи над json[b] — это примерно предпоследний вариант, когда реляцыонная декомпозицыя что-то неработает, и структура в принцыпе неопределена. Ну, или с реляцыонной декомпозицыей есть измеренные проблемы со скоростью. Так-то индэксацыя json у нас так себе, поиск по нему — тожэ (дажэ не в плане скорости), с цэлостностью данных всё не очень хорошо, да и с параллелизмом доступа много плохого. Во-вторых, секцыонирование — в среднем замедляет работу с базой. С нормально организованной базой. Так что рассматривать его как ускорение текущей работы — это нонсенс. Ну, и к тому жэ, примерно в 98% случаев секцыонированием занимаются поскольку могут (хоть как-то), а не потому, что это реально требуется.

0

19.10.2023

Yaroslav Schekin

central hardware
Если сравнивать json vs jsonb то выбор очевиден, а...

> Если сравнивать json vs jsonb то выбор очевиден, Правда? А зачем же у нас два типа-то? ;) И высказывался я не только про это, а про сравнение с нормальной моделью (см. https://t.me/pgsql/505082).

0

19.10.2023

G9T · Accepted Answer

G9T

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

0

19.10.2023

172 похожих чатов

Ребят, подскажите, у кого был опыт, на каких объемах данных

8 ответов

Похожие вопросы