Cómo el equipo de bases de datos de Figma soportó una expansión de 100x

• El equipo de bases de datos de Figma resumió su recorrido de nueve meses para aplicar sharding horizontal a su stack de Postgres y cómo hizo posible una escalabilidad casi infinita

El recorrido de Figma hacia el sharding horizontal de su stack de Postgres

• La escala del stack de bases de datos de Figma creció casi 100 veces desde 2020: este fue un problema positivo que reflejaba la expansión del negocio, pero al mismo tiempo generó desafíos técnicos. En 2020 operaban una sola base de datos Postgres en la instancia física más grande de AWS, y para finales de 2022 habían construido una arquitectura distribuida que incluía caché, réplicas de lectura y múltiples bases de datos particionadas verticalmente.
• Particionado vertical: separaron grupos de tablas relacionadas en sus propias particiones verticales para obtener ganancias graduales de escalado y mantener suficiente margen para adelantarse al crecimiento. Por ejemplo, dividieron grupos de tablas relacionadas como “archivos de Figma” u “organizaciones” en sus propias particiones verticales.
• Transición al sharding horizontal: reconocieron que el particionado vertical por sí solo tenía límites. Tras los primeros esfuerzos de escalado enfocados en reducir el uso de CPU, comenzaron a monitorear distintos cuellos de botella en una flota más grande y diversa. Cuantificaron los límites de escalado de la base de datos desde CPU e IO hasta tamaño de tablas y número de filas escritas. Identificar estos límites fue clave para predecir cuánto margen quedaba por shard.
• Límites del tamaño de las tablas: algunas tablas llegaron a almacenar varios terabytes y decenas de miles de millones de filas, alcanzando un tamaño difícil de manejar en una sola base de datos. A esa escala, las operaciones de vacuum de Postgres (una tarea de fondo esencial para evitar interrupciones por agotamiento del ID de transacción) afectaban la confiabilidad. Las tablas con más escrituras pronto superarían el máximo de IOPS soportado por Amazon RDS. Era un problema que el particionado vertical no podía resolver, por lo que necesitaban una solución más grande para evitar el colapso de la base de datos.

Construir la base para escalar

• Minimizar el impacto en los desarrolladores: absorbieron la mayor parte de la complejidad del modelo de datos relacional para que los desarrolladores de aplicaciones pudieran enfocarse en crear nuevas funciones interesantes en Figma, en lugar de refactorizar grandes partes del código.
• Escalado transparente: buscaron que en el futuro no hicieran falta cambios adicionales en la capa de aplicación al escalar. Es decir, después del trabajo preparatorio inicial para volver compatibles las tablas, las futuras expansiones podrían ser transparentes para los equipos de producto.
• Evitar backfills costosos: evitaron soluciones que implicaran backfills en las tablas grandes de Figma o en todas las tablas. Dado el tamaño de sus tablas y las limitaciones de throughput de Postgres, esos backfills habrían tomado meses.
• Avanzar de forma gradual: identificaron un enfoque que pudiera lanzarse gradualmente mientras reducían el riesgo de cambios importantes en producción. Esto disminuía el riesgo de interrupciones graves y permitía que el equipo de bases de datos mantuviera la confiabilidad de Figma durante la migración.
• Evitar migraciones de un solo sentido: mantuvieron la capacidad de revertir incluso después de completar el trabajo de sharding físico. Esto reducía el riesgo de quedar atrapados en un mal estado si aparecían variables desconocidas.
• Mantener una fuerte consistencia de datos: evitaron soluciones complejas difíciles de implementar sin downtime o que afectaran la consistencia, como los double-writes. Querían una solución que pudiera escalar con casi cero downtime.
• Aprovechar sus fortalezas: mientras trabajaban bajo plazos ajustados, prefirieron un enfoque que pudiera implementarse de la forma más gradual posible. Para las tablas de crecimiento más acelerado, intentaron aprovechar al máximo la experiencia y la tecnología existentes.

Explorar las opciones posibles

