Base de datos de 100 terabytes en PostgreSQL sin fragmentación

¿Es realista configurar una base de datos de 100 TB (aproximadamente 90 TB en realidad) en PostgreSQL sin fragmentación de datos entre varios nodos? ¿Hay historias de éxito / ejemplos sobre configuraciones similares?

Las escrituras de 50K por segundo que necesitan ser absorbidas generalmente son más que un desafío. Incluso en puntos de referencia sintéticos con inserciones bastante simples, los límites de PostgreSQL tienden a alcanzar un máximo de aproximadamente 10 K / s, y allí ni siquiera tiene una bestia tan grande en términos de tamaño de la base de datos.

Además, el sistema de E / S para ese único nodo PostgreSQL será interesante ya que incluso con RAID 10 y suponiendo que las inserciones de 50K serán iguales a solo 50K IOPS (lo que probablemente sea incorrecto, pero depende de su esquema de base de datos e índices) ), necesitará aproximadamente un centenar de discos emparejados con una muy buena matriz que le ahorrará la compra de varios cientos de discos para atender esas escrituras de manera oportuna.

Si el fragmentado es fácil y espera una carga de escritura tan grande, vaya a fragmentar. Las escrituras pueden ser muy difíciles de escalar.

Es realista y funcionará. El rendimiento depende en gran medida de la cantidad de RAM que tenga. Cuanto mayor sea la RAM, mayor será el caché y más tiempo PostgreSQL podrá almacenar en caché los datos antes de descargarlos en el disco.

PostgreSQL escribirá datos en el caché y descargará el caché de vez en cuando. Por lo tanto, 50k INSERTs por segundo no se traducirán a 50k IOPS. Será mucho menos, porque agrupará los registros y los escribirá todos al mismo tiempo.

Una base de datos tan grande no es un problema si la mayoría del trabajo es INSERT. PostgreSQL tendrá que cambiar los índices aquí y allá, pero ese es realmente un trabajo fácil. Si tuviera muchos SELECT en una base de datos de este tamaño, realmente necesitaría particionar.

Una vez trabajé en un Oracle DB (Oracle 10g) con 400TB en un servidor de 16GB, solo una instancia. La carga de trabajo de la base de datos también era un INSERT primario, por lo que algunos SELECT por día y millones de INSERT cada día. El rendimiento estaba lejos de ser un problema.

Con 100TB tienes algunos desafíos importantes. Si funcionará para usted o no depende de cómo quiera abordarlos.

1. Necesita formas suficientes de absorber la carga de escritura. Esto depende de la carga de escritura. Pero con un almacenamiento lo suficientemente impresionante se puede resolver. La velocidad es un gran problema aquí. Del mismo modo, el acceso de lectura debe analizarse cuidadosamente.

2. La mayoría de las bases de datos no consisten en un montón de tablas pequeñas, pero a menudo tienen una o dos realmente grandes, que pueden ser hasta la mitad del tamaño de base de datos. PostgreSQL tiene un límite estricto de 32 TB por tabla. Después de eso, el tipo de tid se queda sin contadores de página. Esto podría manejarse mediante una compilación personalizada de PostgreSQL o mediante particiones de tablas, pero es un desafío serio que debe abordarse al principio.

3. PostgreSQL tiene límites reales en la cantidad de RAM que puede usar para diversas tareas. Entonces, tener más RAM puede o no ayudarte más allá de cierto punto.

4. Copias de seguridad ... Las copias de seguridad son interesantes a esta escala. La base de datos de 60 TB que conozco tuvo que usar copias de seguridad de instantáneas fs y luego falsificar las copias de seguridad para barman para archivar wal. Estas copias de seguridad falsas eran proxies para las copias de seguridad de instantáneas fs. Como dije "No son copias de seguridad falsas. ¡Son copias de seguridad alternativas!"

Hay personas con bases de datos que se acercan a este rango. Conocí al menos a una persona que trabajaba para un banco en los Países Bajos que tenía una base de datos PostgreSQL de 60 TB. Sin embargo, realmente, realmente depende de su carga de trabajo y el tamaño por sí solo no es el problema.