टारनटूल DBMS मध्ये उच्च-स्तरीय प्रतिकृती

नमस्कार, मी DBMS साठी ऍप्लिकेशन तयार करत आहे टारनटूल हे Mail.ru ग्रुपने विकसित केलेले एक व्यासपीठ आहे जे उच्च-कार्यक्षमता DBMS आणि Lua भाषेतील अॅप्लिकेशन सर्व्हर एकत्र करते. टारनटूलवर आधारित सोल्यूशन्सची उच्च गती, विशेषतः, DBMS च्या इन-मेमरी मोडला समर्थन देऊन आणि डेटासह एकाच अॅड्रेस स्पेसमध्ये अॅप्लिकेशन बिझनेस लॉजिक कार्यान्वित करण्याच्या क्षमतेद्वारे प्राप्त केली जाते. त्याच वेळी, ACID व्यवहार वापरून डेटा टिकून राहण्याची खात्री केली जाते (डिस्कवर WAL लॉग ठेवला जातो). टारंटूलमध्ये प्रतिकृती आणि शार्डिंगसाठी अंगभूत समर्थन आहे. आवृत्ती 2.1 पासून सुरू करून, SQL भाषेतील क्वेरी समर्थित आहेत. टारंटूल हे मुक्त स्रोत आहे आणि सरलीकृत BSD परवान्याअंतर्गत परवानाकृत आहे. एक व्यावसायिक एंटरप्राइझ आवृत्ती देखील आहे.

शक्ती अनुभवा! (…उर्फ कामगिरीचा आनंद घ्या)

वरील सर्व गोष्टी डेटाबेससह कार्य करणारे उच्च-लोड अनुप्रयोग तयार करण्यासाठी टारंटूलला एक आकर्षक व्यासपीठ बनवतात. अशा ऍप्लिकेशन्समध्ये, डेटा प्रतिकृतीची आवश्यकता असते.

वर नमूद केल्याप्रमाणे, टारंटूलमध्ये अंगभूत डेटा प्रतिकृती आहे. मास्टर लॉग (WAL) मध्ये समाविष्ट असलेल्या सर्व व्यवहारांच्या प्रतिकृतींवर अनुक्रमे अंमलात आणणे हे त्याच्या ऑपरेशनचे तत्त्व आहे. सहसा अशी प्रतिकृती (आम्ही पुढे त्याला कॉल करू खालची पातळी) ऍप्लिकेशन फॉल्ट टॉलरन्स सुनिश्चित करण्यासाठी आणि/किंवा क्लस्टर नोड्स दरम्यान वाचन लोड वितरित करण्यासाठी वापरले जाते.

तांदूळ. 1. क्लस्टरमध्ये प्रतिकृती

वैकल्पिक परिस्थितीचे उदाहरण म्हणजे एका डेटाबेसमध्ये तयार केलेला डेटा प्रक्रिया/निरीक्षणासाठी दुसऱ्या डेटाबेसमध्ये हस्तांतरित करणे. नंतरच्या प्रकरणात, अधिक सोयीस्कर उपाय वापरणे शक्य आहे उच्चस्तरीय प्रतिकृती - अनुप्रयोग व्यवसाय तर्क स्तरावर डेटा प्रतिकृती. त्या. आम्ही DBMS मध्ये तयार केलेले तयार सोल्यूशन वापरत नाही, परंतु आम्ही विकसित करत असलेल्या ऍप्लिकेशनमध्ये स्वतःच प्रतिकृती लागू करतो. या पद्धतीचे फायदे आणि तोटे दोन्ही आहेत. चला फायद्यांची यादी करूया.

1. रहदारी बचत:

• आपण सर्व डेटा हस्तांतरित करू शकत नाही, परंतु त्याचा फक्त एक भाग (उदाहरणार्थ, आपण केवळ काही सारण्या, त्यांचे काही स्तंभ किंवा विशिष्ट निकष पूर्ण करणारे रेकॉर्ड हस्तांतरित करू शकता);
• निम्न-स्तरीय प्रतिकृतीच्या विपरीत, जी एसिंक्रोनस (Tarantool च्या वर्तमान आवृत्तीमध्ये लागू केली जाते - 1.10) किंवा समकालिक (Tarantool च्या पुढील आवृत्त्यांमध्ये लागू केली जाणार आहे) मोडमध्ये, उच्च-स्तरीय प्रतिकृती सत्रांमध्ये केली जाऊ शकते (उदा. अनुप्रयोग प्रथम डेटा समक्रमित करतो - एक्सचेंज सत्र डेटा, नंतर प्रतिकृतीमध्ये एक विराम आहे, त्यानंतर पुढील एक्सचेंज सत्र इ.);
• जर एखादे रेकॉर्ड अनेक वेळा बदलले असेल, तर तुम्ही फक्त त्याची नवीनतम आवृत्ती हस्तांतरित करू शकता (निम्न-स्तरीय प्रतिकृतीच्या विपरीत, ज्यामध्ये मास्टरवर केलेले सर्व बदल प्रतिकृतींवर क्रमाने प्ले केले जातील).

