Assim como a pergunta pede; é possível particionar uma tabela verticalmente de forma transparente, usando partições virtuais? Eu imagino se fosse possível, que as colunas seriam apenas armazenadas em espaços de tabela separados ou algo assim.
Em meu ambiente específico, temos um servidor de aplicativos que grava em lote uma grande quantidade de dados a cada 15 minutos ou mais. Há muito mais dados do que nossos aplicativos de relatórios precisam. A tabela de fatos primária tem aproximadamente 50 colunas. Usamos cerca de 10 deles.
Existe algum cenário (mesmo que não existam partições verticais virtuais) em que tal esquema possa melhorar o desempenho? Eu imagino que ter seus dados divididos em vários espaços de tabela (e, portanto, potencialmente em vários discos) melhoraria os tempos de busca.
Toda a sua premissa por trás da pergunta é falha. Você não precisa dividir seus dados entre tablespaces para espalhar a E/S em mais discos, você precisa aumentar o número de discos em seu RAID10 ou (melhor ainda) array ASM. Você obterá menos ganho de desempenho, menos eficiência de espaço e muito mais manutenção tentando ajustar manualmente o I/O como você está sugerindo.
O ASM supera o RAID10 principalmente porque entende os dados que estão sendo gravados nele - por exemplo, pode variar o tamanho da faixa entre blocos de dados e logs.
Você pode fazer isso dividindo a tabela em duas, colocando as 10 colunas sobre as quais você relata (junto com a chave primária) em uma tabela (e um tablespace separado) e as outras 40 em outra. Você pode então apresentar uma exibição que une as duas como a tabela principal. Isso provavelmente não será possível sem alterações no aplicativo. Para inserir, use uma
INSERT ALLconsulta ou umINSTEAD OFgatilho na primeira tabela mais umINSERT na segunda tabela.Embora tecnicamente possível, eu questionaria se isso é necessário. Seria melhor distribuir amplamente todos os discos (o ASM faz o MESMO - use-o se possível) para aumentar o número de eixos e IOPS disponíveis, em vez de colocar efetivamente alguns discos fora de ação porque eles contêm dados que não são usado para relatórios.
Afaik, não há como dividir uma parte das colunas de uma tabela em outro espaço de tabela, exceto para armazenamento LOB, onde os dados LOB podem ser armazenados em espaço de tabela separado.
Quanto ao desempenho - o número de colunas não afeta as instruções de seleção, desde que essas colunas não apareçam nelas.
Por outro lado, a divisão da tabela em partições e a indexação adequada têm um impacto significativo no desempenho, que se torna mais óbvio com o aumento do tamanho da tabela. (Você não descreveu seus dados, então ninguém pode aconselhar exatamente como você deve particionar a tabela.)
O particionamento virtual significa o particionamento por uma expressão, que é armazenada como metadados da tabela e não aparece na própria tabela. Consulte a documentação .
Crie uma visualização materializada com as 10 colunas e indexe essa visualização