पार्टी में देर से आने के लिए क्षमा करें। :) यहाँ मेरा जवाब है, 1996 से Mnesia और 1988 के बाद से विभिन्न अन्य डेटाबेस तकनीकों का उपयोग करने के आधार पर।
Mnesia और MySQL वास्तव में अलग-अलग जानवर हैं, और जो सबसे अच्छा है वह इस बात पर बहुत निर्भर करता है कि आप इसका उपयोग कैसे करना चाहते हैं।
यदि आपका आवेदन Erlang में लिखा गया है, तो Mnesia आपको अपने एप्लिकेशन के समान डेटा को उसी मेमोरी स्पेस में संग्रहीत करने की अनुमति देता है, जिसका अर्थ है कि आप कुछ माइक्रोसेकंड के रूप में एक ही डेटा ऑब्जेक्ट को जल्दी से प्राप्त कर सकते हैं। MySQL में यह संभव नहीं है, क्योंकि आपके एप्लिकेशन और डेटाबेस को मेमोरी में अलग किया जाएगा। Mnesia ऐसा कर सकता है और फिर भी मजबूत हो सकता है, इसका कारण यह है कि Erlang भाषा के स्तर पर 'सुरक्षा' को लागू करता है।
कुल मिलाकर, SQL डेटाबेस विलंबता के माध्यम से थ्रूपुट का पक्ष लेते हैं, और जब विलंबता की बात आती है, Mnesia + Erlang आम तौर पर बकाया होते हैं। आपको यह तय करने की आवश्यकता है कि आपके लिए कौन सा सबसे महत्वपूर्ण है। जैसा कि डॉक्स (ऊपर) में कहा गया है, मेन्सिया के लक्ष्य एप्लिकेशन टेलिकॉम स्विचिंग एप्लिकेशन थे, जहां कॉल सेटअप के लिए प्रतिक्रिया समय की आवश्यकताएं लगभग 20 एमएस थीं। यह अनिवार्य रूप से मतलब है कि आप डेटाबेस से केवल तभी पढ़ सकते हैं जब डेटा साझा मेमोरी में था, लेकिन प्रति-कॉल-सेटअप आधार पर लगातार भंडारण के लिए लिखने से बचना होगा। OTOH, इन अनुप्रयोगों को व्यावहारिक रूप से तदर्थ क्वेरी समर्थन की कोई आवश्यकता नहीं है, और बहुत बड़े डेटा सेट का उपयोग नहीं करते हैं। अन्य डोमेन के लिए मानेसिया की उपयुक्तता को बढ़ाने के लिए कुछ काम किया गया है, लेकिन यह एरलांग / ओटीपी विकास टीम के लिए प्राथमिकता नहीं है। मनेसिया यह क्या है, और इस तरह से रहने की संभावना है।
ऊपर दिए गए लिंक में जहां Mnesia और MySQL की तुलना गति के लिए की जाती है, किसी को यह याद रखना होगा कि यह eJabberd में है, जो किसी एकल सर्वर के खिलाफ चलता है यदि वह MySQL है और पूरी तरह से प्रतिकृति डेटाबेस चलाता है यदि वह Mnesia है - और बड़े eJabberd क्लस्टर जितना हो सकता है 10 या अधिक एरांग नोड्स (और इस प्रकार, 10 या अधिक मेन्सिया प्रतिकृतियां)। अतिरेक के दृष्टिकोण से, यह काफी हास्यास्पद और महंगा है, और Mnesia किसी भी तरह से आपको ऐसा करने के लिए मजबूर नहीं करता है। यह स्पष्ट रूप से प्रत्येक नोड पर दुष्ट-तेजी से पढ़ता है, लेकिन लिखना बहुत महंगा होगा। मेरे द्वारा पढ़ी गई कई तुलनाएं एक-नोड MySQL के साथ वितरित मेन्सिया की तुलना करते हुए समाप्त हो गई हैं; यदि MySQL के लिए अतिरेक की आवश्यकता नहीं है, तो इसे मानेसिया के लिए भी आवश्यक नहीं होना चाहिए। Mnesia आपको प्रतिकृति पैटर्न चुनने में काफी लचीला है, और डेटा स्थान एप्लिकेशन के लिए पारदर्शी है।
मनेसिया भी 2 जीबी प्रति टेबल (हालांकि एक विशेष भंडारण विकल्प है) तक सीमित नहीं है। सबसे बड़ा Mnesia डेटाबेस मुझे पता है कि इसमें 600 GB डेटा (64-बिट) RAM + डिस्क है - हालाँकि मैं इसकी अनुशंसा नहीं करता। 10-20 जीबी तक का कुछ भी आधुनिक हार्डवेयर के साथ पूरी तरह से ठीक होना चाहिए, लेकिन पूरी तरह से disc_only_copies छोड़ें और disc_copies का उपयोग करें - यदि आपके पास है तो अधिक रैम खरीदें। मैं शार्दिंग सपोर्ट (mnesia_frag) का उपयोग करने से पहले दो बार सोचता हूं - यह काम करता है, लेकिन शायद ही कभी परेशानी के लायक है।
Mnesia और MySQL के बीच का सबसे बड़ा अंतर शायद SQL ही है: Mnesia में वास्तव में तुलनीय कार्यक्षमता नहीं है; QLC तदर्थ प्रश्नों के लिए कुछ सहायता प्रदान करता है, लेकिन यह SQL के समान लीग में नहीं है, और न ही क्वेरी ऑप्टिमाइज़ेशन का स्तर है। टूलींग और प्रोविजनिंग में, MySQL भी बेहतर है, और यदि आपको एनालिटिक्स की आवश्यकता है, तो कोई सवाल नहीं है, जिसे आपको चुनना चाहिए (यानी Mnesia नहीं)।
मनेसिया देखने का सबसे अच्छा तरीका एर्लांग भाषा के विस्तार के रूप में है। यह आपकी उंगलियों पर सही डेटा डालता है, और छोटे डेटा सेट के लिए उत्कृष्ट है जहां डेटा संरचना और एक्सेस पैटर्न अच्छी तरह से ज्ञात हैं। इस प्रयोजन के लिए, MySQL का उपयोग करना लगभग उतना ही असुविधाजनक है जितना कि MySQL उन चीजों के लिए उपयोग करता है जहां MySQL सबसे अच्छा काम करता है।
अधिकांश एप्लिकेशन बीच में कहीं गिर जाते हैं, और यह वह जगह है जहां यह एक निर्णय कॉल बन जाता है। आप दोनों का उपयोग करके अच्छी तरह से समाप्त हो सकते हैं ...