यह अप्रैल 2021 में प्रकाशित ब्लॉग पोस्ट का अगला भाग है।
हमने एक नमूना एप्लिकेशन बनाया है जो एक सामान्य वेब उपयोग केस और सर्वरलेस फ़ंक्शंस का उपयोग करके प्रमुख सर्वरलेस डेटाबेस के प्रदर्शन की तुलना करता है। परीक्षण किए गए डेटाबेस हैं: DynamoDB, MongoDB (Atlas), Firestore, Cassandra (DataStax Astra), FaunaDB और Redis (Upstash)।
एप्लिकेशन देखें और सोर्स कोड देखें।
तुलना पद्धति
हमने प्रत्येक डेटाबेस के लिए शीर्ष 10 समाचार लेख प्राप्त करने की लेटेंसी (विलंब) की तुलना की है। संपूर्ण डेटा न्यूयॉर्क टाइम्स API से एकत्रित 7,001 वास्तविक समाचार लेख हैं। मापा गया क्वेरी है:
select * from news where section = "World" order by view_count desc limit 10
बैकेंड AWS Lambda पर सर्वरलेस फ़ंक्शंस के रूप में कार्यान्वित है (Firestore के लिए Google Cloud Function)। हमने सर्वरलेस फ़ंक्शंस और डेटाबेस को एक ही क्षेत्र में रखा है (जहां संभव हो) ताकि लेटेंसी न्यूनतम हो।
हमने लेटेंसी माप से डेटाबेस कनेक्शन समय को बाहर रखा है, और क्वेरी से ठीक पहले और बाद में टाइमस्टैम्प रिकॉर्ड किए हैं। लेटेंसी बैकेंड पर (सर्वरलेस फ़ंक्शन के अंदर) मापी और रिकॉर्ड की जाती है, इसलिए इसमें ब्राउज़र और सर्वर के बीच नेटवर्क लेटेंसी शामिल नहीं है। साथ ही, लेटेंसी सर्वरलेस फ़ंक्शन के कोल्ड स्टार्ट समय से प्रभावित नहीं होती।
गतिशील वास्तविक दुनिया के डेटा का अनुकरण करने के लिए, हमने शीर्ष 10 लेखों को यादृच्छिक view_count मान निर्दिष्ट किए। इसलिए प्रत्येक बार हम डेटाबेस को लेखों का एक अलग सेट वापस करने के लिए मजबूर करते हैं, ताकि वे अपने कैश का उपयोग न कर सकें। अपडेट ऑपरेशन लेटेंसी गणना में शामिल नहीं हैं।
यहां आज (25 अगस्त) के लेटेंसी नंबर हैं:

प्रत्येक डेटाबेस के लिए कस्टम कॉन्फ़िगरेशन
DynamoDB
- क्षेत्र: US-West-1
- पढ़ने और लिखने की क्षमता: 50 (डिफ़ॉल्ट मान 5 था)
- इंडेक्स: पार्टीशन कुंजी section (String) और सॉर्ट कुंजी view_count (Number) के साथ GSI
- नोट: ग्लोबल टेबल्स सक्षम नहीं है क्योंकि क्लाइंट पहले से ही उसी क्षेत्र (US-West-1) में है
- कोड देखें
MongoDB (Atlas)
- क्षेत्र: AWS N. Virginia (us-east-1)
- क्लस्टर टियर: M5 (सामान्य)
- इंडेक्स: section और view_count पर कंपाउंड इंडेक्स
- नोट: मैं MongoDB के सर्वरलेस ऑफरिंग को आजमाना चाहता था लेकिन इसमें Node.js ड्राइवर नहीं है। लेकिन यह समस्या नहीं होनी चाहिए क्योंकि मैं DB कनेक्शन को उस हिस्से के बाहर रखता हूं जहां मैं लेटेंसी की गणना करता हूं।
- कोड देखें
Firestore
- क्षेत्र: GCP US-Central
- मोड: डेटास्टोर
- इंडेक्स: section (आरोही) और view_count (अवरोही) पर कम्पोजिट इंडेक्स
- कोड देखें
Cassandra (DataStax Astra)
- क्षेत्र: AWS US-East-1
- योजना: पे-एज़-यू-गो
- इंडेक्स: PRIMARY KEY (section, view_count, id)
- API: REST API
- कोड देखें
FaunaDB
- योजना: इंडिविजुअल ($25 प्रति माह)
- इंडेक्स: term=section, value=view_count
- API: FQL
- कोड देखें
Redis (Upstash)
- क्षेत्र: AWS US-West-1
- योजना: पे-एज़-यू-गो
- इंडेक्स: सॉर्टेड सेट का उपयोग किया गया
- नोट: सिंगल और मल्टी-ज़ोन डेटाबेस का अलग-अलग परीक्षण किया गया
- कोड देखें
विशेष नोट्स
- FaunaDB बेहतर स्थिरता गारंटी और डिफ़ॉल्ट रूप से वैश्विक प्रतिकृति प्रदान करता है। साथ ही, यह आपको तैनाती के लिए क्षेत्र चुनने की अनुमति नहीं देता। ये इसके अपेक्षाकृत कम प्रदर्शन के कारण हो सकते हैं।
- Firestore का प्रदर्शन दूसरों के समान है लेकिन अधिक विचरण के साथ। यह कोल्ड कनेक्शन के ओवरहेड के कारण हो सकता है। मुझे कनेक्शन को जीवित रखने का तरीका नहीं मिला। अगर आपके पास विचार हैं तो मुझे बताएं।
- Cassandra प्राइमरी कुंजी फ़ील्ड्स को अपडेट करने की अनुमति नहीं देता। सेकेंडरी इंडेक्स की सिफारिश नहीं की जाती यदि आप इंडेक्स को बहुत अपडेट करेंगे। इसलिए मैं view_count को अपडेट नहीं कर सका जो इसके प्रदर्शन को सकारात्मक रूप से प्रभावित कर सकता था।
- Upstash सिंगल ज़ोन थोड़ा तेज़ दिखता है, लेकिन Upstash के लिए सिंगल और मल्टी-ज़ोन सेटअप के बीच कोई बड़ा प्रदर्शन अंतर नहीं है। उच्च पर्सेंटाइल में REST API का प्रदर्शन नेटिव API के बहुत करीब दिखता है।
ध्यान दें कि यह एक सतत प्रयास है इसलिए हम बेंचमार्क की गुणवत्ता में सुधार के लिए कोड को रीफैक्टर करना जारी रखेंगे। जब हम किसी उत्पाद का कोड रीफैक्टर करेंगे तो हम उसका हिस्टोग्राम रीसेट कर देंगे। कृपया कोड देखें और हमें बताएं कि क्या सुधार की गुंजाइश है। आप हमसे ट्विटर और डिस्कॉर्ड पर संपर्क कर सकते हैं।