Compressão Avançada da Série de Interpretação Técnica do GaussDB

O autor deste artigo é Feng Ke, arquiteto-chefe do GaussDB do banco de dados em nuvem da Huawei

introdução de fundo

A combinação de compactação de dados e bancos de dados relacionais não é mais um tópico novo. Vimos vários produtos e soluções de compactação de banco de dados. Para o GaussDB, a introdução da compactação de dados hoje, que valor diferente ela pode trazer para os clientes, é uma questão sobre a qual temos pensado há algum tempo.

Para responder a essa pergunta, primeiro realizamos testes extensivos em vários algoritmos de compactação comuns, de LZ4/Snappy com o melhor desempenho, a Zstd/Zlib com desempenho e taxa de compactação balanceados, até LZMA/BZip com ênfase na taxa de compactação. Descobrimos que mesmo os melhores algoritmos de compactação não podem fazer isso sem afetar significativamente o desempenho de um banco de dados online. Também investigamos vários métodos de codificação no campo de banco de dados, incluindo alguns métodos de codificação baseados em previsão e ajuste linear divulgados pela comunidade acadêmica nos últimos anos. A partir dos resultados dos testes e medições reais divulgadas pela pesquisa, a codificação do banco de dados é usada para resolver distribuições numéricas.Comparado com a maturidade do algoritmo de compressão, não há atualmente nenhum método geral de codificação de banco de dados que possa fornecer uma taxa de compressão estável na maioria dos cenários em conjuntos de dados reais.

Este é o nosso julgamento técnico básico no campo da compressão de banco de dados. A prática de produtos anteriores também verificou esse ponto. Vimos que muitos bancos de dados comerciais e de código aberto fornecem suporte para compactação. Na maioria das vezes, a escolha deixada para os clientes é decidir se deseja habilitar a compactação em uma tabela específica. Ativar a compactação significa economizar espaço, mas ao mesmo tempo significa degradar o desempenho.Essa escolha aparentemente simples é precisamente a mais difícil para os clientes. É por isso que existem tantos produtos de compactação de banco de dados, mas raramente vemos a razão fundamental pela qual a compactação de dados é realmente amplamente usada nos negócios on-line de banco de dados.

Isso nos dá mais inspiração. Acreditamos que a tecnologia de compactação de banco de dados verdadeiramente aplicável, que pode equilibrar a taxa de compactação e o impacto nos negócios, deve ser seletiva. Ou seja, podemos determinar a temperatura dos dados com base na tecnologia e, com base nessa determinação, podemos compactar seletivamente dados relativamente frios no negócio sem tocar nesses dados relativamente quentes.

Essa escolha técnica significa que não podemos atender a todos os cenários de negócios. Exigimos que a distribuição de temperatura de dados do negócio atenda à regra de distribuição 80-20. Ou seja, compactamos dados frios que ocupam 80% dos requisitos de armazenamento, mas apenas 20% dos requisitos de computação, e não tocamos nos dados quentes que ocupam apenas 20% dos requisitos de armazenamento, mas ocupam 80% dos requisitos de computação. Felizmente, descobrimos que a maioria das empresas que exigem controle de capacidade possui essas características.

Seleção de cenário e alvo

Através da análise de um grande número de cenários de negócios, descobrimos que as necessidades de negócios para a tecnologia de compactação de banco de dados são diversificadas. Há também cenários em que a transmissão de negócios de recuperação de desastres é compactada. Em cenários diferentes, os requisitos para a tecnologia de compactação são completamente diferentes em termos de indicadores tridimensionais de desempenho de compactação, taxa de compactação e desempenho de descompactação e em termos de tolerância a invasões de negócios.

Isso significa que, se quisermos criar um recurso de compactação avançada do GaussDB de cenário completo, deve ser uma combinação de várias tecnologias, incluindo diferentes algoritmos de compactação, diferentes modelos e métodos de julgamento quente e frio, diferentes organizações de armazenamento de dados, etc., por meio de diferentes Combinação de tecnologias e aplicações para atender às necessidades de diferentes cenários.

Isso também significa que precisamos ter uma prioridade no suporte a diferentes cenários de aplicativos de compactação. A nossa resposta é optar por dar prioridade ao suporte de cenários de compressão de armazenamento OLTP.Esta é a área de negócio onde acreditamos que a tecnologia de compressão de bases de dados é a mais valiosa e, claro, é também a área com os maiores desafios técnicos.

