ڊيلٽا: ڊيٽا هم وقت سازي ۽ افزودگي پليٽ فارم

شرح تي نئين وهڪري جي شروعات جي اميد ۾ ڊيٽا انجنيئر اسان دلچسپ مواد جو ترجمو تيار ڪيو آهي.

جو جائزو

اسان ڪافي مشهور نموني جي باري ۾ ڳالهائينداسين جنهن جي ذريعي ايپليڪيشنون ڪيترن ئي ڊيٽا اسٽورن کي استعمال ڪن ٿيون، جتي هر اسٽور کي پنهنجي مقصدن لاء استعمال ڪيو ويندو آهي، مثال طور، ڊيٽا جي معياري شڪل کي ذخيرو ڪرڻ لاء (MySQL، وغيره)، ترقي يافته ڳولا صلاحيتون مهيا ڪريو (ElasticSearch، وغيره.)، ڪيشنگ (Memcached، وغيره) ۽ ٻيا. عام طور تي، جڏهن ڪيترن ئي ڊيٽا اسٽورن کي استعمال ڪندي، انهن مان هڪ بنيادي اسٽور جي طور تي ڪم ڪري ٿو ۽ ٻيا نڪتل اسٽوريج طور. صرف مسئلو اهو آهي ته انهن ڊيٽا اسٽورن کي هم وقت سازي ڪيئن ڪجي.

اسان ڪيترن ئي مختلف نمونن تي غور ڪيو جيڪي ڪيترن ئي اسٽورن کي هم وقت سازي ڪرڻ جي مسئلي کي حل ڪرڻ جي ڪوشش ڪئي، جهڙوڪ ڊبل لکڻ، ورهايل ٽرانزيڪشن وغيره. بهرحال، انهن طريقن ۾ حقيقي زندگي جي استعمال، اعتبار ۽ سار سنڀال جي لحاظ کان اهم حدون آهن. ڊيٽا جي هم وقت سازي جي اضافي ۾، ڪجهه ايپليڪيشنن کي ٻاهرين خدمتن کي ڪال ڪندي ڊيٽا کي بهتر ڪرڻ جي ضرورت آهي.

ڊيلٽا انهن مسئلن کي حل ڪرڻ لاء ترقي ڪئي وئي. ڊيلٽا آخرڪار ڊيٽا جي هم وقت سازي ۽ افزودگي لاءِ هڪ مسلسل، واقعي تي مبني پليٽ فارم مهيا ڪري ٿي.

موجوده حل

ٻيڻو داخلا

ٻن ڊيٽا اسٽورن کي هم وقت سازي ۾ رکڻ لاءِ، توهان استعمال ڪري سگهو ٿا ڊبل لکڻ، جيڪو هڪ اسٽور تي لکندو آهي ۽ پوءِ فوري طور تي ٻئي ڏانهن لکندو آهي. پهرين رڪارڊنگ ٻيهر ڪوشش ڪري سگهجي ٿي ۽ ٻي کي ختم ڪري سگهجي ٿو جيڪڏهن پهرين ناڪام ٿيڻ کان پوءِ ڪوششن جو تعداد ختم ٿي ويو آهي. بهرحال، ٻه ڊيٽا اسٽور شايد هم وقت سازي کان ٻاهر ٿي وڃن جيڪڏهن ٻئي اسٽور ڏانهن لکڻ ناڪام ٿئي. اهو مسئلو عام طور تي هڪ وصولي جي طريقيڪار ٺاهڻ سان حل ڪيو ويندو آهي جيڪو وقتي طور تي ڊيٽا کي پهرين اسٽوريج کان ٻئي ڏانهن منتقل ڪري سگهي ٿو، يا ائين ڪريو صرف ان صورت ۾ جڏهن ڊيٽا ۾ فرق معلوم ٿئي.

مسئلا:

بحالي جي طريقيڪار کي انجام ڏيڻ هڪ مخصوص نوڪري آهي جنهن کي ٻيهر استعمال نٿو ڪري سگهجي. ان کان علاوه، اسٽوريج جي جڳهن جي وچ ۾ ڊيٽا هم وقت سازي کان ٻاهر رهي ٿي جيستائين بحالي جي طريقيڪار تي عمل ٿئي. حل وڌيڪ پيچيده ٿي ويندو آهي جيڪڏهن ٻن کان وڌيڪ ڊيٽا اسٽور استعمال ڪيا وڃن. آخرڪار، بحالي جي طريقيڪار اصل ڊيٽا جي ماخذ تي لوڊ شامل ڪري سگھي ٿي.

