NoSQL для QA: MongoDB, Redis і консистентність

Що таке NoSQL і чим воно принципово відрізняється від реляційної бази?

NoSQL — збірна назва для сховищ, що пожертвували частиною реляційної моделі заради масштабування, гнучкості структури чи швидкості на своєму патерні доступу; це не «база без SQL» і тим паче не «база без схеми». Ключове питання — хто відповідає за структуру даних. У реляційному світі діє schema-on-write: CREATE TABLE фіксує структуру, і невідповідний рядок сервер просто не прийме. У багатьох NoSQL діє schema-on-read: записати можна що завгодно, а розгрібати структуру доведеться коду, що читає. Тобто схема живе не в базі, а в застосунку — і звичних гарантій цілісності тут ніхто автоматично не забезпечує. Для тестувальника це пряме розширення обов'язків: узгодженість даних доводиться перевіряти самому.

Які основні типи NoSQL-сховищ ти знаєш?

Їх щонайменше чотири, і сильний кандидат наводить кожен із прикладом та задачею. Документні бази (MongoDB, CouchDB) тримають JSON-подібні документи — профілі, каталоги, сутності зі змінною структурою. Сховища ключ-значення (Redis, Memcached, DynamoDB) — найпростіша модель key → value під кеш, сесії, лічильники й черги. Ширококолонкові (Cassandra, HBase) розраховані на логи, часові ряди й загалом величезні обсяги записів із динамічними колонками. Графові (Neo4j) моделюють вузли та ребра — соціальні зв'язки, рекомендації, маршрути. Улюблена перевірка інтерв'юера — чи не вважаєте ви Redis і MongoDB двома схожими базами: моделі в них різні, задачі теж.

Правда, що «SQL надійний, а NoSQL швидкий»?

Ні, це кліше десятирічної давності, і його варто спростувати з прикладами. З одного боку, реляційний PostgreSQL давно працює з документними даними — тип JSONB можна і зберігати, й індексувати. З іншого — MongoDB ще з версії 4.0 має багатодокументні ACID-транзакції, тож «NoSQL без надійності» — теж неправда. Швидкість — не властивість ярлика «SQL чи NoSQL», а функція патерну доступу: діставання ключа з Redis-кешу й повне сканування великої колекції MongoDB відрізняються на порядки. Показова деталь: та сама MongoDB поводиться по-різному залежно від конфігурації — читання з primary узгоджене, а з secondary може віддати застаріле. Тож відповідь рівня senior звучить як «залежить від моделі даних, патерну доступу й налаштувань».

Що таке ACID і BASE, і чим вони відрізняються?

Це два протилежні набори гарантій. ACID (Atomicity, Consistency, Isolation, Durability) обіцяє: транзакція або виконується цілком, або відкочується, а база після неї лишається в коректному стані — так працюють класичні реляційні СУБД. BASE (Basically Available, Soft state, Eventual consistency) — філософія багатьох розподілених NoSQL: відповідь ти отримаєш завжди, але стан системи в конкретний момент може бути неузгодженим і вирівняється лише з часом. Для QA різниця відчутна на практиці: у BASE-системі свіжий запис при читанні з іншої копії даних може бути ще не видимим, і це очікувана поведінка, а не дефект. Водночас жорстко ділити світ на «ACID проти BASE» не варто: транзакції в MongoDB — приклад того, що все вирішує конфігурація конкретної системи.

Як MongoDB зберігає дані і як виглядає запит замість SELECT?

Одиниця зберігання — документ у колекції: JSON-подібна структура (фізично — бінарний BSON) з підтримкою вкладеності й масивів та обов'язковим унікальним _id (за замовчуванням — ObjectId). Замість мови SQL — API, якому передають фільтр у вигляді документа: db.users.find({ status: "active" }) робить те саме, що SELECT * FROM users WHERE status = 'active'. Складніші умови — теж документи, тільки з операторами: { total: { $gt: 100 } } відбере замовлення дорожчі за 100. Висновок ширший за MongoDB: стандартної мови запитів у NoSQL немає, у кожного сховища власний інтерфейс, і це одна з головних відмінностей від реляційного світу.

