Comments 7
В терминологии IBM, MPP состоит из набора узлов, связанных высокоскоростными межузловыми коммутационными каналами. Именно поэтому идёт речь о шасси, так как именно шасси осуществляет высокоскоростную коммутацию (и является, по существу, самой технологически сложной частью системы). Дальше вы фигурным квотингом вырезали объяснение, что сами MPP системы, в свою очередь, могут масштабироваться своим объединением через сеть, и пришли к мнимому противоречию.
Сетевой кластер не является примером MPP с точки зрения IBM.
А то, о чём вы пишете – это распределённая база данных на многоузловой СУБД с архитектурой shared disk. Вещь полезная, но к MPP не имеет прямого отношения и вряд ли может эффективно масштабироваться до массового параллелизма (под которым обычно подразумевается одновременное использование от десятков до десятков тысяч узлов).
Большое спасибо за интересную статью. В своём недавнем докладе вы упомянули, что JDBC-источники в Presto/Trino всегда состоят из одного сплита. Означает ли это, что параллельное вычитывание большой таблицы, например, из PostgreSQL невозможно?
На текущий момент в ванильном Trino скан JDBC источника действительно всегда состоит их одного сплита. Но это не фундаментальное ограничение. Например, коннектор Greenplum в CedrusData умеет параллельно читать таблицу в несколько потоков. Теоретически, такое же улучшение можно сделать и в коннекторе PostgreSQL, что бы он делал параллельные чтение примерно так же, как это делает Greenplum PXF.
Например, коннектор Greenplum в CedrusData умеет параллельно читать таблицу в несколько потоков.
А эти читающие потоки видят консистентное состояние таблицы? Иными словами, они будут выполняться в единой "транзакции", изолирующей параллельное чтение от транзакций на запись, которые в момент чтения могли поменять данные в этой таблице?
Например, коннектор Greenplum в CedrusData умеет параллельно читать таблицу в несколько потоков.
Если не секрет, как именно CedrusData делит таблицу на фрагменты для параллельного скачивания? Делит количество строк в таблице на N , чтобы узнать размер 1 "блока", и далее эмулирует вычитку блоков с помощью LIMIT/OFFSET?
В настоящий момент мы добавляем к запросу предикат сегмента вида:
AND gp_segment_id %% <кол-во сегментов> = <число от 0 до максимального уровня параллелизма - 1>
Более подробно описано у нас в документации: https://docs.cedrusdata.ru/latest/connector/greenplum.html#greenplum-scan-parallelism
Как устроен massively parallel processing (MPP) в Trino