لاگ ٽيبل تبديل ڪريو

جڏهن تبديليون جدولن جي هڪ سيٽ ۾ ٿينديون آهن (جهڙوڪ رڪارڊ داخل ڪرڻ، تازه ڪاري ڪرڻ ۽ حذف ڪرڻ)، تبديلي جا رڪارڊ لاگ ٽيبل ۾ شامل ڪيا ويندا آهن ساڳي ٽرانزيڪشن جي حصي طور. هڪ ٻيو ٿريڊ يا عمل مسلسل لاگ ٽيبل تان واقعن جي درخواست ڪري ٿو ۽ انهن کي هڪ يا وڌيڪ ڊيٽا اسٽورن ڏانهن لکي ٿو، جيڪڏهن ضروري هجي ته، سڀني اسٽورن طرفان رڪارڊ جي تصديق ٿيڻ کان پوءِ لاگ ٽيبل تان واقعن کي هٽايو وڃي.

مسئلا:

اهو نمونو لائبريري جي طور تي لاڳو ڪيو وڃي، ۽ مثالي طور تي ايپليڪيشن جي ڪوڊ کي تبديل ڪرڻ کان سواء جيڪو استعمال ڪري ٿو. پولي گلوٽ ماحول ۾، اهڙي لائبريريءَ جو نفاذ ڪنهن به ضروري ٻوليءَ ۾ موجود هجڻ گهرجي، پر سڀني ٻولين ۾ ڪارڪردگيءَ ۽ رويي جي تسلسل کي يقيني بڻائڻ تمام ڏکيو ڪم آهي.

ٻيو مسئلو سسٽم ۾ اسڪيما تبديلين کي حاصل ڪرڻ ۾ آهي جيڪي ٽرانزيڪشنل اسڪيما تبديلين کي سپورٽ نٿا ڪن [1][2]، جهڙوڪ MySQL. تنهن ڪري، تبديلي ڪرڻ جو نمونو (مثال طور، هڪ اسڪيما تبديلي) ۽ ٽرانزيڪشن طور ان کي تبديلي جي لاگ ٽيبل ۾ رڪارڊ ڪرڻ هميشه ڪم نه ڪندو.

ورهايل ٽرانزيڪشن

ورهايل ٽرانزيڪشن هڪ ٽرانزيڪشن کي ڪيترن ئي متفاوت ڊيٽا اسٽورن ۾ ورهائڻ لاءِ استعمال ڪري سگھجن ٿيون ته جيئن آپريشن يا ته استعمال ٿيل سڀني ڊيٽا اسٽورن لاءِ انجام ڏنو وڃي، يا انهن مان ڪنهن سان به انجام نه ڏنو وڃي.

مسئلا:

ورهايل ٽرانزيڪشن هڪ تمام وڏو مسئلو آهي متضاد ڊيٽا اسٽورن لاءِ. انهن جي فطرت سان، اهي صرف ان ۾ شامل نظام جي سڀ کان گهٽ عام ڊنوميٽر تي ڀروسو ڪري سگهن ٿا. مثال طور، XA ٽرانزيڪشن تي عملدرآمد کي روڪي ٿو جيڪڏهن درخواست جي عمل کي تياري جي مرحلي دوران ناڪام ٿئي ٿي. اضافي طور تي، XA ڊيڊ لاڪ ڳولڻ يا سپورٽ اميد رکندڙ اتفاق ڪنٽرول اسڪيمن کي فراهم نٿو ڪري. ان کان علاوه، ڪجهه سسٽم جهڙوڪ ElasticSearch XA يا ڪنهن ٻئي متضاد ٽرانزيڪشن ماڊل کي سپورٽ نٿا ڪن. اهڙيء طرح، مختلف ڊيٽا اسٽوريج ٽيڪنالاجيز ۾ لکڻ جي ايٽمي کي يقيني بڻائڻ ايپليڪيشنن لاء هڪ تمام مشڪل ڪم رهي ٿو [3].

علائقو

ڊيلٽا کي موجوده ڊيٽا جي هم وقت سازي جي حلن جي حدن کي حل ڪرڻ لاءِ ڊزائين ڪيو ويو آهي ۽ انهي کي پڻ فعال ڪري ٿو آن-دي-فائي ڊيٽا جي افزودگي. اسان جو مقصد انهن سڀني پيچيدگين کي ايپليڪيشن ڊولپرز کان پري ڪرڻ هو ته جيئن اهي ڪاروباري ڪارڪردگي کي لاڳو ڪرڻ تي مڪمل ڌيان ڏئي سگهن. اڳيون اسين بيان ڪنداسين "مووي ڳولها"، اصل استعمال ڪيس Netflix جي ڊيلٽا لاءِ.