find нічого не повертає, хоча даних у колекції повно. З чого почати діагностику?

З типів, а не з підозри на зниклі дані. MongoDB порівнює строго: число 100 у фільтрі ніколи не збіжиться з рядком "100" у документі, неявного приведення не буде — запит мовчки поверне порожній результат. Той самий механізм кусає з ідентифікаторами: ObjectId не дорівнює своєму рядковому представленню, шукати треба через new ObjectId(...). Тому перший крок діагностики — відкрити реальний документ і звірити тип поля з типом у фільтрі. Досвід показує, що в більшості таких «багів» винні тестові дані чи сам запит, а не продукт: це NoSQL-версія правила «спершу перевір свій запит, потім звинувачуй базу».

Чому гнучка схема MongoDB — це окремий клас багів для тестувальника?

Бо колекція не гарантує однакової структури: база без заперечень тримає поруч документи з різними наборами полів. Типові сценарії: у нових користувачів з'явилося поле phone, а в тисяч старих його немає — і код, розрахований на нього, дістає undefined; поле перейменували без міграції даних (isActive → status) — і стара частина колекції читається неправильно, хоча жодна помилка ніде не впала. Захист існує — на колекцію можна повісити валідацію $jsonSchema, — але вона опційна, і в реальних проєктах її часто ніхто не вмикав. Висновок для QA: узгодженість структури документів — це те, що в реляційному світі гарантував сервер, а тут стало вашою роботою.

У чому різниця між null у полі й відсутнім полем у документі?

Це два різні стани документа: null — поле існує з порожнім значенням, відсутнє поле — ключа немає взагалі. Пастка в тому, як їх бачать фільтри. Контрінтуїтивно, фільтр рівності { phone: null } знаходить обидва стани одразу — і явний null, і документи без поля; це задокументована поведінка MongoDB. Розрізнити стани можна лише спеціальними операторами: { phone: { $type: "null" } } дає тільки явний null, а { phone: { $exists: false } } — тільки документи без поля. Для тесту це означає, що вибірка «користувачі без телефону» через рівність із null може виявитися ширшою, ніж задумано, а через $exists: false — вужчою. Симптом плутанини — «зайві» чи «зниклі» документи у вибірці, які виглядають як баг застосунку, хоча насправді неточний фільтр.

Що таке Redis і для чого його зазвичай використовують?

Redis — сховище моделі ключ-значення, що живе в оперативній пам'яті (скидання на диск можливе, але робочий набір — у RAM), звідси його швидкість. Типові ролі: кеш перед основною, повільнішою базою, а ще сесії, лічильники, черги. Обробка команд однопотокова, тому кожна окрема команда атомарна. У ролі кешу найчастіше зустрінете патерн cache-aside: перший погляд — у Redis; якщо ключа немає (miss) — похід в основну базу, а прочитане одразу кладеться в кеш для наступних запитів. Для тестувальника Redis — додатковий шар між застосунком і базою, і саме цей шар зазвичай відповідає на питання «чому UI показує старі дані, якщо бекенд їх уже оновив».

Що таке TTL у Redis і як він пов'язаний з інвалідацією кешу?

TTL (time to live) — термін життя ключа: SET price:42 99 EX 60 означає «тримай 60 секунд», команда TTL price:42 покаже залишок, а після його вичерпання ключ зникне сам. По суті це інвалідація «за годинником», пасивна: свіжі дані гарантовано з'являться лише тоді, коли вікно TTL спливе. Усе, що має оновлюватися швидше, потребує активної інвалідації — і саме тут народжується «протухлий» (stale) кеш. Три класичні сценарії: TTL задовгий, а примусово ключ ніхто не видаляє; базу оновили, а крок «видалити/оновити ключ» у коді загубився; гонка (race condition) — паралельний запис устиг втиснутися між читанням бази й записом у кеш. Тактика QA із цього пряма: старе значення в тесті — спершу питання до кешу і його TTL, а вже потім до бізнес-логіки.

Чим серверний кеш Redis відрізняється від браузерного HTTP-кешу для тестувальника?

