2009-05-26 3 views
38

मैं SQLite का उपयोग किसी साइट के लिए एक उत्पादन डेटाबेस के रूप में करने पर विचार कर रहा हूं जो शायद 20 एक साथ उपयोगकर्ता प्राप्त करेगा, लेकिन एक चोटी की संभावना के साथ जो इसके कई गुणक हो सकता है (चूंकि साइट खुले इंटरनेट पर पहुंच योग्य होगी और वहां है हमेशा एक संभावना है कि कोई व्यक्ति कहीं एक लिंक पोस्ट करेगा जो साइट पर कई लोगों को एक साथ चला सकता है)।कम ट्रैफिक साइट के लिए उत्पादन डेटाबेस के रूप में SQLite?

SQLite एक संभावना है?

मुझे पता है कि यह आदर्श उत्पादन परिदृश्य नहीं है। मैं केवल यह पूछ रहा हूं कि यह यथार्थवादी संभावना होने के दायरे में है या नहीं।

उत्तर

44

SQLite किसी भी तरह की सहमति का समर्थन नहीं करता है, इसलिए आपको इसे उत्पादन वेबसाइट पर चलाने में समस्या हो सकती है। यदि आप 'लाइटर' डेटाबेस की तलाश में हैं, तो शायद कॉच डीबी जैसे समकालीन ऑब्जेक्ट-दस्तावेज़ स्टोर को आजमाने पर विचार करें।

सभी तरह से SQLlite के खिलाफ विकसित करना जारी है, और आप शायद शुरुआत में इसका उपयोग करने के लिए ठीक हैं। यदि आपको लगता है कि आपके एप्लिकेशन में ट्रैक के नीचे अधिक उपयोगकर्ता हैं, तो आप पोस्टग्रेस या माइस्क्ल में संक्रमण करना चाहते हैं।

SQLlite के लेखक इस on the website पते:

SQLite आमतौर पर मध्यम यातायात वेबसाइटों (जो कहने के लिए है, सभी वेबसाइटों का 99.9%) के लिए कम के लिए डेटाबेस इंजन के रूप में महान काम करेंगे। SQLite संभाल सकने वाले वेब ट्रैफ़िक की मात्रा निश्चित रूप से निर्भर करती है कि वेबसाइट अपने डेटाबेस का कितनी भारी उपयोग करती है। आम तौर पर, किसी भी साइट जो 100K हिट/दिन से कम हो जाती है उसे SQLite के साथ ठीक काम करना चाहिए। 100 के हिट/दिन का आंकड़ा एक रूढ़िवादी अनुमान है, न कि कठोर ऊपरी बाउंड। SQLite को यातायात की मात्रा 10 गुणा के साथ काम करने के लिए प्रदर्शित किया गया है।

SQLite आमतौर पर किसी वेबसाइट पर डेटाबेस बैकएंड के रूप में ठीक काम करेगा। लेकिन यदि आप इतनी व्यस्त हैं कि आप डेटाबेस घटक को एक अलग मशीन पर विभाजित करने की सोच रहे हैं, तो आपको निश्चित रूप से SQLite के बजाय एंटरप्राइज़-क्लास क्लाइंट/सर्वर डेटाबेस इंजन का उपयोग करने पर विचार करना चाहिए।

तो मुझे लगता है कि इसका लंबा और छोटा, इसके लिए जाना है, और यदि यह आपके लिए अच्छा काम नहीं कर रहा है, तो एंटरप्राइज़ क्लास डेटाबेस में संक्रमण करना काफी मामूली है। हालांकि, अपनी स्कीमा पर ध्यान दें और अपने डेटाबेस को विकास और दक्षता के साथ दिमाग में डिज़ाइन करें।


यहाँ एक उत्पादन वेब अनुप्रयोग के लिए SQLite का उपयोग कर के आसपास कुछ अधिक स्वतंत्र टिप्पणी के साथ a thread है। ऐसा लगता है कि इसका उपयोग कुछ मिश्रित परिणामों के साथ किया गया है।


संपादित करें (2014):

के बाद से इस उत्तर पोस्ट किया गया था, SQLite अब सुविधाओं एक multi-threaded mode और write ahead logging mode जो कम मध्यम यातायात साइटों के लिए यह की उपयुक्तता के अपने मूल्यांकन को प्रभावित कर सकते।

चार्ल्स लीफर ने SQLite के WAL (आगे लॉगिंग लिखने) सुविधा के बारे में a blog post लिखा है और उचित उपयोगकेस पर कुछ अच्छी तरह से विचार किए गए विचार हैं।

+0

गति समस्याएं? लेकिन बहुत कम उपयोगकर्ताओं के साथ मुझे नहीं पता कि यह वास्तव में एक मुद्दा है, भले ही यह समवर्तीता की अनुमति न दे। (मुझे केवल डेटाबेस के संबंध में दिलचस्पी है) –

+0

दिलचस्प उद्धरण। बहुत बुरा यह स्क्लाइट के लेखक की तुलना में अधिक स्वतंत्र स्रोत से नहीं है। मैं कुछ बाहरी सत्यापन देखना पसंद करूंगा। –