Depois de determinar o cenário, o próximo passo é determinar a meta técnica.Que tipo de competitividade central queremos construir para este cenário depende de nossa análise de cenários típicos de clientes. Identificamos dois cenários típicos de clientes:

Cenário A: O negócio do cliente vem de um minicomputador IBM com uma única base de dados com capacidade de 50 TB e, após a migração para a plataforma aberta, enfrenta problemas de excesso de capacidade e longas janelas de operação e manutenção. Optar por desmontar o banco de dados significa transformação distribuída.Para um negócio de chaves de estoque que funciona de forma estável há muitos anos, o risco de escolher essa tecnologia é muito alto. Escolher a compressão pode reduzir significativamente os riscos de capacidade, mas o projeto inicial do negócio não considerou a separação de quente e frio (como estabelecer partições com base na dimensão de tempo). desempenho do negócio é baixo o suficiente.

Cenário B: O negócio do cliente é implantado com base em clusters distribuídos. A capacidade de um único cluster excedeu 1 PB e ainda está crescendo rapidamente, exigindo expansão regular. Escolher a compactação pode reduzir a frequência da expansão de capacidade, reduzir significativamente os custos de software e hardware de negócios e reduzir o risco de mudança. No entanto, o design de distribuição de dados do negócio é orientado para a escalabilidade (como a criação de partições com base na dimensão do usuário), sem considerar a separação de quente e frio. Portanto, o negócio também precisa de um suporte de tecnologia de compressão zero intrusiva com um baixo impacto no desempenho.

Ao classificar os requisitos de cenários típicos do cliente, determinamos os objetivos básicos do design da compactação de armazenamento GaussDB OLTP:

1. O julgamento quente e frio deve ser zero intrusivo para o negócio e não deve ter nenhuma dependência da distribuição de dados existente e do modelo lógico do negócio;

2. O impacto nos negócios deve ser baixo o suficiente, definimos a meta em menos de 10% e desafiamos 5%;

3. Para fornecer uma taxa de compactação razoável, definimos o alvo como não inferior a 2:1.

A definição de objetivos básicos de projeto nos permite transformar a seleção de tecnologia subsequente em cada cenário específico em um problema determinístico.

Julgamento quente e frio

Depois de determinar os objetivos do projeto, começamos a implementar o projeto. Existem três problemas a serem resolvidos: 1) Como realizar a determinação de dados quentes e frios; 2) Como realizar a organização de armazenamento de dados compactados; 3) Como realizar um algoritmo de compactação competitivo.

Para julgamentos quentes e frios, a granularidade do julgamento deve primeiro ser determinada. O julgamento quente e frio dos dados pode ser implementado com base em diferentes granularidades, como nível de linha, nível de bloco ou nível de tabela/partição. Quanto maior a granularidade, menor a complexidade da implementação, mas maior a intrusão no negócio. Com base nos objetivos do projeto, é natural que escolhamos o julgamento quente e frio em nível de linha, que é a solução com menor dependência da distribuição de dados de negócios. O que precisamos resolver é como controlar o custo de introdução de quente e frio julgamento.

Resolvemos esse problema de maneira inteligente usando o mecanismo existente do mecanismo de armazenamento GaussDB. Especificamente, o mecanismo de armazenamento GaussDB registra o ID da transação (XID) da última modificação da linha nos metadados Meta de cada linha de dados. Essas informações são usadas para dar suporte ao julgamento de visibilidade da transação, implementando assim o controle de simultaneidade de várias versões (MVC). Para uma linha específica, se seu XID for "antigo" o suficiente para ser visível para todas as transações ativas no momento, não nos importamos com o valor específico do XID neste momento. Podemos introduzir um sinalizador específico (FLG) para registrar isso, e o valor preenchido no XID original pode ser substituído por um horário físico, que representa o limite superior do horário da última modificação (LMT, Last Modified Time) da linha à qual pertence. Obviamente, o LMT pode ser usado para dar suporte a julgamentos quentes e frios (consulte a Figura 1 para obter detalhes):

Figura 1: Determinação de quente e frio no nível da linha

A vantagem da solução acima é que a introdução do LMT não adiciona sobrecarga adicional, nem depende do modelo de lógica de negócios. Na maioria das vezes, se os requisitos não forem particularmente rígidos, o negócio pode definir uma regra simples para alcançar julgamentos quentes e frios, como:

