ИМХО, ваш конкретный контекст использования не так чувствителен к проблеме горячих точек , как вы думаете.
Эта проблема действительно применима, когда у вас очень высокая скорость чтения / записи в узкийдиапазон лексикографически близких документов - в вашем случае индекс расписания уведомлений на основе отметки времени.
Запись в индекс происходит при изменении расписаний.Как вы упомянули в комментариях, это не является большой проблемой, так как вы можете легко контролировать скорость таких обновлений.
Даже если вы время от времени получаете широко распространенные обновления расписаний, я бы также сообщил, что пики задержки обновления индекса из-за конфликтов в таких случаях не представляют особой проблемы: вы упомянули, что уведомления отправляются на несколько дней раньше срока -кого волнует, если такие уведомления задерживаются на несколько минут?Кроме того - на стороне чтения вы можете использовать keys_only запросов с последующим прямым поиском ключа для устранения возможной согласованности (которая будет чувствительна к задержкам при обновлении из-за конфликтов / индекса).
Что касается чтениясторона - у вас обычно есть одна операция чтения для индекса за один раз - запрос, получающий список уведомлений для отправки за один интервал.Как только задание получает список, к индексу обычно больше нет необходимости обращаться: задание просто планирует последующие задания, отвечающие за отправку уведомлений в списке (который может получить доступ к соответствующим объектам уведомлений, но не самому индексу!).Разумеется, я предполагаю, что вы будете удобно планировать эти задания запросов друг от друга.
Даже если вы используете курсоры для учета случаев, когда количество уведомлений в списке, возвращаемых запросомбудет слишком большим, чтобы обрабатывать его за один раз (для каждого используемого курсора потребуется воссоздать исходный контекст запроса, скорее всего, снова получить доступ к индексу) - вы можете разбивать такие операции, чтобы ограничить число одновременных операций или сделать их полностью не-overlapping.См. Как удалить все записи из хранилища данных Google? для примера такого ошеломления с использованием отложенных задач GAE (аналогичный подход возможен с использованием доступных в настоящее время более общих облачных задач , которыеподдержка запланированных раз в будущем).