ApsaraDB for SelectDB:High-concurrency point queries

Como funciona

Quando usar o row store

O row store consome espaço de armazenamento adicional. Use a tabela a seguir para decidir se deve ativá-lo.

Ativar o row store

Ative o row store apenas no momento da criação da tabela. Adicione a seguinte propriedade à instrução CREATE TABLE:

"store_row_column" = "true"

Não é possível ativar ou desativar o row store após a criação da tabela.

Otimizar consultas pontuais no modelo Unique Key

Quando enable_unique_key_merge_on_write e store_row_column estão definidos como true em uma tabela do modelo Unique Key, o otimizador de consultas ativa um short query path para consultas pontuais por chave primária. Apenas uma RPC é necessária para executar esse tipo de consulta.

O exemplo a seguir crie uma tabela com row store e MoW ativados:

CREATE TABLE `tbl_point_query` (
    `key` int(11) NULL,
    `v1` decimal(27, 9) NULL,
    `v2` varchar(30) NULL,
    `v3` varchar(30) NULL,
    `v4` date NULL,
    `v5` datetime NULL,
    `v6` float NULL,
    `v7` datev2 NULL
) ENGINE=OLAP
UNIQUE KEY(`key`)
COMMENT 'OLAP'
DISTRIBUTED BY HASH(`key`) BUCKETS 16
PROPERTIES (
    "enable_unique_key_merge_on_write" = "true",
    "light_schema_change" = "true",
    "store_row_column" = "true"
);

O short query path aplica-se apenas quando a cláusula WHERE contém condições de igualdade nas colunas de chave de uma única tabela. Exemplo:

SELECT * FROM tbl_point_query WHERE key = 123;

Usar prepared statements

Os prepared statements são totalmente compatíveis com o protocolo MySQL. Quando ativados no FE, o SelectDB analisa cada instrução SQL e suas expressões uma única vez e armazena o resultado na memória no nível da sessão. As execuções subsequentes reutilizam os objetos em cache e ignoram completamente a análise. Para consultas pontuais por chave primária limitadas por CPU, isso pode aumentar o throughput em mais de quatro vezes.

Os prepared statements funcionam apenas para consultas pontuais baseadas em chaves primárias.

Ativar prepared statements via Java Database Connectivity (JDBC):

1. Adicione useServerPrepStmts=true à URL JDBC:

   jdbc:mysql://127.0.0.1:9030/ycsb?useServerPrepStmts=true

2. Prepare a instrução uma vez e reutilize o objeto PreparedStatement nas consultas:

   // Use ? as a placeholder. Reuse readStatement across multiple queries.
   PreparedStatement readStatement = conn.prepareStatement(
       "SELECT * FROM tbl_point_query WHERE key = ?"
   );
   
   readStatement.setInt(1, 1234);
   ResultSet resultSet = readStatement.executeQuery();
   
   // Reuse the same statement for the next query
   readStatement.setInt(1, 1235);
   resultSet = readStatement.executeQuery();

Ativar o row cache

O SelectDB inclui um page cache que armazena dados coluna por coluna — cada página contém os dados de uma coluna. No modo row store, uma única página armazena dados de várias colunas. Isso a torna mais vulnerável à evicção por grandes consultas analíticas e reduz as taxas de acerto do cache.

O row cache resolve esse problema ao manter um cache dedicado no nível de linha que utiliza a política de evicção LRU (menos recentemente usado). Assim, as linhas acessadas com frequência permanecem na memória mesmo quando grandes consultas analíticas competem por espaço de cache.

Configure o row cache nas configurações do backend (BE):

Limitações

• O row store só pode ser ativado durante a criação da tabela. Não há suporte para modificação de tabelas existentes.

• O short query path aplica-se apenas a condições de igualdade (=) nas colunas de chave de uma única tabela. Consultas JOIN e subconsultas aninhadas não têm suporte.

• A cláusula WHERE deve referenciar apenas colunas de chave (consultas de par chave-valor).

• Os prepared statements funcionam exclusivamente para consultas pontuais por chave primária.

• É obrigatório definir light_schema_change = true para que o short query path funcione corretamente.