Ознакомьтесь с этим документом, чтобы получить рекомендации по масштабированию вашего бессерверного приложения до уровня, превышающего тысячи операций в секунду или сотни тысяч одновременных пользователей. Этот документ содержит расширенные разделы, которые помогут вам глубоко понять систему. Если вы только начинаете работать с Cloud Firestore , обратитесь к руководству по быстрому запуску .
Cloud Firestore и мобильные/веб-SDK Firebase предоставляют мощную модель для разработки бессерверных приложений, где клиентский код напрямую обращается к базе данных. SDK позволяют клиентам отслеживать обновления данных в режиме реального времени. Вы можете использовать обновления в реальном времени для создания адаптивных приложений, не требующих серверной инфраструктуры. Хотя запустить приложение очень просто, полезно понимать ограничения систем, составляющих Cloud Firestore , чтобы ваше бессерверное приложение масштабировалось и хорошо работало при увеличении трафика.
В следующих разделах вы найдете советы по масштабированию вашего приложения.
Выберите местоположение базы данных, расположенное как можно ближе к вашим пользователям.
На следующей диаграмме представлена архитектура приложения реального времени:
Когда приложение, работающее на устройстве пользователя (мобильном или веб-приложении), устанавливает соединение с Cloud Firestore , это соединение перенаправляется на сервер Cloud Firestore расположенный в том же регионе , что и ваша база данных. Например, если ваша база данных находится в регионе us-east1 , соединение также направляется на сервер Cloud Firestore также расположенный в регионе us-east1 . Эти соединения являются долговременными и остаются открытыми до тех пор, пока приложение явно их не закроет. Сервер считывает данные из базовых систем хранения Cloud Firestore .
Расстояние между физическим местоположением пользователя и местоположением базы данных Cloud Firestore влияет на задержку, которую испытывает пользователь. Например, пользователь в Индии, чье приложение взаимодействует с базой данных в регионе Google Cloud в Северной Америке, может обнаружить, что работа приложения происходит медленнее, а скорость работы ниже, чем если бы база данных находилась ближе, например, в Индии или в другой части Азии.
Проектирование с учетом надежности
Следующие темы улучшают или влияют на надежность вашего приложения:
Включить автономный режим
SDK Firebase обеспечивают сохранение данных в автономном режиме. Если приложение на устройстве пользователя не может подключиться к Cloud Firestore , оно остается работоспособным, используя локально кэшированные данные. Это гарантирует доступ к данным даже при нестабильном интернет-соединении или полной потере доступа на несколько часов или дней. Более подробную информацию об автономном режиме см. в разделе «Включение автономных данных» .
Разберитесь с автоматическими повторными попытками.
SDK Firebase берут на себя повторные попытки выполнения операций и восстановление разорванных соединений. Это помогает обойти временные ошибки, вызванные перезапуском серверов или проблемами в сети между клиентом и базой данных.
Выберите между региональными и многорегиональными локациями.
При выборе между региональным и многорегиональным размещением данных приходится идти на компромиссы. Главное различие заключается в способе репликации данных. Это определяет гарантии доступности вашего приложения. Многорегиональный экземпляр обеспечивает более высокую надежность обслуживания и повышает отказоустойчивость данных, но платой за это является стоимость.
Разберитесь в системе обработки запросов в реальном времени.
Запросы в реальном времени, также называемые обработчиками снимков, позволяют приложению отслеживать изменения в базе данных и получать уведомления с низкой задержкой, как только данные изменятся. Приложение может получить тот же результат, периодически опрашивая базу данных на наличие обновлений, но это часто медленнее, дороже и требует больше кода. Примеры настройки и использования запросов в реальном времени см. в разделе «Получение обновлений в реальном времени» . В следующих разделах подробно рассматривается принцип работы обработчиков снимков и описываются некоторые лучшие практики масштабирования запросов в реальном времени при сохранении производительности.
Представьте себе двух пользователей, которые подключаются к Cloud Firestore через приложение для обмена сообщениями, созданное с использованием одного из мобильных SDK.
Клиент А записывает данные в базу данных для добавления и обновления документов в коллекции под названием chatroom :
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
Клиент B отслеживает обновления в той же коллекции, используя обработчик снимков. Клиент B получает немедленное уведомление всякий раз, когда кто-то создает новое сообщение. На следующей диаграмме показана архитектура обработчика снимков:
При подключении клиентом B обработчика снимков к базе данных происходит следующая последовательность событий:
- Клиент B устанавливает соединение с Cloud Firestore и регистрирует слушатель, вызывая метод
onSnapshot(collection("chatroom"))через SDK Firebase. Этот слушатель может оставаться активным в течение нескольких часов. - Интерфейс Cloud Firestore запрашивает данные у базовой системы хранения для инициализации набора данных. Он загружает весь набор результатов, соответствующих заданным документам. Мы называем это запросом на опрос . Затем система оценивает правила безопасности Firebase базы данных, чтобы убедиться, что пользователь имеет доступ к этим данным. Если пользователь авторизован, база данных возвращает ему данные.
- Затем запрос клиента B переходит в режим прослушивания . Прослушиватель регистрируется в обработчике подписок и ожидает обновления данных.
- Теперь клиент А отправляет операцию записи для изменения документа.
- База данных фиксирует изменения в документе в своей системе хранения.
- В транзакционном режиме система фиксирует это же обновление во внутреннем журнале изменений. Журнал изменений устанавливает строгий порядок внесения изменений по мере их появления.
- В свою очередь, список изменений распределяет обновленные данные между пулом обработчиков подписок.
- Обратный сопоставитель запросов проверяет, соответствует ли обновленный документ каким-либо зарегистрированным в данный момент обработчикам снимков. В этом примере документ соответствует обработчику снимков клиента B. Как следует из названия, обратный сопоставитель запросов можно рассматривать как обычный запрос к базе данных, но выполняемый в обратном порядке. Вместо поиска среди документов тех, которые соответствуют запросу, он эффективно ищет среди запросов те, которые соответствуют входящему документу. Найдя совпадение, система пересылает соответствующий документ обработчикам снимков. Затем система оценивает правила безопасности Firebase базы данных, чтобы гарантировать, что данные получат только авторизованные пользователи.
- Система пересылает обновление документа в SDK на устройстве клиента B, и срабатывает обратный вызов
onSnapshot. Если включено локальное сохранение данных, SDK также применяет обновление к локальному кэшу.
Ключевым элементом масштабируемости Cloud Firestore является распределение изменений от журнала изменений к обработчикам подписок и фронтенд-серверам. Это распределение позволяет эффективно распространять одно изменение данных для обработки миллионов запросов в реальном времени и обслуживания подключенных пользователей. Запуская множество реплик всех этих компонентов в нескольких зонах (или нескольких регионах в случае многорегионального развертывания), Cloud Firestore обеспечивает высокую доступность и масштабируемость.
Стоит отметить, что все операции чтения, выполняемые мобильными и веб-SDK, следуют описанной выше модели. Они выполняют запрос на опрос, за которым следует режим прослушивания для поддержания гарантий согласованности. Это также относится к слушателям в реальном времени, вызовам для получения документа и одноразовым запросам . Выполнение запросов на получение одного документа и одноразовых запросов можно рассматривать как кратковременные слушатели снимков, которые имеют аналогичные ограничения по производительности.
Применяйте лучшие практики масштабирования запросов в реальном времени.
Для проектирования масштабируемых запросов в режиме реального времени применяйте следующие передовые методы.
Разберитесь с высокой интенсивностью записи в системе.
Этот раздел поможет вам понять, как система реагирует на растущее число запросов на запись.
Журналы изменений Cloud Firestore , управляющие запросами в реальном времени, автоматически масштабируются горизонтально по мере увеличения объема записи. Когда скорость записи в базу данных превышает возможности одного сервера, журнал изменений распределяется между несколькими серверами, и обработка запросов начинает потреблять данные от нескольких обработчиков подписок вместо одного. С точки зрения клиента и SDK, все это происходит незаметно, и от приложения не требуется никаких действий при разделении. Следующая диаграмма демонстрирует масштабирование запросов в реальном времени:
Автоматическое масштабирование позволяет неограниченно увеличивать объем операций записи, но по мере роста трафика системе может потребоваться некоторое время для ответа. Следуйте рекомендациям правила 5-5-5 , чтобы избежать создания «горячих точек» записи. Key Visualizer — полезный инструмент для анализа таких точек.
У многих приложений наблюдается предсказуемый органический рост, с которым Cloud Firestore может справиться без каких-либо мер предосторожности. Однако пакетные операции, такие как импорт большого набора данных, могут привести к слишком быстрому увеличению объема операций записи. При проектировании приложения следите за тем, откуда поступает трафик записи.
Поймите, как взаимодействуют письмо и чтение.
Систему запросов в реальном времени можно рассматривать как конвейер, соединяющий операции записи с читателями. Каждый раз, когда документ создается, обновляется или удаляется, изменение распространяется из системы хранения к зарегистрированным в данный момент слушателям. Структура журнала изменений Cloud Firestore гарантирует строгую согласованность, что означает, что ваше приложение никогда не получит уведомления об обновлениях, которые не соответствуют порядку их внесения в базу данных. Это упрощает разработку приложений, устраняя нестандартные ситуации, связанные с согласованностью данных.
Такая взаимосвязанная структура означает, что операция записи, вызывающая «горячие точки» или конфликты блокировок, может негативно повлиять на операции чтения. Когда операции записи завершаются с ошибкой или происходит ограничение скорости, чтение может застопориться в ожидании согласованных данных из журнала изменений. Если это произойдет в вашем приложении, вы можете наблюдать как замедление операций записи, так и, как следствие, замедление времени отклика запросов. Избегание «горячих точек» — ключ к предотвращению этой проблемы.
Держите документы и операции по написанию текстов под контролем и оптимизируйте их объем.
При разработке приложений с обработчиками снимков состояния обычно требуется, чтобы пользователи быстро узнавали об изменениях данных. Для этого старайтесь создавать небольшие файлы. Система может очень быстро обрабатывать небольшие документы с десятками полей. Более крупные документы с сотнями полей и большим объемом данных обрабатываются дольше.
Аналогично, отдавайте предпочтение коротким и быстрым операциям фиксации и записи, чтобы минимизировать задержку. Большие пакеты могут обеспечить более высокую пропускную способность с точки зрения записи, но на самом деле могут увеличить время уведомления для обработчиков снимков. Это часто противоречит интуиции по сравнению с использованием других систем баз данных, где пакетная обработка может повысить производительность.
Используйте эффективных слушателей.
По мере увеличения скорости записи в вашу базу данных Cloud Firestore распределяет обработку данных между множеством серверов. Алгоритм шардинга Cloud Firestore пытается разместить данные из одной и той же коллекции или группы коллекций на одном и том же сервере журнала изменений. Система стремится максимизировать возможную пропускную способность записи, сводя к минимуму количество серверов, участвующих в обработке запроса.
Однако некоторые шаблоны могут по-прежнему приводить к неоптимальному поведению обработчиков снимков. Например, если ваше приложение хранит большую часть своих данных в одной большой коллекции, обработчику может потребоваться подключиться ко многим серверам, чтобы получить все необходимые данные. Это остается верным даже при применении фильтра запроса. Подключение ко многим серверам увеличивает риск замедления ответа.
Чтобы избежать замедления отклика, разработайте схему и приложение таким образом, чтобы система могла обслуживать слушателей без обращения к множеству разных серверов. Возможно, лучше всего будет разбить ваши данные на более мелкие коллекции с меньшей частотой записи.
Это похоже на анализ производительности запросов в реляционной базе данных, требующих полного сканирования таблиц. В реляционной базе данных запрос, требующий полного сканирования таблицы, эквивалентен обработчику снимков, отслеживающему коллекцию с высокой частотой изменений. Он может работать медленнее по сравнению с запросом, который база данных может обработать, используя более специфический индекс. Запрос с более специфическим индексом подобен обработчику снимков, отслеживающему отдельный документ или коллекцию, которая изменяется реже. Вам следует провести нагрузочное тестирование вашего приложения, чтобы лучше понять поведение и потребности вашего варианта использования.
Обеспечьте быструю обработку запросов на опрос.
Еще один ключевой аспект оперативных запросов в реальном времени — обеспечение быстроты и эффективности запроса на загрузку данных. При первом подключении нового обработчика снимков, он должен загрузить весь набор результатов и отправить его на устройство пользователя. Медленные запросы снижают отзывчивость приложения. Это включает, например, запросы, которые пытаются прочитать множество документов, или запросы, которые не используют соответствующие индексы.
При определенных обстоятельствах слушатель может также перейти из состояния прослушивания в состояние опроса. Это происходит автоматически и не заметно для SDK и вашего приложения. Следующие условия могут инициировать переход в состояние опроса:
- Система перераспределяет изменения в журнале событий в связи с изменениями нагрузки.
- Наличие «горячих точек» приводит к сбоям или задержкам при записи в базу данных.
- Временные перезапуски сервера временно влияют на работу слушателей.
Если ваши запросы на опрос выполняются достаточно быстро, состояние опроса становится незаметным для пользователей вашего приложения.
Отдавайте предпочтение слушателям, которые живут долго.
Открытие и поддержание активных обработчиков событий как можно дольше часто является наиболее экономически эффективным способом создания приложения, использующего Cloud Firestore . При использовании Cloud Firestore вы платите за документы, возвращаемые вашему приложению, а не за поддержание открытого соединения. Обработчик событий с длительным сроком действия считывает только те данные, которые необходимы для обработки запроса на протяжении всего своего жизненного цикла. Это включает в себя первоначальную операцию опроса, за которой следуют уведомления при фактическом изменении данных. С другой стороны, одноразовые запросы повторно считывают данные, которые могли не измениться с момента последнего выполнения запроса приложением.
В случаях, когда ваше приложение должно обрабатывать большой объем данных, обработчики снимков могут быть неуместны. Например, если ваш сценарий использования предполагает передачу множества документов в секунду через соединение в течение длительного периода времени, возможно, лучше выбрать одноразовые запросы, выполняемые с меньшей частотой.
Что дальше?
- Узнайте , как использовать обработчики снимков .
- Узнайте больше о передовых методах .