APÓS 3 MESES SEM MODIFICAÇÃO

Neste momento, o sistema verifica a tabela de destino e compacta todas as linhas que atendem ao tempo atual menos o LMT por mais de 3 meses.

Observe que no esquema acima, identificamos apenas os pontos de acesso de gravação das linhas, mas não identificamos os pontos de acesso de leitura das linhas. Sabemos apenas que as linhas que atendem às condições não foram atualizadas em 3 meses, mas não podemos confirme se essas linhas estão em 3 meses. Se é lido com frequência em um mês. Atualmente, não há solução técnica de baixo custo para manter os hotspots de leitura das linhas. Para serviços de pipeline, como detalhes de pedidos, essa solução funciona bem, porque a leitura e a gravação de dados exibem as mesmas características de temperatura e sua frequência de acesso continua a diminuir à medida que o tempo não modificado aumenta. Mas para serviços de cobrança como álbuns de fotos de celular, pode não ser suficiente apenas identificar e escrever, porque uma relação de cobrança estabelecida muito cedo ainda pode ser acessada com frequência.

Isso significa que, mesmo que o sistema faça julgamentos quentes e frios, ainda precisamos otimizar os cenários em que a empresa pode acessar dados compactados. Deixamos esse problema para a organização do armazenamento e o algoritmo de compactação. Para o algoritmo de compactação, prestamos mais atenção seu desempenho de descompressão.

Outro problema é que, em alguns cenários, usar o julgamento quente e frio padrão pode não ser suficiente. Por exemplo, para alguns tipos de transações, os detalhes do pedido gerado podem realmente não ser modificados dentro de 3 meses, mas serão atualizados após um determinado condição de gatilho for atendida (como descongelar transações seguras). Esse cenário não é comum em negócios reais, mas se o negócio realmente se preocupa com o desempenho, oferecemos suporte para permitir que o negócio personalize regras além das regras padrão de julgamento quente e frio, como:

APÓS 3 MESES SEM MODIFICAÇÃO EM (order_status = “concluído”)

Neste momento, o sistema irá comprimir apenas os dados que não foram modificados por 3 meses e cujo status do pedido foi concluído.

Atualmente, as regras personalizadas que suportamos são quaisquer expressões de linha válidas. A empresa pode escrever quaisquer expressões complexas para representar as regras de julgamento hot e cold dos dados, mas quaisquer campos referenciados nas expressões só podem ser os campos na tabela de destino. legal Campos. Por meio dessa combinação de regras padrão e personalizadas, fornecemos às empresas um limite suficientemente baixo para uso e melhor flexibilidade.

organização de armazenamento

Quando as linhas que atendem às condições de avaliação hot e cold são compactadas, precisamos decidir como armazenar os dados compactados. Com base no objetivo do projeto, escolhemos a implementação da organização de armazenamento com a menor intrusão nos negócios — compactação intrabloco.

Sabemos que a organização de armazenamento de bancos de dados relacionais é baseada em blocos de comprimento fixo. No banco de dados GaussDB, o tamanho típico do bloco de dados é de 8 KB. A escolha de um bloco de dados maior é obviamente benéfica para a compactação, mas causará maior impacto no desempenho dos negócios .Influência. A chamada compactação intra-bloco refere-se a: 1) Todas as linhas em um único bloco que atendem às condições de julgamento quente e frio serão compactadas como um todo; 2) Os dados formados após a compactação são armazenados no bloco de dados atual e a área de armazenamento é chamada de BCA (Block Compressed Area), que geralmente está localizada no final do bloco.

O design de compactação intra-bloco significa que a descompactação de qualquer dado depende apenas do bloco atual, sem acessar outros blocos de dados. Do ponto de vista da taxa de compactação, esse design não é o mais amigável, mas é muito benéfico para controlar o impacto nos negócios. Observe que em nossa discussão anterior, mesmo que o negócio defina condições de julgamento quentes e frios, ainda há uma certa probabilidade de que os dados compactados sejam acessados. Esperamos que esse custo de acesso possa ter um limite superior determinístico.

