Introducción
Altos volúmenes de clics y conversiones sobrecargan rápidamente las bases de datos relacionales: tablas en crecimiento, consultas más lentas y retrasos en el cálculo de comisiones. Para operadores de Affilentra que prefieren control self‑hosted y licencias perpetuas, se requieren estrategias MySQL escalables. Este artículo describe patrones pragmáticos — particionado, sharding por tiempo, tablas calientes, canalizaciones de archivo y sharding por comerciante — con foco en la integridad de los datos y en un cálculo de comisiones trazable.
Principios de diseño antes de la implementación
- Separar roles: Operadores del software, comerciantes y partners mantienen responsabilidades claras; el acceso a datos y la soberanía sobre los datos del comerciante deben estar reflejados.
- Preservar la integridad del tracking: Los eventos de tracking deben ser idempotentes e infalsificables; los archivos no deben influir en los procesos de facturación.
- Caliente vs. frío: Mantener los datos actuales con buen rendimiento y archivar los datos antiguos de forma compacta.
- Consultas uniformes: Las consultas para el cálculo de comisiones deben ser deterministas y reproducibles — también después del archivado.
Particionado: basado en tiempo y por merchant
El particionado reduce I/O y mejora el Partition Pruning cuando las consultas usan la clave de partición. Dos variantes probadas:
Particionado temporal (Range)
Buena elección para logs de clics y conversiones: particiones por mes o semana. Ventaja: archivado sencillo de periodos completos.
Ejemplo práctico (conceptual):
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: Las consultas deben incluir WHERE created_at BETWEEN ... o WHERE created_at >= ... para que MySQL use Partition Pruning.
Particionado por Merchant o LIST
Para pocos comerciantes muy grandes puede ser útil el particionado LIST por merchant_id o una combinación (subpartitioning). Ventaja: I/O caliente aislado por comerciante.
Sharding: distribución horizontal
El particionado ayuda dentro de una base de datos. Con cargas extremas se necesita sharding horizontal: múltiples instancias MySQL, gobernadas por una capa de enrutamiento en Affilentra (o un proxy).
- Elección de clave: merchant_id como Shard‑Key permite aislamiento por comerciante; alternativamente Hash(partner_id) para distribuir la carga.
- Topología: comerciantes pequeños en un shard compartido, comerciantes de alto volumen en shards propios (DB de inquilino único o esquema).
- Metadatos centrales: mantener centralizados los perfiles de partners, reglas de programa y logs de facturación, para que los cálculos sigan siendo consistentes.
Concepto Affilentra: la separación de roles permite aislamiento por comerciante sin cambiar la lógica de negocio — ideal para una migración gradual a sharding.
Tablas calientes & arquitectura nearline
Regla práctica: solo los últimos N días (p. ej. 7–30 días, dependiendo del negocio) permanecen en las tablas calientes; los datos más antiguos los mueve a un archivo compacto optimizado para consultas.
- Tabla caliente: misma estructura que la tabla en vivo, optimizada para inserts rápidos y lecturas frecuentes.
- Tabla fría/archivo: comprimida, posiblemente con otra Storage‑Engine o en hardware con mayor latencia.
- Intercambio de particiones: en MySQL puede intercambiar particiones (EXCHANGE PARTITION) o mover rápidamente con RENAME/ALTER — minimiza el tiempo de inactividad.
Pipelines de archivo: mover de forma segura y verificable
Flujo de trabajo de archivado en pasos:
- Marcar: marque Clicks/Conversions que aún son relevantes para facturación (p. ej. status = 'pending_settlement').
- Snapshot antes de mover: antes de mover datos, grabe un snapshot de settlement en una tabla separada, para que los cálculos sean reproducibles.
- Mover por lotes: desplace particiones completas o por lotes con IDs consistentes; use pasos atómicos (p. ej. RENAME + INSERT INTO ... SELECT) dentro de la misma BD cuando sea posible.
- Verificación & conciliación: compare contadores (Row‑Counts, Checksums) antes y después del movimiento; los errores deben tener una ruta de reversión.
Herramientas: pt‑archiver (Percona) o trabajos ETL a medida. Lo importante es comportamiento determinista y registro de cada cambio, para que la facturación sea auditable.
Reglas de integridad para el cálculo de comisiones
- Eventos idempotentes: Evitar cálculos duplicados de clics y conversiones usando click_uuid únicos.
- Estado de liquidación: Use campos de estado (pending, validated, paid). Archive solo registros con settled = true o genere una instantánea de liquidación inmutable.
- Transacciones: Realice validaciones y el cálculo de comisiones dentro de transacciones controladas o flujos de trabajo distribuidos.
- Registro de auditoría: Cada pago debería referenciar las IDs de clics y las instantáneas de conversiones utilizadas; esto facilita la conciliación después del archivado.
Estrategias por comerciante
Para comerciantes grandes se recomienda el aislamiento:
- Esquema/BD propia: Alojar merchants con alto volumen en bases de datos separadas; reduce conflictos de replicación y copias de seguridad.
- Particionamiento diferenciado: Dentro del esquema del merchant particionar adicionalmente por tiempo; así se pueden realizar archivados mensuales específicos por merchant.
- Cuotas y SLA por merchant: Supervise I/O, bloqueos y tiempos de consulta por merchant; las decisiones de escalado deben basarse en costes y estado.
Affilentra soporta permisos por rol y hace factible la isolación por merchant: los comerciantes mantienen el control sobre productos y creativos, y los operadores conservan el control de la infraestructura.
Operación y monitorización
- Perfilado de consultas: Identificar consultas lentas y ajustar la estrategia de índices/particiones.
- Higiene de particiones: Añadir/eliminar automáticamente particiones temporales para evitar un exceso de particiones.
- Copias de seguridad y pruebas de restauración: Verificar escenarios de restauración para datos calientes y de archivo por separado.
- Métricas: Monitorizar la tasa de inserts, latencia de lectura, esperas por bloqueos, tasa de pruning de particiones y rendimiento de archivado.
Resumen: plan de implementación por pasos
- Análisis: identificar las consultas principales y los puntos calientes (por merchant, partner, tiempo).
- Particionar: comenzar por tiempo, auditar las cláusulas WHERE para que el pruning funcione.
- Almacenamiento caliente/escalonado: tabla hot para datos recientes, archivo para datos fríos; usar Partition Exchange.
- Aislación por merchant: crear BD separadas o shards para merchants de alto volumen.
- Tubería de archivado e instantáneas: crear snapshots de liquidación, mover en lotes con reconciliación.
- Monitorización y iteración: observar métricas y ajustar la estrategia.
Beneficio práctico para operadores de Affilentra
Con estos patrones, los operadores mantienen la soberanía de los datos en un entorno autoalojado y evitan pérdidas de seguimiento o cálculos erróneos de comisiones. La arquitectura de Affilentra con roles separados facilita el aislamiento por comerciante y permite migraciones controladas a topologías particionadas o shardeadas —sin sacrificar la lógica de negocio.
Actúe ahora: Para una instalación escalable y asesoría sobre estrategias de particionamiento y sharding, elija su punto de entrada: Elegir inicio.
Siguiente paso
Probar Affilentra
Plataforma unificada que integra de forma transparente la puesta a disposición de productos, el tracking, la validación de conversiones, el cálculo de comisiones y el pago, con roles claramente separados; opción de instalación autoalojada con licencia perpetua sin participación en los ingresos; los comerciantes conservan el control sobre productos, condiciones y materiales publicitarios; los socios reciben enlaces de seguimiento personales e historial de pagos verificable.