+0

मुझे लगता है कि वह बहुत स्पष्ट है - वह स्वीकार करता है कि वेब SQLlite के लिए एक आदर्श अनुप्रयोग नहीं है। –

1

मुझे लगता है कि यह आपके पढ़ने/लिखने के अनुपात पर अधिक निर्भर करेगा। यदि यह ज्यादातर डेटाबेस से पढ़ रहा है, तो आप ठीक हो सकते हैं। SQLite में बहु-उपयोगकर्ता लेखन एक समस्या हो सकती है क्योंकि यह डेटाबेस को कैसे लॉक करता है।

+0

क्या आपका मतलब है कि यदि दो एक साथ लिखने का प्रयास किया जाता है, तो यह तब तक लॉक हो जाएगा जब तक कि कोई पूरा नहीं हो जाता है और फिर दूसरे को छोड़ देता है? यह डेटा अखंडता के लिए एक समस्या की तरह नहीं लगता है लेकिन गति के बारे में अधिक है। कम ट्रैफिक वॉल्यूम को देखते हुए, यह सहनशील हो सकता है। –

+0

यह ब्लॉक नहीं करेगा लेकिन SQLITE_BUSY लौटाएगा। यह तय करने के लिए आवेदन पर निर्भर है कि वहां से कैसे आगे बढ़ना है, उदा। थोड़ी देर प्रतीक्षा करें और पुनः प्रयास करें या छोड़ दें और एक त्रुटि लौटाएं। – laalto

+1

वॉल मोड के साथ (आगे लॉगिंग लिखें) एसक्लाइट अधिक प्रदर्शनशील बन गया है, अगर कोई अभी भी रुचि रखता है। – infocyde

0

साइट के उपयोग पर निर्भर करता है। यदि अधिकांश समय आप डेटा पढ़ रहे हैं, तो आप डीबी के लिए बहुत कुछ भी उपयोग कर सकते हैं और अच्छे प्रदर्शन को प्राप्त करने के लिए एप्लिकेशन में डेटा कैश कर सकते हैं।

+0

यह एक बड़ा 'अगर' है। क्या होगा यदि यह सच नहीं है? –

+0

यदि यह सत्य नहीं है, तो आपके प्रश्न में "एक चोटी की संभावना के साथ जो कई गुणक हो सकता है" खंड स्थिति को जोखिम भरा बना देगा। यदि दोनों SQLLite कार्य पर हैं, तो हम दोनों को हमारे संदेह हैं, इसलिए मैंने पहली जगह कैशिंग का सुझाव दिया: यदि आप हिट में बड़ी वृद्धि करते हैं तो इसके प्रदर्शन पर निर्भर होने से बचने के लिए। – Badaro

+0

मैं देखता हूं। लेकिन मैं अपने ऐप में डेटाबेस कार्यक्षमता को अनुमानित करने के विचार के बारे में पागल नहीं हूं। मैं उस काम को डेटाबेस में छोड़ दूंगा। –

5

हम अक्सर आंतरिक डेटाबेस के लिए SQLite का उपयोग करते हैं; कर्मचारी निर्देशिका, घटनाओं का हमारा कैलेंडर, और अन्य इंट्रानेट सेवाएं सभी हल्के डेटाबेस पर चलती हैं। इन ऐप्स को स्केल पर चलाने के लिए यह बड़ी ओवरकिल होगी जो हम "एसएसएल" जैसे "असली" डेटाबेस पर करते हैं। यह विशेष रूप से सच है जब आप कारक करते हैं कि वे एक ही मध्य श्रेणी के कंप्यूटर पर 4 अन्य आभासी मशीनों के साथ चल रहे हैं।

एक बिंदु पर हमारे पास एक बाहरी पक्ष वाली साइट थी जो महीनों के लिए एक स्क्लिट डीबी पर चलती थी जिसमें केवल एक ही रीबूट आवश्यक था। जाहिर है, यह बहुत कम यातायात था, लेकिन यह उसने जो किया उसके लिए अच्छी तरह से रखा।

+0

यह जानना बहुत अच्छा है। धन्यवाद। इस तरह की सकारात्मक प्रतिक्रिया पढ़ने के बाद मैं इस विचार के साथ सहज महसूस कर रहा हूं। –

+0

@carsonwelsh मुझे उम्मीद है कि आप विरोधाभासी प्रतिक्रिया भी मानेंगे;) – Wolf

0

मैं इसे बहुत कम यातायात वेब सर्वर में उपयोग कर रहा हूं (यह एक जीनोमिक डेटाबेस है) और मुझे कोई समस्या नहीं है। लेकिन केवल चयन विवरण हैं, डीबी में कोई लेखन शामिल नहीं है।

1

लोग समवर्ती समस्याओं के बारे में बात करते हैं, लेकिन एसक्लाइट के पास आने वाले अनुरोधों को कैश करने का एक तरीका है और उन्हें कुछ समय इंतजार करना है। यह तुरंत समय सीमा नहीं है।