Шаром, у якому він живе, — і тому способом лікування. HTTP-кеш працює на клієнті, між браузером і мережею; Redis стоїть на сервері, між застосунком і його базою. Симптом у обох однаковий («бачу стару версію»), тому їх постійно плутають. Лакмус — залежність від клієнта: свіжий browser context у Playwright гарантовано обнуляє браузерний кеш, але бекендового Redis навіть не торкається — стара відповідь прилетить і в стерильний контекст, бо її віддає сам сервер. Тож якщо застаріле значення відтворюється в будь-якому браузері й на будь-якій машині, підозра переходить із клієнтського кешу на серверний — і дивитися треба TTL та інвалідацію ключів, а не чистити профіль браузера.

Що таке eventual consistency і чому «запис пройшов» не дорівнює «запис видно»?

Через реплікацію. Розподілене сховище тримає дані в кількох копіях: пише головний вузол (primary), а репліки підтягують зміни асинхронно, із запізненням — це і є лаг реплікації (replication lag). Між «primary підтвердив запис» і «репліка його показує» завжди є вікно, і читання з репліки в цьому вікні повертає старі дані. Eventual consistency якраз це й обіцяє: копії зійдуться — але «зрештою», без гарантії конкретного моменту. У тестах це класично виглядає як «запис пропав»: створили сутність, одразу читаємо — її нема, за секунду — вже є. Заводити на таке баг — помилка; правильна реакція — з'ясувати, звідки читає бекенд, і закласти відкладену видимість у дизайн тесту.

Записали дані, а тест їх одразу не бачить через реплікацію. Як правильно це тестувати?

Полінгом (polling), не паузою. Механіка: у циклі з невеликим інтервалом перевіряємо умову («запис уже видно?») і виходимо або з успіхом, або по загальному таймауту. Так тест чекає рівно стільки, скільки реально тривав лаг, — не більше й не менше. Фіксований sleep програє в обидва боки: поставиш із запасом — сюїт повзе, поставиш впритул — тест флакі, бо лаг реплікації плаває й інколи перевищує паузу. Це окремий випадок універсального принципу синхронізації в автотестах: чекати треба на настання стану, а не на годинник — так само, як з очікуванням елементів у UI чи статусів в API.

Що таке write concern і read preference у MongoDB?

Два регулятори консистентності, у яких часто «зашитий» нібито баг. Write concern керує записом: скільки вузлів кластера мають підтвердити операцію, перш ніж клієнт отримає «ОК»; з версії 5.0 типове значення — підтвердження більшістю. Read preference керує читанням: типово воно йде з primary й бачить усе записане, але його можна перемкнути на secondary, щоб розвантажити primary, — ціною ризику застарілих даних через лаг реплікації. Практичний патерн: команда перемкнула читання на secondary, і в тестах «поїхала» консистентність, хоча з погляду конфігурації все працює як задумано. Тому перед баг-репортом про неузгодженість сильний кандидат спершу дивиться саме ці два налаштування.

Розкажи про CAP-теорему.

CAP описує, чим розподілена система жертвує в момент мережевого збою. Три властивості: Consistency — будь-яке читання повертає найсвіжіший запис або чесну помилку; Availability — система відповідає на кожен запит, нехай і не найсвіжішими даними; Partition tolerance — робота не зупиняється, коли мережа між вузлами рветься. Теорему сформулював Ерік Брюер, а формально довели Гілберт і Лінч у 2002 році. Цінність для QA — не в означеннях, а в сценаріях деградації: сталася коротка партиція — і що робить система? Відхиляє запити заради узгодженості чи приймає їх, ризикуючи розбіжністю реплік? Знаючи обраний компроміс, можна відрізнити задокументовану поведінку під час збою від справжнього дефекту.

Чому «оберіть будь-які два з трьох» — неправильне трактування CAP?

