таблица разделов, что лучше?

Question

У меня есть таблица TimeData, которая должна быть разбита на кварталы для каждого года с 2009 по 2013 год, и ни одной для следующих лет

Я сделал 2 подхода:

1

CREATE TABLE TimeData (
id      NUMBER PRIMARY KEY NOT NULL,
day_name varchar(45),
day     NUMBER(2),
month   NUMBER(2),
quart   NUMBER(1),
year    NUMBER(4)
)

 PARTITION BY LIST (year)
 SUBPARTITION BY LIST (quart)
 (
  SUBPARTITION q1 values (1),
  SUBPARTITION q2 values (2),
  SUBPARTITION q3 values (3),
  SUBPARTITION q2 values (4)
)
  (
SUBPARTITION y_09 VALUES (2009),  
SUBPARTITION y_10 VALUES (2010),  
SUBPARTITION y_11 VALUES (2011),  
SUBPARTITION y_12 VALUES (2012),  
SUBPARTITION other VALUES (DEFAULT),
 ) ;

2

CREATE TABLE TimeData (
id      NUMBER PRIMARY KEY NOT NULL,
day_name varchar(45),
day     NUMBER(2),
month   NUMBER(2),
year    NUMBER(4)
)

PARTITION BY LIST (year)
SUBPARTITION BY RANGE (month)
(
  SUBPARTITION q1 values less than(4),
  SUBPARTITION q2 values less than(7),
  SUBPARTITION q3 values less than(10),
  SUBPARTITION q2 values less than(13)
)
(
SUBPARTITION y_09 VALUES (2009),
SUBPARTITION y_10 VALUES (2010),
SUBPARTITION y_11 VALUES (2011),
SUBPARTITION y_12 VALUES (2012),
SUBPARTITION other VALUES (DEFAULT),
 );

оба подхода продолжают разделяться после 2012 года, я не мог понять, как преодолеть это
, но вопрос в том, делает ли поле 'кварта' лучше?меньше вычислений может быть
или без него, меньше памяти?!

** обновление
третий подход, который только что всплыл в моей голове, состоит в том, чтобы иметь 16 разделов (4 квартала * 4 года) и 17-ераздел - это значения, меньшие (maxvalue) .. таким образом, я могу преодолеть вечное разделение, верно?

Answer 1

Прошло много времени с тех пор, как я работал с разделами, так что возьмите это с крошкой соли ...

Если это действительно так, что вы имеете дело с 16 фиксированными разделами, ничего после этого, и вынужно только те 16 разделов и никогда больше, тогда можно было бы просто использовать диапазоны диапазона, где первый квартал продолжается до начала времени, а последний квартал - до конца времени (замените дату своей собственной разбивкой):

PARTITION BY RANGE (date)
  (PARTITION p2009_q1 VALUES LESS THAN (TO_DATE('2009-04-01', 'YYYY-MM-DD')),
   PARTITION p2009_q2 VALUES LESS THAN (TO_DATE('2009-07-01', 'YYYY-MM-DD')),
   PARTITION p2009_q3 VALUES LESS THAN (TO_DATE('2009-10-01', 'YYYY-MM-DD')),
   PARTITION p2009_q4 VALUES LESS THAN (TO_DATE('2010-01-01', 'YYYY-MM-DD')),
   PARTITION p2010_q1 VALUES LESS THAN (TO_DATE('2010-04-01', 'YYYY-MM-DD')),
   ...
   PARTITION p2013_q3 VALUES LESS THAN (TO_DATE('2014-09-01', 'YYYY-MM-DD')),
   PARTITION p2013_q4 VALUES LESS THAN  MAXVALUE) 

Или вы можете просто хэшировать в 16 ведер.

Теперь в сторону.Вопросы, которые сразу же приходят на ум:

• почему его нужно разбивать на квартальные значения?
• почему его нужно разбивать на части?
• почему только до 2013 года?(что будет после этого?)
• после 2013 года, что будет со старыми данными / разделами?
• после начальной загрузки новые записи будут добавляться только в раздел «текущая дата»?
• какие объемы данных мы ожидаем на раздел?

Разделение - это физический атрибут, который будет зависеть от использования данных.С моей точки зрения гранулирование разделов обычно определяется размером данных и требованиями к архивированию.Например, если регистрируется миллион строк данных журнала в день, я могу разбивать разделы по дням, регулярно предварительно создавая разделы на предстоящие дни и меняя старые дни только на чтение.Данные могут быть полезны только в течение недели, после чего самый старый раздел может быть удален или заархивирован.Тогда у нас есть движущееся окно перегородок.Но если бы я получал только 10 000 записей в неделю, я бы просто создал скользящее окно еженедельных разделов.Не то чтобы мне действительно нужен раздел только для одной недели данных, а потому, что он дает мне простой способ отбрасывать / архивировать данные старше недели (через раздел) в соответствии с требованиями к хранению данных.Конечный пользователь может просматривать данные по дням, часам и т. Д.

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

Да, и, кстати, если вы называете свои разделы в хорошей сортируемой форме (ГГГГММ ДД ...), становится довольно легко написать скрипт, который выполняет немного динамического sql для "изменения таблицы добавления раздела" и следит за созданием раздела (если он еще не был добавлен как функция).Учитывая это, первый и последний разделы должны быть названы немного по-другому.

Answer 2

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

create table TimeData
(
    id number primary key,
    the_date date
)
partition by range(the_date)
interval (numToYMInterval(3, 'month'))
(
    partition first_partition values less than (date '0001-01-01')
);

Использование одной датыстолбец вместо нескольких чисел и столбцы varchar имеют несколько существенных преимуществ:

• Использует значительно меньше памяти
• Удаляет много потенциальных проблем с данными
• Предоставляет гораздо более полезную информацию дляоптимизатор
• Упрощает многие запросы (вам нужно знать функции и форматы даты Oracle, но вам не нужно перестраивать дату)

Интервальное разбиение может значительноулучшить маневренность;Вам никогда не придется беспокоиться о предварительном создании новых разделов.