मेरे अनुभव से, Amazon Aurora भारी लेखन ट्रैफ़िक वाले डेटाबेस को चलाने के लिए अनुपयुक्त है। कम से कम 2017 के आसपास इसके कार्यान्वयन में। शायद समय के साथ इसमें सुधार होगा।
मैंने पहले 2017 में राइट-हैवी एप्लिकेशन के लिए कुछ बेंचमार्क पर काम किया था, और हमने पाया कि RDS (नॉन-ऑरोरा) हमारे एप्लिकेशन और डेटाबेस को देखते हुए, राइट परफॉर्मेंस पर ऑरोरा से कहीं बेहतर था। मूल रूप से, अरोरा आरडीएस की तुलना में धीमी परिमाण के दो आदेश थे। औरोरा के लिए अमेज़ॅन के उच्च प्रदर्शन के दावे स्पष्ट रूप से पूरी तरह से मार्केटिंग-संचालित बकवास हैं।
नवंबर 2016 में, मैंने लास वेगास में Amazon re:Invent सम्मेलन में भाग लिया। मैंने प्रदर्शन के बारे में अपने सवालों के जवाब देने के लिए एक जानकार अरोड़ा इंजीनियर को खोजने की कोशिश की। मुझे केवल जूनियर इंजीनियर ही मिले, जिन्हें इस दावे को दोहराने का आदेश दिया गया था कि ऑरोरा MySQL से जादुई रूप से 5-10x तेज है।
अप्रैल 2017 में, मैंने पेरकोना लाइव सम्मेलन में भाग लिया और एक ओपन-सोर्स डिस्ट्रीब्यूटेड स्टोरेज लेयर के लिए CEPH के साथ मानक MySQL का उपयोग करके ऑरोरा जैसी वितरित स्टोरेज आर्किटेक्चर को विकसित करने के तरीके के बारे में एक प्रस्तुति देखी। यहाँ इसी विषय पर एक वेबिनार है:https://www.percona। कॉम/संसाधन/वेबिनार/mysql-and-ceph , यवेस ट्रूडो द्वारा सह-प्रस्तुत, जिस इंजीनियर को मैंने सम्मेलन में बोलते देखा था।
CEPH के साथ MySQL का उपयोग करने के बारे में जो स्पष्ट हो गया वह यह है कि इंजीनियरों को MySQL बफ़र बदलें क्योंकि द्वितीयक अनुक्रमणिका में परिवर्तनों को कैश करने का कोई तरीका नहीं है, जबकि भंडारण वितरित भी है। इससे माध्यमिक (गैर-अद्वितीय) अनुक्रमणिका वाली तालिकाओं को लिखने के लिए बड़ी प्रदर्शन समस्याएं हुईं।
यह प्रदर्शन समस्याओं के अनुरूप था जिसे हमने अपने एप्लिकेशन को औरोरा के साथ बेंचमार्किंग में देखा था। हमारे डेटाबेस में बहुत सारे सेकेंडरी इंडेक्स थे।
इसलिए यदि आपको उच्च लिखने वाले ट्रैफ़िक वाले डेटाबेस के लिए पूरी तरह से Aurora का उपयोग करना है, तो मेरा सुझाव है कि सबसे पहले आपको अपनी सभी द्वितीयक अनुक्रमणिकाएँ छोड़ दें।
जाहिर है, यह एक समस्या है यदि आपके कुछ प्रश्नों को अनुकूलित करने के लिए अनुक्रमणिका की आवश्यकता है। बेशक दोनों सेलेक्ट क्वेरीज़, लेकिन कुछ UPDATE और DELETE क्वेरीज़ सेकेंडरी इंडेक्स का उपयोग कर सकती हैं।
एक रणनीति यह हो सकती है कि आपके Aurora क्लस्टर की गैर-Aurora रीड रेप्लिका बनाई जाए, और आपके SELECT क्वेरीज़ को सपोर्ट करने के लिए केवल रीड रेप्लिका में सेकेंडरी इंडेक्स बनाया जाए। मैंने ऐसा कभी नहीं किया है, लेकिन स्पष्ट रूप से यह संभव है, https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/
लेकिन यह अभी भी उन मामलों में मदद नहीं करता है जहां आपके अद्यतन/हटाएं बयानों को द्वितीयक अनुक्रमणिका की आवश्यकता होती है। मेरे पास उस परिदृश्य के लिए कोई सुझाव नहीं है। आपकी किस्मत खराब हो सकती है।
मेरा निष्कर्ष यह है कि मैं लिखने के लिए भारी आवेदन के लिए Aurora का उपयोग करना नहीं चुनूंगा। हो सकता है कि भविष्य में यह बदल जाए।
अपडेट अप्रैल 2021:
उपरोक्त लिखने के बाद से, मैंने औरोरा संस्करण 2 के खिलाफ sysbench बेंचमार्क चलाए हैं। मैं विशिष्ट संख्या साझा नहीं कर सकता, लेकिन मैं यह निष्कर्ष निकालता हूं कि वर्तमान Aurora सुधार राइट-हैवी वर्कलोड के लिए बेहतर हैं। मैंने यह सुनिश्चित करने के लिए कई माध्यमिक अनुक्रमणिका के साथ परीक्षण चलाए। लेकिन मैं अपने स्वयं के बेंचमार्क चलाने के लिए औरोरा को अपनाने के बारे में गंभीर किसी को भी प्रोत्साहित करता हूं।
कम से कम, EBS स्टोरेज का उपयोग करके MySQL के लिए पारंपरिक Amazon RDS की तुलना में Aurora बहुत बेहतर है। शायद यहीं पर उनका दावा है कि अरोरा MySQL से 5 गुना तेज है। लेकिन ऑरोरा मेरे द्वारा परीक्षण किए गए कुछ अन्य विकल्पों की तुलना में तेज़ नहीं है, और वास्तव में मेल नहीं खा सकता है:
-
MySQL सर्वर ने स्थानीय भंडारण का उपयोग करते हुए EC2 इंस्टेंस पर खुद को स्थापित किया, विशेष रूप से स्थानीय रूप से संलग्न NVMe के साथ i3 इंस्टेंस। मैं समझता हूं कि इंस्टेंस स्टोरेज भरोसेमंद नहीं है, इसलिए किसी को अनावश्यक नोड्स चलाने की आवश्यकता होगी।
-
MySQL सर्वर ने डायरेक्ट-अटैच्ड SSD स्टोरेज का उपयोग करते हुए खुद को हमारे डेटा सेंटर में भौतिक होस्ट पर स्थापित किया।
Aurora को एक प्रबंधित क्लाउड डेटाबेस के रूप में उपयोग करने का महत्व केवल प्रदर्शन के बारे में नहीं है। इसमें स्वचालित निगरानी, बैकअप, फ़ेलओवर, अपग्रेड आदि भी हैं।
