Postgres no es lento, tu almacenamiento sí

SQLite + NVMe a veces parece hacer trampa. Si mi requisito número uno es la latencia más baja posible, no me imagino eligiendo otra cosa.

Kestrel (AspNetCore) + SQLite + NVMe todo en la misma máquina es donde las cosas se ponen realmente picantes en mi experiencia. Imagina manejar todo el envío de un formulario que muta el estado de la base de datos en decenas a bajos cientos de microsegundos. El tiempo total de reloj de pared necesario para atender cualquier solicitud HTTP puede ser muy inferior a un solo milisegundo. Si tu tiempo promedio de CPU por solicitud es de 30uS, podrías acercarte a medio millón por segundo en una máquina de 16-32 núcleos.

"En aquellos tiempos", teníamos que planificar cuidadosamente el array de almacenamiento subyacente para exprimir cada gramo de rendimiento del servidor de base de datos.

Creo que hay una generación de desarrolladores que simplemente da por sentado los grandes pools de memoria y los SSD; hay una desconexión mental con el hecho de que las bases de datos mapean el almacenamiento subyacente.

Se vuelve obvio una vez que lo saco a relucir en una discusión y casi puedo ver la bombilla encenderse (sucedió mientras discutíamos particionamiento y sharding), pero nunca hacen la conexión de que una consulta se está mapeando a algunos artefactos que residen en el almacenamiento.

Recientemente movimos nuestras instancias de RDS de r8g. a r8gd., lo que agrega NVMe local, y creo que la latencia promedio de I/O pasó de 1.0ms a 0.1ms. ¡Se acumula en consultas grandes!

CloudNativePG soporta Kubernetes Local Storage como una de sus características principales [0]

Gestión de volúmenes persistentes, incluyendo:

Soporte para Local Persistent Volumes con plantillas de PVC.

Reutilización del almacenamiento de Persistent Volumes en Pods.

Volúmenes separados para archivos WAL y tablespaces.

El capítulo Temporary PostgreSQL Cluster Degradation [1] describe cómo configurarlo y comienza con esto

> Si bien el enfoque estándar garantiza la confiabilidad del servicio y aprovecha las capacidades de auto-reparación de Kubernetes, hay escenarios en los que puede ser aceptable operar con un clúster temporalmente degradado. Esto es particularmente relevante para clústeres de PostgreSQL que dependen de almacenamiento local al nodo, donde el almacenamiento es local al nodo trabajador de Kubernetes que ejecuta la base de datos PostgreSQL. El almacenamiento local al nodo, o simplemente almacenamiento local, se emplea para mejorar el rendimiento.

[0] https://cloudnative-pg.io/docs/devel/#main-features

[1] https://cloudnative-pg.io/docs/devel/kubernetes_upgrade/#tem...

Este es el problema fundamental con el almacenamiento en red: todas las aplicaciones por encima asumen que el I/O pequeño es rápido y local, por lo que la latencia de red no se amortiza.

Con replicación a nivel de aplicación, puedes amortizarla en unos pocos pasos (por ejemplo, al hacer commit, hacer 2PC).

Obviamente hay matices, especialmente si tienes que leer desde otro nodo, pero es por eso que mover la replicación lo más arriba posible en la pila generalmente funciona mejor con bases de datos: la base de datos sabe cuándo tocar la red mejor que el disco.

Honestamente, el almacenamiento conectado a la red solo tuvo sentido con HDDs, es ridículo tener que pagar una penalización de 10x tanto en IOPS como en latencia solo por algo de "flexibilidad operativa". Obtienes una arquitectura mucho más simple y robusta si simplemente te quedas con NVMe local y replicación, no es que puedas prescindir de una en la solución de almacenamiento en bloque en red (también replicada) de todos modos...

Estuve usando postgres durante un tiempo vergonzosamente largo antes de aprender la diferencia entre "index scans" e "index only scans".

Incluir columnas relevantes en el índice puede mejorar masivamente el rendimiento, porque postgres no necesita leer la tupla ordenada aleatoriamente en la tabla original.