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

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

мелкая неточность:
Счастливец Паша может выбирать из 4 квартир. Но стоит изменить 1 букву в запросе — с «П» на «С», и выбора не останется! Подойдет только 1 квартира.

в запросе указан Саша:
FROM house, demands WHERE name = 'Саша';

а в выводе запроса приведены 4 квартиры. Такой вывод подошёл бы если бы в запросе был указан Паша.
да, поправил. спасибо!
Планируем реализовать высоконагруженный проект на Postgres.
Если сравнить 3 решения:
1)плоская таблица
2)таблица с 1 JSONPath
3)таблица с несколькими(пусть будет 3) JSONPath
Количество записей ~500 млн

Основная нагрузка — поиск по разным наборам полей, пусть будет (а1 и a1,a2,b1,c1) (где a, b и c — разные JSONPath в п.3 )

У решений 2 и 3 есть возможность достичь такого же быстродействия как и п.1?
Что такое плоская таблица?

Денормализованная

Заранее трудно сказать, будет ли вариант с JSON быстрее. В простейших случаях -нет, т.к. JSON надо дополнительно парсить, чтобы извлечь значения полей (даже JSONb, хоть он и читается гораздо быстрее). Если поиск по индексу по конкретному набору полей внутри JSON, то надо строить функциональный BTree-индекс по этим полям, скорость работы будет примерно такая же.
JSON делали не для скорости, а для функциональности. Например, в нем можно иметь многоуровневую структуру данных внутри одного поля, а в «плоской» таблице как это сделать? В отдельных случаях JSON ускоряет, если, например, позволяет сократить объем данных, или запихнуть несколько таблиц в одну.

Спасибо. Мой пример, я так понимаю, простейший случай.
Да, JSON нужен для удобства, в нашем случае, расширения и возможности сразу его отдавать. Есть некоторые опасения, поэтому рад был бы услышать об опыте на схожих объемах
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
www.postgrespro.ru
Численность
51–100 человек
Дата регистрации
Представитель
Иван Панченко

Блог на Хабре