PolarDB:CREATE TABLE (modo AUTO)

Tipos de partição

Tipo Hash

No PolarDB-X, existem dois tipos de particionamento baseado em hash: particionamento hash e particionamento key. Ambos fazem parte da sintaxe padrão de particionamento do MySQL nativo. Para habilitar recursos flexíveis de gerenciamento de partições — como divisão, mesclagem e migração — e suportar a divisão de hot spots para chaves de partição vetoriais, o PolarDB-X redefine o roteamento para os particionamentos hash e key; embora mantenha compatibilidade sintática com a sintaxe CREATE TABLE do MySQL, sua implementação subjacente de partition routing difere da do MySQL. A tabela a seguir descreve as diferenças entre o particionamento key e o particionamento hash:

Exemplo 1-1: Partição Key

CREATE TABLE key_tbl(
 id bigint not null auto_increment,
 bid int,
 name varchar(30),
 birthday datetime not null,
 primary key(id)
)
PARTITION BY KEY(name, id)
PARTITIONS 8;

## This query triggers partition pruning and scans only a single partition.
SELECT id from key_tbl where name='Jack';

Caso a primeira partition column, name, cause data imbalance ou um data hotspot, realize uma partition split usando a próxima partition column, como id. Para mais detalhes, consulte Modify a table group level partition (AUTO mode).

Se uma chave de partição vetorial com N colunas usar suas primeiras K colunas para roteamento (1 ≤ K ≤ N), incluir condições nas colunas de partição de prefixo (as primeiras K colunas) na cláusula WHERE habilita o pruning de partição.

Exemplo 1-2: Particionamento Hash

CREATE TABLE hash_tbl(
 id bigint not null auto_increment,
 bid int,
 name varchar(30),
 birthday datetime not null,
 primary key(id)
)
partition by hash(id)
partitions 8;

CREATE TABLE hash_tbl_todays(
 id bigint not null auto_increment,
 bid int,
 name varchar(30),
 birthday datetime not null,
 primary key(id)
)
PARTITION BY HASH(TO_DAYS(birthday))
PARTITIONS 8;

Atualmente, o PolarDB-X suporta as seguintes funções de partição:

• YEAR

• MONTH

• DAYOFMONTH

• DAYOFWEEK

• DAYOFYEAR

• TO_DAYS

• TO_MONTHS

• TO_WEEKS

• TO_SECONDS

• UNIX_TIMESTAMP

• SUBSTR/SUBSTRING

Para as funções SUBSTR/SUBSTRING, a chave de partição deve ser do tipo string; para todas as outras funções de partição, deve ser do tipo tempo (como DATE, DATETIME ou TIMESTAMP).

Exemplo 1-3: Expansão de partição Hash

CREATE TABLE hash_tbl2(
 id bigint not null auto_increment,
 bid int,
 name varchar(30),
 birthday datetime not null,
 primary key(id)
)
PARTITION BY HASH(name, birthday)
PARTITIONS 8;

Diferentemente do particionamento key, o particionamento hash usa uma chave de partição vetorial, onde todas as colunas de partição contribuem tanto para os cálculos de hash quanto para os de roteamento. Portanto, para habilitar o pruning de partição, a cláusula WHERE de uma consulta SQL deve especificar condições de igualdade para todas as colunas de partição. Por exemplo, SQL1 pode acionar o pruning de partição na tabela hash_tbl2, mas SQL2 não:

##SQL1 (This query triggers partition pruning, scanning only a single partition)
SELECT id from hash_tbl2 where name='Jack' and birthday='1990-11-11';

##SQL2 (This query does not trigger partition pruning, resulting in a full partition scan)
SELECT id from hash_tbl2 where name='Jack';

Como o hash partitioning usa toda a partition key para calcular o hash value antecipadamente, ele teoricamente distribui os dados de forma mais uniforme do que o key partitioning usando uma vector partitioning key. No entanto, não pode suportar hotspot splitting, pois não há column s subsequentes disponíveis para dividir uma partição quente.

Limitações

