У Авито 200 серверов постгресс и вертика. Вот и весь датавольт

причем тут сервисные бд?

нормализованные модели для детального слоя это нормально (pun intended), я сам делал в России с полдесятка хранилищ (в том числе довольно крупные) на 3NF моделях, одно на DV, вроде все у людей нормально

тяжелые витрины частично материализуют конечно, это плата за гибкость

с другой стороны есть линейно масштабируемые аналитические СУБД, если что-то медленно - просто докупай узлы, и все будет быстро)

Какие например ?

Терадата, я слышал, неплохо масштабируется)

Очень дорогая.

но вообще любая МРР СУБД целится в такую задачу, из того с чем я работал - Exadata, Vertica, Redshift, BigQuery - у всех конечно свои особенности и ограничения, но это рабочие решения

это все относительно

Такой прозрачный намек)

+ Greenplum
+ ClickHouse

по доке не очень понял, а есть возможность задать свои значения стоимости для отклика сети, скорости чтения/записи с диска? или используются константы?

это иначе работает, СВО оптимизатор считает относительные стоимости разных планов для вашего запроса и выбирает тот что дешевле, например вы указали одну последовательность джоинов, а он из статистики знает размеры таблиц и кардиналити отношений, и может предложить последовательность которая будет лучше (при условии всех иннер джоинов конечно); также он выбирает тип джоина исходя из размеров и селективности колонок каждой стороны, ну и так дальше; хотя производительность сети,  и дисков может отличаться у разных систем, оптимизатор берет их за константы и оценивает планы «при прочих равных»

понятно, спасибо, наверно это уже не столь значимо для выбора плана.
Но стоимость доступа к дискам/сети/озу в идеале тоже хотелось бы задавать для своего кластера, оптимизатор же стоимостный, а не кардинальный)

он оценивает относительную стоимость запроса, не абсолютную

в общем если у вас тормозит запрос где агрегация без джоинов, или один тривиальный джоин, или наоборот кругом аутер джоины (они не ассоциативны, нельзя переставлять) или джоины по условию отличному от равенства - оптимизатор ничем не поможет

понятно что кардинальность важней для выора последовательности, но тип join выбирается из стоимости и "Lr = 4 * NEt" (пример константы из доки на чтение 1 байта с диска) может повлиять на тип соединения: к примеру сделать бродкаст или мерж

да, это все влияет, и я думаю что хайв пока берет все за константы или сэмплирует (но это не точно)

и хайв же не контролирует свой ввод/вывод, вот посчитал что он стоимость чтения как при потоковом чтении, а система занята и все чтение по скорости стало рандомным, и чего теперь делать? та же история и с сетью, так что я бы, если бы этот кусок писал, вынес все за скобки