A Figura 2 mostra o processo detalhado de compactação intrabloco: primeiro, quando a compactação é acionada, o sistema verifica todas as linhas no bloco de dados e reconhece que R1 e R3 são dados frios de acordo com as condições de julgamento quentes e frias especificadas ( Figura 2(a)); então, o sistema comprime R1 e R3 como um todo, e armazena os dados compactados no BCA do bloco de dados (Figura 2(b)); se o negócio precisar atualizar R1 posteriormente, o sistema will update The last data gera uma nova cópia R4, e marca que R1 no BCA foi deletado (como mostrado na Figura 2©); finalmente, quando o sistema precisar de mais espaço no bloco de dados, ele pode recuperar o espaço pertencente a R1 no BCA (Figura 2(d)).

Figura 2: Compressão intra-bloco

Há dois pontos a serem observados em todo o design: 1) Na verdade, apenas compactamos os dados de dados do usuário e não compactamos os metadados metadados correspondentes, que geralmente são usados ​​para dar suporte à visibilidade da transação; 2) Damos suporte à alteração de recompactação de dados frios a dados quentes para eliminar o impacto causado pelo erro de julgamento de quente e frio. Da mesma forma, do ponto de vista da taxa de compressão, esse design não é o mais amigável, mas reduz bastante a intrusão nos negócios. Simplificando, o acesso comercial aos dados compactados é exatamente o mesmo que os dados normais, sem nenhuma restrição de funções e não há diferença na semântica da transação. Este é um princípio muito importante: nossa compactação de armazenamento OLTP é completamente transparente para os negócios, que é o princípio básico que este recurso atual e todos os recursos subseqüentes da série de compactação avançada GaussDB seguirão.

algoritmo de compressão

Com base nos objetivos do projeto, se observarmos os indicadores tridimensionais de taxa de compactação, desempenho de compactação e desempenho de descompactação, o que realmente precisamos é de um algoritmo de compactação que possa fornecer taxa de compactação razoável, desempenho de compactação razoável e desempenho de descompactação final. Esta é a base do nosso projeto de algoritmo de compressão.

Testamos primeiro o uso direto do LZ4 para compactação. O LZ4 é atualmente conhecido como uma biblioteca tripartida de código aberto com o melhor desempenho de compactação e descompactação. A partir dos resultados reais da medição, a taxa de compactação do LZ4 é relativamente baixa. Analisamos cuidadosamente seu princípio de algoritmo. LZ4 é uma implementação baseada no algoritmo LZ77. A ideia do algoritmo LZ77 é muito simples, ou seja, os dados a serem compactados são considerados como um fluxo de bytes. O algoritmo parte do atual posição do fluxo de bytes e para frente. Encontre a string correspondente que é igual à posição atual e, em seguida, use o comprimento da string correspondente e o deslocamento da posição atual para representar a string correspondente, de modo a obter o efeito de compressão. Da perspectiva do princípio do algoritmo, o algoritmo LZ77 tem um melhor efeito de compressão para texto longo, mas para um grande número de texto curto e tipos numéricos em dados estruturados, o efeito é limitado. Nossos testes reais também verificaram este ponto.

Em seguida, dividimos o algoritmo de compactação em duas camadas: na primeira camada, codificamos alguns tipos numéricos por colunas e escolhemos a codificação de diferença simples, que é leve o suficiente para descompactar campos específicos sem depender de valores de outros campos; em a segunda camada, chamamos de LZ4 para comprimir os dados codificados. Observe que na primeira camada, na verdade, codificamos por coluna e armazenamos por linha, o que é muito diferente da implementação geral no setor (codificar e armazenar por coluna). O armazenamento por coluna será mais amigável à taxa de compactação, mas a coluna por coluna O armazenamento significa que os dados da mesma linha serão dispersos em diferentes áreas do BCA. Este design tradicional não pode suportar a descompressão parcial que esperamos alcançar mais tarde. Explicaremos esse problema com mais detalhes na conclusão.

Por meio de medições reais, descobrimos que essa implementação de codificação de coluna + compactação geral melhora efetivamente a taxa de compactação e, ao mesmo tempo, controla o aumento óbvio no impacto nos negócios, mas a implementação de duas camadas é fracamente acoplada, o que introduz muita sobrecarga adicional . Portanto, após uma ponderação cuidadosa, decidimos abandonar o LZ4 e reimplementar um algoritmo de compactação fortemente acoplado baseado inteiramente no algoritmo LZ77.