• Limitações de tipo de dados

  • Tipos inteiros: BIGINT, BIGINT UNSIGNED, INT, INT UNSIGNED, MEDIUMINT, MEDIUMINT UNSIGNED, SMALLINT, SMALLINT UNSIGNED, TINYINT e TINYINT UNSIGNED.

  • Tipos de tempo: DATETIME, DATE e TIMESTAMP.

  • Tipos de string: CHAR e VARCHAR.

• Limitações de sintaxe

  • Ao usar uma função de partição com uma chave de partição de coluna única para uma partição hash, a chave deve ser do tipo tempo.

  • Uma chave de partição vetorial para uma partição hash não suporta funções de partição ou divisão de hot spot.

  • Por padrão, o número máximo de partições é 8.192.

  • Por padrão, o número máximo de colunas de partição é 5.

Uniformidade de Dados

• O algoritmo de hash consistente interno para particionamento key e hash é o MurmurHash3, um algoritmo de alto desempenho com baixa probabilidade de colisão.

• Com o MurmurHash3, a distribuição de dados para particionamento key e hash geralmente se torna equilibrada apenas quando o número de valores distintos de chave de partição (N) excede 3.000. Quanto maior o valor de N, mais equilibrada será a distribuição dos dados.

Tipo Range

No PolarDB-X, existem dois tipos de particionamento range: partição range e partição range columns. Ambos fazem parte da sintaxe padrão de particionamento do MySQL nativo. A tabela a seguir compara esses dois tipos de partição.

Exemplo 2-1: Particionamento Range columns

O particionamento Range columns suporta uma chave de partição vetorial, mas não uma função de partição. Por exemplo, para particionar uma tabela por ID do pedido e data do pedido, use a seguinte sintaxe CREATE TABLE:

CREATE TABLE orders(
 order_id int,
 order_time datetime not null)
PARTITION BY RANGE COLUMNS(order_id,order_time)
(
  PARTITION p1 VALUES LESS THAN (10000,'2021-01-01'),
  PARTITION p2 VALUES LESS THAN (20000,'2021-01-01'),
  PARTITION p3 VALUES LESS THAN (30000,'2021-01-01'),
  PARTITION p4 VALUES LESS THAN (40000,'2021-01-01'),
  PARTITION p5 VALUES LESS THAN (50000,'2021-01-01'),
  PARTITION p6 VALUES LESS THAN (MAXVALUE,MAXVALUE)
);

Exemplo 2-2: Particionamento range

O particionamento Range suporta apenas uma chave de partição de coluna única. No entanto, para uma coluna de partição datetime, utilize funções de partição como YEAR, TO_DAYS, TO_SECONDS ou MONTH para converter seus valores em inteiros.

Por exemplo, para criar partições trimestrais na coluna order_time usando particionamento range, use a seguinte sintaxe:

CREATE TABLE orders_todays(
 id int,
 order_time datetime not null)
PARTITION BY RANGE(to_days(order_time))
(
  PARTITION p1 VALUES LESS THAN (to_days('2021-01-01')),
  PARTITION p2 VALUES LESS THAN (to_days('2021-04-01')),
  PARTITION p3 VALUES LESS THAN (to_days('2021-07-01')),
  PARTITION p4 VALUES LESS THAN (to_days('2021-10-01')),
  PARTITION p5 VALUES LESS THAN (to_days('2022-01-01')),
  PARTITION p6 VALUES LESS THAN (MAXVALUE)
);

Limites

• Restrições de tipo de dados

  • Tipos inteiros: BIGINT, BIGINT UNSIGNED, INT, INT UNSIGNED, MEDIUMINT, MEDIUMINT UNSIGNED, SMALLINT, SMALLINT UNSIGNED, TINYINT e TINYINT UNSIGNED.

  • Tipos de data e hora: DATETIME e DATE.

  • Tipos de string: CHAR e VARCHAR.

