Introdução
Volumes elevados de cliques e conversões sobrecarregam rapidamente bases de dados relacionais: tabelas em crescimento, consultas mais longas e cálculo de comissões atrasado. Para operadores do Affilentra, que preferem controlo self‑hosted e licenças permanentes, estratégias MySQL escaláveis são obrigatórias. Este artigo descreve padrões pragmáticos — Partitioning, Sharding por tempo, Tabelas Hot, pipelines de arquivamento e Sharding por comerciante — com foco na integridade dos dados e na cálculo de comissões reproduzível.
Princípios de design antes da implementação
- Separar papéis: Operadores do software, comerciantes e parceiros mantêm responsabilidades claras; o acesso aos dados e a soberania sobre os dados do comerciante devem ser representados.
- Manter a integridade do tracking: Eventos de tracking devem ser idempotentes e infalsificáveis; os arquivos não devem interferir nos processos de faturação.
- Hot vs. Cold: Manter dados atuais com bom desempenho e arquivar dados antigos de forma a poupar espaço.
- Consultas uniformes: As queries para cálculo de comissões devem ser determinísticas e reproduzíveis — mesmo após arquivamento.
Partitioning: baseado em tempo & por comerciante
Partitioning reduz I/O e melhora o Partition Pruning quando as consultas usam a chave de partição. Duas variantes consolidadas:
Partitioning baseado em tempo (Range)
Boa opção para logs de cliques e conversões: partições por mês ou semana. Vantagem: arquivamento simples de intervalos de tempo inteiros.
Exemplo prático (conceitual):
CREATE TABLE clicks (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
merchant_id INT NOT NULL,
partner_id INT NULL,
click_uuid CHAR(36) NOT NULL,
created_at DATETIME NOT NULL,
payload JSON,
UNIQUE KEY ux_click_uuid (click_uuid)
)
PARTITION BY RANGE (TO_DAYS(created_at)) (
PARTITION p_2024_01 VALUES LESS THAN (TO_DAYS('2024-02-01')),
PARTITION p_2024_02 VALUES LESS THAN (TO_DAYS('2024-03-01'))
);
Importante: as consultas devem conter WHERE created_at BETWEEN ... ou WHERE created_at >= ... para que o MySQL utilize Partition Pruning.
Partitioning por merchant ou LIST
Para poucos comerciantes muito grandes, o LIST‑Partitioning por merchant_id pode fazer sentido, ou uma combinação (subpartitioning). Vantagem: I/O Hot isolado por comerciante.
Sharding: distribuição horizontal
Partitioning ajuda dentro de uma base de dados. Em cargas extremas torna‑se necessário o Sharding horizontal: múltiplas instâncias MySQL, geridas por uma camada de routing no Affilentra (ou por um proxy).
- Escolha da chave: merchant_id como Shard‑Key permite isolamento por comerciante; alternativamente Hash(partner_id) para distribuição de carga.
- Topologia: comerciantes pequenos em um shard comum, comerciantes de alto volume em shards próprios (DB single tenant ou Schema).
- Metadados centralizados: mantenha perfis de parceiros, regras de programa e logs de faturamento centralizados para que os cálculos permaneçam consistentes.
Conceito Affilentra: separação de funções permite isolamento por comerciante sem alterar a lógica de negócio — ideal para migração gradual de sharding.
Hot‑Tables & Arquitetura Nearline
Regra prática: apenas os últimos N dias (por exemplo, 7–30 dias, dependendo do negócio) permanecem nas Hot‑Tables; dados mais antigos são movidos para um arquivo compacto, otimizado para consultas.
- Hot Table: mesma estrutura da tabela ativa, otimizada para Inserts rápidos e leituras frequentes.
- Cold/Archive Table: comprimida, possivelmente com outra Storage‑Engine ou em hardware com maior latência.
- Partition Exchange: no MySQL você pode "trocar" partições (EXCHANGE PARTITION) ou mover rapidamente com RENAME/ALTER — minimiza o tempo de inatividade.
Pipelines de arquivo: mover com segurança e auditabilidade
Fluxo de arquivamento em etapas:
- Marcar: marque Clicks/Conversions que ainda são relevantes para faturamento (por exemplo, status = 'pending_settlement').
- Snapshot antes de mover: antes de mover dados, grave um Settlement‑Snapshot numa tabela separada para que os cálculos sejam reproduzíveis.
- Mover por lotes: mova partições completas ou em batches com IDs consistentes; use passos atômicos (por exemplo, RENAME + INSERT INTO ... SELECT) dentro da mesma BD quando possível.
- Verificação & Reconciliação: compare contadores (Row‑Counts, Checksums) antes e depois do movimento; erros devem ter um caminho de rollback.
Ferramentas: pt‑archiver (Percona) ou jobs ETL feitos sob medida. O importante é comportamento determinístico e registro de cada alteração, para que os faturamentos sejam auditáveis.
Regras de integridade para cálculo de comissões
- Eventos idempotentes: Evitar cálculos duplicados para clicks e conversões usando click_uuid único.
- Estado de liquidação: Utilize campos de estado (pending, validated, paid). Arquive apenas registos com settled = true ou crie um snapshot de faturação imutável.
- Transações: Execute validações e cálculos de comissões em transações controladas ou em workflows distribuídos.
- Audit‑Log: Cada pagamento deve referenciar as Click‑IDs e snapshots de conversão usados; isso facilita a reconciliação após arquivamento.
Estratégias por comerciante
Para comerciantes de grande dimensão, recomenda‑se isolamento:
- Esquema/DB próprio: Execute merchants com grandes volumes em bases de dados separadas; reduz conflitos de replicação e backup.
- Particionamento diferenciado: Dentro do esquema do merchant, particione adicionalmente por tempo; assim é possível realizar arquivamentos mensais específicos por merchant.
- Cota e SLA por merchant: Monitorize I/O, locks e tempos de query por merchant; decisões de escalamento devem basear‑se em custos e estado.
Affilentra suporta permissões baseadas em funções e torna a isolação por merchant prática: os comerciantes mantêm controlo sobre produtos e criativos, enquanto os operadores mantêm controlo da infraestrutura.
Operação & Monitorização
- Profiling de queries: Identificar queries lentas e ajustar índices/estratégia de partição.
- Higiene de partições: Adição/remoção automatizada de partições temporais para evitar um número excessivo de partições.
- Backups e testes de restauração: Verifique cenários de restauração separadamente para dados Hot e Archive.
- Métricas: Monitorize taxa de inserts, latência de leitura, lock‑waits, taxa de partition‑pruning e taxa de transferência do arquivamento.
Resumo: Plano de implementação passo a passo
- Análise: Identificar top‑queries e hotspots (por merchant, partner, time).
- Particionar: Começar por tempo, auditar cláusulas WHERE para que o pruning funcione.
- Hot/Tiered Storage: Tabela Hot para dados atuais, arquivo para Cold Data; utilizar Partition Exchange.
- Isolação por merchant: configurar DBs ou shards separados para merchants de alto volume.
- Pipeline de arquivamento & snapshots: Criar snapshots de settlement, mover em batch com reconciliação.
- Monitorização & iterar: Observar métricas e ajustar a estratégia.
Vantagem prática para operadores Affilentra
Com estes padrões, os operadores mantêm a soberania dos dados num ambiente self‑hosted e evitam perda de tracking ou cálculo errado de comissões. A arquitetura do Affilentra com funções separadas facilita a isolação por comerciante e permite migrações controladas para topologias particionadas ou shardadas — sem sacrificar a lógica de negócio.
Aja agora: Para uma instalação escalável e consultoria em estratégias de Partitioning e Sharding escolha o seu ponto de entrada: Einstieg wählen.
Próximo passo
Experimentar o Affilentra
Plataforma unificada que integra de forma transparente disponibilização de produtos, tracking, validação de conversões, cálculo de comissões e pagamento ao longo de funções claramente separadas; opção de instalação self‑hosted com licença perpétua sem partilha de receita; os comerciantes mantêm controlo sobre produtos, condições e materiais promocionais; os parceiros recebem links de tracking pessoais e histórico de pagamentos rastreável.