Isso parecia ser uma tentativa muito arriscada na época.Na verdade, antes de nós, nenhuma equipe de kernel de banco de dados escolheria implementar um algoritmo geral de compressão sozinho. Mas, a julgar pelos benefícios finais, na verdade abrimos uma porta totalmente nova. Quando o limite entre a codificação da coluna e o algoritmo LZ77 é quebrado, introduzimos uma série de inovações de otimização. Considerando o espaço, não podemos mostrar todos os detalhes técnicos. Aqui, introduzimos apenas duas pequenas otimizações:

A primeira otimização são os limites de linha integrados. Descobrimos que, quando o sistema adota o algoritmo de compactação de duas camadas, precisamos salvar adicionalmente o comprimento codificado de cada linha de dados, porque precisamos encontrar o limite de cada linha após a descompactação do algoritmo LZ77, o que não é uma pequena a sobrecarga. Para eliminar esse overhead, optamos por incorporar uma marca de limite de linha no formato de codificação LZ77, essa marca ocupa apenas 1 bit e seu overhead é bastante reduzido em comparação com o esquema existente. É claro que, com esse bit marcador ocupado, o tamanho máximo da janela da pesquisa direta LZ77 é reduzido pela metade, mas em nosso cenário isso não é um problema, porque nosso tamanho de página típico é de apenas 8 KB.

A segunda otimização é a codificação curta de 2 bytes. Na implementação original do LZ4, para melhorar o desempenho da compactação, o sistema usa codificação de 3 bytes para descrever uma correspondência, o que significa que a correspondência mais curta que o sistema pode identificar é de 4 bytes. Mas em dados estruturados, a correspondência de 3 bytes é muito comum, consulte o exemplo a seguir:

A = 1 … B = 2

Entre eles, A e B são dois campos inteiros na mesma linha de dados e seus valores são 1 e 2, respectivamente. Com base na ordem atual de bytes, a forma real de armazenamento da linha de dados na memória é a seguinte:

01 00 00 00 … 02 00 00 00

Preste atenção na parte marcada em vermelho acima, obviamente há uma correspondência de 3 bytes, mas não pode ser reconhecida pelo LZ4.

Resolvemos esse problema introduzindo um código curto adicional de 2 bytes no algoritmo LZ 77. O código curto de 2 bytes pode identificar uma correspondência mínima de 3 bytes, melhorando assim a taxa de compactação em comparação com o LZ4.

Obviamente, a introdução de códigos curtos terá sobrecarga adicional: primeiro, o desempenho da compactação diminuirá até certo ponto, porque precisamos estabelecer duas tabelas HASH independentes. Felizmente, em nosso cenário, o desempenho final da compactação não é nosso objetivo. seguir; em segundo lugar, a codificação de 2 bytes reduz a largura de bits que expressa a distância entre a string correspondente e a string correspondente, o que significa que a correspondência de 3 bytes deve estar mais próxima para ser reconhecida. problema, porque o comprimento de uma linha de dados típica é pequeno o suficiente em relação a esse limite.

avaliação de efeito

Usamos testes TPCC padrão para avaliar o impacto nos negócios de habilitar o recurso de compactação de armazenamento OLTP. O modelo TPCC contém um total de 9 tabelas, das quais existem 3 tabelas de fluxo cujo espaço crescerá dinamicamente. Dentre essas 3 tabelas, a tabela de detalhes do pedido (tabela Orderline) possui uma ordem de grandeza a mais de crescimento de espaço do que outras tabelas, portanto, escolha usar esta tabela Ative a compactação. Com base na semântica de negócios do TPCC, uma vez concluída a entrega de cada pedido, o status do pedido entrará no estado concluído. O pedido concluído não será modificado, mas ainda há uma certa probabilidade de ser consultado. Com base nessa semântica, escolhemos o princípio de julgamento quente e frio para comprimir apenas os pedidos concluídos.

Testamos os valores de desempenho do sistema sem compressão e com compressão, e os resultados são mostrados na Figura 3:

Figura 3: Avaliação de impacto nos negócios

Os resultados do teste mostram que: no cenário de teste TPCC, o desempenho do sistema é reduzido em cerca de 1,5% quando a compactação é habilitada em comparação com quando a compactação não é habilitada. Este é um resultado muito bom, o que significa que o sistema pode permitir a compressão mesmo em cenários de pico de negócios superiores a um milhão de tpmC. Não sabemos se algum outro produto de banco de dados do setor conseguiu atingir esse nível antes disso.

