PlanetScale erreicht 118 Millionen Abfragen pro Sekunde mit Neki
118M Queries per Second on Neki
PlanetScale hat mit Neki 118 Millionen Abfragen pro Sekunde über 512 Shards und 1,22 PiB Daten erreicht. Der Benchmark mit einfachen Point-Selects zeigt nahezu lineare Skalierung: Von 5 auf 50 Shards blieb die Leistung pro Shard konstant, bei 512 Shards stieg sie sogar auf 231.000 QPS. Die p99-Latenz lag bei 6,06 ms am Router und 13,95 ms am Client, bei nur 67 Fehlern pro Sekunde.
Wir haben 118.538.803 QPS über 16 Minuten auf 512 Shards und 1,22 PiB Daten aufrechterhalten.
- farazbabar
2015 konnte ich auf nur ein paar Nodes 1 Million Lese-/Schreibabfragen pro Sekunde erreichen, und ich habe das mit mehreren Datenbanken getestet. Damals erforderte es ein anständiges Netzwerk-Tuning und eine geschickte Platzierung der Nodes innerhalb von AWS, aber es kostete mich etwa 10 bis 15 Dollar pro Durchlauf, wenn ich mich richtig erinnere. Natürlich stellt sich die Frage, wie man solche Leistung skaliert, und deshalb möchte ich den Engineering-Aufwand anerkennen, der hier hineingeflossen ist, aber das ist zu viel Geld. Das erinnert mich daran, als eines meiner Teams Hadoop einsetzte, um nur ein paar Terabyte Offline-Daten zu verarbeiten, und es schaffte, das GANZE ZEUG in nur wenigen Stunden zu verarbeiten. Ich hatte nicht das Herz oder den Mut, ihnen während der Demo zu sagen, dass das Overkill war, aber ich schrieb ein sehr einfaches (und kleines) Stück Code, das alle Signale aus den Offline-Dateien in Sekundenschnelle extrahieren konnte, mit sorgfältiger Netzwerkplanung und Speicheroptimierung, und lud sie für nächste Woche zu einer Demo/Lunch-and-Learn ein.
- jamesblonde
2015 hat MySQL Cluster (NDB Cluster Engine) auf handelsüblicher Hardware 200 Millionen Transaktionen pro Sekunde gebenchmarkt [ref]. Es waren Read-Committed-Transaktionen, keine Snapshot-Isolation, aber trotzdem beeindruckend. NDB ist inzwischen zu RonDB geworden, basiert aber immer noch auf einem nicht-blockierenden 2-Phasen-Commit-Protokoll und ist GPL-v2.
RonDB unterstützt jetzt Infiniband, also sollte es die 1 Milliarde Ops/Sek. locker durchbrechen. Zum Vergleich: Das sind 1 GHz an Transaktionen pro Sekunde.
[ref] https://www.slideshare.net/frazerClement/200-million-qps-on-...
- stephenlf
Ich habe ein Interview gesehen, das Casey Muratori mit Tyler Cloutier (Gründer und Sprecher von SpacetimeDB) geführt hat [1]. Einer von Tylers Punkten ist, dass eine verteilte Datenbank angesichts moderner CPU-Architektur mit Cache Lines auf mindestens 50-100 Nodes aufteilen muss, um den Durchsatz einer cache-optimierten Single-Node-Datenbank zu schlagen.
Es ist cool, die andere Seite dieses Arguments zu sehen. PlanetScale beantwortet die Frage: „Wie sieht es aus, wenn man seine Workload TATSÄCHLICH auf >100 Nodes aufteilt?“
Es gibt einen Platz für beide Technologien. Sehr cooles Zeug.
- danbruc
87,3 % aus dem Cache bedient. Bedeutet das, dass ein Ergebnis zurückgegeben wurde, das im Cache existierte, weil genau dieselbe Abfrage zuvor ausgeführt wurde? Wahrscheinlich immer noch ein relevantes Ergebnis; wenn man Millionen von Abfragen pro Sekunde verarbeiten muss, scheint es nicht unwahrscheinlich, dass man viele wiederholte Abfragen sieht. Aber an diesem Punkt misst man eher die Cache-Performance als die Query-Performance. Aber wenn man nicht einen standardisierten Query-Benchmark ausführt, ist eine einzelne Abfragen-pro-Sekunde-Zahl ohnehin nicht so aussagekräftig, weil die Abfragekomplexität und damit die Ausführungszeit viele Größenordnungen umfassen kann. Einen Namen per ID nachschlagen und über eine Milliarde Zeilen aus siebzehn miteinander verknüpften Tabellen aggregieren sind beides eine einzelne Abfrage.
- cbg0
Ich habe schnell mit ChatGPT für dieselbe Leistung/Speicherkapazität wie der Benchmark gerechnet:
Neki 1 Primary + 2 Replicas: ~5,0 Mio. $/Monat (nur die AWS-Rechnung)
Google Spanner mit 3 integrierten Replicas: ~3,85 Mio. $/Monat