यथार्थवादी सीमा (कुछ Sqlite डेटाबेस के आकार की) डेटा फ़ाइल के लिए यथार्थवादी सीमा के समान है। और यह सीमा आपके कंप्यूटर और सिस्टम पर निर्भर करती है। मेरे वर्तमान लिनक्स डेस्कटॉप पर मैं 350Gbyte फ़ाइल की तुलना में बहुत बड़ा नहीं हो सकता (क्योंकि अंगूठे के नियम के रूप में मैं एक सिंगल फाइल को आधे से अधिक डिस्क विभाजन खाने से बचता हूं)। BTW, उस व्यावहारिक सीमा का असर अन्य SQL RDBMS जैसे PostGreSQL या MariaDB पर भी होता है (लेकिन इनमें से अधिकांश डेटा को कई फ़ाइलों में रख रहे हैं , जिन्हें आप अलग-अलग फ़ाइल सिस्टम पर रख सकते हैं, और उनमें से कुछ दूरस्थ मशीनों पर वितरित डेटा को प्रबंधित करने में सक्षम हैं।) ।)
इस लेख को पढ़ने के बाद मैं अभी भी किसी भी चीज़ के लिए SQLite पर विचार करने के लिए आश्वस्त नहीं हूं जिसके लिए सैकड़ों गीगाबाइट की आवश्यकता हो सकती है
आप सही और गलत हैं।
आप सही हैं, क्योंकि आज के कंप्यूटर (लैपटॉप और डेस्कटॉप पर, सुपर कंप्यूटर या डेटासेंटर सर्वर नहीं), सौ गीगाबाइट अभी भी एक बहुत बड़ी डिस्क स्थान है। तो व्यवहार में, यदि आप इतने बड़े डेटाबेस के बारे में सोचते हैं, तो आप विशेष रूप से एक वास्तविक SQL सर्वर (à la PostGreSQL) की बेहतर कल्पना करेंगे क्योंकि आप शायद बहुत ही सुदूर पहुँच, प्रभावी रूप से समवर्ती पहुँच और शायद वितरित डेटा और टेबल चाहते हैं।
आप कई सौ गीगाबाइट के डेटाबेस से निपटने के लिए बहुत संभवत: SQLite सक्षम (और कभी-कभी परीक्षण किए गए) गलत हैं (सिद्धांत रूप में, मैंने कभी कोशिश नहीं की) हैं, यह मानते हुए कि आपके पास इतनी बड़ी फ़ाइल (और शायद दो में से दो से निपटने में सक्षम एक फाइलसिस्टम है) उन्हें कम से कम)।
मैं निश्चित रूप से (कभी-कभी) कई दर्जनों गीगाबाइट के डेटाबेस के लिए SQLite पर विचार करता हूं (और मैंने एक बार इतनी बड़ी .sqliteफ़ाइल, 40Gbytes के IIRC की कोशिश की थी)। वर्तमान (गैर-सुपर कंप्यूटर) मशीनों पर, मैं SQLite डेटाबेस के कई सौ गीगाबाइट होने में संकोच करूंगा, सिर्फ इसलिए कि इस तरह की फ़ाइल आज के अभ्यास से काफी बड़ी है।
IIRC कुछ हार्डवेयर विक्रेता जो विशेष फाइलसिस्टम मशीनों को बेच रहे थे, उन्होंने मुझे एक टेराबाइट साइक्लाईट एप्लिकेशन के एक बार बोला था (लेकिन मैं गलत हो सकता है)।
बेशक SQLite प्रदर्शन (सभी SQL डेटाबेस की तरह) निर्भर करता है एक बहुत संख्या और टेबल, उनके अनुक्रमित, एसक्यूएल प्रश्नों शामिल की चौड़ाई की। और आप एक साथ (कई अलग-अलग प्रक्रियाओं द्वारा) पहुँच प्राप्त नहीं करना चाहते हैं, और आपको लेन-देन का उपयोग करना चाहिए (अनुभव से, यहां तक कि कुछ मेगाबाइट के एक छोटे SQLITE डेटाबेस पर, आप वास्तव में अपने जैसे प्रविष्टि अनुरोधों के हज़ार को लपेटना चाहते हैं BEGIN TRANSACTION& END TRANSACTION, 10x-) की तुलना में एक बड़े कारक -मोर द्वारा स्केलाइट को धीमा करना।
और व्यक्तिगत अनुभव से, उपयुक्त कॉन्फ़िगरेशन और संगठन के साथ, SQLite उपलब्ध RAM से बड़ा डेटाबेस प्रबंधित करने में सक्षम है (इसलिए 30Gbytes कोई समस्या नहीं है) - लेकिन आप शायद चाहते हैं कि अनुक्रमणिका RAM में फिट हो!
यदि आप एक "सुपर कंप्यूटर" या एक महंगा वर्कस्टेशन के लिए कुछ कोड करने के लिए होते हैं (उदाहरण के लिए 512Gbytes RAM और डिस्क के 8Tbytes और SSD के 512Gbyte) तो आपके पास निश्चित रूप से टेराबाइट सकलाइट डेटाबेस हो सकता है। लेकिन आप ऐसा करना चाहते हैं कि शायद केवल एक (या बहुत कम) प्रक्रिया ही उस डेटाबेस तक पहुंच पा रही है। यदि आपके पास समान डेटाबेस तक पहुँचने की एक दर्जन प्रक्रियाएँ हैं, तो एक वास्तविक SQL RDBMS (A la MariaDB या PostGreSQL) को बेहतर तरीके से स्थापित करें
यह भी ध्यान दें कि .sqliteडेटाबेस फ़ाइलों के द्विआधारी (बाइनरी) प्रारूप को "पोर्टेबल" होने के रूप में प्रलेखित किया गया है, मैं SQL पाठ प्रारूप (उपयोग sqlite3 mydb.sqlite .dump > mydb.sql) में बैकअप डेटाबेस के लिए बहुत पसंद करता हूं । फिर, मुझे उस पाठ्य डंप के लिए कुछ अतिरिक्त डिस्क स्थान की भी आवश्यकता है (और यह यथार्थवादी सीमा को कम करता है)।
आमतौर पर Sqlite अड़चन नहीं है। लेकिन डिस्क हो सकती है।
पुनश्च। जीडीबीएम का उपयोग करके बड़ी अनुक्रमित फ़ाइलों पर एक ही तर्क लागू किया जा सकता है ।
पी पी एस। मेरे में expjs शाखा मेरी पिघल मॉनिटर के (sept.2016) (GPLv3 मुफ्त सॉफ्टवेयर, GitHub पर) मैं कर रहा हूँ बने एक ताजा SQLite डेटाबेस के अंदर JSON में पूरे आवेदन ढेर। मैंने कई लाखों ऑब्जेक्ट्स के साथ छोटे प्रयोग किए हैं (काफी "बड़े") बिना किसी आश्चर्य के। YMMV।