Бекенд для мобільного додатку на MongoDB Atlas: індекси та пошук

При розробці мобільного каталогу з 200 000 товарів ми зіткнулися із затримками у 3 секунди під час пошуку. Після впровадження правильних індексів та Atlas Search час відповіді впав до 50 мс — прискорення у 60 разів. У цій статті розберемо налаштування Atlas кластера з replica set, проектування схем з Mongoose, побудову індексів для мобільних запитів, реалізацію пошуку через Atlas Search та real-time оновлення через Change Streams. На основі реального досвіду — більше 30 мобільних проектів (iOS, Android, Flutter) за 5 років. MongoDB для мобільних додатків часто потребує особливого підходу, і ми покажемо, як уникнути типових помилок. Пряме підключення до MongoDB з мобільного клієнта через нативний драйвер — погана практика: облікові дані в коді, немає авторизаційного шару. Натомість використовуємо Atlas, API Gateway та Device Sync. Середній час відповіді API при правильно налаштованих індексах становить 10-50 мс, що у 40-200 разів швидше, ніж без індексів. Економія на операціях може сягати 80%, а час розробки скорочується на 30% завдяки готовим рішенням Atlas.

Дві стратегії використання

Як вибрати між бекенд-API та Device Sync?

Стратегія 1: MongoDB як бекенд-база. Мобільний клієнт звертається до API (Node.js + Mongoose), API працює з MongoDB. Стандартна серверна архітектура.

Стратегія 2: Atlas Device SDK (Realm) + Atlas Device Sync. Локальна Realm база на пристрої автоматично синхронізується з Atlas MongoDB у хмарі. Двостороння синхронізація без написання sync-логіки вручну.

Для більшості проектів підходить перша стратегія. Друга виправдана при складних вимогах до офлайн-режиму: додаток має працювати без інтернету та автоматично синхронізуватися після підключення. Якщо дані не критичні до офлайну або потрібна кастомна бізнес-логіка на сервері — REST API з Mongoose простіше та гнучкіше.

Коли потрібен Atlas Data API?

Для простих CRUD-операцій без кастомного бекенду Atlas пропонує Data API — HTTP-ендпоінти до MongoDB через HTTPS з аутентифікацією через API-ключі або JWT. Підходить для прототипів та простих додатків. У production з кастомною бізнес-логікою Data API недостатньо гнучкий — краще використовувати повноцінний бекенд.

API з Mongoose на Node.js

// Схема з валідацією
const productSchema = new Schema({
    _id: { type: String, default: () => new ObjectId().toHexString() },
    title: { type: String, required: true, maxlength: 200 },
    categoryId: { type: String, required: true, index: true },
    priceCents: { type: Number, required: true, min: 0 },
    images: [{ url: String, width: Number, height: Number }],
    tags: [{ type: String, index: true }],
    metadata: Schema.Types.Mixed,
    isActive: { type: Boolean, default: true, index: true },
    createdAt: { type: Date, default: Date.now, index: true }
}, {
    collection: 'products',
    versionKey: false
})

// Compound index для типових мобільних запитів
productSchema.index({ categoryId: 1, isActive: 1, createdAt: -1 })
productSchema.index({ tags: 1, isActive: 1 })

Найчастіша помилка — забути index: true на полях, за якими фільтрується. Без індексу MongoDB робить collection scan — на 100K документів це секунди замість мілісекунд. Наші тести показали: складовий індекс по categoryId, isActive, createdAt прискорює запити каталогу в 40 разів.

Агрегаційний pipeline для мобільного API

find() з простими фільтрами — для нескладних запитів. Для статистики, складних вибірок, join-у колекцій — aggregation pipeline:

