- A inicios de este año tumbaron Notion durante 5 minutos para llevar a cabo un sharding de PostgreSQL en el que venían trabajando desde hacía varios meses
→ de inmediato empezaron a aparecer reacciones de que se había vuelto muchísimo más rápido
- ¿Cuándo decidieron hacer sharding?
→ tras crecer decenas de miles de veces en 5 años, el monolito de Postgres que les había funcionado bien empezó a superar su capacidad
→ VACUUM empezó a interrumpirse de forma continua y esperaban que pronto ocurriera un TXID wraparound, así que comenzaron el trabajo de sharding
- Diseñar el esquema de sharding
→ sharding a nivel de aplicación
⇨ qué datos se iban a shardear
⇨ con qué clave particionar para dividir los datos
⇨ cuántos shards crear y cómo organizarlos
→ Decisión #1
⇨ Notion tiene un modelo de datos estructurado por unidades de block
⇨ decidieron shardear todas las tablas conectadas desde la tabla block (Space, Discussion, Comment, etc.)
→ Decisión #2
⇨ block se particiona por workspace ID
⇨ como a cada workspace se le asigna un UUID, usaron eso
→ Decisión #3
⇨ se compone de 480 shards lógicos y 32 bases de datos físicas
la razón para elegir 480 en vez de 512, que es potencia de 2, es que es un número que se puede dividir de manera más flexible
- Migración a los shards
→ 1. Escritura dual en la DB antigua y la nueva (junto con Audit Log)
→ 2. Después de iniciar la escritura dual, comenzaron el backfill de los datos de la DB antigua hacia la nueva
→ 3. Validación de los datos en la DB nueva
→ 4. Cambio a la DB nueva (de forma incremental)
- Lecciones aprendidas a la mala
→ Hagan sharding antes: como esperaron hasta que la carga sobre la DB existente fuera grande, la migración misma también generó carga, así que no tuvieron más opción que hacerlo lentamente
→ Apunten a una migración con zero downtime: el throughput de la escritura dual fue el cuello de botella clave en el cambio final.
→ En lugar de una clave de partición separada, usen una PK compuesta: si hubieran combinado id, que era la PK de la DB existente, con space_id, que era la clave de partición, habrían podido evitar la necesidad de pasar space_id dentro de la app
1 comentarios
El tema del TXID de Postgres es siempre uno de los que salen a relucir
Defectos de PostgreSQL https://es.news.hada.io/topic?id=1829
Lo que aprendimos al escalar PostgreSQL durante 5 años https://es.news.hada.io/topic?id=4101