Co to jest realistyczny, rzeczywisty, maksymalny rozmiar bazy danych SQLite?

Zgodnie z tym artykułem na temat odpowiednich zastosowań dla SQLite mówi, że chociaż SQLite jest ograniczony do 140 terabajtów , RDBMS klient / serwer może działać lepiej:

Baza danych SQLite ma ograniczony rozmiar do 140 terabajtów (2 ⁴⁷ bajtów, 128 tibibajtów). I nawet jeśli mógłby obsługiwać większe bazy danych, SQLite przechowuje całą bazę danych w jednym pliku dyskowym, a wiele systemów plików ogranicza maksymalny rozmiar plików do mniejszej niż to. Jeśli więc zastanawiasz się nad bazami danych tej wielkości, dobrze byłoby rozważyć użycie silnika bazy danych klient / serwer, który rozprzestrzenia swoją zawartość na wiele plików dyskowych, a być może na wiele woluminów.

Ogólnie rzecz biorąc, zgadzam się z tym, ale byłem zaskoczony, gdy dowiedziałem się, że maksymalny limit SQLite był tak wysoki! Z mojego doświadczenia korzystałem z kilku baz danych SQL Server o wielkości ~ 30-100 GB. Pracowałem również pośrednio z dużo większymi bazami danych, używając Oracle, Postgres lub Cassandra. Z tych, przynajmniej o ile mi wiadomo, żaden nie zbliżał się do 140 TB. Nie jestem DBA, więc uważam to za „duże” z mojego bezpośredniego doświadczenia.

Rozważyłem SQLite tylko w sytuacjach, w których baza danych byłaby mała; co najwyżej dziesiątki megabajtów.

Po przeczytaniu tego artykułu nadal nie jestem przekonany, aby kiedykolwiek brać pod uwagę SQLite dla czegokolwiek, co mogłoby wymagać setek gigabajtów. Zastanawiam się jednak, czy nie doceniałem jego możliwości. Jaki jest realistyczny limit maksymalnego rozmiaru dla bazy danych SQLite w zastosowaniu w świecie rzeczywistym?

Realistyczny limit (wielkości niektórych baz danych Sqlite) jest taki sam jak realistyczny limit dla pliku danych. A limit ten zależy w dużej mierze od twojego komputera i systemu. Na obecnym pulpicie Linuksa nie stać mnie na plik większy niż 350 GB (ponieważ z zasady unikam, aby jeden plik zjadał więcej niż połowę partycji dysku). BTW, ten praktyczny limit wpływa również na inne SQL RDBMS, takie jak PostGreSQL lub MariaDB (ale większość z nich przechowuje dane w kilku plikach, które możesz przechowywać w różnych systemach plików, a niektóre z nich są w stanie zarządzać rozproszonymi danymi na zdalnych komputerach. .)

Po przeczytaniu tego artykułu nadal nie jestem przekonany, aby kiedykolwiek brać pod uwagę SQLite dla czegokolwiek, co mogłoby wymagać setek gigabajtów

Masz rację i źle.

Masz rację, ponieważ na dzisiejszym komputerze (laptopy i komputery stacjonarne, nie superkomputery ani serwery centrów danych) sto gigabajtów to wciąż dość duża przestrzeń dyskowa. Więc w praktyce, jeśli myślisz o tak dużej bazie danych, lepiej wyobraź sobie prawdziwy serwer SQL (a la PostGreSQL), w szczególności, ponieważ możesz chcieć bardzo prawdopodobnie dostępu zdalnego, efektywnego dostępu współbieżnego i prawdopodobnie rozproszonych danych i tabel.

Mylisz się (w zasadzie nigdy nie próbowałem) źle, ponieważ bardzo prawdopodobne jest, że SQLite jest w stanie (a czasem przetestować) radzić sobie z bazą danych zawierającą kilkaset gigabajtów, zakładając, że masz system plików zdolny poradzić sobie z tak dużym plikiem (i prawdopodobnie dwoma im przynajmniej).

Z pewnością (czasami) rozważałbym SQLite dla baz danych zawierających kilkadziesiąt gigabajtów (i próbowałem kiedyś tak dużego .sqlitepliku, IIRC o wielkości 40 Gb). Na obecnych (nie-superkomputerowych) komputerach wahałbym się, mając setki gigabajtów bazy danych SQLite, po prostu dlatego, że taki plik jest dość duży jak na dzisiejszą praktykę.

IIRC jakiś sprzedawca sprzętu sprzedający maszyny do systemów plików powiedział mi kiedyś o terabajtowej aplikacji sqlite (ale mogę się mylić).

Oczywiście wydajność SQLite zależy (podobnie jak wszystkie bazy danych SQL) od dużej liczby i szerokości tabel, ich indeksów, zapytań SQL. I nie chcesz mieć równoczesnego dostępu (przez wiele różnych procesów) i powinieneś użyć transakcji (z doświadczenia, nawet na małej bazie danych SQLITE o wielkości kilku megabajtów, naprawdę chcesz owinąć swoje np. Tysiące żądań wstawienia za pomocą BEGIN TRANSACTION& END TRANSACTION, nie zrobienie tego spowalnia Sqlite o duży współczynnik - ponad 10x-).

I z własnego doświadczenia, przy odpowiedniej konfiguracji i organizacji, SQLite jest w stanie zarządzać bazą danych większą niż dostępna pamięć RAM (więc 30 GB nie stanowi problemu) - ale prawdopodobnie chcesz, aby indeksy zmieściły się w pamięci RAM!

Jeśli zdarzy się, że kodujesz coś dla „superkomputera” lub kosztownej stacji roboczej (np. 512 GB pamięci RAM i 8 TB dysku i 512 GB SSD), to z pewnością możesz mieć terabajtową bazę danych Sqlite. Ale będziesz chciał to zrobić, może tylko wtedy, gdy jeden (lub kilka) procesów uzyskuje dostęp do tej bazy danych. Jeśli masz kilkanaście procesów uzyskujących dostęp do tej samej bazy danych, lepiej zainstaluj prawdziwy SQL RDBMS (à la MariaDB lub PostGreSQL)

Zauważ też, że chociaż (binarny) format .sqliteplików baz danych jest udokumentowany jako „przenośny”, zdecydowanie wolę tworzyć kopie zapasowe baz danych w formacie tekstowym SQL (za pomocą sqlite3 mydb.sqlite .dump > mydb.sql). Potrzebuję też trochę dodatkowego miejsca na dysku dla tego zrzutu tekstu (i to obniża realistyczny limit).

Zazwyczaj Sqlite nie stanowi wąskiego gardła. Ale dysk może być.

PS. To samo rozumowanie można zastosować do dużych indeksowanych plików przy użyciu GDBM .

^{PPS. W mojej gałęzi expjs ( wrzesień 2016 ) mojego monitora MELT (darmowe oprogramowanie GPLv3, na github) utrzymuję całą stertę aplikacji w JSON w nowej bazie danych Sqlite. Przeprowadziłem małe eksperymenty z kilkoma milionami obiektów (całkiem „dużymi”) bez złych niespodzianek. YMMV.}