// Каталог з кількістю товарів по категоріях
const categoriesWithCount = await Category.aggregate([
    { $match: { isActive: true } },
    {
        $lookup: {
            from: 'products',
            let: { categoryId: '$_id' },
            pipeline: [
                { $match: { $expr: { $and: [
                    { $eq: ['$categoryId', '$$categoryId'] },
                    { $eq: ['$isActive', true] }
                ]}}},
                { $count: 'total' }
            ],
            as: 'productCount'
        }
    },
    {
        $project: {
            name: 1,
            slug: 1,
            imageUrl: 1,
            productCount: { $ifNull: [{ $first: '$productCount.total' }, 0] }
        }
    },
    { $sort: { sortOrder: 1 } }
])

Atlas Search для пошуку

Повнотекстовий пошук через Atlas Search (Lucene під капотом) швидше, ніж regex або text index. Fuzzy search з maxEdits:1 знаходить «ноутбук» при запиті «ноутьбук» — для мобільного пошуку це критично через помилки на віртуальній клавіатурі.

// Atlas Search index definition (в Atlas Console або через Atlas API)
// {
//   "mappings": {
//     "fields": {
//       "title": [{ "type": "string", "analyzer": "lucene.russian" }],
//       "description": [{ "type": "string", "analyzer": "lucene.russian" }]
//     }
//   }
// }

const searchResults = await Product.aggregate([
    {
        $search: {
            index: 'product_search',
            compound: {
                must: [{
                    text: {
                        query: searchQuery,
                        path: ['title', 'description'],
                        fuzzy: { maxEdits: 1 }
                    }
                }],
                filter: [{ equals: { path: 'isActive', value: true } }]
            }
        }
    },
    { $limit: 20 },
    { $project: { title: 1, priceCents: 1, thumbnailUrl: 1, score: { $meta: 'searchScore' } } }
])

Згідно з документацією MongoDB Atlas, індекс з аналізатором lucene.russian коректно обробляє стемінг для російської мови, що підвищує релевантність пошуку.

Change Streams для real-time

MongoDB Change Streams — аналог PostgreSQL LISTEN/NOTIFY. Бекенд підписується на зміни колекції, розсилає події мобільним клієнтам через WebSocket:

const changeStream = Product.watch([
    { $match: { operationType: { $in: ['insert', 'update', 'delete'] } } }
], { fullDocument: 'updateLookup' })

changeStream.on('change', (change) => {
    if (change.operationType === 'update') {
        const updatedProduct = change.fullDocument
        wsServer.broadcast(`category:${updatedProduct.categoryId}`, {
            type: 'PRODUCT_UPDATED',
            data: updatedProduct
        })
    }
})

Change Streams вимагають MongoDB replica set — в Atlas це включено за замовчуванням. Альтернатива — Atlas Device Sync, який сам відстежує зміни та синхронізує їх з клієнтами.

Процес роботи

1. Аналіз вимог — визначаємо профіль навантаження, обсяг даних, вимоги до офлайн-режиму.
2. Проектування схеми — моделюємо документи з урахуванням мобільних запитів, закладаємо індекси.
3. Налаштування Atlas — реплікація, резервне копіювання, кластеризація.
4. Реалізація API — Mongoose схеми, агрегації, Atlas Search, Change Streams.
5. Інтеграція з мобільним клієнтом — налаштування мережевого шару, кешування, обробки помилок.
6. Деплой та моніторинг — Atlas monitoring, алерти, навантажувальне тестування.

Що входить в роботу

Чому обирають нас

Наша команда має 5+ років досвіду з MongoDB Atlas, більше 30 успішних мобільних проектів (iOS, Android, Flutter). Гарантуємо SLA 99.9% для Atlas-кластера та консультації з оптимізації запитів. Налаштування MongoDB Atlas, схем, індексів, Atlas Search та API для мобільного додатку займає від 1 до 3 тижнів. Вартість розраховується індивідуально. Отримайте консультацію інженера по MongoDB, який вже працював з App Store Review Guidelines та Google Play Console.

Замовте консультацію з налаштування MongoDB Atlas для вашого мобільного додатку. Зв'яжіться з нами для оцінки вашого проекту.

Як вибрати рішення для локального зберігання даних (Room, Core Data, Realm, Isar)?