Бо воно подає P як опцію, а партиції в реальній мережі — неминучість: обладнання й канали відмовляють незалежно від наших побажань. Насправді дилема вужча й ситуативна: коли партиція вже сталася, система мусить або пожертвувати доступністю заради узгодженості (CP — частина запитів дістане відмову), або лишитися доступною і змиритися з тимчасовою розбіжністю даних (AP). Поза збоєм протиставлення зникає — справна система дає й C, і A одночасно. Орієнтир: MongoDB, що читає з primary, поводиться як CP — краще відмовить, ніж віддасть неузгоджене; Cassandra в типовій конфігурації — як AP, відповідає завжди й доузгоджує потім. Тільки не варто клеїти на СУБД одну пару літер назавжди: поведінку визначає конфігурація.

Що таке PACELC і чим воно доповнює CAP?

PACELC додає до CAP другу половину — про життя без збоїв. Формула: при партиції (P) — той самий вибір A проти C, що й у CAP; інакше (Else) — вибір між затримкою (latency) і узгодженістю (consistency). Пояснення просте: сильні гарантії — це додаткові мережеві раунди (дочекатися підтвердження від більшості вузлів, сходити читанням на primary), і платити за них доводиться часом відповіді навіть у цілком здоровій системі. Тобто компроміс консистентності не вмикається лише під час аварії — він діє постійно. Для QA це готове пояснення ефекту «закрутили write concern — усе сповільнилося»: перформанс просів не через баг, а тому що система свідомо посунулася по осі latency/consistency.

Тест бачить стару ціну. Де шукати системно?

Пошук іде рівнями, від клієнта вглиб. Перший рівень — HTTP-кеш браузера: стару відповідь віддає сам клієнт; діагноз — стара версія живе лише в цьому профілі чи браузері, а свіжий контекст її не бачить. Другий — серверний кеш застосунку, типово Redis: база оновлена, але ключ не інвалідовано чи TTL ще не сплив; діагноз — стара версія однакова звідусіль, з будь-якої машини. Третій — реплікація: бекенд читає з репліки, яка ще не наздогнала primary; діагноз — розбіжність зникає сама за секунди, і ловити її треба полінгом. Сила відповіді — у порядку дій: спершу визначити, чи залежить «стара ціна» від клієнта, і лише локалізувавши рівень, лізти в логіку розрахунку. Найчастіше такий «баг ціни» виявляється кешем або відкладеною консистентністю, а не помилкою в коді продукту.

Три кейси, де NoSQL перетворює зелений тест на полювання за примарою: find, який «нічого не повертає» через тип і гнучку схему в MongoDB; запис, який видно не одразу, і полінг замість sleep; і таблиця рішень для «тест бачить стару ціну» — як за симптомом відрізнити рівень кешу. Скрізь — що дивитися і чому.

Кейс 1. MongoDB: find не бачить документ, хоча дані є

Тест перевіряє, що після реєстрації в базі з'явився користувач, і падає: findOne повертає null. У колекції запис насправді є. Дві найчастіші причини — розбіжність типів і гнучка схема.

Спершу дивимося на фактичний документ у колекції:

// те, що реально лежить у базі
{
  "_id": ObjectId("665f1c2a9b1e4a0012ab34cd"),
  "email": "qa@example.com",
  "total": "100",          // рядок, а не число
  "isActive": true          // старе ім'я поля, нові документи пишуть status
}

А тепер фільтр із тесту:

import { MongoClient, ObjectId } from "mongodb";

const client = await MongoClient.connect(process.env.MONGO_URI!);
const users = client.db("shop").collection("users");

// 1) РОЗБІЖНІСТЬ ТИПУ: у базі "100" (рядок), тут 100 (число) — не збіжиться
const byTotal = await users.findOne({ total: 100 });
// byTotal === null, хоча документ існує

// 2) правильно — порівнювати з тим самим типом, що в базі
const okTotal = await users.findOne({ total: "100" });

// 3) ObjectId теж не дорівнює своєму рядку
const idStr = "665f1c2a9b1e4a0012ab34cd";
const byStr = await users.findOne({ _id: idStr });        // null
const byOid = await users.findOne({ _id: new ObjectId(idStr) }); // знайде

Що дивитися і чому:

