La Crisis de Notion: Cómo Solucionaron su Problema de Base de Datos

En 2021, la popularidad de Notion se disparó, pero su servicio se volvió insoportablemente lento. El problema radicaba en su modelo de datos único, donde todo es un bloque, que puede ser un fragmento de texto, una imagen o una página completa. Esta estructura permite una versatilidad increíble, pero también significa que incluso un documento simple puede resultar en cientos o miles de entradas en la base de datos.

Cada bloque se almacena como una fila en una base de datos Postgres con su propio ID único. El enorme volumen de datos finalmente provocó que los usuarios notaran un aumento de la latencia al solicitar datos de la página. La base de datos monolítica única de Notion ya no podía manejar la carga, y su proceso de vacío de Postgres comenzó a instalarse constantemente, lo que provocó tablas hinchadas y un rendimiento degradado.

La Solución: Escalado Horizontal y Sharding

Notion decidió realizar sharding en su base de datos, creando 32 instancias físicas de bases de datos, cada una con 15 esquemas lógicos separados. Cada esquema tendría su propia tabla, como bloque, espacio de trabajo y comentarios, para un total de 480 fragmentos en las 32 bases de datos físicas. El mecanismo de enrutamiento se determinó a nivel de aplicación para determinar dónde se almacenan los datos.

Los Desafíos: Migración de Datos y Limitaciones de Conexión

Notion tuvo que migrar sus datos existentes a los nuevos fragmentos mientras mantenía la consistencia de los datos. Utilizaron la replicación lógica de Postgres para aplicar continuamente los nuevos cambios a las nuevas bases de datos. El proceso implicó configurar tres publicaciones de Postgres en cada base de datos existente, con cada publicación cubriendo cinco esquemas lógicos en las nuevas bases de datos. Se crearon suscripciones para consumir una de las tres publicaciones, cubriendo efectivamente el conjunto de datos relevante.

Sin embargo, las pruebas descubrieron un problema crítico: cada fragmento antiguo se mapeaba a tres fragmentos nuevos, lo que les obligaba a reducir el número de conexiones por instancia de PG bouncer o aumentarlo por 3. Optaron por aumentar el límite de conexión, lo que les permitió mantener un número apropiado de conexiones antes de implementar los cambios en producción.

El Resultado: Mayor Capacidad y Rendimiento Mejorado

El proyecto de re-sharding fue un éxito significativo para Notion. Algunos resultados clave incluyeron:

• Mayor capacidad
• Rendimiento mejorado
• La utilización de CPU e IOPS disminuyó drásticamente, con una nueva utilización que ronda el 20% durante el tráfico máximo en comparación con el 90% anterior.
• Esta nueva arquitectura posicionó a Notion para manejar el crecimiento continuo de usuarios y las demandas continuas de datos.

En conclusión, la crisis de Notion se resolvió mediante una combinación de escalado horizontal y sharding, una cuidadosa migración de datos y soluciones ingeniosas para las limitaciones de conexión. Su nueva arquitectura los ha posicionado para un crecimiento y éxito continuos.