• Revisión de opciones de bases de datos con sharding horizontal: existen varias soluciones populares, tanto open source como administradas, para bases de datos con sharding horizontal compatibles con Postgres o MySQL. Evaluaron CockroachDB, TiDB, Spanner y Vitess. Sin embargo, migrar a una de estas bases de datos alternativas habría requerido una migración de datos compleja para garantizar consistencia y confiabilidad entre dos almacenes de bases de datos distintos.
• Aprovechar la experiencia existente: en los últimos años desarrollaron mucha experiencia sobre cómo operar RDS Postgres de manera estable y eficiente. Durante una migración, habrían tenido que reconstruir esa experiencia de dominio desde cero. Dada su tasa de crecimiento extremadamente agresiva, solo les quedaban unos pocos meses.
• Descartar la elección de una base de datos NoSQL: otra solución escalable que suele elegirse a medida que una empresa crece es una base de datos NoSQL. Sin embargo, ya tenían un modelo de datos relacional muy complejo construido sobre su arquitectura actual de Postgres, y una API NoSQL no ofrecía esa diversidad. Querían que los ingenieros se concentraran en lanzar grandes funciones y construir nuevos productos, en lugar de reescribir casi todas las aplicaciones backend; NoSQL no era una solución viable.
• Considerar construir una solución de sharding horizontal sobre la infraestructura existente de RDS Postgres: no tenía sentido que un equipo pequeño reimplementara internamente una base de datos relacional general con sharding horizontal. Hacerlo significaría competir con herramientas creadas por una gran comunidad open source o por proveedores especializados de bases de datos. Sin embargo, como adaptarían el sharding horizontal a la arquitectura específica de Figma, podía bastar con ofrecer un conjunto de funciones mucho más pequeño. Por ejemplo, decidieron no soportar transacciones entre shards con garantía de atomicidad, porque tenían formas de resolver fallas de transacciones entre shards. Eligieron una estrategia de colocación (colocation) para minimizar los cambios necesarios en la capa de aplicación. Esto les permitió soportar un subconjunto de Postgres compatible con la mayoría de la lógica del producto. Además, pudieron mantener fácilmente compatibilidad hacia atrás entre Postgres con sharding y Postgres sin sharding. Si se encontraban con variables desconocidas, podían volver fácilmente a Postgres sin sharding.

El camino hacia el sharding horizontal

• Introducción al sharding horizontal: el sharding horizontal es el proceso de dividir una sola tabla o un grupo de tablas para repartir los datos entre múltiples instancias físicas de base de datos. Con este proceso, una tabla con sharding horizontal en la capa de aplicación puede soportar cualquier número de shards en la capa física. Siempre pueden seguir escalando simplemente ejecutando divisiones físicas de shards, y esas operaciones ocurren en segundo plano de manera transparente, con downtime mínimo y sin cambios a nivel de aplicación. Gracias a esta capacidad, Figma pudo adelantarse a los cuellos de botella de escalado de bases de datos que aún quedaban y eliminar uno de sus últimos grandes desafíos de escalado. Si el particionado vertical les permitió acelerar a velocidad de autopista, el sharding horizontal quitó el límite de velocidad y les permitió volar.
• La complejidad del sharding horizontal: el sharding horizontal es un nivel más complejo que sus esfuerzos de escalado anteriores. Cuando las tablas se dividen entre múltiples bases de datos físicas, se pierden muchas propiedades de confiabilidad y consistencia que suelen darse por sentadas en una base de datos SQL ACID. Por ejemplo, ciertas consultas SQL pueden volverse ineficientes o imposibles de soportar, y el código de la aplicación debe actualizarse para proporcionar suficiente información que permita enrutar las consultas al shard correcto con la mayor eficiencia posible. Los cambios de esquema deben coordinarse para mantener todos los shards sincronizados, y las claves foráneas y los índices globalmente únicos ya no pueden ser forzados por Postgres. Las transacciones pasan a abarcar múltiples shards, por lo que Postgres ya no puede imponerlas. Ahora puede ocurrir que las escrituras en algunas bases de datos tengan éxito mientras otras fallen. La lógica del producto debe cuidarse para ser robusta frente a estas “fallas de commit parcial” (por ejemplo, al mover un equipo entre dos organizaciones, imagina que solo falta la mitad de los datos).
• Un esfuerzo de varios años hacia el sharding horizontal: sabían que lograr un sharding horizontal completo sería un esfuerzo de varios años. Necesitaban entregar valor incremental mientras reducían el riesgo del proyecto tanto como fuera posible. La primera meta era aplicar sharding lo antes posible en producción a una tabla relativamente simple pero de tráfico muy alto. Esto no solo demostraría la viabilidad del sharding horizontal, sino que también ampliaría su margen en la base de datos con mayor carga. Después podrían construir funciones adicionales mientras aplicaban sharding a grupos de tablas más complejos. Incluso el conjunto de funciones más simple posible seguía siendo un trabajo considerable. De principio a fin, al equipo le tomó aproximadamente nueve meses aplicar sharding a la primera tabla.