• MongoDB не приводить типи мовчки. Рядок "100" і число 100 — різні значення, збіг не спрацьовує. Перш ніж заводити баг «реєстрація не створює користувача», подивіться typeof поля в самому документі й у фільтрі. Часто винен не продукт, а тип у тестових даних.
• _id — це ObjectId, а не рядок. Порівняння з рядковим представленням дає null. Обгортайте ідентифікатор у new ObjectId(...) перед пошуком.
• Гнучка схема ховає поле. Якщо частина коду очікує user.status, а старі документи мають лише isActive, читання дасть undefined — і асерт expect(doc.status).toBe("active") впаде не через баг застосунку, а через відсутню міграцію. Перевіряйте, що поле взагалі є, окремо від його значення.
• null проти відсутнього поля. Контрінтуїтивно: фільтр рівності { phone: null } знаходить обидва стани — і явний null, і документи, де поля немає взагалі. Якщо тесту потрібен лише один із них, кажіть це явно:

// обидва стани: і phone: null, і документи без поля phone
const noPhone = await users.find({ phone: null }).toArray();

// лише явний null (поле є, значення порожнє)
const explicitNull = await users.find({ phone: { $type: "null" } }).toArray();

// лише документи, де поля немає взагалі
const missing = await users.find({ phone: { $exists: false } }).toArray();

Дисципліна read-only тут така сама, як для реляційних БД: із автотесту перевіряємо стан, але не псуємо чужі дані на спільному стенді.

Кейс 2. Eventual consistency: полінг замість sleep

UI-тест створює замовлення через форму, потім читає його статус через API — і зрідка падає, бо читання прилетіло раніше, ніж реплікація доїхала до репліки, з якої читає бекенд. Спокуса поставити sleep(2000) робить тест або повільним, або флакі: лаг реплікації непостійний.

Так робити не треба:

// АНТИПАТЕРН: фіксована пауза під непостійний лаг
await createOrder(page);
await page.waitForTimeout(2000);          // іноді замало, іноді забагато
const res = await request.get(`/api/orders/${id}`);
expect(res.status()).toBe(200);

Правильно — полінг з таймаутом: перевіряємо умову з інтервалом, поки вона не стане істинною або не збіжить час.

import { APIRequestContext, expect } from "@playwright/test";

async function waitForOrder(
  request: APIRequestContext,
  id: string,
  timeoutMs = 10_000,
  intervalMs = 300,
): Promise<void> {
  const deadline = Date.now() + timeoutMs;
  while (Date.now() < deadline) {
    const res = await request.get(`/api/orders/${id}`);
    if (res.status() === 200) return;     // репліка наздогнала — виходимо
    await new Promise((r) => setTimeout(r, intervalMs));
  }
  throw new Error(`Замовлення ${id} не стало видимим за ${timeoutMs} мс`);
}

У Playwright для UI ту саму ідею дає вбудоване очікування з ретраями — воно теж полить, а не спить:

await expect(async () => {
  const res = await request.get(`/api/orders/${id}`);
  expect(res.status()).toBe(200);
}).toPass({ timeout: 10_000, intervals: [300, 500, 1000] });

Що дивитися і чому:

• Лаг непостійний. Під навантаженням реплікація відстає більше, тож будь-яка фіксована пауза — або гальмо, або флак. Полінг чекає рівно стільки, скільки треба.
• Це не баг застосунку. «Запис пропав» одразу після створення — типова eventual consistency: записали на primary, прочитали з репліки до реплікації. Перед баг-репортом перевірте read preference: якщо бекенд читає з secondary, старі дані — очікувані.
• Та сама логіка всюди. «Дочекайся стану, а не спи» працює і в API-, і в UI-тестах: чекаємо на подію, а не на годинник.

Кейс 3. «Тест бачить стару ціну»: таблиця рішень за рівнями

Симптом однаковий — на екрані чи у відповіді стара ціна, хоча бекенд її оновив. Причин щонайменше три, і живуть вони на різних рівнях. Спершу локалізуй рівень за симптомом, а вже потім лізь у логіку.

Швидка перевірка серверного кешу прямо з тесту чи консолі:

import { createClient } from "redis";

const redis = createClient({ url: process.env.REDIS_URL });
await redis.connect();

const cached = await redis.get("price:42");   // що бекенд реально віддає з кешу
const ttl = await redis.ttl("price:42");      // скільки секунд ключ ще житиме
// якщо cached === стара ціна, а ttl великий — винна слабка інвалідація, не логіка