• Restrições de sintaxe

  • Os particionamentos RANGE COLUMNS e RANGE não suportam o uso de um valor NULL como valor limite.

  • O particionamento RANGE COLUMNS não suporta o tipo de dados TIMESTAMP.

  • O particionamento RANGE suporta apenas tipos inteiros. Se a chave de partição usar o tipo TIMESTAMP, utilize a função UNIX_TIMESTAMP para garantir a consistência do fuso horário.

  • O particionamento RANGE não suporta divisão de hot spot.

  • Durante consultas, valores NULL são tratados como o valor mínimo para roteamento de partição.

  • Por padrão, o número máximo de partições é 8.192.

  • Por padrão, o número máximo de colunas de partição é 5.

Tipo List

Semelhante ao range type, o PolarDB-X subdivide a list partitioning policy em dois tipos: list partitioning e list columns partitioning. Ambos usam a sintaxe padrão de particionamento do MySQL nativo. Além disso, o PolarDB-X suporta uma default partition tanto para list partitioning quanto para list columns partitioning. Esta tabela compara os dois tipos:

Exemplo 3-1: Particionamento List columns

O list columns partitioning suporta vector partition keys. Por exemplo, o list columns partitioning permite particionar pedidos por país e cidade. A table creation syntax é a seguinte:

CREATE TABLE orders_region(
 id int,
 country varchar(64),
 city varchar(64),
 order_time datetime not null)
PARTITION BY LIST COLUMNS(country,city)
(
  PARTITION p1 VALUES IN (('China','Hangzhou'), ('China','Beijing')),
  PARTITION p2 VALUES IN (('United States','New York'),('United States','Chicago')),
  PARTITION p3 VALUES IN (('Russia','Moscow'))
);

Exemplo 3-2: Particionamento list

Embora o list partitioning suporte apenas uma single-column partition key, para uma partition column do time-type, utilize partition function expressions como YEAR, MONTH, DAYOFMONTH, TO_DAYS e TO_SECONDS para converter seus valores em um integer type.

Por exemplo, para criar uma list partition baseada no ano da coluna order_time, use a seguinte sintaxe create table:

CREATE TABLE orders_years(
 id int,
 country varchar(64),
 city varchar(64),
 order_time datetime not null)
PARTITION BY LIST(YEAR(order_time))
(
  PARTITION p1 VALUES IN (1990,1991,1992,1993,1994,1995,1996,1997,1998,1999),
  PARTITION p2 VALUES IN (2000,2001,2002,2003,2004,2005,2006,2007,2008,2009),
  PARTITION p3 VALUES IN (2010,2011,2012,2013,2014,2015,2016,2017,2018,2019)
);

Exemplo 3-3: Partições List columns e list com uma partição padrão

O PolarDB-X suporta a criação de list columns partitions e list partitions que incluem uma default partition, para onde são roteados os dados não definidos nas regular partitions.

CREATE TABLE orders_region(
 id int,
 country varchar(64),
 city varchar(64),
 order_time datetime not null)
PARTITION BY LIST COLUMNS(country,city)
(
  PARTITION p1 VALUES IN (('China','Hangzhou'), ('China','Beijing')),
  PARTITION p2 VALUES IN (('United States','New York'),('United States','Chicago')),
  PARTITION p3 VALUES IN (('Russia','Moscow')),
  PARTITION pd VALUES IN (DEFAULT)
);

CREATE TABLE orders_years(
 id int,
 country varchar(64),
 city varchar(64),
 order_time datetime not null)
PARTITION BY LIST(YEAR(order_time))
(
  PARTITION p1 VALUES IN (1990,1991,1992,1993,1994,1995,1996,1997,1998,1999),
  PARTITION p2 VALUES IN (2000,2001,2002,2003,2004,2005,2006,2007,2008,2009),
  PARTITION p3 VALUES IN (2010,2011,2012,2013,2014,2015,2016,2017,2018,2019),
  PARTITION pd VALUES IN (DEFAULT)
);

Limites

• Restrições de tipo de dados

  • Tipos inteiros: BIGINT, BIGINT UNSIGNED, INT, INT UNSIGNED, MEDIUMINT, MEDIUMINT UNSIGNED, SMALLINT, SMALLINT UNSIGNED, TINYINT e TINYINT UNSIGNED.

  • Tipos de tempo: DATETIME e DATE.

  • Tipos de string: CHAR e VARCHAR.

