Irgendwie unvollständig

[mucpower]

Wie funktioniert die NoSQL DB ? Ist das ein Share auf das die ganzen Clusterknoten gemeinsam mit einem ClusterFS drauf zugreifen ? Läuft nur ein DB Server irgendwo oder mehrere und wie wird da synchronisiert bzw. gelocked ?
Wieviel und was wird da gecached ?
Da der Cache lokal ist - wie funktioniert das mit mehr als einem Cache ? Was ist, wenn die lokalen SSDs ausfallen bzw. die VM ? Steckt hiner Discord nur eine VM ?
Irgendwie erschließt sich mir die Architektur anhand des Artikels nicht und somit kann ich auch nicht beurteilen, ob das eine gute oder halbgute Idee ist bzw. nur ein workaround für Google-Probleme.

[MarcusK]

mucpower schrieb:
--------------------------------------------------------------------------------
> Wie funktioniert die NoSQL DB ? Ist das ein Share auf das die ganzen
> Clusterknoten gemeinsam mit einem ClusterFS drauf zugreifen ? Läuft nur ein
> DB Server irgendwo oder mehrere und wie wird da synchronisiert bzw.
> gelocked ?
> Wieviel und was wird da gecached ?
> Da der Cache lokal ist - wie funktioniert das mit mehr als einem Cache ?
> Was ist, wenn die lokalen SSDs ausfallen bzw. die VM ? Steckt hiner
> Discord nur eine VM ?
> Irgendwie erschließt sich mir die Architektur anhand des Artikels nicht und
> somit kann ich auch nicht beurteilen, ob das eine gute oder halbgute Idee
> ist bzw. nur ein workaround für Google-Probleme.

+1

[m03p]

Da wir bei uns auf der Arbeit einen ähnlichen Stack haben kann ich ein zwei sachen ergänzen/beantworten:
Discord nutzt eine verteilte NoSQL-Datenbank namens ScyllaDB, dabei hat man mehrere (typischerweise recht viele also gerne mal 30-40 und mehr) einzelne Datenbankserver (Nodes) die jeweils lokalen storage besitzen, diese sind jeweils gleichwertig, es gibt keinen master oder etwas ähnliches. Die nodes koordinieren sich untereinander und verteilen bzw replizieren die daten sodass eine gleichmäßige Verteilung aufrecht erhalten wird und gewisse redundanzkriterien erfüllt werden. Dafür legt man einen sogenannten replication-factor fest, bei RF=3 wird dann zb jeder Eintrag auf mindestens 3 nodes gespeichert etc. Die Verteilung erfolgt dabei über hashwerte der keys, somit ist von vorne herein definiert welcher node für eine Anfrage zuständig ist und auf welche anderen nodes etwaige Änderungen repliziert werden müssen. Explizites globales locking gibt es dabei nicht direkt, es wird eher auf "eventual consistency" gesetzt, dh es wird kurzzeitig ein potentiell inkonsistenter zustand akzeptiert. Wird ein neuer node hinzugefügt oder ein bestehender ersetzt, zb aufgrund von hardwareversagen, dann wird entsprechendes rebalancing betrieben bis der gewünschte RF erreicht ist.

Zum thema caching: so wie ichs verstanden hab hat jeder node ein RAID1 zwischen einer lokalen SSD und einer (im netzwerk eingebundenen) persistent disk, effektiv gesehen wird also der gesamte storage gecached.

[jhi (Golem.de)]

Damit ist schon alles gesagt was ich auch hätte dazu schreiben können, danke.

Es wird auch, genau wie beschrieben, der gesamte Speicher lokal mit den SSDs gecached. Und ja, effektiv ist das ein Workaround für die Einschränkungen, die Googles Angebot mitbringt.

Johannes Hiltscher
(Golem.de)