Що таке реалістичний, реальний, максимальний розмір для бази даних SQLite?

Згідно з цією статтею про відповідне використання для SQLite, в ній сказано, що, хоча SQLite обмежена 140 терабайт , RDBMS клієнт / сервер може працювати краще:

База даних SQLite обмежена розміром до 140 терабайт (2 ⁴⁷ байт, 128 тибібайт). І навіть якщо він може працювати з більшими базами даних, SQLite зберігає всю базу даних в одному файлі диска, і багато файлових систем обмежують максимальний розмір файлів чимось меншим, ніж це. Отже, якщо ви розмірковуєте з базами даних такого масштабу, вам було б добре подумати про використання двигуна бази даних клієнт / сервер, який поширює його вміст по декількох дискових файлах і, можливо, по декількох томах.

Взагалі я з цим погоджуюся, але з подивом дізнався, що максимальний ліміт SQLite був настільки високим! На моєму досвіді я використав досить багато баз даних SQL Server розміром ~ 30-100 ГБ. Я також опосередковано працював із значно більшими базами даних за допомогою Oracle, Postgres або Cassandra. З них, принаймні, наскільки мені відомо, жоден не наближався до 140 ТБ. Я не DBA, тому це я б вважав "великим" зі свого прямого досвіду.

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

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

Реалістичний ліміт (розміру деякої бази даних Sqlite) такий самий, як і реалістичний межа для файлу даних. І ця межа залежить багато від вашого комп'ютера та системи. На моєму нинішньому робочому столі Linux я не можу дозволити собі значно більший розмір, ніж файл 350 Гбайт (тому що, як правило, я уникаю, щоб один файл з'їв більше половини дискового розділу). До речі, цей практичний ліміт також впливає на інші SQL RDBMS, такі як PostGreSQL або MariaDB (але більшість із них зберігають дані у кількох файлах, які ви можете зберігати в різних файлових системах, а деякі з них здатні керувати розподіленими даними на віддалених машинах .. .)

Прочитавши цю статтю, я все ще не переконаний ніколи вважати SQLite тим, що може вимагати сотні гігабайт

Ви маєте рацію і неправильно.

Ви маєте рацію, адже на сьогоднішньому комп’ютері (ноутбуки та настільні комп’ютери, а не суперкомп'ютери та сервери центрів обробки даних) сто гігабайт все ще є досить великим дисковим простором. Тож на практиці, якщо ви думаєте про таку велику базу даних, вам краще уявити справжній сервер SQL (à la PostGreSQL), зокрема, тому що, можливо, ви хочете дуже ймовірно віддалений доступ, ефективно одночасний доступ і, ймовірно, розподілені дані та таблиці.

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

Я, звичайно, хотів би (іноді) вважати SQLite для баз даних кількох десятків гігабайт (і я спробував одного разу настільки великий .sqliteфайл, IIRC об'ємом 40 Гбайт). На поточних (не суперкомп'ютерних) машинах я б вагався з наявністю багатьох сотень гігабайт бази даних SQLite, просто тому, що такий файл досить великий за сьогоднішньої практики.

IIRC, якийсь постачальник апаратних засобів, що продає спеціалізовані файлові системи, не раз говорив мені про терабайтний додаток sqlite (але я можу помилятися).

Звичайно, ефективність SQLite залежить (як і всі бази даних SQL) від великої кількості та ширини таблиць, їх індексів, залучених запитів SQL. І ви не хочете мати одночасний доступ (за допомогою багатьох різних процесів), і вам слід скористатися транзакціями (за досвідом, навіть у крихітній базі даних SQLITE, що має кілька мегабайт, ви дійсно хочете обернути свої тисячі запитів на вставку BEGIN TRANSACTION& & END TRANSACTION, не робити це - уповільнює Sqlite великим фактором -більше 10x-).

І за особистим досвідом, з відповідною конфігурацією та організацією, SQLite здатний керувати базою даних, більшою, ніж наявна оперативна пам’ять (тому 30 Гбайт - це не проблема) - але ви, мабуть, хочете, щоб індекси вміщувалися в оперативній пам'яті!

Якщо вам трапляється кодувати щось для «суперкомп'ютера» або дорогої робочої станції (наприклад, 512 Гбайт оперативної пам’яті та 8 Тбайт диска та 512 Гбайт SSD), ви, безсумнівно, можете мати терабайтну базу даних Sqlite. Але ви хочете зробити це, можливо, лише якщо один (або дуже мало) процес (и) має доступ до цієї бази даних. Якщо у вас є десяток процесів, які одночасно отримують доступ до однієї бази даних, краще встановіть справжній RDBMS SQL (à la MariaDB або PostGreSQL)

Також зауважте, що хоча (бінарний) формат .sqliteфайлів баз даних задокументований як "портативний", я набагато віддаю перевагу резервного копіювання баз даних у текстовому форматі SQL (використовуючи sqlite3 mydb.sqlite .dump > mydb.sql). Тоді мені також потрібен додатковий простір на диску для цього текстового дампа (і це знижує реалістичну межу).

Зазвичай Sqlite не є вузьким місцем. Але диск може бути.

PS. Це ж міркування можна застосувати до великих індексованих файлів за допомогою GDBM .

^{PPS. У моєму відділенні expjs ( вересень 2016 року ) мого монітора MELT (вільне програмне забезпечення GPLv3, на github) я зберігаю всю купу додатків у JSON всередині нової бази даних Sqlite. Я провів крихітні експерименти з кількома мільйонами об'єктів (досить "великими") без поганих сюрпризів. YMMV.}