2. HTTP एक्सचेंज लागू करण्यात कोणतीही अडचण नाही, जी तुम्हाला रिमोट डेटाबेस सिंक्रोनाइझ करण्याची परवानगी देते.

तांदूळ. 2. HTTP वर प्रतिकृती

3. डाटाबेस स्ट्रक्चर्स ज्या दरम्यान डेटा हस्तांतरित केला जातो ते समान असणे आवश्यक नाही (शिवाय, सामान्य बाबतीत, भिन्न DBMS, प्रोग्रामिंग भाषा, प्लॅटफॉर्म इ. वापरणे देखील शक्य आहे).

तांदूळ. 3. विषम प्रणालींमध्ये प्रतिकृती

नकारात्मक बाजू अशी आहे की, सरासरी, कॉन्फिगरेशनपेक्षा प्रोग्रामिंग अधिक कठीण/खर्चिक आहे आणि अंगभूत कार्यक्षमता सानुकूलित करण्याऐवजी, तुम्हाला स्वतःची अंमलबजावणी करावी लागेल.

जर तुमच्या परिस्थितीत वरील फायदे महत्त्वपूर्ण आहेत (किंवा आवश्यक अट आहेत), तर उच्च-स्तरीय प्रतिकृती वापरण्यात अर्थ आहे. Tarantool DBMS मध्ये उच्च-स्तरीय डेटा प्रतिकृती लागू करण्याचे अनेक मार्ग पाहू.

रहदारी कमी करणे

तर, उच्च-स्तरीय प्रतिकृतीचा एक फायदा म्हणजे रहदारी बचत. हा फायदा पूर्णपणे प्राप्त होण्यासाठी, प्रत्येक एक्सचेंज सत्रादरम्यान हस्तांतरित केलेल्या डेटाचे प्रमाण कमी करणे आवश्यक आहे. अर्थात, आम्ही हे विसरू नये की सत्राच्या शेवटी, डेटा प्राप्तकर्ता स्त्रोतासह सिंक्रोनाइझ करणे आवश्यक आहे (किमान प्रतिकृतीमध्ये गुंतलेल्या डेटाच्या त्या भागासाठी).

उच्च-स्तरीय प्रतिकृती दरम्यान हस्तांतरित केलेल्या डेटाचे प्रमाण कसे कमी करावे? तारीख आणि वेळेनुसार डेटा निवडणे हा एक सरळ उपाय असू शकतो. हे करण्यासाठी, तुम्ही टेबलमध्ये आधीपासून अस्तित्वात असलेले तारीख-वेळ फील्ड वापरू शकता (जर ते अस्तित्वात असेल). उदाहरणार्थ, "ऑर्डर" दस्तऐवजात "आवश्यक ऑर्डर अंमलबजावणी वेळ" फील्ड असू शकते - delivery_time. या सोल्यूशनमध्ये समस्या अशी आहे की या क्षेत्रातील मूल्ये ऑर्डरच्या निर्मितीशी संबंधित अनुक्रमात असणे आवश्यक नाही. त्यामुळे आम्ही जास्तीत जास्त फील्ड मूल्य लक्षात ठेवू शकत नाही delivery_time, मागील एक्सचेंज सत्रादरम्यान प्रसारित केले गेले आणि पुढील एक्सचेंज सत्रादरम्यान उच्च फील्ड मूल्यासह सर्व रेकॉर्ड निवडा delivery_time. कमी फील्ड मूल्यासह रेकॉर्ड एक्सचेंज सत्रांमध्ये जोडले गेले असतील delivery_time. तसेच, ऑर्डरमध्ये बदल होऊ शकतात, ज्याचा फील्डवर परिणाम झाला नाही delivery_time. दोन्ही प्रकरणांमध्ये, बदल स्त्रोतापासून गंतव्यस्थानावर हस्तांतरित केले जाणार नाहीत. या समस्यांचे निराकरण करण्यासाठी, आम्हाला डेटा "ओव्हरलॅपिंग" हस्तांतरित करणे आवश्यक आहे. त्या. प्रत्येक एक्सचेंज सेशनमध्ये आम्ही फील्ड व्हॅल्यूसह सर्व डेटा ट्रान्सफर करू delivery_time, भूतकाळातील काही बिंदू ओलांडत आहे (उदाहरणार्थ, वर्तमान क्षणापासून N तास). तथापि, हे उघड आहे की मोठ्या प्रणालींसाठी हा दृष्टीकोन अत्यंत अनावश्यक आहे आणि आपण ज्यासाठी प्रयत्न करत आहोत ती रहदारी बचत कमी करू शकते. याव्यतिरिक्त, हस्तांतरित केल्या जात असलेल्या टेबलमध्ये तारीख-वेळेशी संबंधित फील्ड असू शकत नाही.

