Re: Update concurrente

No parece ser un desafío exagerado. Las direcciones que te sugeriría son:

1. Ejecutar un EXPLAIN sobre el UPDATE

2. Validar el dimensionamiento del servidor (CPUs, memoria) y la
configuración del motor

3. Evaluar la ideonidad de SSD (aunque sospecho que no sea la primera
prioridad)

El jue., 5 de diciembre de 2019 18:56, Silvio Bravo Cadó <
bravocado(at)gmail(dot)com> escribió:

> Hola Oliver,
>
> Gracias por contestar, aquí algunos datos de las tablas que te comento:
>
> *1. Cuántas filas tiene la tabla A?*
>>
> A tiene: 16M de registros , B tiene 300K
>
>> *2. Sólo para validar: tienes una llave primaria sobre el campo id?*
>>
> No. la referencia entre A y B es lógica.
>
>> *3. Cuántas columnas y cuántos índices tiene la tabla real?A*
>>
> A tiene: 26 columnas y 10 indices, B tiene 20 columnas y 1 indice
> el del primary key y un check constraint
>
>> *4. Cuántos usuarios concurrentes puedes tener?*
>>
> En picos altos como 1k por minuto intentando comprar 1 producto,
> su intento de compra hace que la tabla A y B tengan actividad.
>
>>
>> *Como idea loca, podrías simular varios productos (digamos 4) que se
>> reparten el stock completo y cada vez que llega un pedido se resta del
>> stock de uno al azar? *
>>
> Realicé carga de 1k en 1 minuto diviendo en 3 productos y los
> picos bajaron muy poco de 58 a 48 segundos.
>
>>
>> Olivier
>>
>>
>>
>
> --
>
>
>
> *Ing. Silvio Bravo Cadó*
> Mobile & Web Software Architect
>