Uma chave primária de mais de 5 colunas é ruim para uma tabela grande (+ de 100 milhões)?

Eu estava lendo sobre alguns problemas do banco de dados da vida real e um projeto tinha uma tabela de 100 milhões de linhas mais que tinha 5 colunas como principal. Estou pensando que isso é ruim, mas alguém pode me dizer exatamente por quê?

A tabela era como uma tabela de micro rollup / agregação, portanto as 5 colunas eram como (dia, id_do_mercado, id_do_produto ...). No começo, pensei que uma chave primária de 5 colunas não era o ideal, mas quanto mais pensava, não conseguia encontrar uma boa razão para ser ruim.

Foi uma discussão noturna com metade dos engenheiros da empresa. Alguém acabou de mencionar que este era um projeto ruim, concordou um engenheiro sênior, mas ninguém realmente entendeu o porquê. Assim, tentando pesquisar o assunto por mim mesmo!

Há problemas de desempenho com chaves primárias muito complexas. E pode não estar defendendo contra duplicação, assim como uma chave primária mais simples.

No entanto, existe um padrão de design que frequentemente gera tabelas com uma chave primária composta de seis ou mais componentes. São tabelas de fatos do esquema em estrela. Se a tabela de fatos de um esquema em estrela tiver seis dimensões, a chave primária terá seis componentes. Nunca vi uma tabela de fatos sem chave primária declarada e acho que vale a pena a sobrecarga, mesmo que o processo ETL ainda precise ser cuidadosamente escrito.

Alguns bancos de dados de relatórios imitam o padrão do esquema em estrela, mesmo que não seja explicitamente projetado dessa maneira.

Mais de 100 milhões de linhas não são muito grandes para uma tabela de fatos, especialmente com o big data de hoje.

A tabela em questão era uma tabela de rollup / agregação.

Então não é apenas bom, é "certo".

E cheira a uma tabela Resumo, pois começa com day .

Você tem alguns índices secundários? Lembre-se de que, se você estiver usando o InnoDB, o restante das colunas PRIMARY KEY será alinhado no final do índice secundário. Novamente, isso não é necessariamente um problema.

100 milhões de linhas é muito para um rollup. Parece que a mesa é muito refinada. Ou seja, talvez em vez disso, se (data, a, b, c, d) você tiver quatro rollups com PKs como (data, a, b, c), (data, b, c, d), (data, c, d, a), (data, d, a, b) (ou algumas combinações adequadas). Ao fazer isso, cada um pode ter apenas 10 milhões de linhas, tornando os relatórios ainda mais rápidos e tendo quase tanta flexibilidade no relatório.

Ou talvez mude para (semana, a, b, c, d), levando a talvez apenas 14 milhões de linhas. (Provavelmente mais.)

Usando PARTITION para facilitar a poda --- ingestão de alta velocidade --- dicas do Data Warehouse --- tabelas de resumo . Eles resumem muitas das técnicas que desenvolvi em vários projetos de DW. Como você pode inferir, cada projeto é diferente. O número "típico" de tabelas de resumo (na minha experiência) é 3-7. O destino na compactação é 10 linhas de fatos -> 1 linha de resumo. (Isso pode ser uma 'mediana'.) Em um caso raro, resumi uma tabela Resumo. Em outro caso raro, particionei uma tabela Resumo com bons resultados; geralmente as tabelas de resumo são pequenas o suficiente para serem rápidas o suficiente para acesso direto a partir da interface do usuário.

Bem, na verdade, ter um PK com mais de 5 colunas não é necessariamente ruim por si só.

Torna-se inválido quando o PK também é o índice em cluster, pois esse seria contado como identificador da linha e, portanto, seria adicionado a cada linha em um índice NC. Isso aumentaria drasticamente o espaço necessário.

Também seria ruim se você realmente usar o PK por outro FK, pois é necessário ter os dados de todas as mais de 5 colunas na tabela atual e na referência a ele. Mais uma vez, aumentará muito o armazenamento!

Em termos de desempenho, será ruim quando o PK for usado como índice - seja apenas dentro da tabela ou em conjunto com um FK -, pois uma PK-Key maior contendo mais de 5 colunas ocupará mais espaço, portanto, menos entradas serão cabem em uma página e, a partir de então, mais páginas precisam ser lidas para analisar o índice.

Dito isto - sempre pode haver uma boa razão para fazê-lo de qualquer maneira, como, por exemplo, uma tabela de fatos. Portanto, a melhor resposta seria realmente como na maioria dos casos: depende!

Atenciosamente Dennis

Por mais de 15 anos, não preciso dessa chave, vi-a às vezes e estava apenas causando problemas. Muitos problemas. Antes de tudo, a chave primária é para manter a integridade dos dados e eles devem ser sintéticos. Eles não deveriam ter nenhuma ligação com o mundo real. Por quê ? Uma vez que o mundo real mude, e com certeza sua chave primária se foi, e você deverá atualizá-la e todas as informações relacionadas.

Imagime que você precisa se lembrar deste ker em alguma outra tabela / banco de dados / serviço, em vez de um campo, você precisa copiar vários e pode esquecer de copiar alguns deles. Em vez disso, a chave primária sysntetic é apenas uma parte dos dados que você precisa fornecer. Não estou mencionando a unicidade da indexação, o que pode ser outro grande tópico para discussão.

Resumo tão breve, a chave primária sintética (incremento automático, guia, ..) é simples de manter, copiar, ...

Portanto, considero a chave primária sintética e outra chave para 5 colunas que você mencionou.

Por fim, se a tabela for apenas agregada e nunca alguém precisar fazer referência à linha por chaves (mas o mundo mudar, acredite em mim, pelo menos para mim muda permanentemente), provavelmente o deixarei como está (principal chave com cinco linhas), mas no caso que costumávamos ter, sempre causava muitos problemas. Então eu te disse.