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

34

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

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

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

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

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

Бен Харрисон
источник
3
Я просто думаю, что мы обычно должны учитывать количество одновременных подключений, так как большие наборы данных часто используются несколькими пользователями. Есть ли у вас способ проверить это на собственной системе, не так ли?
Джефф
3
Для чего-то вроде базы данных заархивированных транзакций, к которой почти никогда не требуется доступ, SQLite может быть отличным выбором, и одновременно будет только один пользователь (если есть), и вам не нужно иметь целое Настройка сервера БД для его поддержки. С другой стороны, если у вас несколько одновременно работающих пользователей, вы можете легко столкнуться с проблемами, связанными с блокировкой, задолго до того, как вы попадете в базу данных с несколькими гигабайтами.
Майкл Кохн
2
@Pacerier - да, для установки программного обеспечения. Затем вам нужно назначить роли БД, выяснить, как интегрировать их в систему резервного копирования, убедиться, что система резервного копирования переводит сервер БД в надлежащее состояние в начале и в конце резервного копирования и т. Д., И т. Д. Настройка сервера БД, чем просто установка программного обеспечения. Кроме того, это еще одна услуга, о которой вам нужно беспокоиться с точки зрения сетевой безопасности, и еще одна вещь, о которой вам нужно следить за исправлениями. Если вам НУЖДАЕТСЯ служба db, во что бы то ни стало, сделайте это, но она вам не нужна, у SQLite намного меньше накладных расходов.
Майкл Кохне
1
@ leeand00 - Или вы можете арендовать помещение на месяц.
Джеффо

Ответы:

26

Реалистичный предел (размера некоторой базы данных 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.

Василий Старынкевич
источник
7
Вы могли бы перестать писать после четвертого абзаца. Но +1 в любом случае.
Роберт Харви
3
Возможно, но я был неприятно очень удивлен, когда заметил, что даже на свежей базе данных sqlite размером всего в несколько мегабайт транзакции так важны на практике (только один процесс обращается к этому новому файлу, фактически записывая его).
Василий Старынкевич
3
Это конечно верно для писем. На практике трудно представить базу данных SQLite с размерами, подобными описанным в OP. Postgresql, вероятно, был бы лучшим выбором не из-за его возможностей по размеру, а из-за промышленного параллелизма, которого нет у SQLite.
Роберт Харви
5
Существует множество законных ситуаций, когда у вас могут быть базы данных SQLite с огромными размерами файлов. От самих разработчиков SQLite: думайте об этом меньше как о замене MySql, а больше как о замене fopen. Написание некоторого программного обеспечения для 3D-CAD и использование баз данных SQLite для хранения данных об объектах может быть вполне разумным.
whatsisname
2
@Pacerier: файлы фильмов и аналогичные двоичные объекты обычно не хранятся в базе данных. Они хранятся в файловой системе, а ссылки на них хранятся в базе данных.
Роберт Харви