पांच अलग-अलग डेटा स्टोर्स, प्रत्येक एक प्रश्न का जवाब देते हैं, अन्य गलत जवाब देते हैं: लेनदेन व्यापार डेटा के लिए वितरित SQL, उच्च-लेखन टेलिमेट्री के लिए चौड़ा स्तंभ, अल्पकालिक राज्य के लिए एक मेमोरी स्टोरेज, फ़ाइलों के लिए वस्तु भंडारण, और शब्दार्थ खोज के लिए एक वेक्टर डेटाबेस।
| माप | मूल्य | स्रोत | मापा |
|---|---|---|---|
| उत्पादन में विशिष्ट डाटा भंडार | 5 (YugabyteDB, ScyllaDB, Redis/Valkey, MinIO, Qdrant) | kubectl get statefulsets,deployments --all-namespaces | |
| वितरित एसक्यूएल टोपोलोजी | yb-master and yb-tserver as separate stateful sets | kubectl get statefulsets -n kamo | |
| संस्करण नियंत्रण के तहत एसक्यूएल माइग्रेशन फ़ाइलें | 90 | find . -name '*.sql' across all service repositories | |
| उत्पादन डाटाबेस इंजिन माइग्रेशन पूर्ण | 1 (CockroachDB to YugabyteDB, live data) | service configuration history; port 26257 retired in favour of 5433 |
क्या इमारत यह हमें सिखाया
डेटा कहाँ जाता है इसका डिफ़ॉल्ट जवाब वह है जो अंतिम परियोजना का उपयोग करता है. यही है कि कैसे एक व्यवसाय डेटाबेस के खिलाफ विश्लेषणात्मक एकत्रीकरण चलाने के लिए समाप्त होता है, ग्राहकों के आदेशों को लेता है, या टेबल पंक्तियों में अपलोड की गई फाइलों के तीस गीगाबाइट रखता है. हमने वर्कलोड के खिलाफ प्रत्येक स्टोर को चुना, और जब हमने इसे गलत समझा तो हमने इसे स्थानांतरित कर दिया - प्लेटफॉर्म पहले एक अलग वितरित SQL इंजन पर चला और इसे हटा दिया, जो उत्पादन डेटा के साथ करने के लिए एक सच्ची कठिन बात है और वास्तुकला की चर्चा की किसी भी मात्रा से अधिक अनुभव के रूप में मूल्यवान है।
वितरित एसक्यूएल एकल नोड डाटाबेस के लिए एक ड्रॉप-इन प्रतिस्थापन नहीं है, और वे तरीके जो यह अलग है वे हैं जो काटते हैं. एक लेनदेन अपने पूरे जीवन के लिए एक स्नैपशॉट को पढ़ने-कमिट मोड में भी देखता है, इसलिए एक लेनदेन के भीतर एक पंक्ति का दूसरा पढ़ना बीच में एक अन्य लेनदेन को कमिट नहीं करता है - कोड जो एकल नोड पर सही था, यहाँ चुपके से गलत है. पढ़ने-और-लिखने के संघर्षों को लेनदेन पर फिर से कोशिश करने योग्य त्रुटियों के रूप में देखा जाता है जो कभी कुछ भी नहीं लिखते थे. ये असामान्य किनारे के मामले नहीं हैं; वे मंगलवार हैं, और वे हैं कि हम डेटा कार्य पर क्या वादा करते हैं, इसके बारे में सावधान क्यों हैं।
वस्तु भंडारण प्रत्येक अपलोड फ़ाइल को ले जाता है, सामग्री द्वारा डिडुप्लिकेशन के साथ, और उसका अपना सबक है: एक असफल अपलोड एक पंक्ति छोड़ सकता है जिसे बाद में फिर से कोशिश करने पर डिडुप्लिकेशन के खिलाफ छोड़ा जाता है, एक फ़ाइल का उत्पादन करता है जिसका सिस्टम मानता है कि मौजूद है और सेवा नहीं कर सकता है. हमने उत्पादन में पाया कि. यह अब कुछ ऐसा है जिसके लिए हम किसी भी सिस्टम में जाँच करते हैं जो हम बनाते हैं जो कुछ भी डिडुप्लिकेशन करता है.
के साथ बनाया गया
- YugabyteDB
- ScyllaDB
- Redis
- Valkey
- MinIO
- Qdrant
- PostgreSQL wire protocol
- Hibernate
क्या यह हमारे लिए योग्य है
हमें बताएं कि आप क्या करने की कोशिश कर रहे हैं
एक छोटी बातचीत आमतौर पर यह बताने के लिए पर्याप्त है कि क्या हम सही लोग हैं. यदि हम नहीं हैं, तो हम ऐसा कहेंगे और आपको कहीं बेहतर जगह दिखाएंगे.