Дизайн схемы Redshift

Я пытаюсь разработать схему базы данных, которая должна работать с набором данных, который выглядит следующим образом:

Events
event_id|time|key1|key2|data

И он должен выполнять такие запросы эффективно:

Получить все события, где key1 / key2 = … и время между ними … и.

Одна схема, о которой я думал, будет

Events
primary_key=event_id|key1|key2|data

Key1Lookup
primary_key=key1|sortkey=time|event_id

Key2Lookup
primary_key=key2|sortkey=time|event_id

Так что мой запрос может выглядеть как

SELECT data FROM Events, Key1Lookup WHERE key1=... AND time BETWEEN ... AND ... AND Events.event_id = Key1Lookup.event_id

или

SELECT data FROM Events, Key2Lookup WHERE key2=... AND time BETWEEN ... AND ... AND Events.event_id = Key2Lookup.event_id

Кажется ли это правильным выбором ключа / дизайном запроса? Я совершенно новичок в redshift, поэтому мне действительно нужно руководство ЗДЕСЬ.

Дополнительная информация:
Event_id уникален.
В Key1Lookup key1 не является уникальным, но в Key1Lookup есть только несколько повторов (думайте об этом как о user_id в таблице комментариев).
В Key2Lookup key2 не является уникальным, но в Key2Lookup есть только несколько повторов (думайте об этом как location_id в таблице комментариев).
Существует огромное количество различных key1, и есть огромное количество различных KEY2.
Я ожидаю, что отличное число key1 увеличится много, и я ожидаю, что отличное число KEY2 увеличится много.

1 ответ

  1. Во-первых, несколько указателей, относящихся к тому, что вы упомянули:

    • Redshift не очень понимает первичные ключи или делает какую-либо индексацию внутри. Об этом говорится в документации.

    Ограничения уникальности, первичного ключа и внешнего ключа являются информационными
    только; они не применяются Amazon Redshift .

    • Redshift хранит данные в столбчатом формате. Таким образом, если запрос select не ссылается на определенный столбец, все данные в этом столбце будут проигнорированы.
    • Ключи распределения можно использовать для совместного размещения соединений на двух таблицах. Однако в этих двух таблицах может быть только один dist-ключ.

    Основываясь на этих двух, я бы рекомендовал следующее:

    • Определенно есть ключ сортировки timestamp. Поэтому любой between ... and ...запрос timestampбудет просто пропускать ненужные строки.
    • Если бы у вас была только однаkey, вы могли бы использовать предложенную схему. keyбыл бы dist-ключ, из-за которого ваши соединения (с Eventsтаблицей) были бы очень эффективными. Но не можете пройти этот маршрут, потому что у вас есть два ключа.
    • Таким образом, де-нормализованные данные ( event_id=primary-key|timestamp=sort-key|key1|key2|data) были бы очень эффективны.
      • Это будет лучше, чем объединение на 3 таблицы (каждая из которых будет расти со временем) каждый раз.
      • И как я уже говорил ранее, если ваш запрос select имеет условие только для одного ключа (например, key1=...), весь key2столбец будет проигнорирован.