• Restrições de sintaxe

  • O particionamento List Columns não suporta o tipo de dados TIMESTAMP.

  • O particionamento List suporta apenas tipos inteiros.

  • Nem o particionamento List Columns nem o particionamento List suportam divisão de hot spot.

  • Por padrão, o número máximo de partições é 8.192.

  • Por padrão, o número máximo de colunas de partição é 5.

Tipo CoHash

A política de particionamento CoHash do PolarDB-X é exclusiva do PolarDB-X.

Requisitos de versão

Use a versão 5.4.18-17047709 ou superior.

Casos de uso

Esta estratégia de particionamento é comumente usada nos seguintes cenários de negócio:

Se uma tabela possui colunas correlacionadas, como c1 e c2, cujos últimos quatro caracteres são sempre idênticos, particione-a horizontalmente em ambas as colunas para rotear consultas SQL com condição de igualdade em qualquer uma das colunas para uma única partição.

Portanto, esta estratégia exige que os valores permaneçam consistentes em várias colunas de partição na mesma tabela particionada.

Exemplo 4-1: Definir co-localização com funções de partição independentes

Suponha que sua aplicação tenha uma tabela orders onde as colunas order_id e buyer_id compartilham os mesmos seis últimos dígitos em cada linha. Para particionar esta tabela por esses dígitos compartilhados e garantir que uma consulta de igualdade em qualquer coluna seja roteada para a mesma partição, use a seguinte sintaxe:

CREATE TABLE t_orders(
 id bigint not null auto_increment, 
 order_id bigint, 
 buyer_id bigint,
 order_time datetime not null,
 primary key(id)
) 
PARTITION BY CO_HASH(
 	RIGHT(`order_id`,6) /* The last 6 characters of order_id */,
 	RIGHT(`buyer_id`,6) /* The last 6 characters of buyer_id */
) 
PARTITIONS 8;

Exemplo 4-2: Usando o açúcar sintático Range_Hash para migração de usuários da 1.0 para 2.0

