मैं एक वेब ऐप पर काम कर रहा हूं जो कहीं ईमेल सेवा और सोशल नेटवर्क के बीच है। मुझे लगता है कि भविष्य में वास्तव में बड़ा होने की संभावना है, इसलिए मैं स्केलेबिलिटी के बारे में चिंतित हूं।चरम शार्ड्स: प्रति उपयोगकर्ता एक SQLite डेटाबेस
एक केंद्रीकृत MySQL/InnoDB डेटाबेस का उपयोग करने के बजाय और फिर उस समय विभाजन करते समय इसे विभाजित करने के बजाय, मैंने प्रत्येक सक्रिय उपयोगकर्ता के लिए एक अलग SQLite डेटाबेस बनाने का निर्णय लिया है: एक सक्रिय उपयोगकर्ता प्रति 'shard'।
इस तरह डेटाबेस का बैक अप लेना प्रत्येक उपयोगकर्ता के छोटे डेटाबेस फ़ाइल को एक दिन में एक दूरस्थ स्थान पर कॉपी करने जितना आसान होगा।
स्केलिंग अप नई फ़ाइलों को स्टोर करने के लिए अतिरिक्त हार्ड डिस्क जोड़ने जितना आसान होगा।
जब ऐप एक सर्वर से आगे बढ़ता है तो मैं सर्वर को ग्लस्टरफ़रों का उपयोग करके फाइल सिस्टम स्तर पर एक साथ जोड़ सकता हूं और ऐप को अपरिवर्तित चला सकता हूं, या एक साधारण SQLite प्रॉक्सी सिस्टम को रिग कर सकता हूं जो प्रत्येक सर्वर को आसन्न सर्वरों में स्क्लाइट फ़ाइलों में हेरफेर करने की अनुमति देगा ।
Concurrency समस्या न्यूनतम होगी क्योंकि प्रत्येक HTTP अनुरोध केवल एक या दो डेटाबेस फ़ाइलों को हजारों में से स्पर्श करेगा, और SQLite केवल वैसे भी पढ़ता है।
मैं शर्त लगा रहा हूं कि यह दृष्टिकोण मेरे ऐप को शानदार तरीके से स्केल करने और बहुत अच्छे और अद्वितीय सुविधाओं का समर्थन करने की अनुमति देगा। क्या मैं गलत सट्टा कर रहा हूँ? क्या मुझे कुछ याद आ रही है?
अद्यतन मैंने कम चरम समाधान के साथ जाने का फैसला किया, जो अभी तक ठीक काम कर रहा है। मैं सटीक होने के लिए 256 वर्गमीटर डेटाबेस की एक निश्चित संख्या का उपयोग कर रहा हूं। प्रत्येक उपयोगकर्ता को सरल हैश फ़ंक्शन द्वारा यादृच्छिक शार्ड को सौंपा गया है और बाध्य किया गया है।
मेरे ऐप की अधिकांश सुविधाओं अनुरोध के अनुसार सिर्फ एक या दो टुकड़े करने के लिए उपयोग की आवश्यकता होती है, लेकिन वहाँ विशेष रूप से एक है कि 256 में से 10 से 100 विभिन्न टुकड़ों पर एक साधारण क्वेरी के निष्पादन की आवश्यकता है, उपयोगकर्ता के आधार पर है। टेस्ट इंगित करते हैं कि राम में सभी डेटा कैश किए जाने पर इसमें 0.02 सेकेंड या उससे कम समय लगेगा। मुझे लगता है कि मैं उसके साथ रह सकता हूँ!
अद्यतन 2.0 मैं MySQL/InnoDB एप्लिकेशन को मोड़ा और नियमित रूप से अनुरोध के लिए एक ही प्रदर्शन के बारे में प्राप्त करने में सक्षम था, लेकिन यह है कि एक अनुरोध है कि ठीकरा चलने की आवश्यकता है के लिए, InnoDB 4-5 बार तेज है। इस कारण से, और अन्य कारणों से, मैं इस वास्तुकला को छोड़ रहा हूं, लेकिन मुझे आशा है कि किसी को कहीं इसके लिए उपयोग मिल जाएगा ... धन्यवाद।
यह एक नहीं बल्कि पुराने पोस्ट है, और Gluster साथ अपने अनुभव को शायद अब भी प्रासंगिक नहीं है, लेकिन आप अंत किया GlusterFS से अधिक SQLite की कोशिश कर रहा? – jberryman
इस तरह के एक वास्तुकला पर अनुसंधान पर विचार लोगों के लिए, मैं खुला स्रोत actordb देखने की सलाह देते; प्रत्येक अभिनेता एक SQLite साइलो है और साइलो वितरित कर रहे हैं और बेड़ा प्रोटोकॉल का उपयोग दोहराया - http://www.actordb.com/ –