Netflix وڏي پيماني تي استعمال ڪري ٿو هڪ microservice فن تعمير، ۽ هر microservice عام طور تي هڪ قسم جي ڊيٽا جي خدمت ڪندو آهي. فلم بابت بنيادي معلومات مائيڪرو سروس ۾ موجود آهي جنهن کي مووي سروس سڏيو ويندو آهي، ۽ لاڳاپيل ڊيٽا جهڙوڪ پروڊيوسر، اداڪار، وينڊرز، وغيره بابت معلومات ڪيترن ئي ٻين مائڪرو سروسز (يعني ڊيل سروس، ٽيلنٽ سروس ۽ وينڊر سروس) پاران منظم ڪئي ويندي آهي.
Netflix اسٽوڊيو تي ڪاروبار استعمال ڪندڙ اڪثر ڪري مختلف فلمن جي معيارن تي ڳولا ڪرڻ جي ضرورت آهي، ڇو ته اهو انهن لاء تمام ضروري آهي ته اهي فلم سان لاڳاپيل ڊيٽا کي ڳولڻ جي قابل هوندا.

ڊيلٽا کان اڳ، فلم جي ڳولا ٽيم کي فلم ڊيٽا کي ترتيب ڏيڻ کان اڳ ڪيترن ئي مائڪرو سروسز مان ڊيٽا ڪڍڻ جي ضرورت هئي. ان کان علاوه، ٽيم کي هڪ سسٽم ٺاهڻو هو جيڪو وقتي طور تي ٻين مائڪرو سروسز کان تبديلين جي درخواست ڪندي سرچ انڊيڪس کي اپڊيٽ ڪندو، جيتوڻيڪ اتي ڪا به تبديلي نه هئي. اهو نظام جلدي پيچيده ۽ برقرار رکڻ ڏکيو ٿي ويو.

شڪل 1. ڊيلٽا ڏانهن پولنگ سسٽم
ڊيلٽا استعمال ڪرڻ کان پوءِ، سسٽم کي آسان ڪيو ويو ايونٽ هلائيندڙ سسٽم ۾ جيئن هيٺ ڏنل شڪل ۾ ڏيکاريل آهي. سي ڊي سي (Change-Data-Capture) واقعا ڪيسٽون ڪافڪا جي موضوعن تي ڊيلٽا ڪنيڪٽر استعمال ڪندي موڪليا ويندا آهن. ڊيلٽا اسٽريم پروسيسنگ فريم ورڪ (Flink جي بنياد تي) استعمال ڪندي ٺاهيل ڊيلٽا ايپليڪيشن هڪ موضوع کان سي ڊي سي واقعا وصول ڪري ٿي، انهن کي ٻين مائڪرو سروسز کي ڪال ڪري ان کي بهتر بڻائي ٿي، ۽ آخر ۾ بهتر ڪيل ڊيٽا کي Elasticsearch ۾ سرچ انڊيڪس ڏانهن منتقل ڪري ٿي. سڄو عمل تقريباً حقيقي وقت ۾ ٿئي ٿو، يعني جيئن ئي ڊيٽا گودام ۾ تبديليون ڪيون وينديون آهن، سرچ انڊيڪس اپڊيٽ ڪيا ويندا آهن.

شڪل 2. ڊيلٽا استعمال ڪندي ڊيٽا پائپ لائن
هيٺين حصن ۾، اسين ڊيلٽا-ڪنيڪٽر جي آپريشن کي بيان ڪنداسين، جيڪو اسٽوريج سان ڳنڍيندو آهي ۽ سي ڊي سي واقعن کي ٽرانسپورٽ پرت ڏانهن شايع ڪري ٿو، جيڪو حقيقي وقت جي ڊيٽا ٽرانسميشن انفراسٽرڪچر آهي جيڪو سي ڊي سي واقعن کي ڪافڪا جي عنوانن ڏانهن روانو ڪري ٿو. ۽ بلڪل آخر ۾، اسين ڊيلٽا اسٽريم پروسيسنگ فريم ورڪ بابت ڳالهائينداسين، جنهن کي ايپليڪيشن ڊولپرز ڊيٽا پروسيسنگ ۽ افزودگي منطق لاءِ استعمال ڪري سگھن ٿا.