Para uma migração da 1.0 para 2.0, considere uma tabela orders fragmentada por banco de dados e tabela usando range_hash, definida como: DBPARTIITION BY RANGE_HASH(. Sua tabela particionada correspondente no banco de dados 2.0 AUTO é definida da seguinte forma:

CREATE TABLE orders(
 id bigint not null auto_increment, 
 buyer_id bigint,
 order_id bigint,
 ...
 primary key(id)
) 
PARTITION BY RANGE_HASH(order_id, buyer_Id,6) 
PARTITIONS 8;

O PolarDB-X converte automaticamente a sintaxe RANGE_HASH em uma definição de partição CO_HASH. Por exemplo, RANGE_HASH(order_id, buyer_Id, 6) torna-se a seguinte definição CO_HASH:

CREATE TABLE orders(
 id bigint not null auto_increment, 
 buyer_id bigint,
 order_id bigint,
 ...
 primary key(id)
) 
PARTITION BY CO_HASH(
 	RIGHT(`order_id`,6) /* Uses the last 6 characters of order_id */,
 	RIGHT(`buyer_id`,6) /* Uses the last 6 characters of buyer_id */
) 
PARTITIONS 8;

Principais diferenças em relação ao particionamento hash/key

Como as estratégias de particionamento CoHash e hash/key são semelhantes, esta seção delineia suas principais semelhanças e diferenças de uso.

Considerações

• Seu serviço deve manter a relação coordenada entre os valores das colunas de partição; o PolarDB-X valida apenas os resultados de roteamento. Ao usar o particionamento CO_HASH, o PolarDB-X verifica se todos os valores de coluna de partição especificados para uma linha roteiam para o mesmo shard. No entanto, ele não valida se os próprios valores aderem à relação coordenada. Essa imposição é responsabilidade do seu serviço.

  Por exemplo, suponha que seu serviço exija que os últimos quatro caracteres das colunas c1 e c2 sejam idênticos. Se um valor para c1, como 100234, e um valor para c2, como 1320, ambos rotearem para o shard 0, o PolarDB-X permite a operação insert (c1,c2) values (100234,1320) porque o roteamento é consistente. Contudo, essa operação viola a regra de negócio, já que os últimos quatro caracteres de c1 (0234) e c2 (1320) não são iguais.

• Restrições DML na modificação de colunas de partição Como o particionamento CO_HASH correlaciona os valores de múltiplas colunas de partição, o PolarDB-X impõe as seguintes restrições em operações DML que modificam essas colunas para evitar distribuição incorreta de dados:

  • Para instruções insert e replace, se os valores para diferentes colunas de partição em uma única linha da cláusula VALUES resultarem em partições diferentes, o PolarDB-X rejeita a operação.

  • Para instruções update e upsert, modifique todas as colunas de partição simultaneamente na cláusula SET. Por exemplo, se c1 e c2 forem colunas de partição, use uma instrução como UPDATE t1 SET c1='xx',c2='yy' WHERE id=1. Se os novos valores para diferentes colunas de partição em uma única linha resultarem em partições diferentes, o PolarDB-X rejeita a instrução.

  • Quando CO_HASH é a estratégia de particionamento para um índice secundário global (GSI), o PolarDB-X também rejeita qualquer operação DML na tabela primária que faça com que os valores para diferentes colunas de partição em uma única linha do GSI resultem em partições diferentes.

• Tratamento de zeros à esquerda para tipos inteiros. Como as partition columns em uma estratégia CO_HASH são correlacionadas, frequentemente elas são definidas usando uma partition function como SUBSTR, LEFT ou RIGHT. Esse processo pode resultar em zeros à esquerda quando inteiros são truncados. Por exemplo, suponha que sua lógica de negócio exija que os últimos quatro caracteres de c1 e c2 sejam idênticos. Se c1 for 1000034, os últimos quatro caracteres são a string '0034'. Para uma partition column de integer type, o CO_HASH converte automaticamente qualquer valor truncado para o integer type daquela coluna antes do routing. Como resultado, o CO_HASH converte a string '0034' para o inteiro 34, calcula o hash value e roteia a linha. Este processo lida automaticamente com zeros à esquerda.

Limitações de função de partição

• RIGHT

• LEFT

• SUBSTR

Restrições de tipo de dados

• tipos inteiros: BIGINT, BIGINT UNSIGNED, INT, INT UNSIGNED, MEDIUMINT, MEDIUMINT UNSIGNED, SMALLINT, SMALLINT UNSIGNED, TINYINT e TINYINT UNSIGNED

• tipo de ponto fixo: DECIMAL (com escala 0)

• tipos de tempo: Não suportado

• tipos de string: CHAR e VARCHAR

Restrições de sintaxe

• Não use funções de partição aninhadas, como SUBSTR(SUBSTR(c1,-6),-4), em uma coluna de partição.

• Ao usar o açúcar sintático RANGE_HASH, o parâmetro de comprimento não deve ser negativo.

• Todas as colunas de partição devem ter exatamente o mesmo tipo de dados, incluindo as seguintes propriedades:

  • Conjunto de caracteres e collation

  • Comprimento e precisão

• Por padrão, o número máximo de partições é 8.192.

• Por padrão, o número máximo de colunas de partição é 5.

/*
 * This example defines templated subpartitions by using a LIST-KEY composite strategy.
 * The table is first partitioned by LIST COLUMNS into three partitions.
 * Each partition is then subpartitioned by KEY into four subpartitions, resulting in a total of 12 physical partitions.
*/
CREATE TABLE sp_tbl_list_key_tp(
 id int, 
 country varchar(64),
 city varchar(64),
 order_time datetime not null,
 PRIMARY KEY(id)
)
PARTITION BY LIST COLUMNS(country,city) 
SUBPARTITION BY KEY(id) SUBPARTITIONS 4
(
  PARTITION p1 VALUES IN (('China','Hangzhou')),
  PARTITION p2 VALUES IN (('Russian','Moscow')),
  PARTITION pd VALUES IN (DEFAULT)
);

/*
 * This example uses a LIST-KEY composite strategy to define non-templated subpartitions.
 * The table is partitioned by LIST COLUMNS into three first-level partitions, each of which is then subpartitioned by KEY.
 * The first-level partitions have 2, 3, and 4 subpartitions, respectively.
 * This results in a total of 9 physical partitions (2 + 3 + 4).
*/
CREATE TABLE sp_tbl_list_key_ntp(
 id int, 
 country varchar(64),
 city varchar(64),
 order_time datetime not null,
 PRIMARY KEY(id)
)
PARTITION BY LIST COLUMNS(country,city) 
SUBPARTITION BY KEY(id)
(
  PARTITION p1 VALUES IN (('China','Hangzhou')) SUBPARTITIONS 2,
  PARTITION p2 VALUES IN (('Russia','Moscow')) SUBPARTITIONS 3,
  PARTITION pd VALUES IN (DEFAULT) SUBPARTITIONS 4
);

show create table tbl_varchar_cs;
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| TABLE          | CREATE TABLE                                                                                                                                                                                                          |
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| tbl_varchar_cs | CREATE TABLE `tbl_varchar_cs` (
    `a` varchar(64) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
    KEY `auto_shard_key_a` USING BTREE (`a`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8
PARTITION BY KEY(`a`)
PARTITIONS 64 |
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.07 sec)

explain select a from tbl_varchar_cs where a in ('AbcD');
+-------------------------------------------------------------------------------------------------------------------------+
| LOGICAL EXECUTIONPLAN                                                                                                   |
+-------------------------------------------------------------------------------------------------------------------------+
| LogicalView(tables="tbl_varchar_cs[p29]", sql="SELECT `a` FROM `tbl_varchar_cs` AS `tbl_varchar_cs` WHERE (`a` IN(?))") |
| HitCache:false                                                                                                          |
| Source:PLAN_CACHE                                                                                                       |
| TemplateId: 2c49c244                                                                                                    |
+-------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.11 sec)

explain select a from tbl_varchar_cs where a in ('abcd');
+-------------------------------------------------------------------------------------------------------------------------+
| LOGICAL EXECUTIONPLAN                                                                                                   |
+-------------------------------------------------------------------------------------------------------------------------+
| LogicalView(tables="tbl_varchar_cs[p11]", sql="SELECT `a` FROM `tbl_varchar_cs` AS `tbl_varchar_cs` WHERE (`a` IN(?))") |
| HitCache:true                                                                                                           |
| Source:PLAN_CACHE                                                                                                       |
| TemplateId: 2c49c244                                                                                                    |
+-------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.02 sec)