Testamos a taxa de compactação da tabela Orderline. Como um conjunto de dados mais rico, também selecionamos quatro tabelas (Lineitem, Orders, Customer e Part tabelas) no modelo TPCH para teste. Para comparação, para cada conjunto de dados, testamos o desempenho da taxa de compressão de LZ4, ZLIB e nosso algoritmo de compressão ao mesmo tempo. Entre eles, ZLIB é um algoritmo que enfatiza o desempenho de compressão e descompressão e o equilíbrio da taxa de compressão, e sua compressão e descompressão o desempenho é 5 vezes menor que o do LZ4, -10 vezes. O resultado final é mostrado na Figura 4:

Figura 4: Avaliação da taxa de compressão

Os resultados do teste estão de acordo com nossas expectativas. Quando há muitos campos numéricos, a taxa de compactação do nosso algoritmo de compactação é maior do que a de todos os algoritmos de compactação gerais, mas quando há muitos campos de texto, a taxa de compactação do nosso algoritmo de compactação será estar entre LZ e entre algoritmos de compressão da classe combinada LZ+Huffman.

Dicas de operação e manutenção

Observe que nosso esquema de compactação é realmente offline, ou seja, quando os dados são gerados pela primeira vez, devem ser dados quentes, eles não acionarão a compactação e o desempenho do acesso comercial a esses dados não será afetado de forma alguma; com o passar do tempo pelo desempenho desses dados A temperatura diminuirá gradualmente e, eventualmente, será reconhecida como dados frios por tarefas de compactação independentes e compactadas.

Escolher executar essas tarefas de compactação durante o horário comercial de baixo pico e controlar o consumo de recursos são questões que precisam ser observadas pelo lado da operação e manutenção. Nesta área, fornecemos diversos métodos de operação e manutenção, incluindo a especificação da janela de operação e manutenção, o paralelismo das tarefas de compactação e a quantidade de dados compactados para cada tarefa de compactação. Para a maioria das empresas, a quantidade de dados recém-adicionados por unidade de tempo é relativamente limitada, portanto, a empresa também pode escolher um período de tempo específico para concluir a tarefa de compactação intensivamente, como das 2h às 4h no primeiro dia de cada mês, ponto, conclua a compactação de dados frios adicionados 3 meses atrás.

Antes que uma empresa decida habilitar a compactação, ela pode desejar entender os benefícios após habilitar a compactação e tomar uma decisão com base no tamanho dos benefícios. Para esse fim, fornecemos uma ferramenta de avaliação da taxa de compactação, que pode amostrar os dados da tabela de destino e usar o mesmo algoritmo do processo de compactação real para compactar os dados amostrados e calcular a taxa de compactação, mas não gerará realmente o BCA e não modificará nenhum dado.

Se a empresa migrar dados compactados para outra tabela, todos os dados podem mudar de compactados para não compactados, resultando em expansão de espaço, o que não é introduzido por nossa solução, mas um problema que todas as soluções de compactação precisam resolver. Se as regras de julgamento hot e cold forem muito certas, a empresa pode executar manualmente a tarefa de compactação para que a compactação seja efetivada imediatamente; para a migração de tabelas compactadas de grande capacidade que levam muito tempo, a empresa ainda pode optar por iniciar o tarefa de compactação automática periodicamente para concluir.

Por fim, fornecemos o controle mais refinado para ativar e desativar a compactação. Seja uma única partição em uma tabela comum, uma tabela de partição comum ou qualquer partição única ou subpartição em uma partição secundária, o negócio pode ser transformado ligar ou desligar a compressão de forma independente. Isso possibilita que, em cenários em que o próprio negócio tenha dados quentes e frios diferenciados (por exemplo, com base no particionamento de tempo), ele ainda possa funcionar bem com nosso recurso de compactação.

conclusão

No recurso de compactação de tabela OLTP, introduzimos uma série de inovações tecnológicas, incluindo novos algoritmos de compactação, determinação automática de calor e frio de baixa granularidade e suporte à compactação intrabloco, que pode reduzir bastante o impacto na tabela enquanto fornecendo uma taxa de compactação razoável Impacto nos negócios, esperamos que esse recurso possa desempenhar um papel importante no suporte ao controle de capacidade de serviços online críticos.

Em seguida, continuaremos a inovar e iterar na redução do impacto da introdução da compactação nos negócios, recursos de descompactação parcial e compactação de índice OLTP. Esperamos ter avanços tecnológicos inovadores para resolver problemas relacionados e criar maior valor para os negócios.