Комментарии 8
Запрос распадается на аналогичные асинхронные подзапросы для каждой секции, в том числе удаленные, с финальной агрегацией на координаторе. ... а также частичная агрегация результатов, выполняется удаленно.
Как у вас с эффективностью параллельного выполнение запросов?
В основе шардирования и выполнения распределенных запросов лежат стандартные механизмы секционирования и postgres fdw (foreign data wrapper).
Если сделать ванильные RO async реплики и FDW partition, то можно SQL аналитические запросы гонять к большим данным за приемлемое время?
Бенчмарки никто не делал вертикальный VS горизонтальный scale?
Как у вас с эффективностью параллельного выполнение запросов?
Для планирования параллельного выполнения используются расширенные техники partitionwise join/aggregate. Можем выполнять параллельно соединения по ключу разбиения шардированных таблиц, произвольное соединение шардированных и глобальных таблиц, частичные сортировки-лимиты, агрегации. Но шаффл не поддерживается (например, параллельное соединение не по ключу шардированных таблиц), что может являться ограничением для аналитических запросов.
Если сделать ванильные RO async реплики и FDW partition, то можно SQL аналитические запросы гонять к большим данным за приемлемое время?
Пока поддерживаются только синхронные реплики, в основном для целей отказоустойчивости. На async репликах надо будет решить вопросы распределенной видимости, но идея понятная, да.
Бенчмарки никто не делал вертикальный VS горизонтальный scale?
У себя, конечно, делали много разных бенчмарков, постараемся в отдельной статье показать результаты.
А что в такой схеме будет со временными таблицами ? Вот создалось подключение, в нем CREATE TEMPORARY TABLE, на каком сервере она создастся ? Что будет с последующими запросами к ней в этом же подключении ?
Временная таблица будет создана на сервере, к которому установлено подключение, последующие запросы к ней будут работать стандартным образом в рамках сессии. Исключением являются транзакции, которые одновременно меняют и распределенные и временные таблицы. Такая транзакция требует двухфазного коммита, который сейчас не работает с временными таблицы. По той же причине не поддерживаются распределенные временные таблицы.
Ну при хоть сколько сложной транзакции на запись без временных таблиц очень сложно обойтись.
Впрочем масштабирование транзакций записи (то есть master-master) вообще штука такая себе, по двум причинам. а) Теорему САР никто не отменял. б) Тяжело представить систему, во всяком случае со сложными транзакциями (аля ERP), где с современными серверами можно уткнуться в проблему вертикального масштабирования на мастере (предполагая что там только транзакции записи будут, остальные на слейвах). Естественно предполагая что запросы эффективны (то есть все подперто индексами и т.п.).
ЗЫ: А хотя туплю, речь в данном случае же про шардинг, а не зеркалирование. Тут если честно не помню, как теорема САР работает.
не могу представить ситуации когда без временных таблиц не обойтись.
CTE, функции
Ну как сказать, временные таблицы это своего рода локальные переменные. А вы предлагаете их заменить на использование других функций. Мало того что это не производительно, так это ещё тупо неудобно.
нет, локальные перменные это локальные переменные.
Если вам так хочется.
Таблицы это таблицы.
Тут скорее бы подошли
SELECT set_config('my.num', '2', true);
SELECT current_setting('my.num');
Только они не локальные. Как и временные таблицы.
Временные таблицы вообще по умолчанию сессионные и при коммите даже не происходит очистка, хотя такое поведение и можно настроить.
При чем тут локальность абсолютно не ясно.
Как и замечание о производительности не к месту, в PostgreSQL временные таблицы так-же пишутся на диск и где тут производительность очень интересно узнать
Postgres Pro Shardman: горизонтальное масштабирование реляционных СУБД