Wie Discord Billionen von Nachrichten speichert (2023)
(discord.com)- Als Discords gespeicherte Nachrichtenmenge von Milliarden auf Billionen anwuchs, wurden der Betriebsaufwand und die schwer vorhersagbaren Latenzen eines Cassandra-Clusters mit 177 Nodes Anfang 2022 nicht mehr tragbar
- Das Cassandra-Design rund um
channel_idund Zeit-Buckets erzeugte bei konzentriertem Lese-Traffic großer Server Hot Partitions, und durch Quorum-Lese- und -Schreibvorgänge wirkten sich Latenzen auf eine größere Nutzerbasis aus - Zwischen API und Datenbank wurde ein Rust-basierter Datendienst eingeführt, der gleichzeitige Anfragen auf dieselbe Zeile zusammenfasst und durch konsistentes Hash-Routing auf Basis der Channel-ID die Datenbanklast reduziert
- Die Umstellung auf ScyllaDB erfolgte mit einem neuen Cluster-Setup und einem Rust-Migrator; eine mit Spark auf geschätzt 3 Monate veranschlagte Arbeit wurde auf etwa 9 Tage verkürzt, bei einer Spitzenrate von 3,2 Millionen migrierten Nachrichten pro Sekunde
- Nach der Umstellung im Mai 2022 sank die Zahl der Nodes von 177 Cassandra- auf 72 ScyllaDB-Nodes; der p99-Wert für das Abrufen älterer Nachrichten verbesserte sich von 40–125 ms auf 15 ms, der p99-Wert für das Einfügen von Nachrichten von 5–70 ms auf 5 ms
Der wachsende Betriebsaufwand mit Cassandra
- Discord veröffentlichte 2017 wie es Milliarden von Nachrichten speichert und beschrieb darin die Migration von MongoDB zu Cassandra
- Das Ziel war damals eine skalierbare, ausfallsichere Datenbank mit vergleichsweise geringem Wartungsaufwand, doch mit wachsendem Datenvolumen wurde der Cassandra-Cluster selbst zu einer großen operativen Belastung
- Der
cassandra-messages-Cluster für die Nachrichtenspeicherung wuchs von 12 Nodes im Jahr 2017 auf 177 Nodes Anfang 2022 und speicherte Billionen von Nachrichten - Das Betriebsteam wurde häufig wegen Datenbankproblemen alarmiert, die Latenzen waren schwer vorhersagbar, und zu kostspielig gewordene Wartungsarbeiten mussten reduziert werden
Nachrichtenschema und Hot Partitions
- Das vereinfachte Nachrichtenschema enthielt
channel_id,bucket,message_id,author_idundcontent; der Primärschlüssel war((channel_id, bucket), message_id) - Discords IDs basieren auf Snowflake, sodass sie zeitlich sortierbar sind; Nachrichten wurden nach Channel und einem statischen Zeitfenster, dem Bucket, partitioniert
- In Cassandra werden alle Nachrichten eines bestimmten Channels und Buckets zusammen gespeichert und je nach Replikationsfaktor auf mehrere Nodes repliziert
- Kleine Server von Freundesgruppen und Server mit Hunderttausenden Mitgliedern unterschieden sich bei der Nachrichtenmenge um mehrere Größenordnungen, und dieser Unterschied führte zu entsprechend unterschiedlichen Lasten pro Partition
- Schreibvorgänge werden zunächst an das Commit-Log und die speicherinterne Memtable angehängt und später auf die Festplatte geflusht; Lesevorgänge können jedoch die Memtable und mehrere SSTables abfragen und sind daher teurer
- Wenn sich auf großen Servern viele gleichzeitige Lesevorgänge häufen, wird eine bestimmte Partition zur Hot Partition; die Latenz der betroffenen Node steigt und wirkt sich auch auf andere Queries aus
- Da für Lese- und Schreibvorgänge ein Quorum Consistency Level genutzt wurde, breitete sich die erhöhte Latenz von Nodes, die Hot Partitions bedienten, auf eine größere Nutzerbasis aus
Wartungsengpässe bei Cassandra
- Auch die Compaction in Cassandra wurde immer wieder zum Auslöser von Störungsbehebungen
- SSTables müssen auf der Festplatte compacted werden, um die Leseleistung zu verbessern; wenn die Compaction zurückfällt, steigen die Lesekosten
- Während eine Node Compaction ausführt, konnten Latenzen kaskadenartig zunehmen
- Discord führte häufig eine Operation aus, die intern „Gossip Dance“ genannt wurde
- Eine Node wurde aus dem Traffic genommen, um Compaction auszuführen
- Anschließend wurde sie wieder eingebunden, damit sie anhand der Hints aus Cassandras Hinted Handoff aufholen konnte
- Dieser Vorgang wurde wiederholt, bis der Compaction-Backlog abgebaut war
- Auch das Tuning des JVM Garbage Collectors und der Heap-Einstellungen kostete viel Zeit, und GC Pauses verursachten große Latenzspitzen
Warum der Wechsel zu ScyllaDB erfolgte
- Discord betrieb neben Nachrichten mehrere weitere Cassandra-Cluster, und in jedem Cluster traten ähnliche Probleme auf
- ScyllaDB, an dem Discord im früheren Beitrag Interesse gezeigt hatte, ist eine Cassandra-kompatible Datenbank, in C++ geschrieben, und bietet bessere Performance, schnelle Repairs, Workload-Isolation auf Basis einer Shard-per-Core-Architektur sowie eine Architektur ohne Garbage Collection
- Auch ScyllaDB war nicht frei von Problemen, doch der Umstand, dass es nicht in Java, sondern in C++ geschrieben ist und daher keinen Garbage Collector hat, stand in direktem Gegensatz zu den Betriebsproblemen mit Cassandra
- Nachdem Experimente und Tests Verbesserungen bestätigt hatten, entschied Discord, alle Datenbanken zu ScyllaDB zu migrieren; bis 2020 waren alle Datenbanken außer
cassandra-messagesmigriert - Der Nachrichten-Cluster blieb bis zuletzt übrig, weil er ein großer Cluster mit Billionen von Nachrichten und fast 200 Nodes war
- Die Performance von Reverse Queries in ScyllaDB reichte in frühen Tests nicht für die Anforderungen aus
- Reverse Queries scannen entgegen der Sortierrichtung der Tabelle; ein Beispiel ist das Scannen von Nachrichten in aufsteigender Reihenfolge
- Nachdem das ScyllaDB-Team die Performance-Verbesserungen priorisiert und umgesetzt hatte, war der letzte Blocker für die abschließende Datenbankmigration beseitigt
Rust-basierter Datendienst
- Discord ging davon aus, dass ein reiner Datenbankwechsel nicht automatisch alle Probleme lösen würde, und änderte daher auch die Schicht oberhalb der Datenbank
- Zwischen dem API-Monolithen und dem Datenbank-Cluster wurde ein Datendienst eingeführt, um gleichzeitige Anfragen an die Datenbank zu steuern
- Der Datendienst wurde in Rust geschrieben
- Discord hatte Rust zuvor bereits in einigen Projekten eingesetzt
- Rust bietet Geschwindigkeit auf C/C++-Niveau, ohne Sicherheit aufzugeben
- Das Tokio ecosystem diente als Grundlage für den Aufbau asynchroner I/O-Systeme, und es gab auch Treiberunterstützung für Cassandra und ScyllaDB
- Der Datendienst hat ungefähr einen gRPC-Endpunkt pro Datenbank-Query und enthält bewusst keine Business-Logik
- Kernstück ist die Request-Zusammenführung
- Wenn mehrere Nutzer gleichzeitig dieselbe Row anfragen, wird die Datenbank nur einmal abgefragt
- Die erste Anfrage erzeugt im Dienst eine Worker-Task; nachfolgende Anfragen erkennen die Existenz dieser Task und abonnieren sie
- Die Worker-Task fragt die Datenbank ab und gibt die resultierende Row an alle Abonnenten zurück
Routing erhöht den Effekt der Zusammenführung
- Vor dem Datendienst wurde Routing auf Basis von Consistent Hashing eingesetzt
- Jede Anfrage an den Datendienst erhält einen Routing Key; bei Nachrichten ist dieser Routing Key die Channel-ID
- Da alle Anfragen desselben Channels an dieselbe Service-Instanz gehen, funktioniert die Request-Zusammenführung besser
- Wenn zum Beispiel auf einem großen Server eine
@everyone-Benachrichtigung ausgelöst wird, öffnen viele Nutzer die App und lesen dieselbe Nachricht, wodurch der Datenbank-Traffic stark ansteigen kann - In der vorherigen Architektur konnte eine solche Situation zu einer Hot Partition führen und einen Einsatz des Betriebsteams erforderlich machen; der Datendienst reduziert Traffic-Spitzen zur Datenbank jedoch deutlich
- Diese Verbesserung beseitigte Hot Partitions und Latenzen im Cassandra-Cluster nicht vollständig, verschaffte aber Zeit, um den neuen ScyllaDB-Cluster vorzubereiten und die Migration durchzuführen
Migration von Billionen Nachrichten
- Die Anforderungen an die Migration waren klar
- Billionen von Nachrichten mussten migriert werden
- Es durfte keine Downtime geben
- Da Cassandra weiterhin häufige Störungsbehebungen verursachte, musste die Migration schnell abgeschlossen werden
- Discord baute zunächst einen neuen ScyllaDB-Cluster mit Super-Disk Storage Topology auf
- Local SSDs sorgten für Geschwindigkeit
- RAID spiegelte die Daten auf Persistent Disks
- Die Architektur kombinierte die Geschwindigkeit lokaler Laufwerke mit der Haltbarkeit von Persistent Disks
- Der ursprüngliche Plan war, ab dem Cutover-Zeitpunkt neue Daten in ScyllaDB zu schreiben und historische Daten im Hintergrund zu migrieren
- Für neue Daten begann ein Dual Write nach Cassandra und ScyllaDB, während gleichzeitig der Spark Migrator von ScyllaDB vorbereitet wurde
- Der Spark Migrator erforderte umfangreiches Tuning; nach der Konfiguration lag die geschätzte Fertigstellungszeit bei 3 Monaten
- Danach erweiterte Discord seine bestehende schnelle Datenbankbibliothek und schrieb den Datenmigrator in Rust neu
- Er liest Token Ranges aus der Datenbank
- Er schreibt lokale Checkpoints in SQLite
- Er überträgt Daten massenhaft nach ScyllaDB
- Die geschätzte Fertigstellungszeit des neuen Rust-Migrators sank auf 9 Tage; diese Geschwindigkeit ermöglichte es, statt eines komplexen zeitbasierten Ansatzes die vollständige Umstellung in einem Schritt durchzuführen
Umstellung und Validierung
- Die Migration lief mit einer Spitzenrate von 3,2 Millionen Nachrichten pro Sekunde
- Der Fortschritt blieb bei 99,9999 % stehen, weil die letzten wenigen Token Ranges in Cassandra riesige, nicht compacted Tombstone-Bereiche enthielten
- Nachdem diese Token Ranges compacted worden waren, war die Migration wenige Sekunden später abgeschlossen
- Discord führte eine automatische Datenvalidierung durch, indem ein kleiner Anteil der Leseanfragen an beide Datenbanken geschickt und die Ergebnisse verglichen wurden; die Ergebnisse waren unauffällig
- Der ScyllaDB-Cluster hielt auch dem gesamten Produktions-Traffic gut stand, während Cassandra immer häufiger Latenzprobleme zeigte
- Das Team stellte ScyllaDB vor Ort als Primary Database um
Performance und Größenordnung nach der Umstellung
- Die Umstellung der Nachrichtendatenbank erfolgte im Mai 2022
- Der Betrieb war danach ruhig und stabil; es gab keine Wochenenden mehr, die mit Incident Response verbracht wurden, und keine ständigen Anpassungen von Cluster-Nodes, um die Uptime aufrechtzuerhalten
- Die Node-Zahl sank von 177 Cassandra-Nodes auf 72 ScyllaDB-Nodes
- Der Speicherplatz pro ScyllaDB-Node betrug 9 TB und war damit größer als der Durchschnitt von 4 TB pro Cassandra-Node
- Auch die Tail Latency verbesserte sich deutlich
- Abruf älterer Nachrichten, p99: Cassandra 40–125 ms → ScyllaDB 15 ms
- Einfügen von Nachrichten, p99: Cassandra 5–70 ms → ScyllaDB 5 ms
- Die Performance-Verbesserungen ermöglichten Discord, auf Basis des Vertrauens in die Nachrichtendatenbank neue Produkt-Use-Cases zu erschließen
Bestätigte Lastbewältigung beim World-Cup-Traffic
- Während der World Cup Ende 2022 weltweit verfolgt wurde, zeigten sich Spielszenen auch in Discords Graphen zum Nachrichtenversand
- Der Graph zum Nachrichtenversand während des World Cup Final zeigte mehrere Spikes, die Spielereignissen entsprachen
- Messis Elfmeter und Argentiniens 1:0-Führung
- Argentiniens weiterer Treffer
- Ein 15-minütiges Plateau während der Halbzeit
- Ein Spike, als Mbappé für Frankreich traf und 90 Sekunden später erneut traf, um auszugleichen
- Ende der regulären Spielzeit und Beginn der Verlängerung
- Chat zur Halbzeit der ersten Hälfte der Verlängerung
- Messis weiterer Treffer
- Mbappés Ausgleichstor
- Ende der Verlängerung und Beginn des Elfmeterschießens
- Frankreichs Fehlschuss und Argentiniens Sieg
- Auch bei stark erhöhtem Nachrichtenaufkommen bewältigten der Rust-basierte Datendienst und ScyllaDB den Traffic
- Das endgültige System wurde zu einer Architektur konsolidiert, die Billionen von Nachrichten verarbeiten kann
1 Kommentare
Hacker-News-Kommentare
Der Beitrag scheint Garbage Collection stark verantwortlich zu machen, aber wenn man sich den früheren Beitrag [0] ansieht, wirkt es eher wie eine Grenze der Art, wie Cassandra genutzt wurde, der Massenlöschungen in Cassandra – oder von beidem.
Ein Nutzer löschte per API Millionen von Nachrichten, sodass in einem Channel nur noch eine einzige Nachricht übrig blieb. Da Cassandra Löschungen als Tombstones behandelt, musste es beim Öffnen dieses Channels durch den Nutzer Millionen von Tombstones scannen, obwohl es tatsächlich nur eine Nachricht gab. Die Erklärung lautet, dass dabei schneller Garbage entstand, als die JVM ihn einsammeln konnte.
Außerdem ist von GC-Tuning die Rede, aber [1] zufolge wurde wohl nicht besonders viel getunt, und offenbar liefen Cassandra und vermutlich auch die JVM in älteren Versionen. Dass man gerade erst von CMS migriert war, ist ebenfalls ein wichtiger Punkt.
0) https://discord.com/blog/how-discord-stores-billions-of-messages
Selbst wenn sie die ursprüngliche Lösung falsch eingesetzt haben: Eine Lösung, die schwerer falsch einzusetzen ist, halte ich für besser.
Wenn sie 2022 Java 11 genutzt haben, war das eine vier Jahre alte Runtime; bei Java 8 sogar eine acht Jahre alte. Es ist also gut möglich, dass sie eine Menge Performance liegen gelassen haben.
Needs (2023)
Diese Service-Schicht sah aus wie ein großer, schicker verteilter Varnish Cache. Dass sie nicht von Caching sprechen, sondern das Wort „coalesce“ wählen, legt nahe, dass sie vermutlich nicht viel echtes Caching machen. Es erinnerte mich aber an Varnishs „grace mode“ und den Einsatz gegen Stampedes – also genau den Kontext, in dem ich zum ersten Mal von „Request Coalescing“ gehört habe: https://varnish-cache.org/docs/6.1/users-guide/vcl-grace.htm...
Außerdem freut es mich, dass Consistent Hashing immer wieder auftaucht. Das ist eine großartige Duct-Tape-Technik, deren Nützlichkeit sich in ähnlichen Situationen bewährt hat. Wenn man weiß, wo etwas liegen sollte, weiß auch jeder, wo er danach suchen muss.
proxy_cache_use_stale updating;Ein Mitgründer von ScyllaDB hat noch ein paar Punkte ergänzt: Discord konnte mit Cassandra Repair nicht abschließen, mit Scylla dagegen schon. Scylla hat mit Cassandra vieles gemeinsam, etwa LSM-Trees und Compaction, kann aber mit seinem eigenen CPU-/IO-Scheduler Queries eine höhere Priorität als Compaction geben.
Compaction kann auf eine freie halbe Millisekunde mit ausreichend ungenutzter Bandbreite verschoben werden; dazu gebe es auch viele Artikel. In Scylla gibt es einen sichereren, seit 1,5 Jahren existierenden Modus namens
tombstone_gc=repair, und die kürzlich veröffentlichte neue Architektur auf Basis von Raft und Tablets sei für Nutzer die nächste große Veränderung.Solche Probleme hätte es von vornherein nicht gegeben, wenn man IRC verwendet hätte, ein verteiltes Chat-Protokoll, das seit über 40 Jahren existiert.
Es hat außerdem den Vorteil einer offenen Spezifikation und mehrerer Implementierungen. Es ist auch kein ummauerter Garten. Wenn man IRC heute für zu veraltet hält, kann man sich Matrix oder XMPP ansehen. Es ist schwer zu verstehen, wie Discord die Oberhand gewinnen konnte; eigentlich ist es eher eine Tragödie.
IRC verlangt faktisch einen Bouncer, wenn man Konversationen über mehrere Geräte hinweg verfolgen will. Es verschlüsselt Nachrichten nicht und verschlüsselt optional nur die Verbindung zwischen Client und Server. Ohne Ende-zu-Ende-Verschlüsselung gibt es keine Privatsphäre gegenüber dem Server oder dessen Betreiber, und dieser Server ist ein leicht angreifbarer Single Point of Failure.
Das Matrix-Protokoll ist noch im Wandel, und Implementierungen halten mit der Spezifikation nicht Schritt. Wenn man nicht Element nutzt, hinkt man bei Funktionen und Sicherheit hinterher. Auch XMPP verlässt sich, wie IRC, bei grundlegenden Funktionen wie Ende-zu-Ende-Verschlüsselung auf optionale Erweiterungen, die von Clients möglicherweise nicht vollständig und korrekt unterstützt werden.
Ich empfehle, soatoks Analyse zu lesen: https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/14/security-issues-in-matrixs-ol...
Die Snowden-Enthüllungen von 2013 liegen 11 Jahre zurück. Ende-zu-Ende-Verschlüsselung sollte inzwischen eine Standardfunktion sein und wie eine Commodity behandelt werden; man sollte sie genauso hartnäckig einfordern, wie man HTTPS eingefordert hat. Natürlich implementiert Discord keine Ende-zu-Ende-Verschlüsselung.
Vor Kurzem ist eine sehr technische Gruppe, der ich angehöre, von Telegram zu Matrix gewechselt, und die User Experience ist nicht gut. Die App ist verbuggt und sieht auch nicht besonders gut aus; in der neuen „Element“-App wird SSO nicht unterstützt, sodass ich mein Konto nicht nutzen konnte. Für jemanden wie mich, der sich selbst hineinfuchst, sind das kleine Unannehmlichkeiten, aber ich könnte Freunde nicht davon überzeugen, es zu benutzen.
Man lädt die exe herunter, installiert sie, erstellt ein Konto, und es läuft sofort. Das kann jeder. Es gibt viel nützliche und großartige Software, aber das meiste davon ist für die breite Masse nicht einfach, und manches oder sogar vieles hat nicht einmal eine GUI. Die Leute verkaufen lieber ihre Identität und zahlen sogar Geld, statt zu viele Schritte ertragen zu müssen.
Das Fazit, das ich aus dem Artikel ziehe, könnte etwas anderes sein, als der Autor beabsichtigt hat.
„Das letzte? Unser Freund cassandra-messages. [...] Es war von Anfang an ein großer Cluster. Mit Billionen von Nachrichten und fast 200 Nodes musste jede Migration zwangsläufig eine komplexe Aufgabe sein.“
Angesichts der Größe von Discord wirken weniger als 200 Nodes für den Nachrichtenspeicher überraschend klein. Ich hätte eine komplexe Architektur erwartet, die auf deutlich schnellere Skalierung ausgelegt ist und mehr bewegliche Teile hat. Die tatsächliche Komplexität dürfte höher sein als im Artikel beschrieben, aber wenn ich an meine Erfahrung denke, bei der ich teilweise für über 200 physische Nodes verantwortlich war, die weniger leisteten, frage ich mich, wie stark moderne Cloud-Architekturen überdimensioniert sind.
Aus der Perspektive von jemandem, der mit einer deutlich kleineren Menge von Cassandra-Nodes Milliarden von Datensätzen gespeichert hat: Cassandra war im On-Call-Betrieb wirklich schmerzhaft und war die Ursache mehrerer größerer Ausfälle.
[0] https://news.ycombinator.com/item?id=34950843
Der Artikel ist sehr gut geschrieben. Es ist erfreulich, dass ein Teil der Lösung nicht darin bestand, etwas völlig anderes einzuführen, sondern auf ScyllaDB umzusteigen, das man wie einen Ersatz für Cassandra verwenden kann.
Discord macht es praktisch unmöglich, alte Nachrichten zu löschen. Ein Albtraum für den Datenschutz, und ich frage mich, warum die EU nicht eingeschritten ist.
Die Kernfrage läuft darauf hinaus, ob man Matrix eher wie E-Mail oder eher wie Facebook betrachten sollte. Wenn es E-Mail ist, wären Menschen entsetzt darüber, dass der Absender seine Nachricht aus meinem Mail-Spool löschen kann; wenn es Facebook ist, wären Menschen entsetzt darüber, dass ein Beitrag irgendwo noch sichtbar ist, nachdem man sein Löschrecht ausgeübt hat.
Um das zu lösen, braucht es eine Abwägung; beschrieben wird, dass man den Ansatz gewählt hat, zuerst zu überlegen, was der Geist der DSGVO eigentlich erreichen will.
https://matrix.org/blog/2018/05/08/gdpr-compliance-in-matrix...
Das Problem aus DSGVO-Sicht ist, dass Discord es schwer macht, diese zu löschen. Wenn die Absicht erkannt wird, Kontodaten zu löschen, wird man in Richtung „Anonymisierung“ gelenkt; öffentlich wird der Nutzername von den Nachrichten getrennt, aber man kann sie weiterhin einer bestimmten Person zuordnen. Wenn das serverseitig ebenfalls so gehandhabt wird, müsste man zur Durchsetzung eines Löschverlangens für personenbezogene Daten eines Nutzers riesige Mengen an Nachrichten durchsuchen oder alte Nachrichten massenhaft löschen.
Das EU-Parlament ist insofern kein echtes Parlament, als nur die Kommission neue Gesetze vorschlagen kann und das gewählte Parlament im Wesentlichen nur abstimmt; und die Kommission wird meiner Ansicht nach nicht von der Öffentlichkeit kontrolliert, sondern vom US-Außenministerium. Newsguard und die US-Big-Tech-Unternehmen außer Musk sowie Discord gehören zum selben politisch-finanziellen Establishment-Netzwerk und haben viele ehemalige Leute aus dem Außenministerium.
Ohne öffentlichen Zorn sind Institutionen auf EU-Ebene leicht zu vereinnahmen, und die öffentliche Meinung wird aus meiner Sicht ebenfalls von einem cyberpunkartigen Establishment kontrolliert, das LLMs mit illegalen Discord-Daten trainiert und Wahlwerbung gezielt ausspielt. Letztlich sollte man sich Sorgen machen, dass ein Orwell’scher Zustand entsteht, aus dem man aus einem dauerhaften Establishment nicht mehr herauskommt.
Allerdings halte ich das meiste davon im weiteren Sinne nur mit etwas mehr als 50 % Wahrscheinlichkeit für zutreffend, also sollte man es mit viel Vorsicht genießen.
Cassandra ist im Kern eher eine verteilte, fehlertolerante Hash-Tabelle, bei der überwiegend nur angehängt wird. Wenn man bei hohem Schreibdurchsatz genau so etwas braucht, ist es eine gute Wahl.
Ich verstehe nicht, warum Leute es wie eine Datenbank verwenden. Man stößt sehr schnell an Grenzen, und der Schmerz, es wie eine Datenbank benutzen zu wollen, wird mit zunehmender Skalierung nur schlimmer.
Damit ergibt es für mich als Nachrichtenspeicher eines Chat-Servers keinen Sinn. Es wirkt geeignet als Ziel für Log-Erfassung in verteilten Systemen, also wenn viele Clients Daten hineinkippen, aber man die Logs größtenteils nicht einmal auditieren muss und die Zahl der Lesezugriffe auf einen bestimmten Eintrag unter 1 liegt. Discord-Nachrichten sind offensichtlich nicht so.
Nach meiner Erfahrung habe ich noch kein Projekt gesehen, das mit Cassandra angefangen hat und es nach ungefähr einem Jahr noch weiterverwendet hat. Es dauert etwa ein Jahr, bis man an die Grenzen stößt, und am Ende ersetzt man es durch eine Datenbank wie Postgres.
Ich verstehe nicht, warum man nicht einfach sharden kann. Sind die einzelnen „Server“ von Discord nicht voneinander isoliert? Wenn sie sich gegenseitig keine Nachrichten schicken können, könnte man die Billionen von Nachrichten doch auf Tausende Shards aufteilen, sodass jeder Shard jeweils ein paar Milliarden verarbeitet?
„Das ScyllaDB-Team priorisierte die Verbesserungen und implementierte performante Reverse Queries, wodurch das letzte Datenbankhindernis im Migrationsplan beseitigt wurde“, heißt es.
Ich frage mich, wie viel sie dafür bezahlt haben, dass das erledigt wurde, noch bevor sie ScyllaDB überhaupt einsetzten.