Nuestro enfoque único

• Colocation (colos): hicieron sharding horizontal de grupos de tablas relacionadas como colocations que comparten la misma clave de sharding y el mismo diseño de sharding físico (a las que cariñosamente llaman “colo”). Esto ofrece a los desarrolladores una abstracción amigable para interactuar con tablas con sharding horizontal.
• Sharding lógico: separaron el concepto de “sharding lógico” en la capa de aplicación del de “sharding físico” en la capa de Postgres. Usaron vistas para lanzar primero el sharding lógico, más seguro y de menor costo, antes de ejecutar el failover físico distribuido, que es más riesgoso.
• Motor de consultas de DBProxy: construyeron el servicio DBProxy, que intercepta las consultas SQL generadas en la capa de aplicación y las enruta dinámicamente a distintas bases de datos Postgres. DBProxy incluye un motor de consultas capaz de analizar y ejecutar consultas complejas sobre tablas con sharding horizontal. A través de DBProxy pudieron implementar funciones como balanceo de carga dinámico y hedging de solicitudes.
• Preparación de la aplicación en sombra: agregaron un framework de “preparación de la aplicación en sombra” que permite predecir cómo se comportaría el tráfico real de producción bajo distintas claves de sharding potenciales. Esto da a los equipos de producto una visión clara de qué lógica de la aplicación deben refactorizar o eliminar para prepararla para el sharding horizontal.
• Replicación lógica completa: no fue necesario implementar “replicación lógica filtrada”, que copia solo un subconjunto de los datos a cada shard. En su lugar, copiaron el conjunto completo de datos y luego permitieron lecturas/escrituras solo para el subconjunto que corresponde a cada shard.

Implementación del sharding

• La importancia de elegir la clave de shard: una de las decisiones más importantes en el sharding horizontal es qué clave de shard usar. El sharding horizontal introduce varias restricciones del modelo de datos alrededor de esa clave. Por ejemplo, la mayoría de las consultas deben incluir la clave de shard para poder enrutar la solicitud al shard correcto. Ciertas restricciones de base de datos, como las claves foráneas, solo funcionan cuando la clave foránea es también la clave de sharding. La clave de shard debe distribuir los datos de forma uniforme entre todos los shards para evitar hotspots que generen problemas de confiabilidad o afecten la escalabilidad.
• Enfoque adaptado al modelo de datos de Figma: Figma funciona en el navegador y muchos usuarios pueden colaborar al mismo tiempo en el mismo archivo de Figma. Esto significa que está impulsado por un modelo de datos relacional relativamente complejo que captura metadatos de archivos, metadatos de organizaciones, comentarios, versiones de archivos y más. Como no había un único buen candidato en el modelo de datos existente, consideraron usar la misma clave de sharding para todas las tablas, pero eso habría requerido crear claves compuestas para introducir una clave de sharding unificada, agregar columnas a todos los esquemas de tablas, ejecutar backfills costosos para poblarlas y luego refactorizar considerablemente la lógica del producto. En cambio, adaptaron el enfoque al modelo de datos único de Figma y eligieron unas pocas claves de sharding como UserID, FileID y OrgID. Casi todas las tablas de Figma pueden shardearse usando una de estas claves.
• Introducción de las colocations (colos): introdujeron el concepto de colocation para ofrecer una abstracción amigable a los desarrolladores de producto. Las tablas dentro de un colo admiten joins entre tablas y transacciones completas cuando se restringen a una sola clave de sharding. Como la mayor parte del código de la aplicación ya interactuaba con la base de datos de esta manera, se minimizó el trabajo que los desarrolladores debían hacer para adaptar las tablas al sharding horizontal.
• Garantizar una distribución uniforme de los datos: una vez elegida la clave de sharding, había que garantizar una distribución uniforme de los datos entre todas las bases de datos backend. Desafortunadamente, muchas de las claves elegidas usaban IDs autoincrementales o IDs con prefijo temporal de Snowflake. Eso habría provocado hotspots importantes, con la mayor parte de los datos concentrados en un solo shard. Exploraron migrar a IDs más aleatorios, pero eso habría requerido una migración de datos costosa y prolongada. En su lugar, decidieron usar un hash de la clave de sharding para el enrutamiento. Si se elige una función hash suficientemente aleatoria, se puede garantizar una distribución uniforme de los datos. Una desventaja es que los range scans sobre la clave de shard se vuelven menos eficientes, ya que claves consecutivas pueden terminar hasheadas en distintos shards físicos. Sin embargo, como este patrón de consulta no es común en su codebase, fue una compensación aceptable.

