My Geocode

Migration

Gecachte Ergebnisse nach einem Anbieterwechsel neu zuordnen

· 3 Min. Lesezeit · My Geocode · #caching#migration-planning#geocoding#data-integrity#performance

Caching ist eine sinnvolle und verbreitete Optimierung bei der Geokodierung, da dieselben Adressen oft wiederholt abgefragt werden und es wenig Grund gibt, jedes Mal für eine neue Abfrage zu bezahlen oder auf sie zu warten. Ein Cache, der über Monate oder Jahre mit den Ergebnissen eines Anbieters aufgebaut wurde, schafft bei einer Migration jedoch ein bestimmtes Problem: Was passiert mit all diesen zwischengespeicherten Daten, sobald sich der Anbieter dahinter ändert?

Die sicherste allgemeine Haltung ist, dass zwischengespeicherte Ergebnisse, die an die Koordinatengenauigkeit, die Konventionen der Adressformatierung oder die Match-Konfidenz eines bestimmten Anbieters gebunden sind, nicht stillschweigend als gleichwertig mit Ergebnissen eines neuen Anbieters behandelt werden sollten, selbst wenn der neue Anbieter im Allgemeinen genau ist. Besonders die Koordinatengenauigkeit kann sich zwischen Anbietern subtil unterscheiden, und eine Anwendung, die zwischengespeicherte Breiten- und Längengrade mit mehreren Nachkommastellen speichert, verlässt sich möglicherweise auf Genauigkeitsmerkmale, die für den Anbieter spezifisch sind, der diese Zahl ursprünglich geliefert hat.

Einige praktische Ansätze, grob nach zunehmender Gründlichkeit geordnet:

  • Kennzeichnen Sie Cache-Einträge mit ihrem Quellanbieter. Wenn Ihr Cache noch nicht erfasst, welcher Anbieter ein bestimmtes zwischengespeichertes Ergebnis geliefert hat, fügen Sie dieses Feld vor der Migration hinzu, damit Sie künftig alte und neue Einträge unterscheiden können, statt den gesamten Cache als einen undifferenzierten Pool zu behandeln
  • Legen Sie ein Ablaufdatum für alte Cache-Einträge fest. Statt den gesamten Cache auf einmal zu invalidieren, was einen plötzlichen Anstieg an Live-Anfragen beim neuen Anbieter verursachen kann, lassen Sie alte Einträge auf natürliche Weise nach der TTL ablaufen, die Ihr Cache bereits verwendet, sodass der Übergang zu frischen Ergebnissen des neuen Anbieters schrittweise erfolgt
  • Überprüfen Sie wichtige Cache-Einträge gezielt neu. Bei Adressen, die überproportional wichtig sind, etwa ein Hauptgeschäftsstandort oder eine häufig genutzte Lieferadresse, lohnt sich eine ausdrückliche erneute Abfrage beim neuen Anbieter, statt auf den natürlichen Ablauf des Caches zu warten, denn bei diesen Einträgen würde eine subtile Abweichung am ehesten auffallen

Da gerade die Ergebnisse der Geokodierung von Adressen zu Koordinaten in exakter Formatierung und Genauigkeit zwischen Anbietern variieren können, ist es hier wertvoller, vor dem vollständigen Wechsel eine aussagekräftige Stichprobe Ihrer tatsächlich zwischengespeicherten Adressen beim neuen Anbieter zu testen, als mit synthetischen oder handverlesenen Testadressen zu arbeiten. Echte Cache-Daten spiegeln Ihre echten Nutzungsmuster wider, samt aller Sonderfälle.

Die Kompatibilitäts-Hosts von My Geocode liefern Daten in derselben Feldstruktur wie der ursprüngliche Anbieter, sodass Code, der Cache-Einträge nach Feldnamen liest und speichert, bei einer Migration nicht umstrukturiert werden muss; nur die Werte selbst können sich für eine bestimmte Adresse zwischen Anbietern leicht unterscheiden. Die Kontingent-Header in jeder Antwort, darunter X-Quota-Used und X-Credits-Remaining, dokumentiert unter /docs/rate-limits/, sollten ebenfalls in einen Plan zur Cache-Invalidierung einfließen, denn eine plötzliche Welle von Cache-Misses führt direkt zu einem Anstieg des Anfragevolumens, und diese Welle auf Ihr Kontingent abzustimmen, ist ein kleiner, aber wirklich nützlicher Teil der Migrationsplanung.

Wer die Cache-Migration als eigenes kleines Projekt behandelt und nicht als Nebensache, die automatisch passiert, sobald der Anbieterwechsel live ist, vermeidet eine ganze Klasse subtiler Datenqualitätsprobleme, die sich im Nachhinein viel schwerer diagnostizieren als im Voraus einplanen lassen.

Mehr zu Migration