दुसरा उपाय, अंमलबजावणीच्या दृष्टीने अधिक क्लिष्ट, डेटाची पावती स्वीकारणे. या प्रकरणात, प्रत्येक एक्सचेंज सत्रादरम्यान, सर्व डेटा प्रसारित केला जातो, ज्याची पावती प्राप्तकर्त्याद्वारे पुष्टी केली गेली नाही. हे अंमलात आणण्यासाठी, तुम्हाला सोर्स टेबलमध्ये बुलियन कॉलम जोडणे आवश्यक आहे (उदाहरणार्थ, is_transferred). प्राप्तकर्त्याने रेकॉर्डची पावती कबूल केल्यास, संबंधित फील्ड मूल्य घेते true, ज्यानंतर एंट्री यापुढे एक्सचेंजमध्ये गुंतलेली नाही. या अंमलबजावणी पर्यायाचे खालील तोटे आहेत. प्रथम, हस्तांतरित केलेल्या प्रत्येक रेकॉर्डसाठी, एक पोचपावती तयार करणे आणि पाठवणे आवश्यक आहे. ढोबळपणे सांगायचे तर, हे ट्रान्सफर केलेल्या डेटाचे प्रमाण दुप्पट करणे आणि राउंडट्रिप्सची संख्या दुप्पट करण्याशी तुलना करता येऊ शकते. दुसरे म्हणजे, समान रेकॉर्ड अनेक रिसीव्हर्सना पाठवण्याची शक्यता नाही (मिळणारा पहिला प्राप्तकर्ता स्वतःसाठी आणि इतर सर्वांसाठी पावतीची पुष्टी करेल).

वर दिलेले तोटे नसलेली पद्धत म्हणजे हस्तांतरित सारणीमध्ये स्तंभ जोडणे हे त्याच्या पंक्तीमधील बदलांचा मागोवा घेण्यासाठी आहे. असा स्तंभ तारीख-वेळ प्रकाराचा असू शकतो आणि प्रत्येक वेळी नोंदी जोडल्या/बदलल्या जातात तेव्हा (अॅटोमिकली जोडून/बदलासह) वर्तमान वेळेनुसार सेट/अपडेट करणे आवश्यक आहे. उदाहरण म्हणून, कॉलम कॉल करूया update_time. हस्तांतरित रेकॉर्डसाठी या स्तंभाचे जास्तीत जास्त फील्ड मूल्य जतन करून, आम्ही या मूल्यासह पुढील विनिमय सत्र सुरू करू शकतो (फील्ड मूल्यासह रेकॉर्ड निवडा update_time, पूर्वी संग्रहित मूल्यापेक्षा जास्त). नंतरच्या दृष्टिकोनाची समस्या अशी आहे की डेटा बदल बॅचमध्ये होऊ शकतात. स्तंभातील फील्ड मूल्यांचा परिणाम म्हणून update_time अद्वितीय असू शकत नाही. अशा प्रकारे, हा स्तंभ भाग (पृष्ठ-दर-पृष्ठ) डेटा आउटपुटसाठी वापरला जाऊ शकत नाही. पृष्ठानुसार डेटा पृष्ठ प्रदर्शित करण्यासाठी, आपल्याला अतिरिक्त यंत्रणेचा शोध लावावा लागेल ज्याची कार्यक्षमता खूप कमी असेल (उदाहरणार्थ, डेटाबेसमधून मूल्यासह सर्व रेकॉर्ड पुनर्प्राप्त करणे update_time दिलेल्या एकापेक्षा जास्त आणि नमुन्याच्या सुरुवातीपासून विशिष्ट ऑफसेटपासून प्रारंभ करून, विशिष्ट संख्येतील रेकॉर्ड तयार करणे).