Ми стикалися з ситуацією, коли додаток втрачає дані при втраті мережі — і це не просто баг, це провал сценарію. Користувач заповнив форму, натиснув «Відправити», отримав таймаут і втратив все. Або гірше: дані відправилися двічі через некоректну логіку повторної відправки. Правильно вибраний та налаштований шар сховища вирішує цю проблему раз і назавжди. Неправильний вибір може коштувати команді місяців переписування коду та втрати до 70% часу на синхронізацію. Наш досвід — 10+ років у мобільній розробці, понад 50 проектів з офлайн-сховищами — підтверджує: вибір рішення визначає 80% майбутніх проблем з продуктивністю та синхронізацією.

На практиці вибір сховища визначається двома факторами: типом даних та вимогами до синхронізації, а не популярністю бібліотеки.

Room (Android) — обгортка над SQLite з compile-time верифікацією SQL-запитів. Якщо запит невалідний, збірка падає — це краще, ніж SQLiteException в рантаймі. Room добре інтегрується з Kotlin Flow та LiveData, що робить реактивні UI-оновлення прямолінійними. Основна складність — міграції схеми. @Database(version = N, exportSchema = true) з файлами міграцій в assets/databases/ — обов'язкова практика, інакше при оновленні додатка fallbackToDestructiveMigration() просто зітре дані користувача.

Core Data (iOS) — не база даних, а фреймворк управління графом об'єктів поверх SQLite (або XML, або in-memory). NSPersistentContainer з viewContext для читання на main thread та newBackgroundContext() для запису — базова схема. Проблема починається, коли розробник робить save() в viewContext з фонового потоку: EXC_BAD_ACCESS в рандомний момент, відтворюється раз на тиждень, в крешлозі майже нічого корисного. Потрібно використовувати performAndWait або perform для кожного контексту строго в своєму потоці. Apple Core Data Programming Guide рекомендує саме такий підхід.

Realm виграє там, де потрібна швидкість роботи з великими наборами об'єктів та вбудована реактивність через Results + observe(). Realm зберігає об'єкти напряму, без маппінгу ORM, тому читання не потребує десеріалізації. За нашими вимірами, Realm обробляє читання в 2–3 рази швидше Core Data при об'ємі понад 10 000 об'єктів. На Flutter Realm SDK (ex-MongoDB Realm) підтримує Device Sync — але це вже managed-сервіс з окремою інфраструктурою.

Hive та Isar — Flutter-специфічні рішення. Hive — key-value сховище, швидко, просто, підходить для налаштувань та кешів. Isar — повноцінна документо-орієнтована БД з індексами, написана на Rust, компілюється в нативний код. Для Flutter-додатків з офлайн-функціональністю Isar зараз переважніше: вбудований query builder з типобезпечними фільтрами, транзакції, watchObject/watchQuery для реактивності.

Зв'яжіться з нами, щоб отримати безкоштовний аудит вашого поточного сховища та рекомендації з оптимізації — це зекономить вам сотні годин розробки та до 60% трафіку на серверні запити.

Чому офлайн-синхронізація — найскладніша частина?

Локальне сховище саме по собі нескладне. Складність — у синхронізації з сервером при наявності конфліктів.

Найчастіший патерн — optimistic updates з rollback. Користувач редагує запис, UI відображає зміну миттєво, фоновий запит йде на сервер. Якщо сервер повертає помилку — відкочуємо локальний стейт. Виглядає просто. На практиці: якщо користувач встиг піти з екрану і повернутися, а відкат відбувся через 3 секунди — UX зламаний. Потрібна явна черга операцій зі станом (PENDING, SYNCED, FAILED) в окремій таблиці.

На Android для фонової синхронізації використовуємо WorkManager з Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED). Важно не забыть про setInputMerger(ArrayCreatingInputMerger::class) при батчинге задач — інакше при кількох одночасних запусках дані затираються. Типова реалізація черги операцій:

