Skaliert SpacetimeDB horizontal? Ein ehrlicher Blick auf die drei Dimensionen der Skalierung
Ok, but Does It Scale?
SpacetimeDB beantwortet die häufig gestellte Frage, ob es horizontal skaliert. Der Beitrag unterscheidet drei Skalierungsdimensionen: Rechenleistung, Speicher und Netzwerk. Während Speicher horizontal skalierbar ist, gilt das nicht für alle Transaktionen. Systeme wie CockroachDB zahlen einen hohen Koordinationsaufwand bei konkurrierenden Transaktionen, was die Leistung drastisch senken kann. SpacetimeDB bietet hohe Leistung unter Konkurrenz und Werkzeuge, um parallelisierbare OLTP-Workloads zu skalieren.
Die hässliche Wahrheit ist, dass horizontale Skalierung oft bedeutet, mit mehr Computern weniger zu erreichen: Was ein Computer in 1 Millisekunde schafft, schaffen 10 Computer in 100 Millisekunden.
- timssopomo
Spacetime klingt nach wirklich interessanter Technologie, aber ich bin mir nicht sicher, ob der Vergleich mit CRDB ein guter ist.
Ich habe früher bei Cockroach Labs gearbeitet. Das Problem, das dort gelöst wird, ist ein grundlegend anderes. CRDB als Lösung macht Sinn, wenn man _garantieren_ muss, dass Transaktionen serialisierbar und dauerhaft sind und dass deine Anwendung Knoten- oder Regionsausfälle überstehen kann, während die Konsistenz gewahrt bleibt. In einer naiven Bereitstellung ist es deutlich langsamer als die Arbeit auf einem einzelnen Kern, aber das ist der Preis, den man dafür zahlt, dass man einen Knotenverlust ohne Datenverlust überstehen kann.
Ich sehe nichts, das darauf hindeutet, wie Spacetime das Kernproblem löst, das CRDB löst, nämlich zu garantieren, dass Ausfälle einzelner Knoten ohne Datenverlust oder Verfügbarkeitsverlust toleriert werden können. Es klingt so, als müssten Transaktionen standardmäßig vor Abschluss auf die Festplatte geschrieben werden, was sie auf einem einzelnen Knoten dauerhaft macht, aber man kann nicht sicherstellen, dass sie über Knoten hinweg konsistent sind, ohne den Netzwerk-Overhead zu akzeptieren und den Transaktionsdurchsatz zu verlieren (bei Schreibvorgängen jedenfalls).
Außerdem, nur damit das klar ist: In den mehreren Jahren, in denen ich im Grunde jeden Vorfall bearbeitet habe, kann ich mich nicht an einen Cluster erinnern, der durch das Netzwerk begrenzt war. Wie bei allem gibt es Kompromisse. Man gibt Durchsatz auf und erhält Konsistenz und Verfügbarkeit, und man muss nicht entwickeln, wie man Datenverlust oder Verfügbarkeitsverlust bei Knotenausfällen vermeidet. Wenn ich es nicht falsch verstehe, löst Spacetime ein völlig anderes Problem.
- chermi
Off-Topic, aber... Ich hatte einen Freund, dessen wichtigste Erkenntnis (ironisch gemeint) aus dem Harvard Mini-MBA, während er in einem SEAS-Programm war, war, dass man nur diese Frage stellen musste, um in VC-/tech-orientierten Geschäftskreisen intelligent zu wirken.
Dann haben wir tatsächlich ein Startup gegründet und festgestellt, dass dies keine alberne Frage war. Aber vielleicht ist das zirkulär, wenn der Standardweg VC-Finanzierung ist, hmm.
- philippta
Ich habe vor einiger Zeit Postgres im Einzel- und Mehrknoten-Setup gegen CockroachDB benchmarkt, und meine Ergebnisse stimmen mit dem überein, worüber dieser Beitrag spricht.
https://github.com/philippta/postgresql-cockroachdb-benchmar...
- echohack5
Als jemand, der viel Spacetime für Nebenprojekte verwendet hat (wie https://heat.echohack.app), bin ich immer wieder beeindruckt von der Geschwindigkeit, mit der es arbeitet.
Ich denke, es passieren viele interessante Dinge im Datenbankbereich. Vitess/Neki, Vektor-Stores, Spacetime sind alles wirklich gute Entwicklungen. Ich finde es schade, dass Datenbankentwickler scheinbar eine dramareiche Timeline da draußen haben. Es ist... alles sehr aufregend, zusammen.
Wie auch immer, einige Dinge, die verbessert werden müssen (einige davon werden in diesem Blogbeitrag angesprochen):
1. Backups (schnelle Wiederherstellung) und Disaster Recovery (langsame, dauerhafte Wiederherstellung)
Das ist ein großes Thema, aber manchmal ist Geschwindigkeit nicht das einzige Ziel, das man erfüllen muss. Man muss sicher sein, dass man, wenn alles ausfällt, (irgendwann) alles wieder online bringen kann. Ich habe heute keine wirkliche Möglichkeit, das zu tun.
2. Read Replicas wären sicherlich schön für analytische Workloads
3. Dauerhafte Schreibvorgänge nach S3 wären schön für intermittierende Burst-Workloads (wie CI-Systeme)
Ich denke, die Spacetime-Leute haben sich viel vorgenommen, nicht unbedingt wegen der Technologie (die ist auch schwer), sondern weil die KI-Modelle scheinbar entschieden haben, dass Neon und Postgres alles sind, was existiert.
Ich denke, Spacetime hat eine glänzende Zukunft vor sich, und ich wünsche dem Team alles Gute, während sie hart daran arbeiten, etwas Neues ins Universum zu prägen.
- themgt
> Du kannst deine Serverlogik direkt in die Datenbank deployen
> Du darfst die lizenzierte Arbeit nutzen, vorausgesetzt, deine Anwendung oder dein Dienst verwendet die lizenzierte Arbeit mit nicht mehr als einer SpacetimeDB-Instanz in Produktion und vorausgesetzt, du nutzt die lizenzierte Arbeit nicht für einen Datenbankdienst.
Daher skaliert SpacetimeDB als Open-Source-Produkt nicht.