سي ڊي سي (تبديلي-ڊيٽا-ڪپچر)

اسان ڊيلٽا-ڪنيڪٽر نالي هڪ سي ڊي سي سروس تيار ڪئي آهي، جيڪا حقيقي وقت ۾ ڊيٽا اسٽور مان ڪيل تبديلين کي پڪڙي سگهي ٿي ۽ انهن کي اسٽريم ۾ لکي سگهي ٿي. حقيقي وقت جي تبديلين کي ٽرانزيڪشن لاگ ۽ اسٽوريج ڊمپ مان ورتو وڃي ٿو. ڊمپس استعمال ڪيا ويا آهن ڇو ته ٽرانزيڪشن لاگز عام طور تي تبديلين جي پوري تاريخ کي ذخيرو نٿا ڪن. تبديليون عام طور تي ڊيلٽا واقعن جي طور تي سيريل ٿيل آهن، تنهنڪري وصول ڪندڙ کي پريشان ٿيڻ جي ضرورت ناهي ته تبديلي ڪٿان اچي ٿي.

ڊيلٽا ڪنيڪٽر ڪيترن ئي اضافي خاصيتن کي سپورٽ ڪري ٿو جهڙوڪ:

• ڪافڪا کان اڳ ڪسٽم آئوٽ پٽ ڊيٽا لکڻ جي صلاحيت.
• دستي ڊمپ کي چالو ڪرڻ جي صلاحيت ڪنهن به وقت سڀني ٽيبلن لاءِ، هڪ مخصوص ٽيبل، يا مخصوص پرائمري ڪنجيز لاءِ.
• ڊمپ کي حصن ۾ ٻيهر حاصل ڪري سگهجي ٿو، تنهنڪري ناڪامي جي صورت ۾ ٻيهر شروع ڪرڻ جي ڪا ضرورت ناهي.
• ٽيبل تي تالا رکڻ جي ڪا ضرورت ناهي، جيڪا تمام ضروري آهي انهي کي يقيني بڻائڻ لاءِ ته ڊيٽابيس لکڻ جي ٽرئفڪ کي ڪڏهن به اسان جي سروس طرفان بلاڪ نه ڪيو وڃي.
• AWS دستيابي زونن ۾ بيڪار مثالن جي ڪري اعلي دستيابي.

اسان في الحال MySQL ۽ Postgres کي سپورٽ ڪريون ٿا، بشمول AWS RDS ۽ Aurora تي تعیناتي. اسان پڻ Cassandra (ملٽي ماسٽر) جي حمايت ڪندا آهيون. توھان ڳولي سگھوٿا وڌيڪ تفصيل ڊيلٽا-Connector بابت هتي بلاگ پوسٽ.

ڪافڪا ۽ ٽرانسپورٽ پرت

ڊيلٽا جي ايونٽ ٽرانسپورٽ پرت پليٽ فارم جي ميسيجنگ سروس تي ٺهيل آهي پيڙهه.

تاريخي طور تي، Netflix تي پوسٽنگ کي ڊگھي عمر جي ڀيٽ ۾ رسائي لاء بهتر ڪيو ويو آهي (هيٺ ڏسو). پويون مضمون). واپار بند امڪاني بروکر ڊيٽا جي متضاد هئي مختلف ڪنڊن جي منظرنامي ۾. مثال طور، ناپاڪ ليڊر اليڪشن وصول ڪندڙ لاءِ ذميوار آهي ممڪن طور تي نقل يا گم ٿيل واقعا.

ڊيلٽا سان، اسان چاهيون ٿا مضبوط پائيدار ضمانتون حاصل ڪرڻ لاءِ سي ڊي سي واقعن جي ترسيل کي يقيني بڻائڻ لاءِ نڪتل اسٽورن تي. هن مقصد لاء، اسان هڪ خاص طور تي ٺهيل ڪافڪا ڪلستر کي فرسٽ ڪلاس اعتراض جي طور تي پيش ڪيو. توھان ھيٺ ڏنل جدول ۾ ڪجھ بروکر سيٽنگون ڏسي سگھو ٿا:

Keystone Kafka ڪلستر ۾، ناپاڪ ليڊر اليڪشن عام طور تي پبلشر جي رسائي کي يقيني بڻائڻ لاء شامل آهي. اهو نتيجو ٿي سگهي ٿو گم ٿيل پيغامن جي صورت ۾ جيڪڏهن هڪ غير هم وقت ٿيل نقل کي اڳواڻ طور چونڊيو وڃي. نئين اعلي دستيابي ڪافڪا ڪلستر لاء، اختيار ناپاڪ ليڊر اليڪشن پيغام جي نقصان کي روڪڻ لاء بند ڪيو.

