На этой странице описаны различные интерфейсы, доступные для доступа к данным в базе данных в нативном режиме.
Интерфейсы управления
В нативном режиме поддерживаются два интерфейса для доступа к данным:
Эксплуатация трубопроводов
Новый интерфейс запросов для Cloud Firestore . Конвейерные операции поддерживают компонуемый синтаксис на основе этапов. Вы создаете операцию, определяя последовательность этапов, которые выполняются в определенном порядке. Это позволяет выполнять сложные операции, такие как фильтрация по результату агрегации, что ранее было невозможно в исходном интерфейсе (основные операции).
Функции управления конвейером доступны только в версии Firestore Enterprise и находятся на стадии предварительного запуска.
Основные операции
Основные операции представляют собой оригинальный интерфейс для Cloud Firestore . В основных операциях используется синтаксис цепочки методов ( .where() , .orderBy() , .get() ) для получения документов или коллекций на основе ссылок. Порядок этапов запроса подразумевается, а поддержка агрегации ограничена.
Основные операции доступны как в корпоративной, так и в стандартной версиях, однако параметры индексации по умолчанию существенно различаются в разных версиях. Подробности см. в следующем разделе.
Различия в интерфейсе между версиями.
Благодаря внедрению поддержки нативного режима в корпоративной версии, доступны как операции Firestore Core, так и операции Pipeline. При использовании операций Core в корпоративной версии новое поведение индексов и модель ценообразования снимают многие ограничения стандартной версии.
| Особенность | Стандартное издание | Корпоративная версия |
| Поддерживаемые операции | Ограничено основными операциями Firestore Core. | Поддерживает операции Firestore Core и Pipeline, а также операции, обеспечивающие совместимость Firestore с MongoDB. |
| Требования к индексированию | Для выполнения всех запросов необходимы индексы. | Для выполнения запросов индексы не требуются. |
| Создание индекса | Автоматические индексы создаются для отдельных полей. Вы можете создавать составные индексы вручную. | Автоматическое создание индексов не предусмотрено . Индексы необходимо управлять вручную. |
| Индексированные поля | Дополнительное поле __name__ автоматически добавляется к индексированным полям, если оно еще не присутствует. | Поле __name__ не добавляется автоматически к индексированным полям. Если это важно для вашего приложения, вам необходимо явно указать __name__ в индексированных полях. |
| Нормализация порядка сортировки | В условии запроса ORDER BY происходит нормализация путем добавления в конец полей неравенства и поля __name__ (если оно еще не присутствует). Это гарантирует уникальный, детерминированный порядок результатов независимо от того, какие другие поля содержатся в условии ORDER BY. | Нормализация порядка сортировки отсутствует. Порядок сортировки, например, `sort a ASC`, гарантирует сортировку результатов только по полю `a` . Cloud Firestore будет использовать ваши существующие индексы для возврата результатов в наиболее эффективном порядке. Поэтому, если `a` не является уникальным в наборе результатов, порядок результатов может меняться от запроса к запросу в зависимости от конфигурации индекса, стратегий выполнения и т. д. Для гарантирования уникального, детерминированного порядка результатов необходимо добавить уникальное поле, например, `__name__`, в порядок сортировки. |
| Производительность и стоимость запросов | Как правило, запросы отличаются высокой производительностью благодаря требованиям к индексам. | Оптимизируйте производительность и затраты на запросы, создавая индексы. Вы можете выявить отсутствующие индексы с помощью функций Query Explain и Query Insights. Запросы без индексов могут стать неэффективными и дорогостоящими по мере роста объема данных, что потребует мониторинга и настройки. |
| Накладные расходы на индексацию | Запись в индексы бесплатна, так как индексы создаются автоматически. | При записи индексных записей расходуются единицы записи при записи связанного документа (1 единица записи на 1 КиБ размера индексной записи). Вы экономите на хранении данных, не создавая индексные записи для каждого поля. |
| Модель выставления счетов (чтение/запись/удаление) | Оплата взимается за каждое чтение, запись и удаление документа . | Оплата производится за каждое чтение и запись (транш). Чтение оплачивается в единицах чтения (транши по 4 КиБ). Запись и удаление объединяются в единицы записи (транши по 1 КиБ). |
| Базовая цена (за миллион долларов) Цены указаны для центрального региона США. | Стоимость прочтения: 0,03 доллара за 100 000 документов (или 0,30 доллара за миллион). Стоимость написания: 0,09 доллара за 100 000 документов (или 0,90 доллара за миллион). Удаление: 0,01 доллара за 100 000 документов (или 0,10 доллара за миллион). | Стоимость считанных единиц: 0,05 доллара за 1 миллион считанных единиц. Единицы записи: 0,26 доллара за 1 миллион единиц записи. Цены, как правило, ниже для документов размером менее 4 КиБ по сравнению со стандартной стоимостью чтения. |
| Обновления в режиме реального времени Указанные цены действительны для центрального региона США. | Обновления в режиме реального времени включены в стоимость и оплачиваются как чтение по цене 0,03 доллара за 100 000 документов . | Для обновлений в реальном времени используется новый отдельный артикул (SKU – Realtime Update Units), оплата производится за каждый транш в 4 КиБ. Стоимость обновлений в реальном времени составляет 0,30 доллара США за миллион единиц чтения . |