Как спланировать diststyle для таблицы Redshift со вставками и обновлениями - PullRequest
Новая
       43

Как спланировать diststyle для таблицы Redshift со вставками и обновлениями

0 голосов
/ 12 апреля 2019

У меня есть требование, чтобы мой Redshift был не просто семантическим слоем для внешнего интерфейса, но также использовался для вставок и обновлений в таблицах.

Сомнения:

1) Front-end будет простой структурой, которая будет извлекать таблицу в пользовательский интерфейс и отображать ее с разбивкой на страницы, на данный момент мы делаем select * from table, и для извлечения около 3000 строк требуется около 10 секунд. Можно ли сделать это быстрее?

2) Это довольно новый вариант использования для меня, и я пытаюсь выяснить, какой стиль распространения будет лучшим в этом сценарии? Данные очень маленькие, всего около десятков тысяч. Я использую diststyle all, так как документация предлагает сделать это для любой таблицы, содержащей менее 1 миллиона строк.

3) Для вставок / обновлений нам нужен уникальный столбец, поэтому мы создаем столбец пользовательской идентификации (1,1) в верхней части таблицы и делаем его ключом сортировки, потому что каждое обновление будет выполняться путем поиска уникальная строка в БД, вставка просто добавит добавочное значение к ней. Это правильный путь или есть более сложные способы решения этой проблемы?

4) Любые другие предложения приветствуются.

1 Ответ

1 голос
/ 12 апреля 2019

Хранилище данных, такое как Amazon Redshift, довольно плохо выполняет операции INSERT и UPDATE.

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

Когда данные добавляются с помощью INSERT, новые строки добавляются в конец области хранения.для каждого столбца.(Будучи столбчатой ​​базой данных, каждый столбец хранится отдельно.) Это означает, что несортированная область увеличивается при добавлении данных, что снижает эффективность поиска данных с помощью таблицы.Эту проблему можно исправить, запустив VACUUM, в результате которого строки будут пересортированы.

Amazon Redshift не подходит для использования в качестве стандартной базы данных OLTP.Скорее, он лучше всего подходит для загрузки большого количества информации из существующих источников данных и выполнения сложных запросов по миллионам и миллиардам строк.

Возможно, было бы лучше выполнить такие обновления в обычной базе данных, а затем извлечь данные вRedshift для отчетов («только для чтения»).

Что касается DISTKEY / SORTKEY, общее правило таково:

  • Установите DISTKEY для столбца, наиболее часто используемого вJOIN, потому что он совмещает данные из обеих таблиц в одном и том же срезе
  • Установите SORTKEY на столбец, наиболее часто используемый в операторе WHERE, поскольку он позволяет Redshift «пропустить»дисковые блоки, которые не содержат соответствующие строки.
...