Сергей, мне кажется вы из ежа пытаетесь построить удава. Проверка PK/UK/FK это забота слоя загрузки, а не аналитической DWH. Предполагается, что масс вставка записей в таблицу уже идет чистых данных. Вы зря ожидаете от DWH поведения OLTP. Сами констрейнты нужны, чтобы обозначить правила схем данных. Это используется оптимизатором при построении планов запросов. Это используется при том же MERGE для оптимизации, если объединение идет по первичному ключу. Это используется для построения преджойн проекций аля MASTER-DETAIL, чтобы Вертика могла навесить преджойн на фактовую таблицу, а не измерение. В комплекте Вертики для проверки констрейнтов по таблицам есть специальные функции, их описание в разделе документации "Constraint Management Functions".

P.S. В единичных DML типа "INSERT VALUES" кстати констрейнты полноценно работают, оно и понятно, можно быстро проверить. Если же вы в COPY говорите подгрузить парочку тб данных, странно было бы ожидать от хранилища, чтобы оно все это проверяло во время загрузки, да еще быстро грузило :)

Штучные INSERT/UPDATE вообще Вертике противопоказаны исходя из архитектуры хранения данных. Если многопоточно начать заваливать сервер единичными DML, то не так много времени пройдет, как появится ошибка "too many ROS containers" :) Если вам хватает штучных DML в потоках, то Вертика не та база, которая нужна ;)

Сергей, зачем вам это ? Вы с первоисточников льете дубликаты, OLTP источники их не гарантируют? Откуда информация льется, что она с дубликатами, что в ХД хранится будет и какая аналитика делаться? Не очень понятна задача, пока вижу попытку использования Вертики как OLTP.

Сергей ВаскецовОднако чтобы было понятнее: есть некий "справочник", который настолько прост, что может формироваться автоматически (и на который ссылается основная часть данных). И вот на разных источниках эти данные могут дублироваться по первичному ключу и дополнительному уникальному индексу, с частичным заполнением прочих полей в записи (по-разному на разных источниках), соответственно, крайне удобно было бы просто сливать MERGE-ем такую мелочь (нет - вставилось, есть - обновилось в части тех полей, где NULL). Без предварительной и пост- обработки.
Обычно в хранилищах делают несколько слоев. В стейджинговый слой заливается информация с первоисточников как есть, далее формируется консолидированный слой, где уже все очищается, приводится к единым ключам и приводится к 3 нормальной форме, а уже из него формируются слой витрин, в котором помимо агрегации как раз происходит частичная денормализация данных до уровня звезды.

MERGE конечно тоже никто делать не запрещает, делаете буферную табличку, в нее заливаете справочник, потом мержите с основной. Но учтите, UPDATE/DELETE/MERGE накладывают эклюзивную блокировку на таблицу, пока коммит не пройдет, ни какая другая сессия изменить данные в таблице не сможет, только вставлять новые. Ну и так же разные нюансы, когда в кластере рекаверится нода, идет ребалансировка кластера и т.д. - тоже X/U блокировки будут здорово мешаться, если они часто будут идти - в итоге просто придется останавливать изменения, пока эти операции не пройдут.

Сергей ВаскецовА на тему множества DML и загаживания памяти - там вроде как есть возможность писать напрямую на диск, если немного и осторожно.

Я именно про диск и говорю. Почитайте архитектуру Вертики по хранению данных в ROS контейнерах. Именно для этого WOS и сделан, чтобы оптимизировать работу часто пишущих но коротких сессий, но он на вставках хорошо работать будет, а на изменениях данных выплывут нюансы :)