2008-09-24 10 views
28

मैं एक वेब ऐप पर काम कर रहा हूं जो कहीं ईमेल सेवा और सोशल नेटवर्क के बीच है। मुझे लगता है कि भविष्य में वास्तव में बड़ा होने की संभावना है, इसलिए मैं स्केलेबिलिटी के बारे में चिंतित हूं।चरम शार्ड्स: प्रति उपयोगकर्ता एक SQLite डेटाबेस

एक केंद्रीकृत MySQL/InnoDB डेटाबेस का उपयोग करने के बजाय और फिर उस समय विभाजन करते समय इसे विभाजित करने के बजाय, मैंने प्रत्येक सक्रिय उपयोगकर्ता के लिए एक अलग SQLite डेटाबेस बनाने का निर्णय लिया है: एक सक्रिय उपयोगकर्ता प्रति 'shard'।

इस तरह डेटाबेस का बैक अप लेना प्रत्येक उपयोगकर्ता के छोटे डेटाबेस फ़ाइल को एक दिन में एक दूरस्थ स्थान पर कॉपी करने जितना आसान होगा।

स्केलिंग अप नई फ़ाइलों को स्टोर करने के लिए अतिरिक्त हार्ड डिस्क जोड़ने जितना आसान होगा।

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

Concurrency समस्या न्यूनतम होगी क्योंकि प्रत्येक HTTP अनुरोध केवल एक या दो डेटाबेस फ़ाइलों को हजारों में से स्पर्श करेगा, और SQLite केवल वैसे भी पढ़ता है।

मैं शर्त लगा रहा हूं कि यह दृष्टिकोण मेरे ऐप को शानदार तरीके से स्केल करने और बहुत अच्छे और अद्वितीय सुविधाओं का समर्थन करने की अनुमति देगा। क्या मैं गलत सट्टा कर रहा हूँ? क्या मुझे कुछ याद आ रही है?

अद्यतन मैंने कम चरम समाधान के साथ जाने का फैसला किया, जो अभी तक ठीक काम कर रहा है। मैं सटीक होने के लिए 256 वर्गमीटर डेटाबेस की एक निश्चित संख्या का उपयोग कर रहा हूं। प्रत्येक उपयोगकर्ता को सरल हैश फ़ंक्शन द्वारा यादृच्छिक शार्ड को सौंपा गया है और बाध्य किया गया है।

मेरे ऐप की अधिकांश सुविधाओं अनुरोध के अनुसार सिर्फ एक या दो टुकड़े करने के लिए उपयोग की आवश्यकता होती है, लेकिन वहाँ विशेष रूप से एक है कि 256 में से 10 से 100 विभिन्न टुकड़ों पर एक साधारण क्वेरी के निष्पादन की आवश्यकता है, उपयोगकर्ता के आधार पर है। टेस्ट इंगित करते हैं कि राम में सभी डेटा कैश किए जाने पर इसमें 0.02 सेकेंड या उससे कम समय लगेगा। मुझे लगता है कि मैं उसके साथ रह सकता हूँ!

अद्यतन 2.0 मैं MySQL/InnoDB एप्लिकेशन को मोड़ा और नियमित रूप से अनुरोध के लिए एक ही प्रदर्शन के बारे में प्राप्त करने में सक्षम था, लेकिन यह है कि एक अनुरोध है कि ठीकरा चलने की आवश्यकता है के लिए, InnoDB 4-5 बार तेज है। इस कारण से, और अन्य कारणों से, मैं इस वास्तुकला को छोड़ रहा हूं, लेकिन मुझे आशा है कि किसी को कहीं इसके लिए उपयोग मिल जाएगा ... धन्यवाद।

+0

यह एक नहीं बल्कि पुराने पोस्ट है, और Gluster साथ अपने अनुभव को शायद अब भी प्रासंगिक नहीं है, लेकिन आप अंत किया GlusterFS से अधिक SQLite की कोशिश कर रहा? – jberryman

+0

इस तरह के एक वास्तुकला पर अनुसंधान पर विचार लोगों के लिए, मैं खुला स्रोत actordb देखने की सलाह देते; प्रत्येक अभिनेता एक SQLite साइलो है और साइलो वितरित कर रहे हैं और बेड़ा प्रोटोकॉल का उपयोग दोहराया - http://www.actordb.com/ –

उत्तर

25

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

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

तुम भी फाइल सिस्टम संसाधनों के लिए बाहर देखने की जरूरत है सकते हैं, लेकिन आप कुछ कैशिंग और लेखन लाभ प्राप्त करते हैं जब एक "मानक डेटाबेस" का उपयोग (अर्थातMySQL, PostgreSQL, आदि) क्योंकि वे कैसे डिज़ाइन किए गए हैं। आपके प्रस्तावित डिज़ाइन में, आप उनमें से कुछ पर गायब हो जाएंगे।

+2

यह एक अच्छा जवाब है। एक अतिरिक्त विचार "पैमाने की अर्थव्यवस्था" है - डेटा जैसे डेटा के साथ रखा गया डेटा कुशल कंप्रेशन के लिए अनुमति देता है, बहुत बेहतर डिस्क उपयोग (जिसे आपने कैश टिप्पणी के साथ संकेत दिया हो), और भी बहुत कुछ। – SquareCog

+0

मुझे कुछ इसी तरह का सामना करना पड़ रहा है। मैं डीबी 4o और डीबी 4o का उपयोग कर रहा हूं मूल रूप से संपूर्ण डेटाबेस को पूछताछ के लिए स्मृति में लोड करता है। इसलिए मैंने सोचा कि यह प्रति उपयोगकर्ता एक डीबी रखना और डीबी को गतिशील रूप से स्मृति में लोड करना अधिक कुशल होगा और एक बार एक विशाल डीबी लोड नहीं करेगा। इस मामले पर कोई विचार – Jigzat