Що дивитися і чому:

• Спершу рівень, потім логіка. Якщо стара версія залежить від браузера — це клієнтський кеш; якщо однакова всюди — серверний кеш або реплікація. Плутати їх означає лікувати не там: чистий контекст Playwright не чіпає Redis усередині бекенда.
• Протухлий кеш — не баг ціни. Бекенд оновив базу, але ключ не інвалідовано або TTL завеликий. Це перевіряється командою TTL, а не переглядом коду розрахунку ціни.
• Зникає само за секунди — це реплікація. Тимчасова розбіжність, що вирівнюється, — ознака eventual consistency, а не втраченого запису. Ловиться полінгом, а не баг-репортом.

SQL vs NoSQL

• Знаю, що NoSQL — не «без схеми», а schema-on-read: сервер перестає відхиляти невалідні дані, а перевірка цілісності переїхала з бази в застосунок і стала роботою QA.
• Розумію різницю ACID vs BASE: строга транзакція проти «basically available, soft state, eventual consistency».
• Можу спростувати кліше «SQL надійний, NoSQL швидкий»: PostgreSQL має JSONB, MongoDB — ACID-транзакції з 4.0, а швидкодія залежить від патерну доступу.

Типи NoSQL

• Знаю чотири моделі — документна, ключ-значення, ширококолонкова, графова — з прикладом і застосуванням кожної.
• Не зливаю Redis і MongoDB в одне: ключ-значення для кешу/сесій vs документне сховище для гнучких сутностей.
• Розумію, що перед тестуванням треба з'ясувати саме тип моделі й гарантію консистентності в цій конфігурації.

MongoDB і гнучка схема

• Знаю, що дані лежать документами (BSON) у колекціях, у кожного є _id типу ObjectId, а запит — це фільтр-документ, не SQL.
• Можу пояснити, чому find нічого не повертає при розбіжності типів: MongoDB не приводить рядок до числа мовчки (і ObjectId не дорівнює рядку).
• Розумію гнучку схему як окремий клас багів: різні поля в документах однієї колекції, undefined на старих даних, перейменування без міграції, а також пастку null проти відсутнього поля (рівність із null ловить обидва стани, розрізняють їх $exists/$type).
• Пам'ятаю, що $jsonSchema-валідація опційна й часто вимкнена, тож узгодженість документів перевіряю сам, дотримуючись read-only на спільних стендах.

Redis як кеш

• Розумію cache-aside (спершу кеш, за промаху — база, результат назад у кеш) і що TTL (SET ... EX, TTL) — це «пасивна» інвалідація протягом вікна, а не миттєва.
• Можу назвати три причини протухлого кешу: завеликий TTL без інвалідації, забутий крок «оновити/видалити ключ», гонка між читанням із бази й записом у кеш.
• Розрізняю серверний кеш Redis (між застосунком і базою) і браузерний HTTP-кеш: чистий browser context прибирає другий, але не перший.

Eventual consistency

• Можу пояснити реплікацію й eventual consistency: запис на primary, асинхронне розповзання на репліки, лаг реплікації (replication lag) — тож читання з репліки одразу після запису може бути старим, і це не баг.
• Знаю, що write concern задає, скільки вузлів підтверджують запис (з 5.0 — більшість), а read preference — звідки читати (primary vs secondary).
• Тестую видимість запису полінгом з таймаутом, а не sleep: чекаю на подію, а не на годинник.

CAP і PACELC

• Можу розкласти CAP на C/A/P і пояснити, що P неминуча, а не опціональна.
• Розумію, що вибір C проти A виникає лише під час партиції, а на справній мережі система дає і C, і A; орієнтир — MongoDB з primary тяжіє до CP, Cassandra до AP (залежить від конфігурації).
• Можу пояснити PACELC: навіть без збою сильніша узгодженість коштує latency, тож компроміс присутній завжди.
• Вмію відрізнити три рівні «старої версії» — HTTP-кеш браузера, кеш застосунку (Redis), лаг реплікації — і не плутаю, який де лікується.