Обычная реляционная база на одном сервере закрывает большинство задач. Но когда нужна гибкая схема, огромный масштаб или глобальное распространение, у GCP есть отдельные базы под эти случаи. Разберём три главные и когда брать их вместо Cloud SQL.
Firestore
Firestore — это управляемая документная база: данные хранятся как JSON-подобные документы, собранные в коллекции, а не как строки в таблицах. Её главные черты — serverless (не думаете о серверах и мощности, платите за операции и хранение, масштабируется сама) и удобство для приложений: гибкая схема, запросы по полям, а в мобильных и веб-клиентах — синхронизация в реальном времени и работа офлайн.
Firestore — выбор по умолчанию, когда нужна NoSQL в GCP: пользовательские профили, настройки, каталоги, чаты, состояние приложений. Ближайший аналог в AWS — DynamoDB, но Firestore богаче по запросам и заточен под клиентскую синхронизацию.
Как и в любой NoSQL, проектирование начинается не со схемы, а с того, как вы будете читать данные: под запросы раскладывают документы и заводят индексы. Произвольные джойны, как в SQL, здесь не делают.
Bigtable
Bigtable — база другого класса: широко-колоночное хранилище (wide-column) для очень больших объёмов и очень высокой пропускной способности с предсказуемо низкой задержкой. Её берут под потоковые и аналитические нагрузки: временные ряды, метрики, события интернета вещей, данные для аналитики — там, где идут миллионы операций в секунду. Для обычного backend-сервиса это избыточно; Bigtable оправдывает себя на действительно больших потоках.
Spanner
Spanner — уникальная база: она даёт и SQL с транзакциями и согласованностью, как у реляционной базы, и горизонтальный масштаб с глобальным распространением, как у NoSQL. То есть вы работаете с привычными таблицами, SQL и ACID-транзакциями, но без потолка одного сервера и с возможностью растянуться на несколько регионов мира.
За это платят: Spanner дороже и сложнее обычной базы, поэтому его берут, когда действительно нужен глобальный масштаб с реляционной семантикой — крупные финансовые и торговые системы, глобальные каталоги. Для сервиса, который помещается на один сервер, это из пушки по воробьям.
Что выбрать
- Cloud SQL (PostgreSQL) — классическое приложение, реляционная модель, джойны, данные на одном сервере. Разумный выбор по умолчанию.
- Firestore — нужна гибкая документная модель, serverless и синхронизация с клиентами; большинство NoSQL-задач.
- Bigtable — гигантские потоки данных с низкой задержкой (метрики, временные ряды, аналитика).
- Spanner — нужен глобальный масштаб с полноценным SQL и транзакциями.
Практический совет новичку: не берите Firestore или Spanner «на будущее». Если данные спокойно живут на одном сервере и нужны джойны — Cloud SQL проще и дешевле. Специализированные базы оправдывают себя там, где обычная упирается в потолок.
Где это применяется
Эти базы закрывают ниши, куда не дотягивается обычная реляционная: гибкая документная модель и клиентская синхронизация (Firestore), гигантские потоки (Bigtable), глобальный масштаб с SQL (Spanner). В связке с serverless Firestore особенно естественна: функция без сервера + база без сервера дают систему, тарифицируемую по факту.
Типичные ошибки новичков:
- берут Firestore или Spanner для маленького сервиса — там, где Cloud SQL проще и богаче;
- ждут от Firestore привычного SQL с джойнами — это другая модель доступа;
- плохо проектируют под запросы — и упираются в неудобные и дорогие выборки.
Что учить дальше: обычные реляционные и кэширующие сервисы — в управляемых данных; как обращаться к базам из кода — в интеграции со Spring Boot; общие принципы выбора хранилища не привязаны к облаку — их разбирает системный дизайн. Сравнить подход можно с NoSQL-базой AWS — DynamoDB.