तुम्ही मागील पद्धतीमध्ये किंचित सुधारणा करून डेटा ट्रान्सफरची कार्यक्षमता सुधारू शकता. हे करण्यासाठी, आम्ही बदलांचा मागोवा घेण्यासाठी कॉलम फील्ड व्हॅल्यू म्हणून पूर्णांक प्रकार (लांब पूर्णांक) वापरू. चला स्तंभाचे नाव देऊ row_ver. प्रत्येक वेळी रेकॉर्ड तयार/सुधारित केल्यावर या स्तंभाचे फील्ड मूल्य अद्याप सेट/अपडेट केले जाणे आवश्यक आहे. परंतु या प्रकरणात, फील्डला वर्तमान तारीख-वेळ नियुक्त केले जाणार नाही, परंतु काही काउंटरचे मूल्य, एकाने वाढविले जाईल. परिणामी, स्तंभ row_ver अनन्य मूल्ये असतील आणि केवळ “डेल्टा” डेटा (मागील एक्सचेंज सत्राच्या समाप्तीपासून जोडलेला/बदललेला डेटा) प्रदर्शित करण्यासाठीच नाही तर ते पृष्ठांमध्ये सहजपणे आणि प्रभावीपणे विभाजित करण्यासाठी देखील वापरले जाऊ शकते.

उच्च-स्तरीय प्रतिकृतीच्या फ्रेमवर्कमध्ये हस्तांतरित केलेल्या डेटाचे प्रमाण कमी करण्याची शेवटची प्रस्तावित पद्धत मला सर्वात इष्टतम आणि सार्वत्रिक वाटते. चला ते अधिक तपशीलवार पाहू.

पंक्ती आवृत्ती काउंटर वापरून डेटा पास करणे

सर्व्हर/मास्टर भागाची अंमलबजावणी

एमएस एसक्यूएल सर्व्हरमध्ये, हा दृष्टिकोन अंमलात आणण्यासाठी एक विशेष स्तंभ प्रकार आहे - rowversion. प्रत्येक डेटाबेसमध्ये एक काउंटर असतो जो प्रत्येक वेळी रेकॉर्ड जोडला/बदलल्यावर एकाने वाढतो rowversion. या काउंटरचे मूल्य जोडलेल्या/बदललेल्या रेकॉर्डमध्ये या स्तंभाच्या फील्डला स्वयंचलितपणे नियुक्त केले जाते. टारनटूल डीबीएमएसमध्ये समान अंगभूत यंत्रणा नाही. तथापि, टारनटूलमध्ये ते हाताने लागू करणे कठीण नाही. हे कसे केले जाते ते पाहूया.

प्रथम, थोडीशी शब्दावली: टॅरनटूलमधील सारण्यांना स्पेस म्हणतात, आणि रेकॉर्डला टपल्स म्हणतात. टारंटूलमध्ये तुम्ही अनुक्रम तयार करू शकता. क्रम क्रमबद्ध पूर्णांक मूल्यांच्या नामांकित जनरेटरपेक्षा अधिक काही नाही. त्या. आम्हाला आमच्या हेतूंसाठी नेमके हेच हवे आहे. खाली आपण असा क्रम तयार करू.

टारंटूलमध्ये कोणतेही डेटाबेस ऑपरेशन करण्यापूर्वी, तुम्हाला खालील कमांड चालवावी लागेल:

box.cfg{}

परिणामी, Tarantool वर्तमान निर्देशिकेत डेटाबेस स्नॅपशॉट आणि व्यवहार लॉग लिहिण्यास सुरुवात करेल.

चला एक क्रम तयार करूया row_version:

box.schema.sequence.create('row_version',
    { if_not_exists = true })

पर्याय if_not_exists निर्मिती स्क्रिप्ट अनेक वेळा कार्यान्वित करण्याची परवानगी देते: ऑब्जेक्ट अस्तित्वात असल्यास, Tarantool पुन्हा तयार करण्याचा प्रयत्न करणार नाही. हा पर्याय पुढील सर्व DDL कमांडमध्ये वापरला जाईल.

उदाहरण म्हणून एक जागा तयार करू.

box.schema.space.create('goods', {
    format = {
        {
            name = 'id',
            type = 'unsigned'

        },
        {
            name = 'name',
            type = 'string'

        },
        {
            name = 'code',
            type = 'unsigned'

        },
        {
            name = 'row_ver',
            type = 'unsigned'

        }
    },
    if_not_exists = true
})

येथे आम्ही स्पेसचे नाव सेट करतो (goods), फील्ड नावे आणि त्यांचे प्रकार.

टारंटूलमधील स्वयं-वाढीव फील्ड देखील अनुक्रम वापरून तयार केले जातात. फील्डनुसार स्वयं-वाढणारी प्राथमिक की तयार करू id:

box.schema.sequence.create('goods_id',
    { if_not_exists = true })