La solución “lógica”

• Reducir el riesgo del lanzamiento del sharding horizontal: para reducir el riesgo del lanzamiento del sharding horizontal, quisieron separar el proceso físico de dividir shards del proceso de preparar las tablas en la capa de aplicación. Para ello separaron el “sharding lógico” del “sharding físico”. Así pudieron dividir la migración en dos partes, implementarlas de forma independiente y reducir el riesgo. El sharding lógico ofrecía confianza en el stack de serving mediante un lanzamiento gradual de bajo riesgo. Cuando encontraban bugs, revertir el sharding lógico era un simple cambio de configuración. Revertir una operación de shard físico era posible, pero requería una coordinación más compleja para garantizar la consistencia de los datos.
• Qué ocurre después del sharding lógico: una vez que una tabla queda shardeadа lógicamente, todas las operaciones de lectura y escritura ya funcionan como si tuviera sharding horizontal. En términos de confiabilidad, latencia y consistencia, se comporta como si estuviera shardeadа horizontalmente, pero los datos siguen ubicados físicamente en un solo host de base de datos. Cuando ya tenían confianza en que el sharding lógico funcionaba como esperaban, entonces realizaban la operación de sharding físico. Esto implicaba copiar los datos desde una sola base de datos, shardearlos entre varios backends y luego volver a enrutar el tráfico de lectura y escritura hacia las nuevas bases de datos.

Un motor de consultas capaz

• Rediseño del stack backend para soportar sharding horizontal: al principio, los servicios de aplicación se comunicaban directamente con PGBouncer, la capa de connection pooling. Pero el sharding horizontal exige un análisis, planeación y ejecución de consultas mucho más complejos. Para soportarlo, construyeron un nuevo servicio en golang llamado DBProxy. DBProxy se ubica entre la capa de aplicación y PGBouncer. Incluye lógica para balanceo de carga, mejor observabilidad, soporte transaccional, gestión de la topología de la base de datos y un motor de consultas liviano.
• Componentes clave del motor de consultas:
  • Parser de consultas: lee el SQL enviado por la aplicación y lo convierte en un árbol de sintaxis abstracta (AST).
  • Planner lógico: analiza el AST y extrae del plan de consulta el tipo de consulta (insert, update, etc.) y el ID del shard lógico.
  • Planner físico: mapea la consulta del ID de shard lógico a la base de datos física. Reescribe la consulta para ejecutarla en el shard físico adecuado.
• El enfoque “scatter-gather”: funciona como un juego de escondidas en toda la base de datos: envía la consulta a todos los shards (scatter) y luego reúne las respuestas de cada uno (gather). Suena divertido, pero si se usa en exceso con consultas complejas, puede hacer que la base de datos se vuelva lenta como caracol.
• Implementación de consultas en un mundo con sharding horizontal: las consultas de un solo shard se filtran por una sola clave de shard. El motor de consultas solo necesita extraer esa clave y enrutar la consulta a la base de datos física correspondiente. La complejidad de ejecutar la consulta se “empuja hacia abajo” a Postgres. Pero si en la consulta falta la clave de sharding, el motor tiene que realizar un “scatter-gather” más complejo. En ese caso, debe hacer fan-out de la consulta a todos los shards (fase scatter) y luego agregar los resultados (fase gather).
• Simplificación de la compatibilidad con SQL: si el servicio DBProxy hubiera soportado compatibilidad completa con SQL, se habría parecido mucho al motor de consultas de Postgres. Querían minimizar la complejidad de DBProxy simplificando la API y reducir el trabajo de los desarrolladores de aplicación que tendrían que reescribir consultas no soportadas. Para determinar el subconjunto adecuado, construyeron un framework de “shadow planning” con el que podían definir posibles esquemas de sharding de tablas y ejecutar la etapa de planeación lógica sobre tráfico real de producción. Registraban las consultas y sus planes asociados en la base de datos Snowflake para poder hacer análisis offline. A partir de esos datos, eligieron un lenguaje de consultas que soporta el 90% más común de las consultas, evitando al mismo tiempo la complejidad del peor caso del motor. Por ejemplo, se permiten todos los range scans y point queries, pero los joins solo se permiten entre dos tablas del mismo colo cuando se realizan sobre la clave de sharding.

