Прочитайте этот документ, чтобы получить руководство по масштабированию вашего бессерверного приложения за пределы тысяч операций в секунду или сотен тысяч одновременных пользователей. Этот документ содержит расширенные темы, которые помогут вам глубже понять систему. Если вы только начинаете работать с Cloud Firestore , вместо этого ознакомьтесь с руководством по быстрому старту .
Cloud Firestore и Firebase mobile/web SDK предоставляют мощную модель для разработки бессерверных приложений, где клиентский код напрямую обращается к базе данных. SDK позволяют клиентам прослушивать обновления данных в режиме реального времени. Вы можете использовать обновления в режиме реального времени для создания адаптивных приложений, не требующих серверной инфраструктуры. Хотя очень легко что-то запустить, полезно понимать ограничения в системах, из которых состоит Cloud Firestore , чтобы ваше бессерверное приложение масштабировалось и работало хорошо при увеличении трафика.
Советы по масштабированию вашего приложения см. в следующих разделах.
Выберите расположение базы данных, близкое к местоположению ваших пользователей.
На следующей диаграмме показана архитектура приложения реального времени:
Когда приложение, работающее на устройстве пользователя (мобильном или веб-устройстве), устанавливает соединение с Cloud Firestore , соединение направляется на сервер фронтенда Cloud Firestore в том же регионе , где расположена ваша база данных. Например, если ваша база данных находится в us-east1 , соединение также идет на сервер фронтенда Cloud Firestore также в us-east1 . Эти соединения являются долгосрочными и остаются открытыми до тех пор, пока приложение явно не закроет их. Фронтенд считывает данные из базовых систем хранения Cloud Firestore .
Расстояние между физическим местоположением пользователя и местоположением базы данных Cloud Firestore влияет на задержку, которую испытывает пользователь. Например, пользователь в Индии, чье приложение взаимодействует с базой данных в регионе Google Cloud в Северной Америке, может обнаружить, что работа приложения замедлилась, а работа приложения оказалась менее быстрой, чем если бы база данных находилась ближе, например, в Индии или в другой части Азии.
Надежный дизайн
Следующие темы улучшают или влияют на надежность вашего приложения:
Включить автономный режим
Firebase SDKs обеспечивают сохранение данных в автономном режиме. Если приложение на устройстве пользователя не может подключиться к Cloud Firestore , приложение остается пригодным для использования, работая с локально кэшированными данными. Это обеспечивает доступ к данным, даже если пользователи испытывают нестабильные интернет-соединения или полностью теряют доступ на несколько часов или дней. Более подробную информацию об автономном режиме см. в разделе Включение автономных данных .
Понимание автоматических повторных попыток
Firebase SDKs заботятся о повторных попытках операций и восстановлении разорванных соединений. Это помогает обойти временные ошибки, вызванные перезапуском серверов или сетевыми проблемами между клиентом и базой данных.
Выбирайте между региональным и многорегиональным расположением
При выборе между региональным и мультирегиональным расположением есть несколько компромиссов. Главное отличие заключается в том, как реплицируются данные. Это определяет гарантии доступности вашего приложения. Мультирегиональный экземпляр обеспечивает более высокую надежность обслуживания и увеличивает долговечность ваших данных, но компромисс заключается в стоимости.
Понять систему запросов в реальном времени
Запросы в реальном времени, также называемые прослушивателями снимков, позволяют приложению прослушивать изменения в базе данных и получать уведомления с малой задержкой, как только данные изменятся. Приложение может получить тот же результат, периодически опрашивая базу данных на предмет обновлений, но это часто медленнее, дороже и требует больше кода. Примеры настройки и использования запросов в реальном времени см. в разделе Получение обновлений в реальном времени . В следующих разделах подробно описывается, как работают прослушиватели снимков, и описываются некоторые из лучших практик для масштабирования запросов в реальном времени с сохранением производительности.
Представьте себе двух пользователей, которые подключаются к 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"))через Firebase SDK. Этот слушатель может оставаться активным в течение нескольких часов. - Интерфейс Cloud Firestore запрашивает базовую систему хранения для загрузки набора данных. Он загружает весь результирующий набор соответствующих документов. Мы называем это запросом на опрос . Затем система оценивает правила безопасности Firebase базы данных, чтобы убедиться, что пользователь может получить доступ к этим данным. Если пользователь авторизован, база данных возвращает данные пользователю.
- Затем запрос клиента B переходит в режим прослушивания . Прослушиватель регистрируется в обработчике подписки и ждет обновлений данных.
- Клиент А теперь отправляет операцию записи для изменения документа.
- База данных фиксирует изменение документа в своей системе хранения.
- Транзакционно система фиксирует то же самое обновление во внутреннем журнале изменений. Журнал изменений устанавливает строгий порядок изменений по мере их возникновения.
- Журнал изменений, в свою очередь, распространяет обновленные данные среди пула обработчиков подписок.
- Обратный сопоставитель запросов выполняется, чтобы проверить, соответствует ли обновленный документ зарегистрированным в данный момент прослушивателям снимков. В этом примере документ соответствует прослушивателю снимков клиента B. Как следует из названия, вы можете думать об обратном сопоставителе запросов как об обычном запросе к базе данных, но выполненном в обратном порядке. Вместо того чтобы искать в документах те, которые соответствуют запросу, он эффективно ищет в запросах те, которые соответствуют входящему документу. После обнаружения соответствия система пересылает рассматриваемый документ прослушивателям снимков. Затем система оценивает правила безопасности Firebase базы данных, чтобы гарантировать, что только авторизованные пользователи получат данные.
- Система пересылает обновление документа в SDK на устройстве клиента B, и срабатывает обратный вызов
onSnapshot. Если включено локальное сохранение, SDK также применяет обновление к локальному кэшу.
Ключевая часть масштабируемости Cloud Firestore зависит от разветвления от журнала изменений до обработчиков подписок и серверов frontend. Разветвление позволяет эффективно распространять одно изменение данных для обслуживания миллионов запросов в реальном времени и подключенных пользователей. Запуская множество реплик всех этих компонентов в нескольких зонах (или нескольких регионах в случае многорегионального развертывания), Cloud Firestore достигает высокой доступности и масштабируемости.
Стоит отметить, что все операции чтения, выполненные с помощью мобильных и веб-SDK, следуют модели, описанной выше. Они выполняют запрос опроса, за которым следует режим прослушивания для обеспечения гарантий согласованности. Это также относится к прослушивателям в реальном времени, вызовам для извлечения документа и одноразовым запросам . Вы можете рассматривать извлечение отдельных документов и одноразовые запросы как кратковременные прослушиватели снимков, которые имеют схожие ограничения по производительности.
Применяйте лучшие практики для масштабирования запросов в реальном времени
Применяйте следующие передовые методы для разработки масштабируемых запросов в реальном времени.
Понимание большого трафика записи в системе
Этот раздел поможет вам понять, как система реагирует на растущее количество запросов на запись.
Журналы изменений Cloud Firestore , которые управляют запросами в реальном времени, автоматически масштабируются горизонтально по мере увеличения трафика записи. По мере того, как скорость записи для базы данных превышает возможности одного сервера, журнал изменений разделяется между несколькими серверами, и обработка запросов начинает потреблять данные из нескольких обработчиков подписок вместо одного. С точки зрения клиента и SDK все это прозрачно, и никаких действий со стороны приложения не требуется, когда происходит разделение. Следующая диаграмма демонстрирует, как масштабируются запросы в реальном времени:
Автоматическое масштабирование позволяет вам увеличивать трафик записи без ограничений, но по мере увеличения трафика системе может потребоваться некоторое время для ответа. Следуйте рекомендациям правила 5-5-5 , чтобы избежать создания точек доступа записи. Key Visualizer — полезный инструмент для анализа точек доступа записи.
Многие приложения имеют предсказуемый органический рост, который Cloud Firestore может обеспечить без мер предосторожности. Однако пакетные рабочие нагрузки, такие как импорт большого набора данных, могут слишком быстро увеличивать объемы записи. При проектировании приложения следите за тем, откуда поступает трафик записи.
Понять, как взаимодействуют записи и чтения
Вы можете представить себе систему запросов в реальном времени как конвейер, соединяющий операции записи с читателями. Каждый раз, когда документ создается, обновляется или удаляется, изменение распространяется из системы хранения к зарегистрированным в данный момент слушателям. Структура журнала изменений Cloud Firestore гарантирует сильную согласованность, что означает, что ваше приложение никогда не получает уведомлений об обновлениях, которые не соответствуют порядку, когда база данных зафиксировала изменения данных. Это упрощает разработку приложений, устраняя пограничные случаи вокруг согласованности данных.
Этот подключенный конвейер означает, что операция записи, вызывающая горячие точки или конфликт блокировок, может негативно повлиять на операции чтения. Когда операции записи терпят неудачу или испытывают дросселирование, чтение может остановиться в ожидании согласованных данных из журнала изменений. Если это происходит в вашем приложении, вы можете увидеть как медленные операции записи, так и коррелированное медленное время ответа для запросов. Избегание горячих точек является ключом к тому, чтобы избежать этой проблемы.
Соблюдайте небольшие объемы документов и операций записи
При создании приложений с прослушивателями снимков вы обычно хотите, чтобы пользователи быстро узнавали об изменениях данных. Чтобы добиться этого, старайтесь делать вещи небольшими. Система может очень быстро пропускать через систему небольшие документы с десятками полей. Более крупные документы с сотнями полей и большими данными обрабатываются дольше.
Аналогично, отдавайте предпочтение коротким, быстрым операциям фиксации и записи, чтобы поддерживать низкую задержку. Большие пакеты могут обеспечить более высокую пропускную способность с точки зрения писателя, но на самом деле могут увеличить время уведомления для слушателей снимков. Это часто нелогично по сравнению с использованием других систем баз данных, где вы можете использовать пакетирование для повышения производительности.
Используйте эффективных слушателей
По мере увеличения скорости записи в вашу базу данных Cloud Firestore распределяет обработку данных между многими серверами. Алгоритм шардинга Cloud Firestore пытается разместить данные из одной и той же коллекции или группы коллекций на одном сервере журнала изменений. Система пытается максимизировать возможную пропускную способность записи, сохраняя при этом как можно меньшее количество серверов, участвующих в обработке запроса.
Однако некоторые шаблоны все еще могут приводить к неоптимальному поведению прослушивателей снимков. Например, если ваше приложение хранит большую часть своих данных в одной большой коллекции, прослушивателю может потребоваться подключение ко многим серверам для получения всех необходимых ему данных. Это остается верным даже при применении фильтра запросов. Подключение ко многим серверам увеличивает риск более медленных ответов.
Чтобы избежать этих более медленных ответов, спроектируйте свою схему и приложение так, чтобы система могла обслуживать слушателей, не обращаясь ко многим разным серверам. Возможно, лучше всего будет разбить ваши данные на более мелкие коллекции с меньшей скоростью записи.
Это похоже на размышления о запросах производительности в реляционной базе данных, которые требуют полного сканирования таблиц. В реляционной базе данных запрос, который требует полного сканирования таблиц, является эквивалентом прослушивателя снимков, который отслеживает коллекцию с высокой текучестью. Он может выполняться медленнее по сравнению с запросом, который база данных может обслужить с использованием более конкретного индекса. Запрос с более конкретным индексом похож на прослушиватель снимков, который отслеживает один документ или коллекцию, которая изменяется реже. Вам следует провести нагрузочное тестирование своего приложения, чтобы лучше понять поведение и потребность вашего варианта использования.
Быстро выполняйте опросы
Другая ключевая часть отзывчивых запросов в реальном времени заключается в том, чтобы убедиться, что запрос опроса для загрузки данных быстрый и эффективный. При первом подключении нового прослушивателя снимков прослушиватель должен загрузить весь набор результатов и отправить его на устройство пользователя. Медленные запросы делают ваше приложение менее отзывчивым. Сюда входят, например, запросы, которые пытаются прочитать много документов, или запросы, которые не используют соответствующие индексы.
При некоторых обстоятельствах слушатель также может вернуться из состояния прослушивания в состояние опроса. Это происходит автоматически и прозрачно для SDK и вашего приложения. Следующие условия могут вызвать состояние опроса:
- Система перебалансирует журнал изменений в связи с изменениями нагрузки.
- Горячие точки приводят к сбоям или задержкам записи в базу данных.
- Временные перезагрузки сервера временно влияют на слушателей.
Если ваши опросные запросы выполняются достаточно быстро, состояние опроса становится прозрачным для пользователей вашего приложения.
Отдавайте предпочтение долгоживущим слушателям
Открытие и поддержание активности слушателей как можно дольше часто является наиболее экономически эффективным способом создания приложения, использующего Cloud Firestore . При использовании Cloud Firestore вы платите за документы, возвращаемые в ваше приложение, а не за поддержание открытого соединения. Долгоживущий прослушиватель снимков считывает только те данные, которые ему необходимы для обслуживания запроса в течение всего срока его существования. Это включает в себя начальную операцию опроса, за которой следуют уведомления, когда данные фактически изменяются. С другой стороны, одноразовые запросы повторно считывают данные, которые могли не измениться с момента последнего выполнения запроса приложением.
В случаях, когда ваше приложение должно потреблять большой объем данных, прослушиватели снимков могут быть неподходящими. Например, если ваш вариант использования требует передачи большого количества документов в секунду через соединение в течение длительного периода времени, может быть лучше выбрать одноразовые запросы, которые выполняются с меньшей частотой.
Что дальше?
- Узнайте , как использовать прослушиватели снимков .
- Узнайте больше о передовом опыте .