Bir SQLite veritabanı için gerçekçi, gerçek dünya, maksimum boyut nedir?

SQLite İçin Uygun Kullanımlar başlıklı bu makaleye göre , SQLite'ın 140 terabayt ile sınırlı olmasına rağmen , bir istemci / sunucu RDBMS'nin daha iyi çalışabileceğini söylüyor :

Bir SQLite veritabanının boyutu 140 terabayt (2 ⁴⁷ bayt, 128 tibibit) ile sınırlıdır. Ve daha büyük veritabanlarını işleyebilse bile, SQLite tüm veritabanını tek bir disk dosyasında depolar ve birçok dosya sistemi maksimum dosya boyutunu bundan daha küçük bir değerle sınırlar. Dolayısıyla, bu büyüklükteki veritabanlarını düşünürseniz, içeriğini birden fazla disk dosyasına ve belki de birden çok birime yayan bir istemci / sunucu veritabanı motoru kullanmayı düşünebilirsiniz.

Genel olarak, buna katılıyorum, ancak SQLite'nin maksimum limitinin çok yüksek olduğunu öğrendiğimde şaşırdım! Deneyimlerime göre ~ 30-100GB boyutunda epeyce SQL Server veritabanları kullandım. Ayrıca Oracle, Postgres veya Cassandra kullanarak daha büyük veritabanlarında dolaylı olarak çalıştım. Bunlardan en azından bildiğim kadarıyla hiçbiri 140 TB'a yaklaşmıyordu. Ben bir DBA değilim, bu yüzden doğrudan tecrübemden dolayı "büyük" olarak kabul ediyorum.

Veritabanının küçük olacağı durumlar için sadece SQLite'ı dikkate aldım; en fazla onlarca megabayt.

Bu makaleyi okuduktan sonra, hala yüzlerce gigabayt gerektirebilecek herhangi bir şey için SQLite'ı düşünmeye ikna olmadım. Ama onun yeteneklerini küçümsemediğimi merak ediyorum. Gerçek dünyada kullanımda bir SQLite veritabanı için gerçekçi bir maksimum boyut sınırı nedir?

Gerçekçi sınır (bazı Sqlite veritabanının boyutunda), bir veri dosyası için gerçekçi sınırla aynıdır. Ve bu sınır, bilgisayarınızın ve sisteminizin çoğuna bağlıdır. Şu anki Linux masaüstümde 350Gbaytlık bir dosyadan çok daha büyük bir miktarımı karşılayamam (çünkü kural olarak, tek bir dosyanın yarısından daha fazla disk bölümü yemekten kaçınıyorum). BTW, bu pratik sınır ayrıca PostGreSQL veya MariaDB gibi diğer SQL RDBMS'leri de etkiler (ancak bunların çoğu , farklı dosya sistemlerinde tutabileceğiniz birkaç dosyada veri saklıyor , bazıları da uzak makinelerde dağıtılmış verileri yönetiyor .. .)

Bu makaleyi okuduktan sonra, hala yüzlerce gigabayt gerektirebilecek herhangi bir şey için SQLite'ı düşünmeye ikna olmadım

Haklısın ve yanlışsın.

Haklısınız, çünkü bugünün bilgisayarında (dizüstü bilgisayarlar ve masaüstü bilgisayarlar, süper bilgisayarlar veya veri merkezi sunucuları değil), yüz gigabayt hala oldukça büyük bir disk alanı. Bu nedenle pratikte, eğer böyle büyük bir veritabanı düşünürseniz, özellikle uzaktan erişim, etkili bir şekilde eşzamanlı erişim ve muhtemelen dağıtılmış veri ve tablolar isteyebileceğiniz için gerçek bir SQL sunucusu (à la PostGreSQL) daha iyi düşünebilirsiniz.

(Prensipte, hiç denemedim) yanlıştır, çünkü çok büyük bir olasılıkla SQLite birkaç yüz gigabaytlık bir veri tabanı ile başa çıkabilmektedir (muhtemelen iki tanesi gibi) en azından onları).

Kesinlikle (bazen) birkaç düzine gigabaytın veritabanları için .sqliteSQLite'yi düşünürdüm (ve bir kez bu kadar büyük bir dosyayı, 40Gbaytlık IIRC'yi denedim). Şu anki (süper bilgisayar dışı) makinelerde, yüzlerce gigabayt SQLite veri tabanına sahip olmaktan çekinmiştim, çünkü bugün böyle bir dosya bugünün uygulaması ile oldukça büyük.

IIRC özel dosya sistemleri satan bazı donanım satıcıları makineleri terabayt sqlite uygulamasından bir kez bana konuştu (ama yanlış olabilir).

Tabii SQLite performansı (tüm SQL veritabanları gibi) bağlı bir çok tablolar, onların endeksler, ilgili SQL sorguları sayısı ve genişliği. Ve (çeşitli süreçlerden geçerek) eşzamanlı erişime sahip istemiyoruz ve hatta birkaç megabayt bir minik SQLITE veritabanında, deneyim (işlem kullanmalısınız, gerçekten ile örneğin yerleştirme taleplerinin bin sarmak istiyorum BEGIN TRANSACTION& END TRANSACTIONBunu yapmamak Sqlite'yi 10x'tan büyük bir faktörle yavaşlatıyor).

Ve kişisel deneyime göre, uygun konfigürasyon ve organizasyon ile SQLite, mevcut RAM'den daha büyük bir veritabanını yönetebilir (bu nedenle 30Gbyte bir sorun değildir) - ancak dizinlerin RAM'e sığmasını istersiniz!

Bir "süper bilgisayar" veya pahalı bir iş istasyonu için bir şey kodlarsanız (örneğin 512Gbayt RAM ve 8Tbayt disk ve 512Gbayt SSD ile) kesinlikle bir terabayt Sqlite veritabanına sahip olabilirsiniz. Ancak, bunu yalnızca bir (veya çok az) işlem bu veritabanına erişiyorsa yapmak isteyeceksiniz. Aynı veritabanına aynı anda erişen bir düzine işlem varsa, gerçek bir SQL RDBMS (à la MariaDB veya PostGreSQL) kurun.

Ayrıca, .sqliteveritabanı dosyalarının (ikili) formatının "taşınabilir" olarak belgelenmesine rağmen, veritabanlarını SQL metin biçiminde (kullanarak sqlite3 mydb.sqlite .dump > mydb.sql) yedeklemeyi tercih ederim . Ardından, bu metin dökümü için ek disk alanına da ihtiyacım var (ve bu, gerçekçi sınırı düşürür).

Genellikle Sqlite tıkanıklık değildir. Ancak disk olabilir.

PS. Aynı sebep, GDBM kullanılarak büyük indeksli dosyalara da uygulanabilir .

^{PPS. Benim içinde expjs dalı (github GPLv3 serbest yazılımlar,) benim ERİME monitörün (sept.2016) ı am devam eden taze bir SQLite veritabanı içinde JSON bütün uygulama yığın. Kötü sürprizler olmadan milyonlarca nesneyle (oldukça "büyük") küçük deneyler yaptım. YMMV.}