Perspectivas a futuro

• Encapsulación de shards lógicos: Tuvieron que decidir cómo encapsular los shards lógicos. Exploraron dividir los datos usando una base de datos de Postgres independiente o un esquema de Postgres. Desafortunadamente, esto requería cambios físicos en los datos al hacer el sharding lógico, lo que era tan complejo como dividir shards físicos.
• Representación de shards mediante vistas de Postgres: En cambio, decidieron representar los shards como vistas de Postgres. Se pueden crear varias vistas para cada tabla, y cada una corresponde a un subconjunto de datos de un shard determinado. Esto tiene una forma como la siguiente: CREATE VIEW table_shard1 AS SELECT * FROM table WHERE hash(shard_key) >= min_shard_range AND hash(shard_key) < max_shard_range). Todas las operaciones de lectura y escritura se realizan a través de esta vista.
• Creación de vistas shardeadas sobre una base de datos física existente sin sharding: Era posible hacer sharding lógico antes de ejecutar una operación riesgosa de resharding físico. Cada vista se accedía a través de su propio servicio de connection pooling shardeado. El connection pooler seguía apuntando a instancias físicas no shardeadas, haciendo que parecieran shardeadas. Mediante feature flags en el motor de consultas, pudieron lanzar gradualmente lecturas y escrituras shardeadas para reducir el riesgo, y revertir en cualquier momento en cuestión de segundos redirigiendo el tráfico de vuelta a la tabla principal. Para cuando ejecutaron el primer reshard, ya tenían confianza en la seguridad de la topología shardeada.
• Riesgos de depender de vistas: Las vistas agregan sobrecarga de rendimiento y, en algunos casos, pueden cambiar de forma fundamental cómo el query planner de Postgres optimiza las consultas. Para validar este enfoque, recopilaron un corpus de consultas de producción sanitizadas y ejecutaron pruebas de carga con y sin vistas. Confirmaron que, en la mayoría de los casos, las vistas solo añadían una sobrecarga mínima de rendimiento, y que incluso en el peor caso era menor al 10%. También construyeron un framework de shadow reads que enviaba todo el tráfico de lectura en tiempo real a través de las vistas y comparaba el rendimiento y la exactitud de las consultas con y sin vistas. Como resultado, confirmaron que las vistas eran una solución viable con un impacto mínimo en el rendimiento.

Resolver problemas de topología

• Comprensión de la topología por parte de DBProxy para enrutar consultas: Era necesario que las tablas y las bases de datos físicas entendieran la topología. Debido a la separación entre los conceptos de sharding lógico y físico, surgió la necesidad de encontrar una forma de representar estas abstracciones dentro de la topología.
• Mapeo de tablas y claves de shard: Necesitaban una forma de mapear la tabla users a la clave de shard user_id, y de mapear un ID de shard lógico (123) a la base de datos lógica y física correspondiente.
• Particionamiento vertical y dependencia de archivos de configuración hardcodeados: En el particionamiento vertical dependían de archivos de configuración simples y hardcodeados que mapeaban las tablas a su partición correspondiente. La transición al sharding horizontal exigía un sistema más complejo.
• Cambios dinámicos en la topología y necesidad de actualización rápida del estado en DBProxy: Durante la división de shards, la topología cambiaba dinámicamente, por lo que DBProxy necesitaba actualizar rápidamente su estado para evitar enrutar solicitudes a la base de datos equivocada.
• Compatibilidad hacia atrás de los cambios de topología: Todos los cambios de topología debían ser compatibles hacia atrás, sin introducir cambios en la ruta crítica del sitio.
• Construcción de una topología de base de datos que encapsula metadatos complejos de sharding horizontal: Construyeron una topología de base de datos que encapsulaba metadatos complejos de sharding horizontal y proporcionaba actualizaciones en tiempo real en menos de un segundo.
• Simplificación de la administración de bases de datos mediante la separación de topologías lógicas y físicas: Redujeron costos y complejidad al mantener la misma topología lógica que producción en entornos no productivos, mientras reducían la cantidad de bases de datos físicas.
• Aplicación de invariantes dentro de la topología mediante una librería de topología: Mantuvieron la corrección del sistema durante la implementación del sharding horizontal imponiendo invariantes dentro de la topología, como que cada ID de shard debía mapearse exactamente a una base de datos física.

