Комментарии 5
Мастер аутентифицирует соединение и обрабатывает входящий SQL-запрос. Запрос оптимизируется и разбивается на более мелкие компоненты, которые отправляются в сервер-сегменты - другие экземпляры базы данных PostgreSQL, где обрабатываются для получения окончательных результатов.
Сегменты выполняют вычисления и возвращают результаты обработки в Мастер, который координирует эти результаты и представляет конечный итог клиенту.
Так оно что, однопроходное? Если надо сделать сделать репартишененинг на лету, то работать не будет?
Условно, есть у нас таблица orders побитая по хешу от userid по сегментам. А хотим по каждому ордеру найти, сколько юзеров уже заказали этот товар до этого ордера. Причём, объем таблицы таков, что на один сервер-сегмент не войдёт. То есть, единственный способ это выполнить - это сделать репартишененинг по хешу от goodid по сервер-сегментам на лету (поднять абсолютно все данные с диска, и перепослать их полносвязным графом между сегментами), исполнить на них запросы, и только тогда уже на мастер. Серьёзные решения вроде Vertica такое умеют.
Что-то вроде:
select o1.id, count(distinct o2.userid)
from orders as o1
left join orders as o2 on o2.goodid = o1.goodid and o1.ts > o2.ts
group by o1.id
ГП тоже умеет и в редистрибуцию и в броадкаст таблицы/датасета, и активно их использует) в статье все в общих чертах описано. Даже касательно кликхауса - правая таблица совершенно необязательно должна помещается в память, в последних версиях клика по кр мере.
По сравнению с вертикой, какие минусы у гп, навскидку : в гп нет кластерного индекса (в том же кликхаузе по факту он есть), соответственно нет мерж джойнов; нет join elimination; индексы в гп по факту сложно использовать, ТК они не сжимаются и ... Еще какие-то там с ними проблемы; механизма проекций тоже нет, но можно просто создать таблицу-дубль с другой дистрибуцией; вроде ещё что-то было, щас не могу вспомнить...
В целом же ГП весьма хорош, тот опенсорс который во многом не хуже платных mpp баз.
Да когда вы уже закончите то носиться с этим технологическим трупом по имени GreenPlum?
Тупикоя ветвь эволюции.
GP это: Дорогое хранение со специфическими требованиями к железу, медленный движок сам по себе (ни одной join оптимизации современной нет и не будет), технологические ограничения на масштабирование (и даже не изза мастера который тоже сам по себе тот еще ботлнек), не самое лучшее сжатие данных даже в колоночном формате, фиксированный паралелеризм обработки.
На сотни Тб он у них масштабируется. Ну-ну :)
В Clickhouse давно есть транзакции и ACID
https://clickhouse.com/docs/en/guides/developer/transactionalClickHouse можно и на Windows развернуть
https://clickhouse.com/docs/en/getting-started/quick-startВроде проблему с единичными update/delete они тоже порешали. Правда ссылку сходу не смог найти. Надо в Release Notes копать
Итого: я привел лишь несколько несоответствий автора. Думаю перед началом такого сравнения стоит внимательнее изучить документацию по продуктам.
Что такое СУБД Greenplum? Зачем она нужна в больших проектах DWH? Чем отличается от ClickHouse?