اسان به وڌياسين نقل ڪرڻ وارو عنصر 2 کان 3 تائين ۽ گھٽ ۾ گھٽ insync replicas 1 کان 2. پبلشرز جيڪي ھن ڪلستر ڏانھن لکندا آھن انھن کي ٻين سڀني کان جوابن جي ضرورت آھي، يقيني بڻائڻ ته 2 مان 3 نقلن ۾ پبلشر پاران موڪليل سڀ کان وڌيڪ موجوده پيغام آھن.

جڏهن هڪ بروکر مثال ختم ٿئي ٿو، هڪ نئون مثال پراڻي کي تبديل ڪري ٿو. جڏهن ته، نئين بروکر کي پڪڙڻ جي ضرورت پوندي غير هم وقت ٿيل نقلن سان، جنهن ۾ ڪيترائي ڪلاڪ وٺي سگھن ٿا. هن منظر جي بحالي واري وقت کي گهٽائڻ لاءِ، اسان استعمال ڪرڻ شروع ڪيو بلاڪ ڊيٽا اسٽوريج (Amazon Elastic Block Store) بدران مقامي بروکر ڊسڪ جي. جڏهن هڪ نئون مثال ختم ٿيل بروکر مثال کي تبديل ڪري ٿو، اهو EBS حجم کي ڳنڍيندو آهي جيڪو ختم ٿيل مثال هو ۽ نئين پيغامن سان پڪڙڻ شروع ٿئي ٿو. اهو عمل ڪلاڪ کان منٽن تائين بيڪ لاگ ڪليئرنس وقت گھٽائي ٿو ڇاڪاڻ ته نئين مثال کي هاڻي خالي رياست کان نقل ڪرڻ جي ضرورت ناهي. مجموعي طور تي، الڳ اسٽوريج ۽ بروکر لائف سائيڪل خاص طور تي بروکر سوئچنگ جي اثر کي گھٽائي ٿو.

ڊيٽا پهچائڻ جي ضمانت کي وڌيڪ وڌائڻ لاء، اسان استعمال ڪيو پيغام ٽريڪنگ سسٽم انتهائي حالتن ۾ ڪنهن به پيغام جي نقصان کي ڳولڻ لاء (مثال طور، ورهاڱي جي اڳواڻ ۾ گھڙي جي ڊسڪشن).

اسٽريم پروسيسنگ فريم ورڪ

ڊيلٽا جي پروسيسنگ پرت Netflix SPaaS پليٽ فارم جي چوٽي تي ٺهيل آهي، جيڪا Netflix ماحولياتي نظام سان Apache Flink انضمام مهيا ڪري ٿي. پليٽ فارم هڪ صارف انٽرفيس مهيا ڪري ٿو جيڪو اسان جي ٽائيٽس ڪنٽينر مئنيجمينٽ پليٽ فارم جي چوٽي تي Flink نوڪريون ۽ Flink ڪلستر جي آرڪيسٽريشن جي ترتيب کي منظم ڪري ٿو. انٽرفيس نوڪري جي ترتيبن کي پڻ منظم ڪري ٿو ۽ صارفين کي اجازت ڏئي ٿو ته ڪنفيگريشن تبديليون متحرڪ طور تي بغير فلڪ نوڪريون ٻيهر گڏ ڪرڻ جي.

ڊيلٽا مهيا ڪري ٿو هڪ وهڪرو پروسيسنگ فريم ورڪ جي بنياد تي Flink ۽ SPaaS جيڪو استعمال ڪري ٿو تشريح جي بنياد تي DSL (ڊومين مخصوص ٻولي) تخنيقي تفصيلن کي ختم ڪرڻ لاء. مثال طور، ان قدم جي وضاحت ڪرڻ لاءِ جنهن تي واقعن کي ڪال ڪندي خارجي خدمتن کي وڌايو ويندو، صارفين کي هيٺين DSL لکڻ جي ضرورت آهي، ۽ فريم ورڪ ان جي بنياد تي هڪ ماڊل ٺاهيندو، جيڪو Flink پاران عمل ڪيو ويندو.

شڪل 3. ڊيلٽا ۾ ڊي ايس ايل تي افزودگي جو مثال