मैंने डिफ़ॉल्ट टाइमआउट सेटिंग शून्य के बारे में चीजें पढ़ी हैं, जिसका अर्थ है कि यह तुरंत समाप्त हो जाता है और यह बकवास है। शायद लोगों ने इस सेटिंग को समायोजित नहीं किया?

+1

समेकन और वितरित सर्वरों के बारे में सोचें उदाहरण के लिए लोड बैलेंसर्स और एकाधिक डेटाबेस हैं। यह वह जगह है जहां स्क्लाइट काम नहीं करता है। अपने आप पर, यह एक स्टैंडअलोन समाधान के रूप में बहुत अच्छा है। मैं इसका उपयोग करता हूं :) – radtek

+0

कुछ हद तक पुराना हो सकता है [WAL] (https://www.sqlite.org/wal.html "लिखें-आगे लॉगिंग") – Wolf

0

पहले से ही शानदार उत्तर में जोड़ने के लिए: चूंकि आप इस मामले में सर्वर-कम समाधान के साथ काम कर रहे हैं, इसलिए आप प्रतिकृति, या अपने डीबी के क्षैतिज स्केलिंग के साथ-साथ अन्य उन्नत विकल्पों के अलविदा कह सकते हैं। यदि आपके पास एकाधिक उपयोगकर्ता जानकारी के समान सटीक हिस्से को अद्यतन करते हैं तो यह भी सबसे अच्छा विकल्प नहीं है। यदि आप भविष्य में डेटाबेस को शेड करना चाहते हैं तो आपको डेटा माइग्रेट करना होगा और किसी और चीज़ पर जाना होगा। इसके अलावा यदि आपके पास लोड बैलेंसर और एकाधिक सिस्टम शामिल हैं तो स्क्लाइट का उपयोग करते हुए डेटा केंद्रीयता को बनाए रखना मुश्किल होगा। ये कुछ कारण हैं जिनकी सिफारिश नहीं की जाती है। छोटी परियोजनाओं के लिए यह महान है, और विकास के लिए महान है।

2

हमें के साथ पर्यावरण पर एक समान विकल्प का सामना करना पड़ा है, बिल्कुल कोई नहीं लिखता है, और हमने SQLite का उपयोग करके चुना है।

देखें मेरी इस विषय पर blog post:

खैर, मुख्य धारणा जो इस समाधान बनाता है सैद्धांतिक रूप से संभव है कि हमारी SQLite डेटाबेस पूरी तरह से केवल पढ़ने के लिए। हमारे सर्वर कोड को कभी भी नहीं बदला जाना चाहिए। यह किसी भी लॉकिंग समस्याओं को हल करेगा, के रूप में कोई पढ़ा ताला नहीं है। हम इंटरनेट पर कहीं भी कह सकते हैं कि पर SQLite के उच्च-थ्रूपुट पढ़ने में कोई समस्या नहीं है, कोई लिख नहीं है - यह संभव हो सकता है!

+0

दिलचस्प उपयोग केस पेश किया गया था। आपका ब्लॉग पोस्ट 11 अक्टूबर, 2014 से डेटिंग कर रहा है। क्या आप कहेंगे कि यह अद्यतित है या आज कुछ महत्वपूर्ण नई याद आ रही है? – Wolf

+0

@ वुल्फ - मुझे नहीं पता कि यह अद्यतित है (उदाहरण के लिए मैं वाल से परिचित नहीं हूं), लेकिन धारणाओं के साथ अभी भी, मुझे लगता है कि निष्कर्ष अभी भी वही है। –

7

SQLite website से छोटा अंश यह सब कहता है।

  • डेटा एक नेटवर्क के द्वारा आवेदन से अलग है?→ क्लाइंट/सर्वर

  • कई समवर्ती लेखकों चुनें? → क्लाइंट/सर्वर

  • बिग डेटा चुनें? → क्लाइंट/सर्वर

  • अन्यथा → SQLite चुनें!

SQLite "सिर्फ काम करता है"।

+0

*** SQLite "बस काम करता है"। *** - यह एक अच्छा * शुरुआती बिंदु * हो सकता है। एसक्यूएलएट काम करने के लिए बंद होने पर क्या होता है, इसके बारे में सोचना और अधिक दिलचस्प नहीं है, उदाहरण के लिए यदि यातायात बढ़ता है। क्या बाद में डीबीएमएस को बदलना भी आसान होगा? – Wolf

0

ऐसा लगता है कि क्यूइंग के साथ आप SQLite के साथ समेकन लेखन समस्याओं से बचने के साथ भी दूर हो सकते हैं। सीधे एसक्लाइट डीबी को लिखने के बजाय आप एक कतार में लिखेंगे जो बदले में क्रमशः पहले आउट मोड में स्क्लाइट डीबी को लिखता है। सुनिश्चित नहीं है कि आपका आवेदन उस स्थान तक पहुंच जाएगा जहां आपको इसकी आवश्यकता होगी यदि यह लिखने योग्य होगा या केवल क्लाइंट/सर्वर डीबी पर जा रहा है ... लेकिन एक विचार।

संबंधित मुद्दे