स्टार्टअप कंपनी को किस डेटाबेस सिस्टम पर विचार करना चाहिए?

Question

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

यह मैं गैर रिलेशनल डाटाबेस सिस्टम जैसे MongoDB, CouchDB, Cassandra या Hadoop बारे में सोचते हैं बना दिया है। दुर्भाग्य से मुझे या तो कोई अनुभव नहीं है। मैंने मोंगोडीबी पर कुछ अच्छी समीक्षा पढ़ी है और यह दिलचस्प लगती है। मुझे समय बिताने में खुशी है और सीखना है कि क्या कोई रास्ता तय करता है। मैं किसी भी भरोसेमंद डीबीएमएस के साथ जाने पर विचार करने के लिए किसी भी पेशकश बिंदु या मुद्दों की सराहना करता हूं?

Answer 1

यहाँ अन्य उत्तर तकनीकी पहलुओं पर मुख्य रूप से ध्यान केंद्रित किया है पसंद नहीं है, लेकिन मुझे लगता है कि महत्वपूर्ण बिंदुओं बनाया जा रहे हैं चीजों की स्टार्टअप कंपनी पहलू पर कि फोकस:

प्रतिभा का

• Availabililty। MySQL बहुत आम है और आपको अधिक दुर्लभ डेटाबेस सिस्टम की तुलना में डेवलपर्स को खोजने के लिए शायद यह आसान (और अधिक महत्वपूर्ण, सस्ता) मिल जाएगा। इस बड़े डेवलपर बेस का अर्थ अधिक ट्यूटोरियल, एक अधिक सक्रिय समर्थन समुदाय आदि का होगा।
• विकास की आसानी। फिर से, क्योंकि MySQL इतना आम है, आप पाएंगे कि यह कई प्रणालियों/सेवाओं के लिए पसंद का डीबी है। यह आम जमीन किसी बाहरी एकीकरण को थोड़ा आसान बना सकती है।
• आप ऐसी परिस्थिति की तैयारी कर रहे हैं जो कभी अस्तित्व में न हो, और यदि ऐसा होता है तो इसका प्रबंधन किया जा सकता है। बहुत कम व्यवसाय (कभी-कभी स्टार्टअप नहीं) MySQL की सीमाओं के करीब आते हैं, और सभी उचित सम्मान के साथ (और मैं बस अनुमान लगा रहा हूं); संभावना है कि आपका स्टार्टअप कभी भी व्यवस्थित, अच्छी तरह से संसाधनित MySQL डीबी को अपंग करने के लिए डेटा थ्रुपुट के प्रकार को हिट करेगा, लगभग शून्य है। के रूप में MySQL एक बहुत डेटा के संभाल कर सकते हैं

असल में, अपना समय (== पैसे) खर्च नहीं करते जो डाटाबेस का उपयोग करने के बारे में चिंता करना, अच्छी तरह से साबित होता है और अच्छी तरह से समर्थन किया।

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

एफवाईआई, पसंद का मेरा कैशिंग समाधान memcached है।

Answer 2

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

क्यों आप कोशिश नहीं करते कि MySQL आपके सेटअप में बड़ी डेटा राशि के साथ कैसे व्यवहार करता है? कुछ स्क्रिप्ट बनाएं जो यथार्थवादी डेटा को MySQL परीक्षण डेटाबेस में उत्पन्न करें और सिस्टम पर कुछ लोड उत्पन्न करें और देखें कि यह पर्याप्त तेज़ है या नहीं।

केवल तभी पर्याप्त तेज़ नहीं होने पर, पहले डेटाबेस को अनुकूलित करने और विभिन्न डेटाबेस इंजन में बदलने पर विचार करना शुरू करें।

NHibernate से सावधान रहें, यह समाधान आसान है और कोड के साथ आसान है, लेकिन बड़ी मात्रा में डेटा के साथ खराब प्रदर्शन है। उदाहरण के लिए संगठनों के साथ आलसी या उत्सुक लाने का उपयोग सावधानी से विचार किया जाना चाहिए। मेरा मतलब यह नहीं है कि आपको NHibernate का उपयोग नहीं करना चाहिए, लेकिन यह सुनिश्चित कर लें कि आप कैसे समझते हैं कि NHibernate कैसे काम करता है, उदाहरण के लिए "n + 1 selects" -problem का अर्थ है।

Answer 3

मापें, मान लीजिए।

