Nada é pré-gerado
A disponibilidade, assim como o preço, é resolvida no momento em que é solicitada, a partir de regras e exceções. Não existe nenhum job de manutenção criando linhas com antecedência, e nada para ficar atrasado.
Velocidade e confiabilidade
Rápida hoje. Igualmente rápida com dez vezes o tráfego.
Um calendário de dez anos custa exatamente o mesmo que consultar amanhã. Operações em lote rodam como uma única ida e volta, não uma consulta por linha. E os índices dos quais os relatórios e os preços dependem já existiam antes do volume que os exigiria.
- Zero pré-geração Um calendário de dez anos custa exatamente o mesmo que consultar amanhã
- 1 ida e volta Operações em lote rodam como consultas únicas em bloco, verificadas por testes que contam o registro real de consultas
- Enfileirado, não bloqueante Importações de CSV e e-mails de confirmação rodam em segundo plano, em blocos, nunca prendendo quem os disparou
Quatro peças para se manter rápida.
Cada uma remove uma forma diferente pela qual a performance costuma se degradar em silêncio, até deixar de ser silenciosa.
Em lote, nunca linha por linha
Carregar capacidades para um calendário, resolver preços em um intervalo de datas, ou importar um CSV de códigos de estoque, tudo isso roda como um número limitado de consultas, independente de quantas linhas estão envolvidas.
Os índices existem antes de serem necessários
As consultas de relatórios, disponibilidade e preços são sustentadas por índices projetados junto com a própria funcionalidade, não adicionados depois, quando algo já ficou lento em produção.
O trabalho em segundo plano fica fora da requisição
Importações grandes e e-mails de confirmação passam por uma fila, para que enviar dez mil códigos de estoque ou mandar um recibo nunca faça ninguém esperar na página.
Como a velocidade é comprovada, não apenas anunciada
Cinco práticas por trás de por que a plataforma se mantém rápida à medida que os dados crescem, não só quando começa pequena.
- 1
A contagem de consultas é verificada, não presumida
O relatório de vendas é testado com 3 pedidos e depois com 30, verificando exatamente o mesmo número de consultas nas duas vezes, então "isso escala" é algo que um teste realmente checa, não apenas uma esperança.
- 2
Uma importação de CSV roda em blocos limitados
Uma importação de estoque transmite o arquivo mil linhas de cada vez, inserindo cada bloco como uma única escrita em lote em vez de linha por linha, para que um arquivo com dezenas de milhares de linhas nunca mantenha uma transação gigante aberta.
- 3
Um job na fila espera a transação realmente ser efetivada
Jobs vinculados a algo recém-escrito, um e-mail de confirmação de pedido, uma importação de estoque, só começam depois que a transação do banco de dados que criou esses dados realmente for efetivada, nunca antes.
- 4
Um índice é construído para o formato de consulta que atende
Um índice composto por organização, status e data do recibo atende todos os filtros do relatório de uma vez; um separado, por assunto e status, atende especificamente consultas do tipo "quem chegou a este status neste período", porque são padrões de acesso genuinamente diferentes.
- 5
Uma nova tentativa duplicada nunca corrompe os dados
Se um job de importação na fila é reexecutado, uma verificação de duplicidade por bloco, somada à restrição de unicidade do próprio banco de dados, impede que o mesmo código de estoque seja inserido duas vezes, então repetir a tentativa é sempre seguro.
Velocidade que você pode verificar, não só acreditar
O mesmo teste de regressão de contagem de consultas que protege o relatório de vendas, executado com dois volumes diferentes de pedidos, verificando um número idêntico de consultas nas duas vezes.
TEST BuildsSalesReportTest.php
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
{
"test": "sales report query count",
"orders_in_range": [
3,
30
],
"queries_executed": [
14,
14
]
}Verificado por teste automatizado
Um relatório com 3 pedidos executa exatamente o mesmo número de consultas que um com 3 milhões
A forma mais comum de um relatório ficar lento em silêncio é uma consulta extra escondida dentro de um laço, invisível com um punhado de pedidos de teste e só visível em produção, em escala. A bateria de testes da Tiqory fixa a contagem exata de consultas para 3 pedidos e verifica de novo a mesma contagem para 30, capturando uma consulta perdida por linha no momento em que é introduzida, não meses depois, quando o histórico de pedidos de um cliente já cresceu o suficiente para chamar atenção.
Perguntas frequentes
Não. Nada na disponibilidade é pré-gerado ou armazenado com antecedência; toda data e franja é resolvida a partir de regras e exceções no momento em que é solicitada, então uma consulta para daqui a dez anos custa o mesmo que uma para amanhã.
Ele é processado em segundo plano, em blocos de mil linhas, inseridas como escritas em lote em vez de uma de cada vez, e nunca bloqueia quem enviou de usar o resto do painel.
Um teste constrói o relatório com 3 pedidos, depois com 30, e verifica que o número exato de consultas ao banco de dados permanece idêntico nas duas vezes. Isso é uma propriedade comprovada, não uma suposição.
Não. Uma verificação de duplicidade por bloco, apoiada por uma restrição de unicidade no banco de dados como última barreira, garante que repetir um job de importação que falhou é sempre seguro e nunca cria o mesmo código de estoque duas vezes.
Antes. Os índices para consultas de relatórios, disponibilidade e preços são projetados junto com a funcionalidade que precisa deles, como parte da própria construção, não anexados depois como um remendo quando uma consulta começa a estourar o tempo limite.
Mais reservas. Mais canais. A mesma calma.
A Tiqory mantém disponibilidade, preços, pagamentos e acesso a trabalhar juntos enquanto a sua operação cresce. Conte-nos para onde vai; mostramos como chegar lá sem recomeçar.