1. Основные понятия

В Doris данные логически описываются в виде таблиц. Таблица включает в себя строки и столбцы. Строка — строка пользовательских данных. Столбец используется для описания различных полей в строке данных.

Столбец можно разделить на две категории: ключ и значение. С точки зрения бизнеса ключ и значение могут соответствовать столбцам измерений и столбцам индикаторов соответственно. Ключевой столбец Doris — это столбец, указанный в операторе создания таблицы. Столбец после ключевого слова «уникальный ключ», «агрегированный ключ» или «дубликат» в операторе создания таблицы является ключевым столбцом в дополнение к ключевому столбцу. , остальное — столбец «Значение».

Модели данных Дорис в основном делятся на 3 категории:

Aggregate Unique Duplicate

Ниже мы представим их отдельно.

2. Агрегатная модель

Мы используем практические примеры, чтобы проиллюстрировать, что такое модель агрегации и как ее правильно использовать.

Агрегация данных импорта

Предположим, что компания имеет следующую схему таблицы данных:

ColumnName	Type	AggregationType	Comment
user_id	   LARGEINT		пользователь id
date	    DATE		дата заполнения данных
city	   VARCHAR(20)		пользователь Местосуществовать Город
age	       SMALLINT		пользовательвозраст
sex	        TINYINT		пользовательпол
last_visit_date	DATETIME	REPLACE	последний раз посещаемый пользователем
cost	         BIGINT	SUM	пользовательобщее потребление
max_dwell_time	INT	MAX	  пользовательмаксимальное время пребывания
min_dwell_time	INT	MIN	    пользователь Минимальное время пребывания

Если преобразовать его в оператор создания таблицы, он будет выглядеть следующим образом (информация о разделении и распределении в операторе создания таблицы опущена):

CREATE DATABASE IF NOT EXISTS example_db;

