Externe Daten bei jeder Anfrage einholen oder lokal speichern?

Question

Mein Team und ich arbeiten an einem Projekt, bei dem wir Daten von einer zentralen Quelle zu verschiedenen Client-Websites abrufen müssen.

Die Daten werden in JSON und der zentralen Quelle gespeichert, die auf Nodejs und MongoDB ausgeführt wird. Die Client-Sites sind meist Wordpress (einige andere Drittanbieter-CMS) und laufen daher auf PHP und MySQL.

Die Art und Weise, wie wir es eingerichtet haben, besteht darin, bei jeder Anfrage die Daten (Immobilien-Listings) aus der zentralen Datenbank abzurufen und wie normales HTML anzuzeigen.

Ich bin besorgt, dass dies ressourcenintensiv sein wird und eine langsamere Lösung sein wird, angesichts der Tatsache, dass externe Daten nach jeder Anfrage gesucht und abgerufen werden müssen.

Meine Frage ist: Ist das eine ideale Lösung? Was wäre besser?

Mein erster Gedanke war, eine Push/Store-Lösung zu entwickeln, bei der die zentrale Quelle die Daten, die sie gesammelt haben, ausschleust und lokal auf jeder Client-Site speichert. Aber das würde offensichtlich eine Art von Datenbankinfrastruktur auf jedem Client erfordern, was es wahrscheinlich komplizierter macht als nötig.

Gedanken?

Answer 1

Eine zentrale Datenquelle ist nicht schlecht, wenn sie im selben Netzwerk ist und nicht viel Overhead verursacht. Sie müssen einen Test ausführen, um sicherzustellen, dass die Anrufe von den meisten Clients ähnliche Antwortzeiten haben. Wenn der Zugriff kein Problem ist, kann die zentrale Datenbank so viele Clients parallel verwalten, dass eine zentrale Datenbank sinnvoll ist.

Nachteil ist, dass es einen einzigen Fehlerpunkt macht. Wenn es scheitert, gehen alle Websites unter. Wenn die Last erhöht wird, verschlechtert sich die Leistung auf allen Knoten, wenn sie nicht richtig abgestimmt wird.

Ich werde ein verteiltes Modell vorschlagen.Sie benötigen jeden Tag einen Pull-Job, um Daten einmal außerhalb der Geschäftszeiten zu holen und lokal auf jedem Client zu speichern. Daher benötigen Sie möglicherweise einen DBA, der Ihnen dabei hilft. Sie müssen sich die Datengröße und die Zeit ansehen, die benötigt wird, um die Daten zu aktualisieren, um sicherzustellen, dass sie schnell beendet werden. Die Website muss während dieser Zeit nicht heruntergefahren werden. Außerdem können verschiedene Clients bei Bedarf zu unterschiedlichen Zeiten aktualisiert werden.

Ich hatte eine ähnliche Situation, in der mein Team DB zu DB-Replikation über einen Batch-Job verwendet, die jeden Tag außerhalb der Geschäftszeiten ausgeführt wird (wir nehmen nur modifizierte/hinzugefügte Datensätze für die Replikation, um die Größe der Datenaktualisierung zu reduzieren) Logik basierend auf Ihrem Datensatz).

Soweit Client komplex wird, ich glaube nicht, dass es eine große Änderung in der Komplexität aus Coding Perspektive machen wird. Ihr Frontend wird sich nicht ändern, nur der Aufruf von Daten (wahrscheinlich ein Webservice) wird Daten von der DB anstatt vom zentralen Datenspeicher erhalten.

Ich werde vorschlagen, eine Abstraktionsschicht zu behalten, Daten über eine Schnittstelle holen, die 2 Implementierungen haben sollte, eine, die Daten vom zentralen Datenspeicher erhält und eine, die vom lokalen Datenspeicher erhält. Auf diese Weise können Sie leicht austauschen. Also ja, marginal mehr Arbeit, aber keine signifikante Zunahme der Komplexität.

Eine letzte Sache zu berücksichtigen ist Überwachungspflicht. Wir hatten Probleme, bei denen die Replikation manchmal fehlschlägt und erneut manuell ausgelöst werden muss. Dies sollte bei der lokalen DB berücksichtigt werden. Sie müssen diese Überlegung vor der Bereitstellung einer solchen Architektur prüfen. Dieser Ansatz ist teurer, da Sie mehr Datenbanken und möglicherweise einen DBA benötigen, um sie zu überwachen.