सोशल नेटवर्किंग ऐप के लिए MySQL के बजाय कैसंड्रा

Question

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

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

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

क्या कोई मुझे इस पर सलाह दे पाएगा? मुझे आशा है कि मैं बहुत सामान्य नहीं हूं!

Answer 1

उदाहरण के लिए आप कैसंड्रा में उपयोगकर्ता डेटा - उपयोगकर्ता नाम, पासवर्ड, पते इत्यादि जैसी चीजें संग्रहीत करेंगे?

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

मैंने यह भी पढ़ा है कि neo4j जैसे कुछ सामाजिक ऐप्स द्वारा उपयोग किए गए मित्र संबंधों का प्रतिनिधित्व करने के लिए बहुत बेहतर है क्योंकि यह एक ग्राफ डेटाबेस है।

मैं सही नौकरी के लिए सही उपकरण का एक बड़ा प्रशंसक हूं। मैंने neo4j का उपयोग नहीं किया है, लेकिन मैं db4o (जो ऑब्जेक्ट डेटाबेस है) का उपयोग कर रहा हूं और इसे बहुत उपयोगी लगता है। यह विकास को ऐसे टूल का उपयोग करना आसान बनाता है जो आपकी आवश्यकताओं का मूल रूप से समर्थन करता है। चूंकि आपको ग्राफ की आवश्यकता है और एसक्यूएल में ग्राफ के साथ काम करना एक दर्द है, इसलिए मैं इसे एक नज़र देने की सिफारिश करता हूं, और मूल्यांकन करता हूं कि यह आपकी विशिष्ट आवश्यकताओं के अनुरूप है या नहीं।

मिक्सिंग डेटाबेस जब तक पसंद प्राकृतिक है (यानी संबंधित डेटाबेस विशिष्ट नौकरियों के साथ उपयोगी है, ग्राफ के लिए एक ग्राफ डेटाबेस, टेबल के लिए एक टेबल, लेनदेन की आवश्यकता वाले किसी भी चीज़ के लिए एसीआईडी ​​डेटाबेस, सुरक्षा, आदि ...)।

Answer 2

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

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

अस्वीकरण: मेरे पास नहीं है (अभी तक?) नोएसक्यूएल डेटाबेस के साथ अनुभव पर कोई हाथ नहीं है: मुझे पता है कि इसके बारे में पढ़ने से क्या आता है।

Answer 3

मैं माईएसक्यूएल और कैसंद्रा के साथ कुछ परीक्षण करने का सुझाव दूंगा। जब हमें अपनी नौकरियों में से एक में PostgreSQL और MongoDB के बीच कोई विकल्प बनाना पड़ा, तो हमने दोनों में लाखों रिकॉर्डों पर क्वेरी समय की तुलना की और पाया कि लगभग 10 एम रिकॉर्ड पोस्टग्रेस हमें पर्याप्त प्रतिक्रिया समय प्रदान करेंगे।

हम जानते थे कि हमें कम से कम कुछ वर्षों तक रिकॉर्ड्स की संख्या नहीं मिलेगी, और हमें पोस्टग्रेस के साथ अनुभव था (जबकि उस समय मोंगोडीबी बहुत परिपक्व नहीं था), इसलिए हम पोस्टग्रेस के साथ गए।

मेरा मुद्दा यह है कि आप शायद माईएसQL बेंचमार्क देख सकते हैं, कुछ प्रदर्शन परीक्षण स्वयं कर सकते हैं, अपने डेटासेट का आकार अनुमान लगा सकते हैं और यह कैसे बढ़ने जा रहा है, और इस तरह एक सूचित निर्णय लेते हैं।

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

Answer 4

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