Схема

Типы

Важно использовать правильный тип для кодирования столбцов (например, BIGINT, DATE, DATETIME). Хотя всегда можно использовать строковые типы (VARCHAR, и т.д.) для кодирования более специфических значений, это не рекомендуется. Строки занимают больше места и медленнее обрабатываются в операциях, таких как фильтрация, объединение и агрегирование.

При загрузке CSV-файлов можно использовать механизм автоматического определения типа CSV-читателя автоматическое определение типа для получения правильных типов для входных данных CSV.

Если вы работаете в среде с ограниченным объёмом памяти, использование меньших типов данных (например, TINYINT) может уменьшить объем памяти и дискового пространства, необходимого для выполнения запроса. Сжатие bitpacking в DuckDB означает, что небольшие значения, хранящиеся в больших типах данных, не будут занимать больше места на диске, но они будут занимать больше памяти во время обработки.

Рекомендация Используйте наиболее ограничительные типы при создании столбцов. Избегайте использования строк для кодирования более специфических данных.

Микротест: Использование метки времени

Мы иллюстрируем разницу в скорости агрегирования, используя creationDate столбец таблицы комментариев LDBC на масштабе 300. Эта таблица содержит приблизительно 554 миллиона неупорядоченных значений метки времени. Мы выполняем простой запрос агрегирования, возвращающий средний день месяца из меток времени в двух конфигурациях.

Во-первых, мы используем DATETIME для кодирования значений и выполняем запрос с использованием функции extract datetime:

SELECT avg(extract('day' FROM creationDate)) FROM Comment;

Во-вторых, мы используем тип VARCHAR и используем строковые операции:

SELECT avg(CAST(creationDate[9:10] AS INTEGER)) FROM Comment;

Результаты микротеста следующие:

Результаты показывают, что использование значения DATETIME приводит к меньшим размерам хранения и более быстрой обработке.

Микротест: Объединение по строкам

Мы иллюстрируем разницу, вызванную объединением по разным типам, вычислив самообъединение по таблице комментариев LDBC на масштабе 100. Таблица содержит 64-битные целые идентификаторы, используемые в качестве атрибута id каждой строки. Мы выполняем следующую операцию объединения:

SELECT count(*) AS count
FROM Comment c1
JOIN Comment c2 ON c1.ParentCommentId = c2.id;

В первом эксперименте мы используем правильные (наиболее ограничительные) типы, т.е. столбцы id и ParentCommentId определены как BIGINT. Во втором эксперименте мы определяем все столбцы как тип VARCHAR. Хотя результаты запросов одинаковы в обоих экспериментах, время выполнения значительно различается. Приведённые ниже результаты показывают, что объединение по столбцам BIGINT примерно в 1,8 раза быстрее, чем выполнение того же объединения по столбцам типа VARCHAR, кодирующим то же значение.

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

Ограничения

DuckDB позволяет определять ограничения, такие как UNIQUE, PRIMARY KEY, и FOREIGN KEY. Эти ограничения могут быть полезны для обеспечения целостности данных, но они отрицательно влияют на производительность загрузки, так как требуют создания индексов и выполнения проверок. Кроме того, они очень редко улучшают производительность запросов, поскольку DuckDB не полагается на эти индексы для операторов объединения и агрегирования (см. индексирование для получения более подробной информации).

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

Микротест: Влияние первичных ключей

Мы иллюстрируем влияние использования первичных ключей с таблицей комментариев LDBC на масштабе 300. Эта таблица содержит приблизительно 554 миллиона записей. Сначала мы создаём схему без первичного ключа, а затем загружаем данные. Во втором эксперименте мы создаём схему с первичным ключом, а затем загружаем данные. В обоих случаях мы берём данные из .csv.gz файлов и измеряем время, необходимое для выполнения загрузки.

В этом случае первичные ключи будут оказывать только (небольшое) положительное влияние на очень селективные запросы, например, при фильтрации по одному идентификатору. Они не оказывают влияния на операторы объединения и агрегирования.

Рекомендация Для наилучшей производительности при массовой загрузке, по возможности, избегайте определения ограничений первичного ключа.