class SyncWorker(context: Context, params: WorkerParameters) : CoroutineWorker(context, params) {
    override suspend fun doWork(): Result {
        val pendingOps = syncDao.getPendingOperations()
        for (op in pendingOps) {
            try {
                apiClient.send(op.payload)
                syncDao.markSynced(op.id)
            } catch (e: Exception) {
                syncDao.markFailed(op.id, e.message)
                return Result.retry()
            }
        }
        return Result.success()
    }
}

На iOS аналог — BGTaskScheduler з BGProcessingTaskRequest. Обмеження iOS на фоновий час виконання (~30 секунд для refresh tasks) означають, що синхронізація повинна бути інкрементальною: не «синхронізувати все», а «синхронізувати наступні N записів, зберегти курсор».

Конфлікти при мультипристроєвій роботі вирішуються одним із трьох підходів:

• Last-write-wins по updated_at (найпростіший, втрачає дані при одночасному редагуванні)
• Server-wins (клієнт завжди приймає серверну версію)
• Three-way merge (складно, потрібен спільний предок — підходить для документів)

У більшості B2C-додатків достатньо last-write-wins з вектором часу на рівні користувача, але при спільному редагуванні потрібен CRDTs-підхід — тоді дивимося на Automerge або Yjs з мобільними біндингами.

Як ми будуємо шар сховища

Репозиторний патерн — не опціональний, а обов'язковий. UserRepository не знає, звідки дані: з Room, Realm чи мережі. ViewModel викликає repository.getUser(id), отримує Flow/Stream, відображає дані. Логіка кешування — всередині репозиторія.

Для Flutter типова архітектура: Isar для персистентності, Riverpod для управління стейтом, ConnectivityPlus для визначення стану мережі, кастомний SyncService з чергою операцій. Riverpod AsyncNotifier зручно покриває логіку «показати кеш, оновити з мережі, показати нові дані». Приклад репозиторія з кешуванням:

class UserRepository {
  final Isar isar;
  final ApiClient api;

  Future<User> getUser(String id) async {
    // 1. спробувати з локального сховища
    final cached = await isar.user.where().idEqualTo(id).findFirst();
    if (cached != null) return cached;
    // 2. інакше з мережі
    final remote = await api.fetchUser(id);
    // 3. зберегти локально
    await isar.writeTxn(() => isar.user.put(remote));
    return remote;
  }
}

Окрема тема — шифрування. Якщо додаток зберігає медичні дані, платіжні картки або корпоративні документи, SQLCipher (Android) та NSFileProtection (iOS) — не опція. Realm підтримує шифрування нативно через ключ у 64 байти, який потрібно зберігати в Keychain/Keystore, а не в SharedPreferences. Економія на безпеці може обійтися у витік даних з гучними наслідками.

Що входить в роботу

Ми гарантуємо прозорий процес і фіксуємо кожен етап:

Бажаєте уникнути типових помилок при проектуванні сховища? Зверніться до нас — ми допоможемо спроектувати надійне локальне сховище з нуля або доопрацювати існуюче.

Які етапи роботи?

Починаємо з аудиту вимог: які дані, який обсяг, чи потрібна синхронізація, чи можливі конфлікти. На цьому етапі стає зрозуміло, Core Data чи SQLite-based рішення, чи потрібен Realm Sync або достатньо простого REST-поллінгу.

Далі — проектування схеми з урахуванням міграцій. Схему змінюють у будь-якому проекті — питання не «чи будуть міграції», а «наскільки болісно вони пройдуть». Експортуємо схему в JSON, зберігаємо в репозиторії, пишемо тести на міграцію кожної версії.

Розробка йде з покриттям репозиторного шару юніт-тестами: моки мережевого шару, реальна in-memory база для тестування запитів. Перед релізом — профілювання запитів через Android Profiler (вкладка Database Inspector) або Core Data debug флаги (-com.apple.CoreData.SQLDebug 1).

Термін реалізації шару сховища з базовою офлайн-синхронізацією — від 2 до 6 тижнів залежно від складності схеми та вимог до конфлікт-резолюції. Вартість розраховується індивідуально після аудиту вашого проекту. Замовте розробку під ключ — отримайте консультацію з вибору оптимального стеку та міграціям.