Operaciones de sharding físico

• Última etapa tras dejar listas las tablas para el sharding: La etapa final fue el failover físico desde una base de datos no shardeada hacia una base de datos shardeada. Pudieron reutilizar gran parte de la misma lógica para el sharding horizontal, aunque había algunas diferencias notables, como pasar de una relación 1 a 1 entre bases de datos a una de 1 a N.
• Necesidad de reforzar la durabilidad del proceso de failover: Tuvieron que hacer más robusto el proceso de failover para prepararse ante nuevos modos de falla en los que una operación de sharding podía tener éxito solo en una parte de la base de datos.
• La mayoría de los riesgos ya se había resuelto durante el particionamiento vertical: Como muchos de los factores de riesgo ya se habían mitigado durante el particionamiento vertical, pudieron avanzar hacia la primera operación de sharding físico mucho más rápido de lo que habría sido posible de otro modo.

En qué punto está hoy el viaje de sharding horizontal

• Inversión multianual en sharding horizontal: Tras reconocer que se requería una inversión de varios años en sharding horizontal para la escalabilidad futura de Figma, lanzaron su primera tabla con sharding horizontal en septiembre de 2023.
• Ejecución exitosa del failover: Lograron un failover exitoso con 10 segundos de disponibilidad parcial temporal en el primario de la base de datos y sin impacto en la disponibilidad de las réplicas. Después del sharding, no hubo regresiones en latencia ni en disponibilidad.
• Manejo de shards complejos: Procesaron un shard relativamente simple de la base de datos con mayor tasa de escritura. Este año planean shardear bases de datos cada vez más complejas con decenas de tablas y miles de puntos de llamada en el código.
• Necesidad de sharding horizontal para todas las tablas de Figma: Esto es necesario para eliminar el último límite de escalabilidad y lograr una verdadera capacidad de crecimiento. Un mundo completamente shardeado horizontalmente ofrece varios beneficios, como mayor confiabilidad, reducción de costos y mayor velocidad para los desarrolladores.
• Problemas que aún deben resolverse:
  • Soporte para actualizaciones de esquema con sharding horizontal
  • Generación de IDs globalmente únicos para claves primarias con sharding horizontal
  • Transacciones atómicas entre shards para casos de uso críticos para el negocio
  • Índices distribuidos globalmente únicos (actualmente solo compatibles en índices que incluyen la clave de shard)
  • Mayor velocidad para desarrolladores con modelos de ORM compatibles de forma fluida con el sharding horizontal
  • Operaciones de reshard totalmente automatizadas que puedan ejecutar divisiones de shards con solo hacer clic en un botón
• Reevaluación del enfoque existente de sharding horizontal en RDS: Este viaje comenzó hace 18 meses bajo una presión de plazos muy ajustados. Con el desarrollo y la maduración continua de los almacenes NewSQL, ahora tienen suficiente margen para reevaluar los trade-offs entre mantenerse en el camino actual o cambiar a una solución open source o administrada.
• Avances emocionantes en el camino del sharding horizontal: Aunque todavía están en una etapa temprana de los desafíos que quedan por resolver, esperan compartir análisis más profundos sobre distintas partes de su stack de sharding horizontal. Si te interesan proyectos como este, piden que te pongas en contacto. Están contratando.

Opinión de GN⁺

• El equipo de bases de datos de Figma buscó superar los límites de escalabilidad de la base de datos mediante sharding horizontal, un paso importante para sostener el crecimiento y el rendimiento de una herramienta de colaboración basada en la nube.
• El sharding horizontal plantea nuevos desafíos en la gestión de datos y la optimización de consultas, lo que exige nuevos conocimientos y habilidades para administradores de bases de datos y desarrolladores.
• Aunque el sharding horizontal mejora considerablemente la escalabilidad de las bases de datos, también requiere nuevas soluciones para el manejo de consultas complejas y el mantenimiento de la consistencia de los datos.
• Un proyecto open source que ofrece capacidades similares es CitusDB, que permite escalar horizontalmente bases de datos Postgres.
• Al adoptar tecnologías de sharding horizontal, es necesario considerar la complejidad del modelo de datos, el rendimiento de las consultas y la flexibilidad y mantenibilidad del sistema, lo que implica encontrar un equilibrio entre la escalabilidad de la base de datos y la facilidad de administración.

