My Geocode

Миграция

Пересопоставление кэшированных результатов после смены провайдера

· 3 мин чтения · My Geocode · #кэширование#планирование-миграции#геокодирование#целостность-данных#производительность

Кэширование это разумная и распространённая оптимизация для геокодирования, поскольку одни и те же адреса часто запрашиваются многократно и нет особого смысла каждый раз платить за новый запрос или ждать его. Но кэш, накопленный за месяцы или годы на результатах одного провайдера, создаёт при миграции особую проблему: что происходит со всеми этими кэшированными данными, когда меняется стоящий за ними провайдер.

Самая безопасная общая позиция такова: кэшированные результаты, привязанные к точности координат, правилам форматирования адресов или уверенности сопоставления конкретного провайдера, не следует молча считать равноценными результатам нового провайдера, даже если новый провайдер в целом точен. Точность координат, в частности, может незначительно различаться у разных провайдеров, и приложение, которое хранит кэшированные широту и долготу с несколькими знаками после запятой, может полагаться на характеристики точности, присущие именно тому провайдеру, который изначально выдал это число.

Несколько практических подходов, примерно в порядке возрастания тщательности:

  • Помечайте записи кэша провайдером-источником. Если ваш кэш ещё не записывает, какой провайдер выдал тот или иной результат, добавьте это поле до миграции, чтобы в дальнейшем отличать старые записи от новых, а не считать весь кэш единым неразличимым массивом
  • Задайте срок жизни для устаревших записей кэша. Вместо того чтобы сразу аннулировать весь кэш, что может вызвать внезапный всплеск живых запросов к новому провайдеру, позвольте старым записям естественно истечь по TTL, который ваш кэш уже использует, чтобы переход на свежие результаты нового провайдера происходил постепенно
  • Выборочно перепроверяйте особо ценные записи кэша. Для адресов, которые значат непропорционально много (основное место ведения бизнеса, часто используемый адрес доставки), стоит явно выполнить повторный запрос к новому провайдеру, а не ждать естественного истечения кэша, поскольку именно в этих записях незначительное расхождение будет заметнее всего

Поскольку результаты прямого геокодирования, в частности, могут различаться у разных провайдеров точным форматированием и точностью, в этом случае проверка значимой выборки ваших реальных кэшированных адресов на новом провайдере до полного перехода ценнее, чем проверка на синтетических или отобранных вручную тестовых адресах. Реальные кэшированные данные отражают ваши реальные сценарии использования, со всеми пограничными случаями.

Совместимые хосты My Geocode возвращают данные в той же структуре полей, что и исходный провайдер, поэтому код, который читает и сохраняет записи кэша по именам полей, не потребует переделки при миграции: для конкретного адреса у разных провайдеров могут немного различаться только сами значения. Заголовки квоты, присутствующие в каждом ответе, в том числе X-Quota-Used и X-Credits-Remaining, описанные на /docs/rate-limits/, тоже стоит учесть в плане аннулирования кэша, поскольку внезапная волна промахов кэша напрямую превращается во всплеск объёма запросов, а распределение этой волны с учётом вашей квоты является небольшой, но действительно полезной частью планирования миграции.

Если относиться к миграции кэша как к отдельному небольшому проекту, а не как к чему-то второстепенному, что произойдёт само собой после переключения провайдера, можно избежать целого класса незаметных проблем с качеством данных, которые гораздо сложнее диагностировать задним числом, чем предусмотреть заранее.

Ещё в разделе «Миграция»