Кеширование: Cloud MemoryStore против Cloud Firestore против Realtime DB?

У меня есть небольшая коллекция (100 документов), которая будет периодически обновляться, скажем, каждые 5 минут. Какое решение поможет быстрее прочитать этот сборник? Firestore, Realtime DB или MemoryStore (чтение выполняется из приложения Firebase).

На самом деле я спрашиваю об этом, потому что где-то читал, что облачное хранилище данных использует кеш памяти в качестве прикрытия, и это заставило меня задуматься, есть ли у firestore такой вид кеширования; Если да, то почему бы не использовать memorystore напрямую.

Заранее благодарим за отзыв!




Ответы (1)


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

Cloud Memorystore совместим с протоколом Redis, что позволяет легко выполнять миграцию с нулевым изменением кода.

Для документов Firestore по-прежнему должен обеспечивать достаточную производительность без дополнительного кэширования ... если какое-либо кеширование имело бы смысл, то это было бы кеширование результатов запроса, кеширование результатов вычислений; например. из агрегации доменов SUM() и AVG(); там это определенно имело бы смысл.

person Martin Zeitler    schedule 24.09.2018
comment
Спасибо Мартину за ваш отзыв. Не могли бы вы указать на некоторую документацию о кешировании результатов запросов в firestore. Спасибо ! - person MBHA Phoenix; 25.09.2018
comment
@BlackPhoenix это далеко выходит за рамки этого вопроса - хотя вы даже не указали среду (язык) и не показали ни малейшей попытки решить какую-либо проблему с производительностью, которой у вас еще даже нет. кроме того, я имел в виду кеширование в MemoryStore, а не в Firestore (любое руководство по Redis должно показывать, как это работает, потому что его можно использовать для доступа к нему). - person Martin Zeitler; 25.09.2018