PlanetScale alcanza 118 millones de consultas por segundo con Neki
118M Queries per Second on Neki
PlanetScale probó Neki en 512 shards, cada uno con un primario Postgres, y sostuvo 118,5 millones de consultas por segundo durante 16 minutos sobre 1,22 PiB de datos. La latencia p99 fue de 6,06 ms en el router y 13,95 ms en el cliente, con una escalabilidad casi lineal: de 5 a 50 shards el rendimiento por shard se mantuvo dentro del 0,8%. El benchmark usó solo lecturas puntuales por clave primaria, sin escrituras ni consultas entre shards.
Diez veces los shards, diez veces el rendimiento. Luego diez veces más.
- farazbabar
En 2015, pude llegar a 1 millón de consultas de lectura/escritura por segundo en solo un par de nodos y lo probé con múltiples bases de datos; requería (en ese momento) un ajuste de red decente y una ubicación de nodos dentro de AWS, pero me costó alrededor de 10 a 15 dólares por ejecución, si mal no recuerdo. Obviamente, está el tema de escalar ese rendimiento, así que quiero reconocer el esfuerzo de ingeniería que se ha puesto en esto, pero es demasiado dinero. Esto me recuerda cuando uno de mis equipos usó Hadoop para procesar solo unos pocos terabytes de datos offline y pudieron procesar TODO en solo unas pocas horas. No tuve el corazón ni el valor para decirles durante la demostración que eso era excesivo, pero escribí un fragmento de código muy simple (y pequeño) que podía extraer todas las señales de los archivos offline en meros segundos con una planificación de red cuidadosa y optimización de almacenamiento, y los invité a una demostración/almuerzo y aprendizaje la semana siguiente.
- jamesblonde
En 2015, MySQL Cluster (motor NDB Cluster) alcanzó un benchmark de 200 millones de transacciones por segundo en hardware comercial [ref]. Eran transacciones con read-committed, no de aislamiento de snapshot, pero aun así impresionante. NDB ahora se ha convertido en RonDB, pero sigue basado en un protocolo de commit de dos fases no bloqueante y es GPL-v2.
RonDB ahora tiene soporte para infiniband, por lo que debería superar los 1B de operaciones/seg. Como referencia, eso es 1 GHz de transacciones/seg.
[ref] https://www.slideshare.net/frazerClement/200-million-qps-on-...
- stephenlf
Vi una entrevista que Casey Muratori hizo con Tyler Cloutier (fundador y portavoz de SpacetimeDB) [1]. Uno de los puntos que menciona Tyler es que, dada la arquitectura moderna de CPU con líneas de caché, una base de datos distribuida necesita distribuirse a al menos 50-100 nodos para superar el rendimiento de una base de datos de un solo nodo optimizada para caché.
Es genial ver el otro lado de ese argumento. PlanetScale está respondiendo la pregunta: "¿cómo se ve cuando SÍ distribuyes tu carga de trabajo a >100 nodos?"
Hay un lugar para ambas tecnologías. Cosas muy interesantes.
- danbruc
87.3 % servido desde caché. ¿Eso significa que devolvió un resultado existente en la caché porque la misma consulta exacta se ejecutó antes? Probablemente sigue siendo un resultado relevante, si tienes que procesar millones de consultas cada segundo, no parece improbable que veas muchas consultas repetidas. Pero en ese punto estás midiendo más el rendimiento de la caché que el rendimiento de las consultas. Pero a menos que ejecutes algún benchmark de consultas estandarizado, un número único de consultas por segundo no es muy informativo de todos modos, porque la complejidad de la consulta y, por lo tanto, el tiempo de ejecución pueden abarcar muchos órdenes de magnitud. Buscar un nombre por ID y agregar mil millones de filas de diecisiete tablas unidas son ambas una sola consulta.
- cbg0
Hice algunos cálculos rápidos con ChatGPT para el mismo rendimiento/almacenamiento que el benchmark:
Neki 1 primario + 2 réplicas: ~$5.0M/mes (solo la factura de AWS)
Google Spanner con 3 réplicas integradas: ~$3.85M/mes