show create table tbl_varchar_ci;
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| TABLE          | CREATE TABLE                                                                                                                                                                      |
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| tbl_varchar_ci | CREATE TABLE `tbl_varchar_ci` (
    `a` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
    KEY `auto_shard_key_a` USING BTREE (`a`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8
PARTITION BY KEY(`a`)
PARTITIONS 64 |
+----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.06 sec)

explain select a from tbl_varchar_ci where a in ('AbcD');
+------------------------------------------------------------------------------------------------------------------------+
| LOGICAL EXECUTIONPLAN                                                                                                  |
+------------------------------------------------------------------------------------------------------------------------+
| LogicalView(tables="tbl_varchar_ci[p4]", sql="SELECT `a` FROM `tbl_varchar_ci` AS `tbl_varchar_ci` WHERE (`a` IN(?))") |
| HitCache:false                                                                                                         |
| Source:PLAN_CACHE                                                                                                      |
| TemplateId: 5c97178e                                                                                                   |
+------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.15 sec)

explain select a from tbl_varchar_ci where a in ('abcd');
+------------------------------------------------------------------------------------------------------------------------+
| LOGICAL EXECUTIONPLAN                                                                                                  |
+------------------------------------------------------------------------------------------------------------------------+
| LogicalView(tables="tbl_varchar_ci[p4]", sql="SELECT `a` FROM `tbl_varchar_ci` AS `tbl_varchar_ci` WHERE (`a` IN(?))") |
| HitCache:true                                                                                                          |
| Source:PLAN_CACHE                                                                                                      |
| TemplateId: 5c97178e                                                                                                   |
+------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.02 sec)