Transcript
00:00:00आपके कोड में गिट (git) है, पर आपके डेटा का क्या? समस्या यही है, एक गलत CSV या एक गलत कॉन्फ़िगरेशन रो,
00:00:07स्प्रेडशीट में एक बदलाव और अब आपका ऐप काम करना बंद कर देता है। कोई साफ डिफ (diff) नहीं, कोई ब्रांच या पुल रिक्वेस्ट नहीं,
00:00:13कोई आसान रोलबैक नहीं। यह है डॉल्ट (Dolt), यह एक SQL डेटाबेस है जो बिल्कुल गिट की तरह काम करता है। आप टेबल को ब्रांच कर सकते हैं,
00:00:20रो (rows) को एडिट कर सकते हैं, बदलावों को डिफ कर सकते हैं, उन्हें कमिट और मर्ज कर सकते हैं। असल डेटा के लिए असल वर्ज़न कंट्रोल। मैं
00:00:26आपको अगले कुछ मिनटों में दिखाऊंगा कि इसे कैसे सेटअप करें और कैसे इस्तेमाल करें।
00:00:35हम जानते हैं कि ज़्यादातर समय डेटाबेस अपने काम में बेहतरीन होते हैं, यानी डेटाबेस होने में। वे डेटा स्टोर करते हैं, वे आपको
00:00:41SQL के साथ क्वेरी करने देते हैं। लेकिन वे उन वर्कफ़्लो में उतने अच्छे नहीं हैं जो हम रोज़ इस्तेमाल करते हैं, जैसे ब्रांचिंग,
00:00:47रिव्यू करना, डिफ करना, मर्ज करना, रोल बैक करना, यह देखना कि किसने क्या बदला। इसलिए अक्सर हम
00:00:54दो बुरे विकल्पों में से एक को चुनते हैं। पहला विकल्प है आप डेटा को एक असली डेटाबेस में रखते हैं, आपको SQL इंडेक्स,
00:01:00कंसट्रेंट्स और स्ट्रक्चर मिलते हैं, लेकिन जब डेटा बदलता है तो रिव्यू की प्रक्रिया वैसी नहीं होती जैसी होनी चाहिए।
00:01:07फिर दूसरा विकल्प है कि हम डेटा को CSV, JSON या YAML में रखते हैं ताकि गिट उसे ट्रैक कर सके। अब आपको
00:01:13कमिट और पुल रिक्वेस्ट मिल जाते हैं, लेकिन आप वो खो देते हैं जो डेटाबेस के लिए अच्छा है। कोई असली SQL नहीं, कमज़ोर
00:01:20स्कीमा एन्फोर्समेंट, दर्दनाक डिफ और मर्ज। और जब कोई पूछता है कि इस रिकॉर्ड को किसने बदला, तो जवाब
00:01:27बस वही होता है, डेटाबेस एक्सेस वाला कोई व्यक्ति। वह किसी भी तरह का असली
00:01:32वर्कफ़्लो नहीं है। लेकिन अब इसके बजाय इसकी कल्पना करें। क्या होगा अगर आप एक ब्रांच कमांड चला सकें, 'dolt branch fix this data',
00:01:39dolt diff, dolt commit, dolt merge। ये वे कमांड्स हैं जो हम पहले से इस्तेमाल कर रहे हैं, लेकिन हम उन्हें
00:01:46अपने असल डेटाबेस टेबल के खिलाफ इस्तेमाल कर रहे हैं। डॉल्ट यही कर रहा है, यह हमारे डेटाबेस के लिए वर्ज़न कंट्रोल है।
00:01:52अगर आपको अपने वर्कफ़्लो को तेज़ करने वाले कोडिंग टूल पसंद हैं, तो सब्सक्राइब ज़रूर करें, हमारे वीडियो
00:01:57लगातार आते रहते हैं। बहुत बातें हो गईं, हमारे पास विकल्प हैं। SQL Lite, Postgres के लिए डॉल्ट है, आप नाम लें। चलिए इसका
00:02:04तेज़ संस्करण करते हैं। मैं यहाँ CD करूँगा और GitHub से डॉल्ट हब गेटिंग स्टार्टेड को क्लोन करूँगा।
00:02:10मैं फोल्डर में जाऊंगा। अब पहले एक पब्लिक डॉल्ट डेटाबेस क्लोन करें और मैं 'dolt sql' चलाऊंगा। अब हम
00:02:18SQL के अंदर हैं, तो मैं सीधे टर्मिनल में ही SQL कमांड चला सकता हूँ। ठीक है, मैं एक छोटा बदलाव करूँगा
00:02:27और हम 'dolt diff' चलाएंगे। और यह वह पहला 'रुको, अभी क्या हुआ' जैसा पल है।
00:02:34डॉल्ट यह नहीं कहता कि कोई फाइल बदल गई है, यह असली टेबल का अंतर (diff) दिखाता है। कौन सी रो बदली, कौन सा कॉलम
00:02:43बदला, पुरानी वैल्यू और नई वैल्यू। मैं यहाँ देख सकता हूँ। अब हम इसे कमिट कर सकते हैं, तो 'dolt add'
00:02:50फिर मैं 'dolt commit -m' चला सकता हूँ, एक कमेंट डाल सकता हूँ। मैं इसका उपयोग करके इसकी पूरी ब्रांच बना सकता हूँ,
00:02:56checkout, और हम बस 'checkout -b' और अपनी ब्रांच का नाम चलाएंगे। अगर मैं इसके ऊपर एक और बदलाव करूँ, तो मैं
00:03:03इसे फिर से 'dolt diff' कर सकता हूँ, मैं इसे फिर से कमिट कर सकता हूँ और फिर से ऐड कर सकता हूँ। अब अगर मैं वापस जाऊं और
00:03:10मर्ज करूँ, मैं main पर चेकआउट कर सकता हूँ और मैं 'dolt merge' चला सकता हूँ। ये सभी कमांड हम पहले से जानते हैं, हम बस
00:03:17इसे अब SQL के साथ कर रहे हैं। अंत में, आप 'dolt log' चला सकते हैं, अब आपके डेटाबेस में एक कमिट हिस्ट्री है, कोई बैकअप नहीं,
00:03:24कोई डंप फाइल नहीं और कोई स्प्रेडशीट एडिट लॉग नहीं। एक असली वर्ज़न डेटाबेस, यही यहाँ मुख्य विचार है।
00:03:31गिट वर्कफ़्लो, लेकिन टेबल के लिए। अब सब कुछ पीछे हटाते हैं और देखते हैं कि यह सब कैसे काम करता है।
00:03:37पहली बार में डॉल्ट जानबूझकर जाना-पहचाना लगता है। आपके पास 'dolt status', 'diff', 'add', 'commit', 'branch' जैसी कमांड्स हैं।
00:03:44checkout, अगर आप गिट जानते हैं, तो आपका दिमाग पहले से ही इस पूरे वर्कफ़्लो के आकार को समझता है।
00:03:48वे जिस चीज़ के लिए जा रहे हैं, डॉल्ट फ़ाइलों को ट्रैक नहीं कर रहा है, यह रिलेशनल टेबल को ट्रैक कर रहा है। आप इसे
00:03:55कमांड लाइन से इस्तेमाल कर सकते हैं या आप 'dolt sql server' चला सकते हैं। ऐसा करने से, आप अब इसे MySQL संगत
00:04:01क्लाइंट्स, ORMs, BI टूल्स या एप्लिकेशन कोड का उपयोग करके कनेक्ट कर सकते हैं। तो आपका ऐप डॉल्ट को एक सामान्य SQL डेटाबेस की तरह मान सकता है, लेकिन आपको
00:04:09डेटा के चारों ओर वर्ज़न कंट्रोल मिलता है। यही महत्वपूर्ण हिस्सा है। आप एक असली
00:04:14डेटाबेस और गिट वर्कफ़्लो के बीच चयन नहीं कर रहे हैं, आपको एक ही जगह दोनों मिलते हैं। डॉल्ट 'crawly tree' नामक चीज़ का उपयोग करता है। 'crawly tree'
00:04:22का आसान संस्करण यहाँ है: एक सामान्य डेटाबेस पढ़ने और लिखने को तेज़ करने के लिए पेड़ जैसी संरचनाओं का उपयोग करता है।
00:04:29डॉल्ट एक ऐसी पेड़ जैसी संरचना का उपयोग करता है जो वर्ज़निंग में भी अच्छी है। तो हर बार जब आप कमिट करते हैं तो पूरे डेटाबेस को कॉपी करने के बजाय,
00:04:36डॉल्ट उन हिस्सों को साझा कर सकता है जो समान रहे और उन हिस्सों को ट्रैक कर सकता है जो
00:04:42वास्तव में बदल गए। अब हम न केवल ऐसी चीज़ें पूछ रहे हैं जैसे 'वर्तमान वैल्यू क्या है', हम वास्तव में पूछ सकते हैं
00:04:47ऐसी चीज़ें जैसे 'यह रो कुछ होने से पहले कैसी दिखती थी'। यही यहाँ बड़ी बात है।
00:04:52क्योंकि जब कुछ टूट जाता है, तो हम अनुमान नहीं लगाना चाहते। आप हिस्ट्री का निरीक्षण करना चाहते हैं। मैं अब
00:04:56डिफ की समीक्षा कर सकता हूँ, आप बदलाव देख सकते हैं और यदि आवश्यक हो, तो आप रोल बैक कर सकते हैं। यह
00:05:02स्ट्रक्चर्ड डेटा के लिए वर्ज़न कंट्रोल है। आपकी ब्रांच, कमिट, डिफ, मर्ज, रो और कॉलम के लिए हिस्ट्री। तो डॉल्ट कहाँ
00:05:10चीजों के प्रवाह में वास्तव में फिट बैठता है? क्योंकि यह सब बहुत अच्छा लगता है, लेकिन यही वह जगह है जहाँ यह भ्रमित करने वाला हो सकता है।
00:05:15आप 'git for data' सुन सकते हैं और आप शायद सोच रहे होंगे कि 'ठीक है, हमारे पास तो पहले से ही
00:05:21इसके लिए टूल्स हैं'। हाँ, हमारे पास उनके लिए टूल्स हैं, लेकिन वे अलग-अलग समस्याओं को हल करते हैं। आप CSV
00:05:28और JSON फ़ाइलों को गिट में रख सकते हैं। वह तब काम करता है जब डेटा छोटा और सरल हो। गिट आपके स्कीमा को नहीं समझता,
00:05:35यह आपके प्राइमरी की को नहीं जानता और यह कंसट्रेंट्स को लागू नहीं करने वाला है। यह आपके CSV पर जॉइन नहीं चला सकता
00:05:41जब तक आप और टूल्स नहीं जोड़ते। तो गिट आपको वर्ज़न कंट्रोल देता है, लेकिन यह वास्तव में डेटाबेस के लिए नहीं है।
00:05:47फिर DVC है। DVC ML वर्कफ़्लो के लिए बहुत अच्छा है, खासकर बड़े डेटा सेट और मॉडल आर्टिफैक्ट्स के लिए, लेकिन
00:05:53यह आपका लाइव रिलेशनल डेटाबेस बनने की कोशिश नहीं कर रहा है। हाँ, आपके पास lakeFS है जो गिट जैसे विचार लाता है
00:06:00ऑब्जेक्ट स्टोरेज और डेटा लेक के लिए। लेक स्केल पर बहुत उपयोगी है, लेकिन फिर से, वह पूरी तरह से अलग परत है। यह
00:06:07यह कहने जैसा नहीं है कि 'SQL टेबल को ब्रांच करें, कुछ रो बदलें, एक डिफ चलाएं और इसे वापस मर्ज करें'।
00:06:13पारंपरिक डेटाबेस में भी हिस्ट्री टूल्स होते हैं, टेम्पोरल टेबल, ऑडिट लॉग, CDC, लेकिन उनमें से ज़्यादातर
00:06:20सामान्य वर्कफ़्लो जैसा महसूस नहीं कराते। वे आपको वह साफ लूप, ब्रांच, चेंज, डिफ, मर्ज, रोलबैक नहीं देते।
00:06:27मैं हर प्रोडक्शन सिस्टम में आँख बंद करके डॉल्ट को नहीं डालूंगा। यहाँ मुद्दा यह नहीं है। मुद्दा यह है,
00:06:33अगर आपके काम में स्ट्रक्चर्ड डेटा शामिल है जो समय के साथ बदलता है और वे बदलाव वास्तव में चीजों को तोड़ सकते हैं,
00:06:40तो मुझे लगता है कि डॉल्ट आज़माने लायक है। पहली बार जब यह आपको एक साइलेंट खराब डेटा परिवर्तन से बचाता है, तो वर्कफ़्लो
00:06:46थोड़ा अधिक स्पष्ट महसूस होने लगता है। हमारे पास गिट है, हमारे पास डेटा के लिए कुछ क्यों नहीं है? अब हमारे पास कुछ हद तक है। अगर
00:06:52आपको ऐसे कोडिंग टूल्स पसंद हैं, तो Better Stack चैनल को सब्सक्राइब करना सुनिश्चित करें। हम आपको अगले
00:06:57वीडियो में मिलेंगे।
Community Posts
No posts yet. Be the first to write about this video!
Write about this video