Тогда не понятно что вы хотели оценить. В случае с одной (индексированной) таблицей это явно оверхед на работу с jsonb, связанный также с полным извлечением данных jsonb. В случае с двумя таблицами всё упирается в просмотр бОльшей таблицы сканом. У вас даже время выполнения сопоставимое получилось для всех записей и по одному клиенту. Без индекса такой подзапрос не делают же. Без индекса просто ожидаемый результат.
Вывод с выигрышность-невыигрышностью мне кажется не верный.
Сам делал денормализацию, в том числе с коллекциями в оракле. Очень от сценария использования зависит. Если обработка в бд, то лучше уж ухитриться кластеризовать данные.
Павел, секундочку, а какой план запроса в случае реляционной схемы? Ответы на вопросы производительности стоит начинать искать с плана и только с него.
Но, на сколько я понимаю, логическая репликация сейчас имеет ограничения (сходу не перечислю) и не гарантирует оригинальную очередность применения dml. Поэтому (с патрони) и используется чтение журнала. И получится ли одновременно настроить два вида репликаций - для поддержания кластера и для наливки нового. Опять же, из мира mssql . Делаем полный бакап, наливаем. Разностный, опять наливаем. Обрубаем клиентов, последняя разница и переключение клиентов на новый кластер. Либо вообще detach-attach базы.
Получается, что нужно делать pg_upgrade. А в 14 версии индексы поменялись, значит несовместимость и хардлинком не получится переехать?
Есть множество статей про Патрони, с разными dcs. Версии обновляются, что-то меняется. Суть остается.
Но если бы в вашей статье был подъем версии patroni/etcd/postgre, то это было бы супер. К сожалениию, моего профиля не достаточно чтобы это осознать, а вот появляющиеся плюшки в новых версиях бд я готов понимать, объяснять и потреблять. Научите поднимать версию postgre, пожалуйста. С простоем в 8 секунд.
Да, сиквел и контроль версий это боль. Особенно если не code first.
Мы пока сделали серверный триггер, который на все ddl пишет в табличку кто, какой объект , когда, ну и сам текст ddl.
Не гит конечно, но зато абсолютно прозрачно и универсально.
Можно пойти дальше и эти логи собирать в виде файлов и привести к тому, что получилось у вас.
Вот как раз сегодня брат жены отписал, что в фейсбук взяли, попытаем на предмет 1КК в год....
Тогда не понятно что вы хотели оценить. В случае с одной (индексированной) таблицей это явно оверхед на работу с jsonb, связанный также с полным извлечением данных jsonb. В случае с двумя таблицами всё упирается в просмотр бОльшей таблицы сканом. У вас даже время выполнения сопоставимое получилось для всех записей и по одному клиенту. Без индекса такой подзапрос не делают же. Без индекса просто ожидаемый результат.
Вывод с выигрышность-невыигрышностью мне кажется не верный.
Сам делал денормализацию, в том числе с коллекциями в оракле. Очень от сценария использования зависит. Если обработка в бд, то лучше уж ухитриться кластеризовать данные.
Павел, секундочку, а какой план запроса в случае реляционной схемы? Ответы на вопросы производительности стоит начинать искать с плана и только с него.
Но, на сколько я понимаю, логическая репликация сейчас имеет ограничения (сходу не перечислю) и не гарантирует оригинальную очередность применения dml. Поэтому (с патрони) и используется чтение журнала. И получится ли одновременно настроить два вида репликаций - для поддержания кластера и для наливки нового. Опять же, из мира mssql . Делаем полный бакап, наливаем. Разностный, опять наливаем. Обрубаем клиентов, последняя разница и переключение клиентов на новый кластер. Либо вообще detach-attach базы.
Получается, что нужно делать pg_upgrade. А в 14 версии индексы поменялись, значит несовместимость и хардлинком не получится переехать?
Есть множество статей про Патрони, с разными dcs. Версии обновляются, что-то меняется. Суть остается.
Но если бы в вашей статье был подъем версии patroni/etcd/postgre, то это было бы супер. К сожалениию, моего профиля не достаточно чтобы это осознать, а вот появляющиеся плюшки в новых версиях бд я готов понимать, объяснять и потреблять. Научите поднимать версию postgre, пожалуйста. С простоем в 8 секунд.