Во всех ключевых облачных хранилищах данных существует множество средств миграций из in-house-хранилищ, однако, как мне кажется, путь к успеху в миграции в "облака" состоит не только из уменьшения затрат на обслуживание инфраструктуры, но и повышения производительности путём изменения модели данных под особенности каждого из хранилищ.

Я попробую доказать, что копирование традиционных star- и snowflake-схем не позволяет получить максимальную производительность в таких хранилищах как Amazon Redshift и Google Big Query, но и приводит к дополнительным финансовым затратам.

Мы обсудим, почему модели данных одного и того же хранилища должны быть разными между Redshift и Big Query, как эффективно использовать возможности данных СУБД.

Большинство советов по работе с данными СУБД сводится к "увеличьте размер кластера" или "добавьте sort key". Порой это уменьшает скорость выполнения запросов при гораздо более высокой стоимости владения.

Будет продемонстрировано несколько примеров с production, как с уменьшением мощности кластера общая производительность системы повысилась, а также рассмотрен ряд радикальных подходов, как системы с единственной сверхширокой таблицей фактов вместо star-схемы с таблицами фактов и измерений.