Мы находимся в процессе миграции нашего локального Oracle дБ в облако. Самый большой проект - переместить нашу таблицу фактов, которая отслеживает транзакции клиентов.
Краткий вопрос : Какой лучший способ разделить / разделить таблицу фактов в BigQuery, когда вы не можете использовать дату поле для разделения из-за ограничения в 4000 разделов? Цель состоит в том, чтобы максимизировать производительность запросов и минимизировать затраты.
Подробный вопрос Я не хочу дублировать таблицу в BigQuery, потому что я хочу, чтобы она была оптимизирована для BigQuery. Итак, я изучал разделение, разделение и кластеризацию. Также рассматривает денормализацию, но это другой вопрос.
В нашем Oracle db мы просто делим на целую дату YYYYMMDD
. Я не верю, что мы можем сделать это в BigQuery, однако из-за того, что таблица может иметь только 4000 разделов. Если мы разделим по дням, наша таблица может содержать данные только за чуть менее 11 (4000/365) лет - что намного ниже того, что нам нужно в настоящее время для миграции.
Конечно, есть и другие поля, которые мы может разделить помимо даты (например, местоположение сайта), но я считаю, что дата может быть лучше.
Ниже приведены варианты, которые я рассматриваю. Допустим, таблица содержит столбец datetime
order_date
и целочисленную версию даты order_date_id
- Shard by year (ie все заказы с
order_date
в 2001 go в my_table_2001
, разбить каждую таблицу на order_date
- Нет шардинга, иметь одну большую таблицу, создать целочисленный столбец для года (
order_year
) и использовать его для столбца раздела - Шард другим столбец (например, местоположение сайта), затем разделить на
order_year
- Shard на
order_year
и другой столбец (например, местоположение сайта), разделить на order_date
Если я собираюсь разделять таблицы на части, я определенно хочу использовать столбец datetime
для разделения, чтобы я мог использовать подстановочные знаки для запроса всех разделенных таблиц. Я обнаружил, что целочисленные диапазоны для разбиения не позволяют использовать подстановочные знаки.
Также важно отметить, что бизнес-пользователи могут постоянно запрашивать данные для больших диапазонов дат, если не все доступные данные.