Ich arbeite an einer Webanwendung, die in der Vergangenheit auf einem PHP / MySQL-Stack aufgebaut war.
Eine der Schlüsseloperationen der Anwendung musste einige schwere Berechnungen durchführen, die eine Iteration über jede Zeile einer ganzen DB-Tabelle erforderten. Unnötig zu sagen, dass dies ein ernsthafter Engpass war. Also wurde eine Entscheidung getroffen, den gesamten Prozess in Java neu zu schreiben.
Dies gab uns zwei Vorteile. Erstens war Java als Sprache viel schneller als ein PHP-Prozess. Der zweite war, dass wir den gesamten Datensatz im Speicher des Java-Anwendungsservers verwalten konnten. Jetzt können wir die rechenintensiven Operationen im Speicher ausführen und alles geschieht viel schneller.
Das hat eine Weile funktioniert, bis wir gemerkt haben, dass wir skalieren müssen, also brauchen wir jetzt mehr Webserver.
Das Problem ist, dass alle nach dem aktuellen Design den exakt gleichen Zustand beibehalten müssen. Sie alle fragen die Datenbank ab, verarbeiten die Daten und speichern sie im Speicher. Aber was passiert, wenn Sie diese Daten ändern müssen? Wie erhalten alle Server Konsistenz?
Diese Architektur scheint mir fehlerhaft zu sein. Der Leistungsvorteil, alle Daten im Speicher zu halten, liegt auf der Hand, aber dies erschwert die Skalierbarkeit erheblich.
Was sind die Möglichkeiten von hier? Zu einem In-Memory, Schlüssel-Wert, Datenspeicher wechseln? Sollten wir den Zustand innerhalb der Webserver vollständig aufgeben?
wechseln Sie jetzt zu Erlang: -)
Ja, das ist ein Witz; aber da ist ein Körnchen Wahrheit. Das Problem ist: Sie hatten Ihren Zustand ursprünglich in einem externen, gemeinsamen Repository: der DB. Jetzt haben Sie es (teilweise) in einem internen, nicht freigegebenen Repository vorberechnet: Java RAM-Objekte. Der naheliegende Weg ist, dass es immer noch vorausberechnet ist, aber in einem externen gemeinsamen Repository, je schneller, desto besser.
Eine einfache Antwort ist memcached.
Ein anderer ist es, einen eigenen 'Calc-Server' zu erstellen, der sowohl die Berechnungsaufgabe als auch die (Teil-) Ergebnisse zentralisiert. Die Web-Frontend-Prozesse greifen nur auf diesen Server zu. In Erlang wäre das der natürliche Weg. In anderen Sprachen können Sie es tun, nur mehr Arbeit. Überprüfen Sie ZeroMQ für Inspiration, auch wenn Sie es am Ende nicht verwenden (aber es ist eine verdammt gute Umsetzung).
Dies kann ein Klischee sein, aber die Daten werden immer erweitert, um den Platz zu füllen, in den Sie sie eingefügt haben. Ihre Daten könnten heute alle in den Speicher passen, aber ich garantiere Ihnen, dass sie das irgendwann nicht mehr tun werden. Wie weit das ist, ist der Zeitrahmen, in dem Sie eine bessere Architektur finden müssen. Die Aussagekraft Ihrer Bewerbung ist nur ein Symptom für dieses größere Problem.
Werden alle Berechnungen für den gesamten Datensatz durchgeführt? Ist das etwas, was Sie in einer Charge über Nacht tun können und tagsüber Zugang haben? Wie zeitempfindlich ist das?
Ich denke, das sind die Fragen, die Sie beantworten müssen, weil Sie irgendwann nicht genug Speicher kaufen können, um die Daten zu speichern, die Sie brauchen. Das hört sich vielleicht albern an, wo du jetzt bist, aber du solltest planen, dass das wahr ist. Viele Entwickler, mit denen ich gesprochen habe, denken nicht darüber nach, wie Erfolg aussieht und welche Auswirkungen sie auf ihre Designs hat.
Ich stimme Ihnen zu - das klingt fehlerhaft, aber ich brauche mehr Details, um es sicher zu wissen.
Sie erwähnen einen großen Datensatz und schwere Berechnungen, aber Sie sprechen nicht darüber, wie die Daten aktualisiert werden, wann die Berechnungen durchgeführt werden, ob es sich um Daten eines Tages oder den gesamten Datensatz usw. handelt viel wie ein Batch-Job, der täglich offline erledigt werden konnte.
Wenn das der Fall ist, bin ich mir nicht sicher, wo das Internet dran hängt. Führen Ihre Webbenutzer nach dem Knirschen nur benutzerdefinierte Abfragen aus? Sind die Daten schreibgeschützt oder nur für Benutzer lesbar? Oder ändern sie die Daten ständig im laufenden Betrieb?
Ich frage mich, ob die von Ihnen gewählte Persistenztechnologie die Dinge beeinflusst? Vielleicht könnte eine NoSQL-Alternative für Ihr Problem besser sein - wie ein verteilter MongoDB-Cluster.
Das ist, glaube ich, sowohl eine Daten-Engine-Frage als auch eine Webserver-Verteilungsfrage. Warum kann Ihre (zentrale) Datenbank-Engine die Berechnung nicht (schnell genug) durchführen?
Sie könnten vorberechnete Werte speichern, die als veraltet gekennzeichnet sind, wenn die zugrunde liegenden Daten geändert werden, was eine Neukalibrierung erfordert. Es gibt keine Notwendigkeit, neu zu berechnen, wenn sich Daten ändern. Sie müssen nur verwalten, wann und wie die Änderung auftritt, da dies Auswirkungen auf die Benutzer der Daten hat.
Tags und Links web-applications architecture scalability