Знаете я уже вышел из того возраста, когда я ковыряюсь в планах, если и смотрю, то как правило живые планы и присматриваюсь как какой узел тикает. Обычно на смотрю на типы полей, индексы и запрос и вижу, что надо исправить. Причем в последнее время на даже на ранее неизвестных мне БД. По поводу "поподробнее куда и сколько уходило времени" -- я не вдаюсь в такие детали -- мой подход -- исправил запрос залетало. А в планах можете поковыряться сами. Мне за почти 20 лет программирования на БД это уже надоело. Как правило, когда кто-то не может оптимизировать запрос - идут ко мне.

Поэтому чем меньше ключ -- тем быстрее. Можете начать громче кричать, что в моих словах нет пруфа, что это не обоснованно, что надо обосновать ... мне это не интересно.
Замените varchar(32) на GUID -- выигрыш в 2 раза и более, на BIGINT в 4 раза и более, на INT64 в 8 раз, на INT32 в 16 раз.

Лично проверено на таких БД как MS SQL, Oracle, Vertica, GreenPlum, SAP HANA, MySQL, SSAS.

Удручает то, что часто приходится разгребать полное Г. после тех, кто не задумывался о типах полей.

Напишите A JOIN B на полях различных размеров и типов и сами для себя сделайте пруф. Посмотрите планы. У меня хватает запросов с 15-25 джойнами для оптимизации.

dbms_photoshop,

молодец!!!

[youtube=https://www.youtube.com/watch?v=IZw1cB1uDts]

теперь можешь прокомментировать/проанализировать вторую часть

Ты сам внимательно прочитал указанную статью?

Data Vault is essentially a layer between the information mart / star schema and staging. There is some additional overhead that comes with developing this layer both in terms of ETL development and modeling. If the project is on a small scale or the project’s life is short-lived, it may not be worth pursuing a Data Vault model.

Видимо теоретик запутался в понятиях KNOT и ANCHOR/HUB . LINK/TIE на первый как правило не историчен, на второй историчен. Мне вот тоже странно смотреть на людей, которые ни черта не имеют практического опыта в данных моделях, но начинают теоретизировать в неизвестное никуда.

dbms_photoshop,

Дело лишь в том, что у Полковника есть опыт разработки DV, а у меня якорной модели. У Голова есть опыт и того и другого. Как это вписывается в хранилище нам понятно. Мне доводилось встречаться с ними лично.

У тебя похоже знания теоретические. А твои требования, докажи, продемонстрируй. Возьми проект по DV или Якорям и реализуй сам. Тогда поймешь.

Я использовать якорную модель в качестве стейджа. Судя по тому, что рассказывал мне голов при личной встрече -- он тоже.

Я внедрял в Вайлдберрз и Мираторге. В последнем по имеющимся сведениям они по прежнему работают.

Был на собесе в Profi.ru уже года 3-4 назад. Там планировали делать. Есть ещё какая-то контора на западе Москвы, там тоже есть якоря на Вертике.

Время от времени вижу в вакансия требования о знании якорей.

Из Авито Голов ушел уже давно. То, что человек с кем собеседовались ничего не сказал, не значит, что их похерили. В большой конторе могут и не знать, что в соседнем отделе.

s_ustinov,

По сути не было.

Сначала данные лили в буфер -- по сути временная таблица. Потом в якоря. Потом таблицу, которые SWAP PATRITION-ом загонял в конечные факты. Примерно так. Примерно это же показывал Голов, когда я с ним общался в Авито.

Якоря хороши на сущностях типа заказов, где происходит более 20 обновлений записей в процессе обработки. Ещё они хороши, где крупный справочник, вроде товаров завязан на много таблиц, типа заказы, платежи, поставки, остатки, цены, планы и т.п.

Если вы покопаетесь в статьях основателя, то там есть исследование, что эффект от якорей начинает проявляться лишь после уровня в поллимона записей.

Я достигал того, что сопливая однонодная вертика обрабатывала данные в 3-4 раза быстрее, чем MS SQL со значительно более мощным железом.

Если вы умеете разрабатывать правильный код на массивно-параллельных базах, то не вылезут. Если не умеете, то вылезут.

Но главный принцип там простой -- справочники клонируются на все ноды, факты шардируются по всем нодам, но иногда требуется соединить что-то вперемешку и тогда будет перемешивание. Но это редко.

Якорная модель на массивно параллельные БД ложиться хорошо. Хотя могут быть нюансы под конкретную задачу.

Для нее важны джойны. Поэтому Кликхаус плох для нее. Гринплам тоже не очень, но Голов говорит, что последняя версия уже может потянуть.

Вертика, Терадата. Вот ок.

да полностью повторяет, но stage в моем понимании данные сохраняет, а буфер нет

Если вопрос ко мне, я затрудняюсь ответить почему это спикеру пришло в голову.
Господин Воронин предложил для ознакомления видео 22419419
Я высказал недоумение относительно увиденного.

Если вопрос про линк и историю, то можно просмотреть с 33:33