box.space.goods:create_index('primary', {
    parts = { 'id' },
    sequence = 'goods_id',
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

टारंटूल अनेक प्रकारच्या निर्देशांकांना समर्थन देते. सर्वात सामान्यपणे वापरल्या जाणार्‍या निर्देशांकांमध्ये TREE आणि HASH प्रकार आहेत, जे नावाशी संबंधित संरचनांवर आधारित आहेत. TREE हा सर्वात अष्टपैलू इंडेक्स प्रकार आहे. हे आपल्याला एका संघटित पद्धतीने डेटा पुनर्प्राप्त करण्यास अनुमती देते. परंतु समानता निवडीसाठी, HASH अधिक योग्य आहे. त्यानुसार, प्राथमिक कीसाठी HASH वापरण्याचा सल्ला दिला जातो (जे आम्ही केले).

स्तंभ वापरण्यासाठी row_ver बदललेला डेटा हस्तांतरित करण्यासाठी, तुम्हाला या स्तंभाच्या फील्डमध्ये अनुक्रम मूल्ये बांधणे आवश्यक आहे row_ver. परंतु प्राथमिक कीच्या विपरीत, स्तंभ फील्ड मूल्य row_ver केवळ नवीन रेकॉर्ड जोडतानाच नव्हे तर विद्यमान बदलताना देखील एकाने वाढ केली पाहिजे. यासाठी तुम्ही ट्रिगर वापरू शकता. टारंटूलमध्ये दोन प्रकारचे स्पेस ट्रिगर आहेत: before_replace и on_replace. जेव्हा जेव्हा स्पेसमधील डेटा बदलतो तेव्हा ट्रिगर फायर केले जातात (बदलांमुळे प्रभावित झालेल्या प्रत्येक ट्युपलसाठी, ट्रिगर फंक्शन लॉन्च केले जाते). विपरीत on_replace, before_replace-ट्रिगर्स तुम्हाला ट्युपलचा डेटा सुधारण्याची परवानगी देतात ज्यासाठी ट्रिगर कार्यान्वित केला जातो. त्यानुसार, शेवटचे प्रकारचे ट्रिगर आपल्यासाठी अनुकूल आहेत.

box.space.goods:before_replace(function(old, new)
    return box.tuple.new({new[1], new[2], new[3],
        box.sequence.row_version:next()})
end)

खालील ट्रिगर फील्ड मूल्य बदलते row_ver अनुक्रमाच्या पुढील मूल्यापर्यंत टपल संचयित केले row_version.

अंतराळातून डेटा काढण्यास सक्षम होण्यासाठी goods स्तंभानुसार row_ver, चला अनुक्रमणिका तयार करूया:

box.space.goods:create_index('row_ver', {
    parts = { 'row_ver' },
    unique = true,
    type = 'TREE',
    if_not_exists = true
})

निर्देशांक प्रकार - झाड (TREE), कारण स्तंभातील मूल्यांच्या चढत्या क्रमाने डेटा काढावा लागेल row_ver.

स्पेसमध्ये काही डेटा जोडूया:

box.space.goods:insert{nil, 'pen', 123}
box.space.goods:insert{nil, 'pencil', 321}
box.space.goods:insert{nil, 'brush', 100}
box.space.goods:insert{nil, 'watercolour', 456}
box.space.goods:insert{nil, 'album', 101}
box.space.goods:insert{nil, 'notebook', 800}
box.space.goods:insert{nil, 'rubber', 531}
box.space.goods:insert{nil, 'ruler', 135}

कारण पहिले फील्ड स्वयं-वाढीव काउंटर आहे; त्याऐवजी आम्ही शून्य पास करतो. टारंटूल आपोआप पुढील मूल्य बदलेल. त्याचप्रमाणे, स्तंभ फील्डचे मूल्य म्हणून row_ver तुम्ही शून्य पास करू शकता - किंवा मूल्य अजिबात निर्दिष्ट करू शकत नाही, कारण हा स्तंभ जागेत शेवटचे स्थान व्यापतो.

चला अंतर्भूत परिणाम तपासू:

tarantool> box.space.goods:select()
---
- - [1, 'pen', 123, 1]
  - [2, 'pencil', 321, 2]
  - [3, 'brush', 100, 3]
  - [4, 'watercolour', 456, 4]
  - [5, 'album', 101, 5]
  - [6, 'notebook', 800, 6]
  - [7, 'rubber', 531, 7]
  - [8, 'ruler', 135, 8]
...

तुम्ही बघू शकता, पहिली आणि शेवटची फील्ड आपोआप भरली जातात. आता जागा बदलांचे पृष्ठ-दर-पृष्ठ अपलोड करण्यासाठी फंक्शन लिहिणे सोपे होईल goods:

local page_size = 5
local function get_goods(row_ver)
    local index = box.space.goods.index.row_ver
    local goods = {}
    local counter = 0
    for _, tuple in index:pairs(row_ver, {
        iterator = 'GT' }) do
        local obj = tuple:tomap({ names_only = true })
        table.insert(goods, obj)
        counter = counter + 1
        if counter >= page_size then
            break
        end
    end
    return goods
end

फंक्शन पॅरामीटर म्हणून मूल्य घेते row_ver, ज्यापासून बदल अनलोड करणे आवश्यक आहे, आणि बदललेल्या डेटाचा एक भाग परत करतो.

टारंटूलमधील डेटा सॅम्पलिंग इंडेक्सद्वारे केले जाते. कार्य get_goods निर्देशांकानुसार एक पुनरावृत्ती वापरते row_ver बदललेला डेटा प्राप्त करण्यासाठी. Iterator प्रकार GT (त्यापेक्षा जास्त, पेक्षा मोठा) आहे. याचा अर्थ असा की इटरेटर अनुक्रमे पास केलेल्या की (फील्ड व्हॅल्यू) पासून सुरू होणारी अनुक्रमणिका मूल्ये पार करेल row_ver).

पुनरावृत्ती करणारा ट्यूपल्स परत करतो. त्यानंतर HTTP द्वारे डेटा हस्तांतरित करण्यात सक्षम होण्यासाठी, ट्युपल्सला त्यानंतरच्या अनुक्रमिकरणासाठी सोयीस्कर संरचनेत रूपांतरित करणे आवश्यक आहे. उदाहरण यासाठी मानक फंक्शन वापरते tomap. वापरण्याऐवजी tomap तुम्ही तुमचे स्वतःचे कार्य लिहू शकता. उदाहरणार्थ, आम्हाला फील्डचे नाव बदलायचे आहे name, फील्ड पास करू नका code आणि फील्ड जोडा comment:

local function unflatten_goods(tuple)
    local obj = {}
    obj.id = tuple.id
    obj.goods_name = tuple.name
    obj.comment = 'some comment'
    obj.row_ver = tuple.row_ver
    return obj
end

आउटपुट डेटाचा पृष्ठ आकार (एका भागातील रेकॉर्डची संख्या) व्हेरिएबलद्वारे निर्धारित केला जातो page_size. उदाहरणामध्ये मूल्य page_size 5 आहे. वास्तविक प्रोग्राममध्ये, पृष्ठाचा आकार सहसा अधिक महत्त्वाचा असतो. हे स्पेस ट्युपलच्या सरासरी आकारावर अवलंबून असते. डेटा हस्तांतरण वेळ मोजून इष्टतम पृष्ठ आकार प्रायोगिकरित्या निर्धारित केला जाऊ शकतो. पृष्‍ठाचा आकार जितका मोठा असेल तितका पाठवण्‍या आणि प्राप्त करण्‍याच्‍या बाजूंमध्‍ये राउंडट्रिप्सची संख्‍या कमी असेल. अशा प्रकारे तुम्ही बदल डाउनलोड करण्यासाठी एकूण वेळ कमी करू शकता. तथापि, जर पृष्ठ आकार खूप मोठा असेल, तर आम्ही नमुना अनुक्रमित करण्यासाठी सर्व्हरवर बराच वेळ घालवू. परिणामी, सर्व्हरवर येणाऱ्या इतर विनंत्यांवर प्रक्रिया करण्यात विलंब होऊ शकतो. पॅरामीटर page_size कॉन्फिगरेशन फाइलमधून लोड केले जाऊ शकते. प्रत्येक प्रसारित जागेसाठी, आपण त्याचे स्वतःचे मूल्य सेट करू शकता. तथापि, बहुतेक स्थानांसाठी डीफॉल्ट मूल्य (उदाहरणार्थ, 100) योग्य असू शकते.

फंक्शन कार्यान्वित करू get_goods:

tarantool> get_goods(0)

---
- - row_ver: 1
    code: 123
    name: pen
    id: 1
  - row_ver: 2
    code: 321
    name: pencil
    id: 2
  - row_ver: 3
    code: 100
    name: brush
    id: 3
  - row_ver: 4
    code: 456
    name: watercolour
    id: 4
  - row_ver: 5
    code: 101
    name: album
    id: 5
...

फील्ड व्हॅल्यू घेऊ row_ver शेवटच्या ओळीतून आणि फंक्शनला पुन्हा कॉल करा:

tarantool> get_goods(5)

---
- - row_ver: 6
    code: 800
    name: notebook
    id: 6
  - row_ver: 7
    code: 531
    name: rubber
    id: 7
  - row_ver: 8
    code: 135
    name: ruler
    id: 8
...

पुन्हा एकदा:

tarantool> get_goods(8)
---
- []
...

जसे तुम्ही बघू शकता, अशा प्रकारे वापरल्यास, फंक्शन सर्व स्पेस रेकॉर्ड पृष्ठानुसार पृष्ठ परत करते goods. शेवटचे पान रिकाम्या निवडीनंतर येते.

स्पेसमध्ये बदल करूया:

box.space.goods:update(4, {{'=', 6, 'copybook'}})
box.space.goods:insert{nil, 'clip', 234}
box.space.goods:insert{nil, 'folder', 432}

आम्ही फील्ड मूल्य बदलले आहे name एका नोंदीसाठी आणि दोन नवीन नोंदी जोडल्या.

चला शेवटचा फंक्शन कॉल पुन्हा करू:

tarantool> get_goods(8)
---



- - row_ver: 9
    code: 800
    name: copybook
    id: 6
  - row_ver: 10
    code: 234
    name: clip
    id: 9
  - row_ver: 11
    code: 432
    name: folder
    id: 10
...

फंक्शनने बदललेले आणि जोडलेले रेकॉर्ड परत केले. तर फंक्शन get_goods तुम्हाला शेवटच्या कॉलपासून बदललेला डेटा प्राप्त करण्यास अनुमती देते, जी विचाराधीन प्रतिकृती पद्धतीचा आधार आहे.

आम्ही HTTP द्वारे परिणाम जारी करणे JSON स्वरूपात या लेखाच्या कक्षेबाहेर ठेवू. आपण याबद्दल येथे वाचू शकता: https://habr.com/ru/company/mailru/blog/272141/

क्लायंट/गुलाम भागाची अंमलबजावणी

प्राप्त झालेल्या बाजूची अंमलबजावणी कशी दिसते ते पाहूया. डाउनलोड केलेला डेटा संचयित करण्यासाठी प्राप्तीच्या बाजूला एक जागा तयार करूया:

box.schema.space.create('goods', {
    format = {
        {
            name = 'id',
            type = 'unsigned'

        },
        {
            name = 'name',
            type = 'string'

        },
        {
            name = 'code',
            type = 'unsigned'

        }
    },
    if_not_exists = true
})

box.space.goods:create_index('primary', {
    parts = { 'id' },
    sequence = 'goods_id',
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

जागेची रचना स्त्रोतातील जागेच्या संरचनेसारखी असते. परंतु आम्ही प्राप्त केलेला डेटा इतर कोठेही पास करणार नाही, कॉलम row_ver प्राप्तकर्त्याच्या जागेत नाही. शेतात id स्त्रोत अभिज्ञापक रेकॉर्ड केले जातील. म्हणून, रिसीव्हरच्या बाजूने ते स्वयं-वाढीव करण्याची आवश्यकता नाही.

याव्यतिरिक्त, आम्हाला मूल्ये जतन करण्यासाठी जागा आवश्यक आहे row_ver:

box.schema.space.create('row_ver', {
    format = {
        {
            name = 'space_name',
            type = 'string'

        },
        {
            name = 'value',
            type = 'string'

        }
    },
    if_not_exists = true
})

box.space.row_ver:create_index('primary', {
    parts = { 'space_name' },
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

प्रत्येक लोड केलेल्या जागेसाठी (फील्ड space_name) आपण येथे शेवटचे लोड केलेले मूल्य जतन करू row_ver (फील्ड value). स्तंभ प्राथमिक की म्हणून कार्य करतो space_name.

स्पेस डेटा लोड करण्यासाठी फंक्शन तयार करू goods HTTP द्वारे. हे करण्यासाठी, आम्हाला HTTP क्लायंट लागू करणारी लायब्ररी आवश्यक आहे. खालील ओळ लायब्ररी लोड करते आणि HTTP क्लायंट इन्स्टंट करते:

local http_client = require('http.client').new()

आम्हाला json deserialization साठी लायब्ररी देखील आवश्यक आहे:

local json = require('json')

डेटा लोडिंग फंक्शन तयार करण्यासाठी हे पुरेसे आहे:

local function load_data(url, row_ver)
    local url = ('%s?rowVer=%s'):format(url,
        tostring(row_ver))
    local body = nil
    local data = http_client:request('GET', url, body, {
        keepalive_idle =  1,
        keepalive_interval = 1
    })
    return json.decode(data.body)
end

फंक्शन url पत्त्यावर HTTP विनंती कार्यान्वित करते आणि पाठवते row_ver पॅरामीटर म्हणून आणि विनंतीचा डीसीरियलाइज्ड परिणाम परत करते.

प्राप्त डेटा जतन करण्याचे कार्य असे दिसते:

local function save_goods(goods)
    local n = #goods
    box.atomic(function()
        for i = 1, n do
            local obj = goods[i]
            box.space.goods:put(
                obj.id, obj.name, obj.code)
        end
    end)
end

अंतराळात डेटा वाचवण्याचे चक्र goods व्यवहारात ठेवले (यासाठी फंक्शन वापरले जाते box.atomic) डिस्क ऑपरेशन्सची संख्या कमी करण्यासाठी.

शेवटी, स्थानिक स्पेस सिंक्रोनाइझेशन फंक्शन goods स्त्रोतासह आपण ते याप्रमाणे अंमलात आणू शकता:

local function sync_goods()
    local tuple = box.space.row_ver:get('goods')
    local row_ver = tuple and tuple.value or 0

    —— set your url here:
    local url = 'http://127.0.0.1:81/test/goods/list'

    while true do
        local goods = load_goods(url, row_ver)

        local count = #goods
        if count == 0 then
            return
        end

        save_goods(goods)

        row_ver = goods[count].rowVer
        box.space.row_ver:put({'goods', row_ver})
    end
end

प्रथम आपण पूर्वी जतन केलेले मूल्य वाचतो row_ver जागेसाठी goods. जर ते गहाळ असेल (पहिले एक्सचेंज सत्र), तर आम्ही ते म्हणून घेतो row_ver शून्य पुढे सायकलमध्ये आम्ही निर्दिष्ट url वरील स्त्रोतावरून बदललेल्या डेटाचे पृष्ठ-दर-पृष्ठ डाउनलोड करतो. प्रत्येक पुनरावृत्तीवर, आम्ही प्राप्त केलेला डेटा योग्य स्थानिक जागेवर जतन करतो आणि मूल्य अद्यतनित करतो row_ver (अंतराळात row_ver आणि व्हेरिएबल मध्ये row_ver) - मूल्य घ्या row_ver लोड केलेल्या डेटाच्या शेवटच्या ओळीतून.

अपघाती लूपिंगपासून संरक्षण करण्यासाठी (प्रोग्राममध्ये त्रुटी असल्यास), लूप while द्वारे बदलले जाऊ शकते for:

for _ = 1, max_req do ...

फंक्शन कार्यान्वित करण्याच्या परिणामी sync_goods जागा goods रिसीव्हरमध्ये सर्व स्पेस रेकॉर्डच्या नवीनतम आवृत्त्या असतील goods स्रोत मध्ये.

साहजिकच, अशा प्रकारे डेटा हटवणे प्रसारित केले जाऊ शकत नाही. अशी गरज असल्यास, तुम्ही डिलीशन मार्क वापरू शकता. जागेत जोडा goods बुलियन फील्ड is_deleted आणि रेकॉर्ड भौतिकरित्या हटवण्याऐवजी, आम्ही तार्किक हटवणे वापरतो - आम्ही फील्ड मूल्य सेट करतो is_deleted अर्थ मध्ये true. कधीकधी बुलियन फील्डऐवजी is_deleted फील्ड वापरणे अधिक सोयीचे आहे deleted, जे रेकॉर्डच्या तार्किक हटविण्याची तारीख-वेळ संग्रहित करते. तार्किक हटविल्यानंतर, हटविण्यासाठी चिन्हांकित केलेले रेकॉर्ड स्त्रोतापासून गंतव्यस्थानावर हस्तांतरित केले जाईल (वर चर्चा केलेल्या तर्कानुसार).

क्रम row_ver इतर स्पेसमधून डेटा प्रसारित करण्यासाठी वापरला जाऊ शकतो: प्रत्येक प्रसारित केलेल्या जागेसाठी वेगळा क्रम तयार करण्याची आवश्यकता नाही.

आम्ही Tarantool DBMS वापरून अनुप्रयोगांमध्ये उच्च-स्तरीय डेटा प्रतिकृतीचा एक प्रभावी मार्ग पाहिला.

निष्कर्ष

1. टारंटूल डीबीएमएस हे उच्च-लोड ऍप्लिकेशन्स तयार करण्यासाठी एक आकर्षक, आशादायक उत्पादन आहे.
2. निम्न-स्तरीय प्रतिकृतीपेक्षा उच्च-स्तरीय डेटा प्रतिकृतीचे अनेक फायदे आहेत.
3. लेखात चर्चा केलेली उच्च-स्तरीय प्रतिकृती पद्धत तुम्हाला केवळ गेल्या एक्सचेंज सत्रापासून बदललेल्या रेकॉर्डचे हस्तांतरण करून हस्तांतरित केलेल्या डेटाचे प्रमाण कमी करण्यास अनुमती देते.

स्त्रोत: www.habr.com