Lo que aprendimos al escalar PostgreSQL durante 5 años

 (onesignal.com)
18 puntos por xguru 2021-04-20 | 1 comentarios | Compartir por WhatsApp

Lo que aprendió el servicio de notificaciones push OneSignal al operar 75 TB de datos en 40 servidores de base de datos

  • Vista general de los datos: las tablas subscribers y notifications son las más grandes

  • Bloat: fenómeno en el que ocupa más espacio, se vuelve más lento y requiere más poder de cómputo

→ Table bloat: VACUUM

→ Index bloat: optimización Heap Only Tuple (HOT)

→ Activar autovacuum

→ Automatizar el particionado de tablas con la extensión pg_partman

→ pg_repack y pgcompacttable

  • Actualizaciones de la base de datos

→ pg_upgrdae requiere que la base de datos esté fuera de línea, así que no era una opción

→ Configurar por separado un servidor PostgreSQL con la nueva versión y usar replicación lógica con la extensión pglogical

  • XID Wraparound

→ La función MVCC (Multi Version Concurrency Control) de PostgreSQL usa IDs de transacción de 32 bits, por lo que si hay muchas transacciones puede agotarse rápido

→ Es importante monitorear los XID restantes

→ autovacuum_freeze_max_age

  • Promoción de réplica

→ Para una promoción rápida de la réplica, ponerla detrás de haproxy

  • Particionado

→ Las versiones recientes de PostgreSQL ya traen integrada la función de particionado de tablas

→ Cuando se necesite particionado, recomiendan dividir en muchas particiones siempre que sea posible

→ OneSignal planea pasar de 16 a 256, y luego a 4096 particiones

  • Sharding

→ No hay soporte integrado

→ Originalmente hacían sharding usando Tenant ID, separando UUID v4 por rangos

→ Actualmente están creando un proxy de datos que reconoce particiones y shards

Lecturas relacionadas

1 comentarios

 
xguru 2021-04-20