6

मुझे रखरखाव दुःस्वप्न की तरह लगता है। क्या होता है जब स्कीमा उन सभी डीबी पर बदल जाती है?

+0

स्कीमा परिवर्तन गतिशील रूप से तैयार की जा सकती है। सुविधा का उपयोग करने वाले नए एप्लिकेशन कोड सक्षम होने से पहले संगत स्कीमा परिवर्तन (जैसे कॉलम जोड़ना) एक सप्ताह में एक बार एक उपयोगकर्ता को लुढ़काया जा सकता है। असंगत परिवर्तन शुरू किया जा सकता है के रूप में प्रत्येक डेटाबेस फ़ाइल खोला जाता है। कोई डाउनटाइम नहीं –

+1

ऐसा लगता है कि यह फोगबगज़ के लिए कोई समस्या नहीं है, जहां प्रत्येक क्लाइंट का अपना SQL सर्वर डेटाबेस होता है ... –

+0

कोई समस्या नहीं है यदि आपका स्कीमा माइग्रेशन स्वचालित रूप से संभाला जाता है।हाथ से करने के लिए मुश्किल लेकिन फिर आप प्रलोभन से बचने के लिए कठिन डेटाबेस उत्पादन मैनुअल अपडेट करना चाह सकते हैं। –

3

यदि आप प्रत्येक उपयोगकर्ता के लिए एक अलग डेटाबेस बना रहे हैं, तो ऐसा लगता है कि आप संबंध स्थापित नहीं कर रहे हैं ... तो एक रिलेशनल डेटाबेस का उपयोग क्यों करें?

+0

अच्छा प्रश्न। प्रत्येक उपयोगकर्ता के डेटाबेस के भीतर संबंध * होते हैं। साथ ही, SQLite आपको एक से अधिक डेटाबेस से तालिकाओं के साथ 'ATTACHING' एक डेटाबेस को अन्य डेटाबेस में निष्पादित करने की अनुमति देता है। –

1

यदि आपका डेटा शेड करना आसान है, तो मानक डेटाबेस इंजन का उपयोग क्यों न करें, और यदि आप पर्याप्त बड़े पैमाने पर स्केल करते हैं तो डीबी बाधा बन जाती है, अलग-अलग उपयोगकर्ताओं के साथ अलग-अलग उपयोगकर्ताओं के साथ डेटाबेस को शेड करता है? प्रभाव वही है, लेकिन आप छोटे छोटे डेटाबेस का उपयोग नहीं कर रहे हैं।

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

4

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

इस समस्या का एक संभव समाधान "minishards" 100 उपयोगकर्ता प्रत्येक अप करने के लिए हो सकता है 1024 SQLite डेटाबेस आवास से मिलकर तैयार करना है। यह डीबी प्रति उपयोगकर्ता दृष्टिकोण से अधिक कुशल होगा, क्योंकि डेटा अधिक कुशलता से पैक किया जाता है। और Innodb डेटाबेस सर्वर दृष्टिकोण से हल्का, क्योंकि हम स्क्लाइट का उपयोग कर रहे हैं।

Concurrency भी बहुत अच्छा होगा, लेकिन प्रश्न कम सुरुचिपूर्ण (shard_id yuckiness) होगा। तुम क्या सोचते हो?

1

प्रति उपयोगकर्ता एक डेटाबेस होने से व्यक्तिगत उपयोगकर्ता डेटा को बहाल करना वास्तव में आसान हो जाएगा, लेकिन @John ने कहा, स्कीमा परिवर्तनों के लिए कुछ काम की आवश्यकता होगी।

यह मुश्किल है, लेकिन यह गैर तुच्छ बनाने के लिए पर्याप्त बनाने के लिए पर्याप्त नहीं है।

2

मैं इस वास्तुकला पर विचार कर रहा हूं क्योंकि मैं मूल रूप से सर्वर पक्ष SQLLIte डेटाबेस का उपयोग बैकअप और ग्राहकों के लिए सिंकिंग प्रतिलिपि के रूप में करना चाहता था। सभी डेटा में क्वेरी करने के लिए मेरा विचार पूर्ण-पाठ खोज के लिए स्फिंक्स का उपयोग और लिपिक से सभी डेटा के फ्लैट डंप से Hadoop नौकरियों को चलाने और उसके बाद webservies के रूप में परिणाम को बेनकाब करने के लिए है। यह पोस्ट मुझे विचार के लिए कुछ रोक देता है, इसलिए मुझे उम्मीद है कि लोग अपनी राय के साथ प्रतिक्रिया देना जारी रखेंगे।

4

http://freshmeat.net/projects/sphivedb

SPHiveDB SQLite डेटाबेस के लिए एक सर्वर है। यह SQLite डेटाबेस का उपयोग करने के लिए नेटवर्क इंटरफेस का पर्दाफाश करने के लिए HTTP पर JSON-RPC का उपयोग करता है। यह एक फ़ाइल में एकाधिक SQLite डेटाबेस संयोजन का समर्थन करता है। यह कई फाइलों के उपयोग का भी समर्थन करता है। यह चरम शेरिंग स्कीमा के लिए डिज़ाइन किया गया है - प्रति उपयोगकर्ता एक SQLite डेटाबेस।

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

  • कोई संबंधित समस्या नहीं^_^