Какие типы баз данных существуют
Что проверяют
Можете ли вы разложить базы по моделям данных и сразу привязать их к мобильной задаче: что хранить на устройстве, а что оставить серверу. Следом почти всегда спрашивают про Room и про то, чем он отличается от голого SQLite.
Как отвечать
Классификация по модели данных:
- реляционные: таблицы, схема, SQL, транзакции ACID. На сервере PostgreSQL и MySQL, на устройстве SQLite, который встроен в Android;
- ключ-значение: Redis на сервере, на устройстве
DataStore(Preferences или Proto), старыйSharedPreferences, для скорости MMKV; - документные: JSON-подобные документы без жёсткой схемы. В мобильной разработке это прежде всего Firestore с офлайн-кэшем;
- колоночные (ClickHouse) и широкостолбцовые (Cassandra): аналитика и огромные объёмы записи, к клиенту отношения не имеют;
- графовые: связи как первоклассные объекты, Neo4j;
- объектные: хранят объекты без ORM, на Android это ObjectBox и Realm;
- векторные: поиск по эмбеддингам,
pgvectorили специализированные движки.
Дальше перейдите к Android. Основной выбор это Room: обёртка над SQLite с проверкой SQL на этапе компиляции, DAO, Flow из запросов и миграциями через Migration или @AutoMigration. На главном потоке Room запрос не выполнит без явного allowMainThreadQueries(). Альтернатива SQLDelight: пишете SQL, получаете типобезопасный Kotlin, работает в Kotlin Multiplatform. Для настроек и флажков берут DataStore, для кэша сетевых ответов обычно хватает Room.
Где спотыкаются
Говорят «NoSQL быстрее и лучше масштабируется» без условий. Скорость зависит от модели доступа, а консистентность и джойны реляционные базы дают из коробки.
Хранят в SharedPreferences списки и JSON-массивы. Файл читается целиком в память, а commit() на главном потоке даёт подвисания, поэтому таким данным место в базе.
Не знают про миграции Room. Изменили @Entity, подняли version без Migration, и приложение падает у пользователей, а fallbackToDestructiveMigration() спасает запуск ценой их данных.