База даних на кожного орендаря: розгляньте SQLite

В індустрії SaaS дуже часто використовують архітектуру з окремою базою даних для кожного клієнта. Є кілька причин, чому виникає така архітектура, ось деякі з них:

1. Продукти, що виникли в On-Premises
2. Вимоги до сегрегації даних/безпеки
3. Невелика кількість клієнтів у великих компаній

Основний недолік очевидний ― висока вартість інфраструктури для кожного клієнта.

Ідея мати 100 000 спроб на місяць може викликати гарячі дебати щодо рентабельності для бізнесу, якщо ці потенційні клієнти зазнають потенційних витрат на інфраструктуру.

Отже, ситуація може виглядати так:

1. У вас є архітектура "Окрема база даних для кожного клієнта" з якоїсь причини.
2. Ви хочете розширити вашу воронку, залучаючи більше пробних користувачів.
3. Кожна пробна версія потребує окремої бази даних, що дорого.
4. Це заважає росту бізнесу, що неприємно.
5. Потрібно зменшити витрати на окремі бази даних якнайбільше.

Рішення: SQLite

Здається, що SQLite зараз на піку популярності, оскільки все більше людей розуміють, що їм, ймовірно, не потрібен повний PostgreSQL/MySQL для кожного клієнта, і SQLite може бути використаний замість цього.

Це піднімає питання про підтримку флоту баз даних SQLite. І для цього є кілька комерційних рішень (не даю поради, перевірте перед використанням):

• https://turso.tech/ + https://turso.tech/libsql
• https://blog.cloudflare.com/sqlite-in-durable-objects/

База даних SQLite — це всього лише файл, тому наявність будь-якої кількості "холодних" баз даних генерує тільки витрати на зберігання. Тому це не є проблемою. SQLite як вбудована база даних має малий обсяг пам'яті, тому запуск великої кількості екземплярів SQLite також може бути ефективним. База даних SQLite — це лише один файл — коли вона перевірена — тому створення нового екземпляра з холодного сховища — це просто питання передачі файлу. Нічого складного.

Отже, це виглядає як чудовий варіант — і, ймовірно, це справді так. До певної міри.

SQLite: Єдина вбудована SQL база даних на ринку

Існують інші вбудовані бази даних, такі як H2 або Derby для JVM стека. Але в порівнянні з SQLite вони виглядають покинутими. Сторінка архітектури для H2 повідомляє:

Станом на жовтень 2013 року Томас все ще працює над нашим новим сховищем даних під назвою MVStore. Це з часом замінить сховище на основі B-дерева.

Я перевірив, MVStore є в кодовій базі. Але що завадило авторам оновити документацію протягом останніх 11 років? Я не знаю. Але я вірю, що вони повинні це зробити.

Тим часом H2 безумовно підтримується. Були випуски у 2024 році.

BerkleyDB є ще одним прикладом вбудованої бази даних. Але це база даних типу "ключ-значення". BerkleyDB надає SQL інтерфейс, але це SQLite з BTree backend, який замінено на BerkleyDB backend. Тому, для мене це ще одне підтвердження домінування SQLite.

Але у SQLite є свій особливий стиль

Ось кілька випадкових уривків з вихідного коду SQLite.

Уривок 1:

void *pKey;  
pCur->nKey = sqlite3BtreePayloadSize(pCur);  
pKey = sqlite3Malloc( pCur->nKey + 9 + 8 );  
if( pKey ){  
 rc = sqlite3BtreePayload(pCur, 0, (int)pCur->nKey, pKey);  
 if( rc==SQLITE_OK ){  
 memset(((u8*)pKey)+pCur->nKey, 0, 9+8);  
 pCur->pKey = pKey;  
 }else{  
 sqlite3_free(pKey);  
 }  
}else{  
 rc = SQLITE_NOMEM_BKPT;  
}

Уривок 2:

/* EXCERPT 2*/  

nPayload = *pIter;  
if( nPayload>=0x80 ){  
 u8 *pEnd = &pIter[8];  
 nPayload &= 0x7f;  
 do {  
 nPayload = (nPayload<<7) | (*++pIter & 0x7f);  
 } while( (*pIter)>=0x80 && pIter “If it works don’t touch it.”

І коли код виглядає крихким і важким для зміни, здається дуже привабливим просто додати ще один шар поверх попереднього, а не витрачати зусилля на очищення.

Цікава деталь.
SQLite використовує власну систему контролю версій під назвою Fossil.

SQLite не поганий — він достатньо хороший

SQLite — це перевірене в бою програмне забезпечення. Воно працює дуже добре. Проект має свої пріоритети і суворо їх дотримується. І якщо вам потрібна вбудована база даних з низьким споживанням ресурсів і довгостроковою зворотною сумісністю як основним пріоритетом — SQLite буде рішенням для вас.

Щоб підкреслити, файл бази даних підтримує сумісність з Windows 95:

Сторінка з байтом блокування — це єдина сторінка в файлі бази даних, що містить байти за межами між 1073741824 і 1073742335, включно.
…
Сторінка з байтом блокування виникла через необхідність підтримки Win95, яка була основною операційною системою, коли цей формат файлів був розроблений…

Є довгий список інших поворотів на зворотну сумісність, які впливають на дизайн SQLite. Наприклад, відсутність типу даних boolean. І це робить SQLite хорошим, але не ідеальним.

І, здається, SQLite зайняв свою "солодку" нішу і фактично усунув ринки для потенційних альтернатив. Якщо SQLite достатньо хороший, то навіщо шукати інше рішення? Немає причини. Тому ніхто цього не зробив. І так ми маємо SQLite і більше нічого.

Ще раз. SQLite — це справді гарний інструмент. Те, що погано, це відсутність конкуренції.

Альтернативний вбудований SQL-двигун

Хоча це не є обов'язковим, було б непогано мати альтернативу SQLite, яка вирішить деякі з проблем:

• Чиста SQL-синтаксис, без компромісів, зроблених десятиліття тому
• Розширена підтримка примітивних типів даних: Boolean, Date, Vector/Embedding
• Асинхронний дизайн
• Можливо, різні структури індексів для підвищення ефективності
• Прозорі тестування, внески та ліцензування
• І так далі

На самому ділі, створення вбудованого двигуна бази даних — це здійсненне завдання. І тепер є попит на це на ринку. Можливо, з'явиться щось справді нове. Тримаємо кулаки.

Перекладено з: Database-per-Tenant: Consider SQLite