Автоматическое обновление до Cloud Firestore, как насчет запросов-предков и групп сущностей?

#google-app-engine #google-cloud-platform #google-cloud-datastore #datastore

#google-app-engine #google-облачная платформа #google-облачное хранилище данных #хранилище данных

Вопрос:

Об объявлении автоматического обновления до Cloud Firestore для проектов хранилища данных Google.

Преимущества, в том числе:

  • Запросы в конечном итоге больше не являются согласованными; вместо этого все они строго согласованы.
  • Транзакции больше не ограничены 25 группами сущностей.
  • Операции записи в группу объектов больше не ограничены частотой 1 в секунду.

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

Что произойдет со всей этой логикой приложения и структурой данных БД, когда она будет автоматически перенесена в Firestore? Поскольку данные будут строго согласованы, похоже, больше не будет необходимости в группах сущностей и запросах-предках! …Если не используется внутри межгрупповой транзакции для атомарного поведения между несколькими сущностями

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

Ответ №1:

Моя интерпретация объявления в вашем контексте:

  • Ваши существующие межгрупповые транзакции не затрагивают более 25 групп сущностей из-за текущего ограничения. Снижение лимита на 25 групп не окажет на них никакого влияния, они должны продолжать работать по-прежнему
  • запросы-предки по-прежнему поддерживаются
  • структурирование / группировка ваших данных в группах сущностей по-прежнему поддерживается, независимо от причины, стоящей за этим. Возможно, ваше конкретное разделение было вызвано текущими ограничениями — миграция может устранить эту причину, но не более того.

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

В целом я полагаю, что все существующие приложения останутся незатронутыми, иначе Google не стал бы выполнять обновления автоматически — они просто уведомили бы владельцев приложений о внесении необходимых изменений к определенной дате с руководством по миграции на месте — как они делали с другими изменениями, не совместимыми с обратной связью.

Комментарии:

1. Спасибо @Dan, всегда рад видеть ваши комментарии и ответы :). Я обеспокоен тем, что сохранение структуры предков может фактически снизить производительность в дальнейшем! Поскольку на данный момент группа сущностей выросла ( к сожалению! ), чтобы преодолеть некоторые ситуации, когда требуется строгая согласованность, которая больше не потребуется после автоматического обновления. Кроме того, известно ли вам о каких-либо объявлениях о том, когда ожидается завершение всей миграции?

2. Затем я бы начал рассматривать реальную миграцию. Но сначала я бы провел несколько параллельных сравнений производительности (документы — это mum wrt performance) — все еще в моем списке задач, поскольку аналогичная задача предстоит и моим приложениям. Я не видел никаких дат.