پروسيسنگ فريم ورڪ نه رڳو سکيا جي وکر کي گھٽائي ٿو، پر عام آپريشنل مسئلن کي حل ڪرڻ لاءِ عام اسٽريم پروسيسنگ خاصيتون جهڙوڪ ڊيپليٽيشن، اسڪيمائيزيشن، ۽ لچڪ ۽ لچڪ پڻ مهيا ڪري ٿو.

ڊيلٽا اسٽريم پروسيسنگ فريم ورڪ ٻن اهم ماڊلز تي مشتمل آهي، ڊي ايس ايل ۽ API ماڊل ۽ رن ٽائيم ماڊل. DSL ۽ API ماڊل DSL ۽ UDF (User-Defined-Function) APIs مهيا ڪري ٿو ته جيئن صارف پنهنجو پروسيسنگ منطق لکي سگھن (جهڙوڪ فلٽرنگ يا تبديليون). رن ٽائم ماڊل هڪ ڊي ايس ايل پارسر جو نفاذ مهيا ڪري ٿو جيڪو DAG ماڊلز ۾ پروسيسنگ مرحلن جي اندروني نمائندگي ٺاهي ٿو. Execution جزو اصل Flink بيانن کي شروع ڪرڻ ۽ آخرڪار Flink ايپليڪيشن کي هلائڻ لاءِ DAG ماڊل جي ترجماني ڪري ٿو. فريم ورڪ جي فن تعمير هيٺ ڏنل شڪل ۾ بيان ڪئي وئي آهي.

شڪل 4. ڊيلٽا اسٽريم پروسيسنگ فريم ورڪ آرڪيٽيڪچر

ھن طريقي سان ڪيترائي فائدا آھن:

• صارفين کي Flink يا SPaaS جي جوڙجڪ جي وضاحتن ۾ شامل ٿيڻ جي بغير پنھنجي ڪاروباري منطق تي ڌيان ڏئي سگھي ٿو.
• اصلاح اهڙي طريقي سان ٿي سگهي ٿي جيڪا صارفين لاءِ شفاف هجي، ۽ غلطين کي درست ڪري سگهجي ٿو بغير ڪنهن تبديليءَ جي صارف ڪوڊ (UDF) ۾.
• ڊيلٽا ايپليڪيشن جو تجربو استعمال ڪندڙن لاءِ آسان ڪيو ويو آهي ڇاڪاڻ ته پليٽ فارم لچڪ ۽ لچڪ فراهم ڪري ٿو دٻي کان ٻاهر ۽ مختلف تفصيلي ميٽرڪ گڏ ڪري ٿو جيڪي الرٽ لاءِ استعمال ٿي سگهن ٿيون.

پيداوار جي استعمال

ڊيلٽا هڪ سال کان مٿي پيداوار ۾ آهي ۽ ڪيترن ئي Netflix اسٽوڊيو ايپليڪيشنن ۾ اهم ڪردار ادا ڪري ٿو. هن ٽيمن کي استعمال جي ڪيسن تي عمل ڪرڻ ۾ مدد ڪئي جهڙوڪ سرچ انڊيڪسنگ، ڊيٽا اسٽوريج، ۽ واقعي تي هلندڙ ڪم فلوز. هيٺ ڏنل ڊيلٽا پليٽ فارم جي اعلي سطحي فن تعمير جو هڪ جائزو آهي.

شڪل 5. ڊيلٽا جي اعلي سطحي فن تعمير.

مڃيل نشانيون

اسان ھيٺين ماڻھن جو شڪريو ادا ڪرڻ چاھيون ٿا جيڪي Netflix تي ڊيلٽا جي ٺاھڻ ۽ ترقيءَ ۾ شامل ھئا: ايلن وانگ، چارلس زاؤ، جيبن يون، جوش سنيڊر، ڪستوري چترجي، مارڪ چو، اولوف جوهانسن، پيوش گوئل، پرشانٿ رامداس، رگھورام اونٽي. سري نواسن، سنديپ گپتا، اسٽيون وو، ٿرنگا گاميٿيگي، يون وانگ ۽ زين زونگ سو.

ذريعو

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. مارٽن ڪلپمن، اليسٽر آر بيرسفورڊ، بوئرج سوينگن: آن لائين ايونٽ پروسيسنگ. ڪميون. ACM 62(5): 43–49 (2019). DOI: doi.org/10.1145/3312527

مفت ويبينار لاءِ سائن اپ ڪريو: "ڊيٽا بلڊ ٽول Amazon Redshift Storage لاءِ."

جو ذريعو: www.habr.com