CREATE TABLE IF NOT EXISTS example_db.example_tbl_agg1
(
    `user_id` LARGEINT NOT NULL COMMENT "пользовательid",
    `date` DATE NOT NULL COMMENT "дата заполнения данныхвремя",
    `city` VARCHAR(20) COMMENT "пользователь Местосуществовать Город",
    `age` SMALLINT COMMENT "пользовательвозраст",
    `sex` TINYINT COMMENT "пользовательпол",
    `last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "последний раз посещаемый пользователем",
    `cost` BIGINT SUM DEFAULT "0" COMMENT "пользовательобщее потребление",
    `max_dwell_time` INT MAX DEFAULT "0" COMMENT "пользовательмаксимальное время пребывания",
    `min_dwell_time` INT MIN DEFAULT "99999" COMMENT "пользователь Минимальное время пребывания"
)
AGGREGATE KEY(`user_id`, `date`, `city`, `age`, `sex`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

Как видите, это таблица фактов с типичной пользовательской информацией и поведением доступа. В общей звездообразной схеме информация о пользователе и поведение доступа обычно хранятся в таблицах измерений и таблицах фактов соответственно. Здесь, чтобы было удобнее объяснить модель данных Дорис, мы храним две части информации в одной таблице.

Столбцы в таблице разделены на «Ключ» (столбец измерения) и «Значение» (столбец показателя) в зависимости от того, установлен ли AggregationType. Те, у которых не установлен AggregationType, например user_id, date, age и т. д., называются ключом, а те, у которых установлен AggregationType, называются значением.

Когда мы импортируем данные, строки с одинаковым столбцом «Ключ» будут агрегированы в одну строку, а столбец «Значение» — в соответствии с установленным типом агрегирования. AggregationType в настоящее время имеет следующие методы агрегации и agg_state:

СУММА: искать и, несколько строк из Value Накопить.
ЗАМЕНА: Замена, следующая партия данныхсерединаиз Value Заменит форвард, импортированный в строке из Value。
МАКС.: сохранить максимальное значение.
МИН: сохранение минимального значения.
REPLACE_IF_NOT_NULL: замена ненулевого значения. и REPLACE изразличие существует для null значение, замена не производится.
HLL_UNION：HLL Тип из Списокиз метод агрегации, применяют HyperLogLog Алгоритмическая агрегация.
BITMAP_UNION：BIMTAP Тип метода агрегации из Списокиз, выполняет агрегацию битовых изображений из объединения.

Если эти методы агрегации не могут удовлетворить ваши потребности, вы можете использовать тип agg_state.

Допустим, у нас есть следующие импортированные данные (необработанные данные):

user_id	date	city	age	sex	last_visit_date	cost	max_dwell_time	min_dwell_time
10000	2017-10-01	Пекин	20	0	2017-10-01 06:00:00	20	10	10
10000	2017-10-01	Пекин	20	0	2017-10-01 07:00:00	15	2	2
10001	2017-10-01	Пекин	30	1	2017-10-01 17:05:45	2	22	22
10002	2017-10-02	Шанхай	20	1	2017-10-02 12:59:12	200	5	5
10003	2017-10-02	Гуанчжоу	32	0	2017-10-02 11:20:00	30	11	11
10004	2017-10-01	Шэньчжэнь	35	0	2017-10-01 10:00:15	100	3	3
10004	2017-10-03	Шэньчжэнь	35	0	2017-10-03 10:20:22	11	6	6

Импортировать данные через sql:

insert into example_db.example_tbl_agg1 values
(10000,"2017-10-01","Пекин",20,0,"2017-10-01 06:00:00",20,10,10),
(10000,"2017-10-01","Пекин",20,0,"2017-10-01 07:00:00",15,2,2),
(10001,"2017-10-01","Пекин",30,1,"2017-10-01 17:05:45",2,22,22),
(10002,"2017-10-02","Шанхай",20,1,"2017-10-02 12:59:12",200,5,5),
(10003,"2017-10-02","Гуанчжоу",32,0,"2017-10-02 11:20:00",30,11,11),
(10004,"2017-10-01","Шэньчжэнь",35,0,"2017-10-01 10:00:15",100,3,3),
(10004,"2017-10-03","Шэньчжэнь",35,0,"2017-10-03 10:20:22",11,6,6);

Предположим, что это таблица, в которой фиксируется поведение пользователей, посещающих определенную страницу товара. Давайте возьмем первую строку данных в качестве примера и объясним ее следующим образом:

данные	иллюстрировать
10000	пользователь id,Каждый пользователь однозначно идентифицируется id
2017-10-01	время хранения данных с точностью до даты
Пекин	пользователь Местосуществовать Город
20	пользовательвозраст
0	Пол мужской (1 представляю женщин)
2017-10-01 06:00:00	пользователь Это посещение этой страницыизвремя,С точностью до секунды
20	пользователь Это посещение вызвано потреблением
10	пользовательэтот визит,Оставайтесь на этой страницеизвремя
10	пользовательэтот визит,Время оставаться на этой странице (избыточно)

Затем, когда этот пакет данных правильно импортируется в Doris, окончательное хранилище в Doris выглядит следующим образом:

user_id	date	city	age	sex	last_visit_date	cost	max_dwell_time	min_dwell_time
10000	2017-10-01	Пекин	20	0	2017-10-01 07:00:00	35	10	2
10001	2017-10-01	Пекин	30	1	2017-10-01 17:05:45	2	22	22
10002	2017-10-02	Шанхай	20	1	2017-10-02 12:59:12	200	5	5
10003	2017-10-02	Гуанчжоу	32	0	2017-10-02 11:20:00	30	11	11
10004	2017-10-01	Шэньчжэнь	35	0	2017-10-01 10:00:15	100	3	3
10004	2017-10-03	Шэньчжэнь	35	0	2017-10-03 10:20:22	11	6	6

Как видите, для пользователя 10 000 осталась только одна строка агрегированных данных. Данные остальных пользователей остаются в соответствии с исходными данными. Здесь мы сначала объясним агрегированные данные пользователя 10 000:

Первые 5 столбцов не изменяются, начиная со столбца 6 Last_visit_date:

• 2017-10-01 07:00:00: Потому что last_visit_date Метод агрегирования столбцов: ЗАМЕНИТЬ, так что 2017-10-01 07:00:00 заменил 2017-10-01 06:00:00 Сохранено.
  • Примечание: существуют изданные в одной импортной партии, для REPLACE В этом методе агрегации порядок замены не гарантируется. Как и в примере существования, оно в конечном итоге было сохранено, также возможно, что 2017-10-01 06:00:00。Для разных партий импортасерединаизданные,Гарантировано,Последняя изданная партия заменит предварительную партию.
• 35: поскольку типом агрегирования столбца затрат является СУММА, 35 получается путем сложения 20 + 15.
• 10: Потому что max_dwell_time Тип агрегирования столбца: МАКС, так 10 и 2 Возьмите максимальное значение и получите 10。
• 2: Потому что min_dwell_time Тип агрегирования столбца: МИН, так что 10 и 2 Возьмите минимальное значение и получите 2。

После агрегирования в Doris будут храниться только агрегированные данные. Другими словами, подробные данные будут потеряны, и пользователи больше не смогут запрашивать подробные данные перед агрегированием.

3. Уникальная модель

Если у пользователей есть потребность в обновлении данных, они могут выбрать использование уникальной модели данных. Модель Unique может гарантировать уникальность ключа. Когда пользователь обновляет часть данных, новые записанные данные перезапишут старые данные с тем же ключом.

Два метода реализации

Unique Модельпредоставил Два метода реализации：

слияние при чтении

В реализации слияния во время чтения пользователи не будут запускать какие-либо операции, связанные с дедупликацией данных, при записи данных. Все операции дедупликации данных выполняются во время запроса или сжатия. Таким образом, производительность записи при слиянии во время чтения выше, производительность запросов хуже, а потребление памяти также выше.

объединить при записи (merge-on-write)。

существовать 1.2 версию, мы представили знания при Согласно данным реализации, эта реализация завершит всю работу по дедупликации данных на этапе записи, поэтому она может обеспечить очень хорошую производительность. с 2.0 Из версии,слова при записи были очень зрелыми и стабильными,Благодаря своему совершенству из Запроспроизводительности,Мы рекомендуем большинству пользователей выбирать эту реализацию. с 2.1 версия это,объединить при записистановятся Unique Реализация модели по умолчанию О Два метода реализациииз Подробные различия,пользователь В этой главе вы можете прочитать следующее содержаниеизпредставлять。О Два метода Различия в реализацииизпроизводительности см. в следующей главе «Ограничения модели агрегации».

Семантика обновления данных

Unique Семантика обновления модели по умолчанию — UPSERT для всей строки, т. е. UPDATE OR INSERT, строка данных key Если существование сохранено, выполняется обновление, если существование не сохранено, вставляются новые данные. существует Вся линейка UPSERT означает, Прямо сейчасделатьпользовательделатьиспользовать insert into Укажите несколько столбцов для записи, Дорис. Такжесуществовать Planner Использовать недостающие столбцы в NULL значение или значение по умолчанию для заполнения Частичный список обновлен. Если пользователь желает обновить некоторые поля,Необходимо использовать слова при записи, чтобы достичь,И укажите определенные параметры, чтобы включить частичное обновление списка поддержки.

Слияние при чтении (та же реализация, что и агрегатная модель)

ColumnName	Type	IsKey	Comment
user_id	BIGINT	Yes	пользователь id
username	VARCHAR(50)	Yes	пользователь Никнейм
city	VARCHAR(20)	No	пользователь Местосуществовать Город
age	SMALLINT	No	пользовательвозраст
sex	TINYINT	No	пользовательпол
phone	LARGEINT	No	пользователь Телефон
address	VARCHAR(500)	No	пользовательадрес
register_time	DATETIME	No	пользовательзарегистрироватьсявремя

Это типичная таблица базовой информации пользователя. Этот тип данных не имеет требований к агрегации и должен обеспечивать только уникальность первичного ключа. (Первичный ключ здесь — user_id + имя пользователя). Тогда наш оператор создания таблицы будет выглядеть следующим образом:

CREATE TABLE IF NOT EXISTS example_db.example_tbl_unique
(
    `user_id` LARGEINT NOT NULL COMMENT "пользовательid",
    `username` VARCHAR(50) NOT NULL COMMENT "пользователь Никнейм",
    `city` VARCHAR(20) COMMENT "пользователь Местосуществовать Город",
    `age` SMALLINT COMMENT "пользовательвозраст",
    `sex` TINYINT COMMENT "пользовательпол",
    `phone` LARGEINT COMMENT "пользователь Телефон",
    `address` VARCHAR(500) COMMENT "пользовательадрес",
    `register_time` DATETIME COMMENT "пользовательзарегистрироватьсявремя"
)
UNIQUE KEY(`user_id`, `username`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

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

ColumnName	Type	AggregationType	Comment
user_id	BIGINT		пользователь id
username	VARCHAR(50)		пользователь Никнейм
city	VARCHAR(20)	REPLACE	пользователь Местосуществовать Город
age	SMALLINT	REPLACE	пользовательвозраст
sex	TINYINT	REPLACE	пользовательпол
phone	LARGEINT	REPLACE	пользователь Телефон
address	VARCHAR(500)	REPLACE	пользовательадрес
register_time	DATETIME	REPLACE	пользовательзарегистрироватьсявремя

И заявление о создании таблицы:

CREATE TABLE IF NOT EXISTS example_db.example_tbl_agg3
(
    `user_id` LARGEINT NOT NULL COMMENT "пользовательid",
    `username` VARCHAR(50) NOT NULL COMMENT "пользователь Никнейм",
    `city` VARCHAR(20) REPLACE COMMENT "пользователь Местосуществовать Город",
    `age` SMALLINT REPLACE COMMENT "пользовательвозраст",
    `sex` TINYINT REPLACE COMMENT "пользовательпол",
    `phone` LARGEINT REPLACE COMMENT "пользователь Телефон",
    `address` VARCHAR(500) REPLACE COMMENT "пользовательадрес",
    `register_time` DATETIME REPLACE COMMENT "пользовательзарегистрироватьсявремя"
)
AGGREGATE KEY(`user_id`, `username`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

То есть реализация слияния во время чтения модели Unique может быть полностью заменена методом REPLACE в агрегатной модели. Его внутренняя реализация и методы хранения данных абсолютно одинаковы. Никаких дополнительных примеров здесь приводиться не будет.

объединить при записи Unique Модельизобъединить при зафиксировано выполнение, Запроспроизводительность ближе к duplicate Модель,существование имеет требования к ограничениям первичного ключа и имеет большие преимущества, чем модель агрегации в сценариях из Запроспроизводительности,Особенность существования агрегации Запросов и необходимости фильтрации большого количества данныхиз Запросов с помощью индексов.

Продолжая использовать приведенную выше таблицу в качестве примера, оператор создания таблицы выглядит следующим образом:

CREATE TABLE IF NOT EXISTS example_db.example_tbl_unique_merge_on_write
(
    `user_id` LARGEINT NOT NULL COMMENT "пользовательid",
    `username` VARCHAR(50) NOT NULL COMMENT "пользователь Никнейм",
    `city` VARCHAR(20) COMMENT "пользователь Местосуществовать Город",
    `age` SMALLINT COMMENT "пользовательвозраст",
    `sex` TINYINT COMMENT "пользовательпол",
    `phone` LARGEINT COMMENT "пользователь Телефон",
    `address` VARCHAR(500) COMMENT "пользовательадрес",
    `register_time` DATETIME COMMENT "пользовательзарегистрироватьсявремя"
)
UNIQUE KEY(`user_id`, `username`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"enable_unique_key_merge_on_write" = "true"
);

Структура таблицы, созданная с помощью этого оператора создания таблицы, полностью отличается от модели агрегации:

ColumnName	Type	AggregationType	Comment
user_id	BIGINT		пользователь id
username	VARCHAR(50)		пользователь Никнейм
city	VARCHAR(20)	NONE	пользователь Местосуществовать Город
age	SMALLINT	NONE	пользовательвозраст
sex	TINYINT	NONE	пользовательпол
phone	LARGEINT	NONE	пользователь Телефон
address	VARCHAR(500)	NONE	пользовательадрес
register_time	DATETIME	NONE	пользовательзарегистрироватьсявремя

существоватьвключенобъединить при записиопцийиз Unique В таблице на этапе импорта данныхсуществовать перезаписанные и обновленные изданные будут отмечены для удаления, и в то же время будут записаны новые изданные в новый исходный файл. существуют Запросиз времени, Все файлы, помеченные для удаления, будут отфильтрованы на уровне файлов, а все файлы, помеченные для удаления, будут самыми последними, что исключает указание. при чтениисерединаизданныепроцесс полимеризации,И во многих случаях он может поддерживать несколько изменений предиката. Поэтому существование многих сцен может привести к большим улучшениям.,Особенно когда существование имеет совокупный Запросиз.

【Уведомление】

Unique Метод реализации таблицы может быть определен только при создании таблицы и не может быть определен методом проведения. schema change Внесите изменения. старомодный Merge-on-read Реализация не может быть плавно обновлена ​​до Merge-on-write из реализации (данные организованы совершенно по-другому), при необходимости используйте вместо этого слова при записииз версии реализации, вам необходимо вручную выполнить вставку into unique-mow-table select * from source table.

4. Дублирующая модель

существуют в некоторых сценариях многомерного анализа,данные не имеют ни первичного ключа,Совокупного спроса также нет. поэтому,Мы представляем Duplicate модель данных для удовлетворения таких потребностей. Приведите примеры.

ColumnName	Type	SortKey	Comment
timestamp	DATETIME	Yes	Записать время
type	INT	Yes	Тип журнала
error_code	INT	Yes	код ошибки
error_msg	VARCHAR(1024)	No	Подробности ошибки
op_id	BIGINT	No	ответственное лицо id
op_time	DATETIME	No	время обработки

Инструкция создания таблицы выглядит следующим образом:

CREATE TABLE IF NOT EXISTS example_db.example_tbl_duplicate
(
    `timestamp` DATETIME NOT NULL COMMENT "Записать время",
    `type` INT NOT NULL COMMENT "Тип журнала",
    `error_code` INT COMMENT "код ошибки",
    `error_msg` VARCHAR(1024) COMMENT "Подробности ошибки",
    `op_id` BIGINT COMMENT "ответственное лицоid",
    `op_time` DATETIME COMMENT «время обработки»
)
DUPLICATE KEY(`timestamp`, `type`, `error_code`)
DISTRIBUTED BY HASH(`type`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

Эта модель данных отличается от Aggregate и Unique Модель. Данные сохраняются точно так же, как в импортированном файле, без какой-либо агрегации. Даже если две строки данных идентичны, они будут сохранены. И существование указывается в операторе создания таблицы DUPLICATE KEY используется только для указания того, по каким столбцам сортируются базовые данные. (Более подходящим названием было бы «Сортированное». Column”, Вот название "ДУБЛИКАТ" KEY» используется только для четкого указания используемой модели данных. Столбец"из Для получения дополнительных пояснений обратитесь к указателю суффикса форвард).существовать DUPLICATE KEY При выборе мы рекомендуем соответствующий выбор перед 2-4 Просто перечислите это.

Эта модель данных подходит для хранения исходных данных, которые не имеют ни требований агрегирования, ни ограничений уникальности первичного ключа. Дополнительные сценарии использования см. в разделе «Ограничения модели агрегации».

Дублировать модель без сортировки столбцов

Не указано при создании таблицы Unique、Aggregate или Duplicate , будет создан по умолчанию Duplicate Модельизповерхность,ис Автоматически указывать сортировку Список.

когдапользовательи Нет сортировкинуждатьсяизкогда,Это можно настроить в свойствах таблицы «Проводитьсуществовать»:

"enable_duplicate_without_keys_by_default" = "true"

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

Инструкция создания таблицы выглядит следующим образом:

CREATE TABLE IF NOT EXISTS example_db.example_tbl_duplicate_without_keys_by_default
(
    `timestamp` DATETIME NOT NULL COMMENT "Записать время",
    `type` INT NOT NULL COMMENT "Тип журнала",
    `error_code` INT COMMENT "код ошибки",
    `error_msg` VARCHAR(1024) COMMENT "Подробности ошибки",
    `op_id` BIGINT COMMENT "ответственное лицоid",
    `op_time` DATETIME COMMENT «время обработки»
)
DISTRIBUTED BY HASH(`type`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"enable_duplicate_without_keys_by_default" = "true"
);

MySQL > desc example_tbl_duplicate_without_keys_by_default;
+------------+---------------+------+-------+---------+-------+
| Field      | Type          | Null | Key   | Default | Extra |
+------------+---------------+------+-------+---------+-------+
| timestamp  | DATETIME      | No   | false | NULL    | NONE  |
| type       | INT           | No   | false | NULL    | NONE  |
| error_code | INT           | Yes  | false | NULL    | NONE  |
| error_msg  | VARCHAR(1024) | Yes  | false | NULL    | NONE  |
| op_id      | BIGINT        | Yes  | false | NULL    | NONE  |
| op_time    | DATETIME      | Yes  | false | NULL    | NONE  |
+------------+---------------+------+-------+---------+-------+
6 rows in set (0.01 sec)

5. Рекомендации по выбору моделей данных

Потому что данные Модельсуществовать уже были определены при создании таблицы.,и не могут быть изменены. так,Очень важно выбрать подходящую изданную Модель.

Aggregate Модель может содержать предварительно полимеризованный,Значительно сокращает объем сканирования и вычислений, необходимых при агрегировании Запросов.,Он очень подходит для сценариев с фиксированными шаблонами и типами отчетов. Но граф(*) Вопрос был очень недружелюбным. Списокначальствометод агрегирования,существуют при выполнении других видов изагрегации Запрос,Необходимо учитывать семантическую корректность.

Уникальная модель предназначена для сценариев, в которых требуются уникальные ограничения первичного ключа.,Гарантировано Ограничение уникальности первичного ключа。но нельзя использовать ROLLUP ждать Преполимеризацияприноситьиз Запрос Преимущества。Для агрегации Запрос Есть более высокийпроизводительностьнуждатьсяизпользователь,рекомендоватьделатьиспользоватьс 1.2 Версия добавлена ​​изообъединить при записывает реализацию.

Duplicate Подходит для любого размера Ad-hoc Запрос。虽然同样无法利использовать Преполимеризацияизхарактеристика,Но не подлежит агрегации Модельиз,Вы можете воспользоваться Список, чтобы сохранить Модельиз (только чтение связанного списка).,не читая весь Ключевой Список).

【ссылка】：Знакомство с официальным сайтом Doris