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

В соответствии с этой статьей о подходящем использовании для SQLite говорится, что, хотя SQLite ограничен 140 терабайтами , клиент-серверная СУБД может работать лучше:

Размер базы данных SQLite ограничен 140 терабайтами (2 ⁴⁷ байт, 128 тибибайт). И даже если он может обрабатывать большие базы данных, SQLite хранит всю базу данных в одном файле на диске, и многие файловые системы ограничивают максимальный размер файлов чем-то меньшим, чем это. Поэтому, если вы рассматриваете базы данных такого масштаба, вам лучше рассмотреть возможность использования механизма клиент-серверной базы данных, который распределяет свой контент по нескольким дисковым файлам и, возможно, по нескольким томам.

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

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

После прочтения этой статьи я все еще не убежден, что когда-либо рассматривал SQLite для всего, что может потребовать сотен гигабайт. Но мне интересно, недооценил ли я его возможности. Каково реалистичное ограничение максимального размера для базы данных SQLite в реальных условиях?

Реалистичный предел (размера некоторой базы данных Sqlite) такой же, как реалистичный предел для файла данных. И этот предел зависит от вашего компьютера и системы. На моем текущем рабочем столе Linux я не могу позволить себе намного больший, чем 350-гигабайтный файл (потому что, как правило, я избегаю, чтобы один единственный файл занимал более половины раздела диска). Кстати, этот практический предел также влияет на другие СУБД SQL, такие как PostGreSQL или MariaDB (но большинство из них хранят данные в нескольких файлах, которые вы можете хранить в разных файловых системах, а некоторые из них могут управлять распределенными данными на удаленных машинах. .)

После прочтения этой статьи я все еще не убежден, что когда-либо буду рассматривать SQLite для всего, что может потребовать сотен гигабайт.

Вы правы и неправы.

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

Вы (в принципе, я никогда не пытался) ошибаться, потому что весьма вероятно, что SQLite способен (и иногда тестируется) работать с базой данных объемом в несколько сотен гигабайт, предполагая, что у вас есть файловая система, способная работать с таким большим файлом (и, вероятно, двумя их по крайней мере).

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

IIRC, какой-то производитель оборудования, продающий специализированные файловые системы, говорил мне когда-то о терабайтном sqlite-приложении (но я могу ошибаться).

Конечно , производительность SQLite зависит (как и все базы данных SQL) много числа и ширины таблиц, их индексов, запросов SQL участвующих. И вы не хотите иметь одновременный доступ (многими различными процессами), и вы должны использовать транзакцию (по опыту, даже для крошечной базы данных SQLITE размером в несколько мегабайт, вы действительно хотите обернуть свои, например, тысячу запросов на вставку с помощью BEGIN TRANSACTION& END TRANSACTIONотсутствие этого замедляет Sqlite в большей степени (более чем в 10 раз).

И по собственному опыту, с подходящей конфигурацией и организацией, SQLite может управлять базой данных, превышающей доступную оперативную память (поэтому 30 Гбайт не проблема), но вы, вероятно, хотите, чтобы индексы помещались в ОЗУ!

Если вам придётся что-то кодировать для «суперкомпьютера» или дорогостоящей рабочей станции (например, с 512 ГБ ОЗУ и 8 ТБ диска и 512 ГБ SSD), у вас наверняка может быть база данных Sqlite терабайт. Но вы захотите сделать это, возможно, только если один (или очень немногие) процесс (ы) обращаются к этой базе данных. Если у вас есть дюжина процессов, одновременно обращающихся к одной и той же базе данных, лучше установить настоящую СУБД SQL (как MariaDB или PostGreSQL)

Также обратите внимание, что хотя (двоичный) формат .sqliteфайлов баз данных задокументирован как «переносимый», я предпочитаю создавать резервные копии баз данных в текстовом формате SQL (используя sqlite3 mydb.sqlite .dump > mydb.sql). Затем мне также нужно дополнительное дисковое пространство для этого текстового дампа (и это снижает реалистичный предел).

Обычно Sqlite не является узким местом. Но диск может быть.

PS. Те же рассуждения могут быть применены к большим индексированным файлам с использованием GDBM .

^{PPS. В моей ветке expjs ( сентябрь 2016 ) моего монитора MELT (свободное программное обеспечение GPLv3, на github) я сохраняю всю кучу приложений в JSON внутри свежей базы данных Sqlite. Я провел крошечные эксперименты с несколькими миллионами объектов (довольно «больших») без неприятных сюрпризов. YMMV.}