रिलेशनल डेटाबेस और नोएसक्यूएल डेटाबेस दोनों बड़े पैमाने पर स्केल कर सकते हैं, यदि प्रत्येक मामले में एप्लिकेशन सही लिखा गया है, और यदि यह सिस्टम चल रहा है तो ठीक से ट्यून किया गया है।

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

केवल एक बार जब आप अपनी प्रदर्शन समस्या को समझ लेते हैं तो आपको विदेशी तकनीक की खोज करनी चाहिए, जब तक कि आप उस तकनीक से सहज न हों या किसी अन्य कारण से इसे आजमाएं।

Answer 4

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

पोस्टरेएसक्यूएल आमतौर पर ओरेकल का सबसे अच्छा मुफ्त प्रतिस्थापन होता है और बीएसडी लाइसेंस अधिक व्यापार अनुकूल होना चाहिए।

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

वहाँ तीन चीजें हैं जो वास्तव में गहरा प्रभाव एक अपने सबसे अच्छे डेटाबेस विकल्प है जिस पर कर रहे हैं और आप का उल्लेख नहीं है:

1. अपने डेटा के आकार या आप अपने डेटाबेस के भीतर फ़ाइलों को स्टोर करने की जरूरत है।
2. बड़ी संख्या में पढ़ने और बहुत कम (यहां तक ​​कि प्रतिबंधित) लिखते हैं। उस स्थिति में डेटाबेस से अधिक आपको एक निर्देशिका की आवश्यकता होती है जैसे कि LDAP
3. डेटा वितरण और/या प्रतिकृति का महत्व। अधिकतर रिलेशनल डेटाबेस को कम या ज्यादा अच्छी तरह से दोहराया जा सकता है, लेकिन उनकी अवधारणा/डिज़ाइन की वजह से डेटा वितरण भी संभाल नहीं पाता है ... लेकिन क्या आप एक ऐसे डेटा को संभाल लेंगे जो एक सर्वर में फिट न हो या एक्सेस अधिकारों को विशेष अलग करने की आवश्यकता हो/अतिरिक्त सर्वर?

हालांकि ज्यादातर लोगों के लिए एक गैर संबंधपरक डेटाबेस के लिए जाना होगा सिर्फ इसलिए कि वे सीखने एसक्यूएल

Answer 5

मेरा सुझाव है कि आप प्रत्येक डीबी को आजमाएं और उस व्यक्ति को चुनें जो आपके एप्लिकेशन को विकसित करना सबसे आसान बनाता है। एक साधारण ट्यूटोरियल के साथ MongoDB को आजमाने के लिए http://try.mongodb.org पर जाएं। शुरुआत के समय से गति के बारे में चिंता न करें डेवलपर समय CPU समय से अधिक मूल्यवान है।

मुझे पता है कि कई मोंगोडीबी उपयोगकर्ता अपने ओआरएम और उनकी कैशिंग परत को कुचलने में सक्षम हैं। मोंगो का डेटा मॉडल उन वस्तुओं के बहुत करीब है जो आप संबंधपरक तालिकाओं के साथ काम करते हैं, इसलिए आप आमतौर पर अपनी ऑब्जेक्ट्स को सीधे स्टोर कर सकते हैं, भले ही उनमें नेस्टेड ऑब्जेक्ट्स की सूचियां हों, जैसे ब्लॉग पोस्ट टिप्पणियों के साथ। इसके अलावा, क्योंकि अधिकांश साइटों के लिए मोंगो पर्याप्त तेज़ है, इसलिए आप कैशिंग की जटिलताओं से निपटने से बच सकते हैं और आमतौर पर अधिक वास्तविक समय की साइट प्रदान कर सकते हैं। उदाहरण के लिए, Wordnik.com reported 250,000 एक 1.2TB/5 बिलियन ऑब्जेक्ट डीबी के साथ पढ़ता है/सेकंड और 100,000 आवेषण/सेक।

वहाँ नेट से MongoDB से कनेक्ट करने के लिए कुछ तरीके हैं, लेकिन मुझे लगता है कि मंच है जो पता करने के लिए के साथ पर्याप्त अनुभव नहीं है सबसे अच्छा है:

• नॉर्म: http://wiki.github.com/atheken/NoRM/
• MongoDB-CSharp: http://github.com/samus/mongodb-csharp
• सरल-MongoDB: http://code.google.com/p/simple-mongodb/

अस्वीकरण: मैं 10gen MongoDB पर के लिए काम तो मैं थोड़ा पक्षपाती हूँ।