Ich bin dabei, eine Anwendung von Master / Slave nach HRD zu migrieren. Ich würde gerne einige Kommentare von denen hören, die die Migration bereits durchgemacht haben.
Ich habe ein einfaches Beispiel ausprobiert, um eine neue Entity ohne Vorgänger anzugeben und auf eine Seite umzuleiten, um alle Entitäten aus diesem Modell aufzulisten. Ich habe es mehrmals versucht und es war immer konsistent. Ihnen habe ich 500 indizierte Eigenschaften und wieder, immer konsistent ...
Ich war auch besorgt über einige Ansprüche von einem Limit von 1 Put () pro Entity-Gruppe pro Sekunde. Ich habe () 30 Entitäten mit demselben Vorfahren (dieselbe HTTP-Anfrage, aber put () eins nach dem anderen) und es war im Grunde kein Unterschied, 30 Entitäten ohne Vorfahren zu setzen. (Ich benutze NDB, könnte es eine Art von Optimierung tun?)
Ich habe das mit einer leeren App ohne Traffic getestet und frage mich, wie sehr ein echter Traffic die "mögliche Konsistenz" beeinflussen würde.
Ich bin mir bewusst, dass ich "eventuelle Konsistenz" bei der lokalen Entwicklung prüfen kann. Meine Frage ist:
Muss ich meine App wirklich neu strukturieren, um die Konsistenz zu gewährleisten?
Oder es wäre akzeptabel, es so zu belassen, wie es ist, weil die letztendliche Konsistenz tatsächlich in der Praxis für 99% konsistent ist?
Wenn Sie eine kleine App haben, leben Ihre Daten wahrscheinlich auf demselben Teil der gleichen Festplatte und Sie haben eine Instanz. Sie werden wahrscheinlich keine mögliche Konsistenz bemerken. Wenn Ihre App wächst, bemerken Sie mehr. Normalerweise dauert es Millisekunden, bis Konsistenz erreicht wird, aber ich habe Fälle gesehen, in denen es eine Stunde oder länger dauert.
Im Allgemeinen sind Abfragen, wo Sie es am meisten bemerken. Eine Möglichkeit, die Auswirkungen zu verringern, besteht darin, nur nach Schlüsseln zu suchen und anschließend ndb.get_multi () zum Laden der Entitäten zu verwenden. Durch das Holen von Entitäten nach Schlüsseln wird sichergestellt, dass Sie die neueste Version dieser Entität erhalten. Es kann jedoch nicht garantiert werden, dass die Schlüsselliste sehr konsistent ist. Sie könnten also Entitäten erhalten, die nicht mit den Abfragebedingungen übereinstimmen, also durchlaufen Sie die Entitäten und überspringen Sie diejenigen, die nicht übereinstimmen.
Nach dem, was ich bemerkt habe, wächst der Schmerz der Konsistenz allmählich, wenn deine App wächst. Irgendwann musst du es ernst nehmen und die kritischen Bereiche deines Codes aktualisieren, um damit umzugehen.
Was ist der schlimmste Fall, wenn Sie widersprüchliche Ergebnisse erhalten?
Sieht ein Benutzer unwichtige Informationen, die veraltet sind? Das ist wahrscheinlich in Ordnung.
Werden Sie etwas Wichtiges falsch berechnen, wie den Preis von etwas? Oder die Anzahl der Artikel in einem Geschäft auf Lager? In diesem Fall möchten Sie dieses zufällige Ereignis vermeiden.
Nur von der Beobachtung her scheint es, als würden sich letztendlich konsistente Ergebnisse zeigen, wenn Ihr Datensatz größer wird. Ich vermute, dass Ihre Daten auf mehrere Tablets verteilt sind.
Auch wenn Sie Ihre Entitäten mit get () - Anfragen nach Schlüssel / ID zurücklesen, wird es immer konsistent sein. Stellen Sie sicher, dass Sie eine Abfrage durchführen, um schließlich konsistente Ergebnisse zu erhalten.
Die Replikationsgeschwindigkeit wird hauptsächlich vom Server abhängig sein. In der Regel beträgt die Replikationsverzögerung bei einem unausgelasteten System Millisekunden.
Aber die Idee von "schließlich konsistent" ist, dass Sie Ihre App schreiben müssen, damit Sie sich nicht darauf verlassen; Jede Replikationsverzögerung muss innerhalb der Einschränkungen Ihrer Anwendung zulässig sein.
Tags und Links python google-app-engine app-engine-ndb