[GN⁺]

Opiniones de Hacker News

• Tablas grandes y límites de IOPS de RDS

  • Se menciona que la tabla más grande llega a varios TB y que pronto superará el máximo de IOPS que soporta RDS.
  • RDS para PostgreSQL alcanza un máximo de 256,000 IOPS en un volumen de 64 TB.
  • En una configuración multi-AZ, esto representa un costo de $70K al mes.

• Resultados del sharding y costos

  • Al final, se asume un sharding de 5 vías, donde cada shard soporta alrededor de 50,000 IOPS y 12 TB de datos.
  • En una configuración multi-AZ, esto representa un costo de $100K al mes.

• Tiempo y costo del sharding

  • Tomó 9 meses hacer sharding de la primera tabla.
  • Como también fueron necesarios cambios en la aplicación, se calcula como 9 meses * 20 días laborables/mes * (3 ingenieros de BD + 2 ingenieros de aplicación) = 900 días-hombre.
  • Si se asume un salario promedio de $100K para un ingeniero, el costo total es de aproximadamente $400K.

• Comparación de costos con YugabyteDB

  • Se estima que YugabyteDB, un NewSQL compatible con PostgreSQL, costaría $15K al mes para igualar el máximo rendimiento de RDS.
  • Figma gastó internamente unas 25 veces más ($400K/$15K) en implementar sharding horizontal y sigue usando RDS, que además cuesta unas 6 veces más ($100K/$15K).

• Propuesta de separar la base de datos por cliente

  • Se sugiere que podría ser más fácil poner a cada cliente en una base de datos (lógica) separada.
  • Como no se requieren transacciones entre distintos clientes, parece que están resolviendo un problema más difícil de lo que realmente es.
  • No está claro si las bases de datos (lógicas) de PostgreSQL escalarían bien, pero en principio no es imposible.

• Construir una versión para PG similar a Vitess de MySQL

  • La reescritura de consultas resulta interesante.
  • Si se pone una capa entre la BD y la aplicación, también se podrían habilitar varios ACL (listas de control de acceso).

• Consideración sobre FoundationDB

  • Surge la duda de por qué no intentaron usar FoundationDB.
  • Había problemas con el vacuuming (recolección de basura) de PostgreSQL.
  • En versiones anteriores, el vacuuming requería el doble de espacio, aunque eso podría haber cambiado en las versiones más recientes.

• Enfoque de tratar el sharding como un hack

  • Es mejor depender de las API del sistema operativo en lugar de manejar directamente el buffering/caching de I/O de bajo nivel.
  • Persiste la percepción de que todavía faltan técnicas/infraestructura similares para el sharding de BD.

• Dudas sobre no usar la extensión Citus

  • Citus, una extensión madura de Postgres, no se menciona en el artículo.
  • Puede que no conocieran Citus o que lo hayan ignorado por alguna razón específica.

• Posibilidad de usar Aurora Limitless

  • Se pregunta si podrían usar Amazon Aurora Limitless.

• Comprensión de las bases de datos NoSQL

  • NoSQL es adecuado para backends que manejan datos no estructurados cuando no se necesita un modelo relacional complejo.
  • Postgres también lo soporta con el tipo de dato jsonb, pero como ya tienen un buen modelo de datos, no necesitan usarlo demasiado.

• Madurez del sharding y consideración de soluciones NewSQL

  • Dado que el sharding ya ha madurado, se plantea si vale la pena considerar soluciones NewSQL para tener sharding automático y soporte multirregión.
  • Aprender a operar una base de datos NewSQL también implica un costo adicional.

• Tecnología Spanner de Google y evaluación de Figma

  • En Google, Spanner se considera una tecnología casi mágica que permite sharding horizontal infinito y transacciones, y casi todos los proyectos se están moviendo a Spanner.
  • Se expresa curiosidad sobre cómo evaluó Figma a Cloud Spanner y si con su esquema horizontal de Postgres realmente renunciaron al soporte de transacciones, aunque fuera de forma temporal.