ڈیلٹا: ڈیٹا سنکرونائزیشن اور افزودگی پلیٹ فارم

شرح پر ایک نئے بہاؤ کے آغاز کی توقع میں ڈیٹا انجینئر ہم نے دلچسپ مواد کا ترجمہ تیار کیا ہے۔

کا جائزہ لیں

ہم کافی مقبول پیٹرن کے بارے میں بات کریں گے جس کے ذریعے ایپلیکیشنز متعدد ڈیٹا اسٹورز کا استعمال کرتی ہیں، جہاں ہر اسٹور کو اپنے مقاصد کے لیے استعمال کیا جاتا ہے، مثال کے طور پر، ڈیٹا کی کینونیکل شکل (MySQL، وغیرہ) کو ذخیرہ کرنے کے لیے، اعلی درجے کی تلاش کی صلاحیتیں فراہم کرتے ہیں (ElasticSearch، وغیرہ)، کیشنگ (Memcached، وغیرہ) اور دیگر۔ عام طور پر، ایک سے زیادہ ڈیٹا اسٹورز استعمال کرتے وقت، ان میں سے ایک پرائمری اسٹور کے طور پر کام کرتا ہے اور دوسرے کو مشتق اسٹورز کے طور پر۔ صرف مسئلہ یہ ہے کہ ان ڈیٹا اسٹورز کو کیسے ہم آہنگ کیا جائے۔

ہم نے متعدد مختلف نمونوں کو دیکھا جنہوں نے متعدد اسٹورز کو ہم آہنگ کرنے کے مسئلے کو حل کرنے کی کوشش کی، جیسے ڈبل رائٹ، تقسیم شدہ لین دین وغیرہ۔ تاہم، ان طریقوں میں حقیقی زندگی کے استعمال، وشوسنییتا، اور دیکھ بھال کے لحاظ سے اہم حدود ہیں۔ ڈیٹا سنکرونائزیشن کے علاوہ، کچھ ایپلیکیشنز کو بیرونی خدمات کو کال کر کے ڈیٹا کو بہتر بنانے کی بھی ضرورت ہوتی ہے۔

ڈیلٹا ان مسائل کو حل کرنے کے لیے تیار کیا گیا تھا۔ ڈیلٹا بالآخر ڈیٹا کی مطابقت پذیری اور افزودگی کے لیے ایک مستقل، ایونٹ پر مبنی پلیٹ فارم فراہم کرتا ہے۔

موجودہ حل۔

ڈبل انٹری

دو ڈیٹا اسٹورز کو مطابقت پذیر رکھنے کے لیے، آپ ڈوئل رائٹ استعمال کر سکتے ہیں، جو ایک اسٹور پر لکھتا ہے اور پھر فوراً بعد دوسرے کو لکھتا ہے۔ پہلی ریکارڈنگ کی دوبارہ کوشش کی جا سکتی ہے اور دوسری کو روکا جا سکتا ہے اگر کوششوں کی تعداد ختم ہونے کے بعد پہلی ناکام ہو جائے۔ تاہم، اگر دوسرے سٹور کو لکھنا ناکام ہو جاتا ہے تو دونوں ڈیٹا سٹور مطابقت پذیر ہو سکتے ہیں۔ یہ مسئلہ عام طور پر ایک ریکوری طریقہ کار بنا کر حل کیا جاتا ہے جو وقتاً فوقتاً ڈیٹا کو پہلے اسٹوریج سے دوسرے میں منتقل کر سکتا ہے، یا ایسا صرف اس صورت میں کیا جا سکتا ہے جب ڈیٹا میں فرق پایا جائے۔

مسائل یہ ہیں:

بحالی کے طریقہ کار کو انجام دینا ایک مخصوص کام ہے جسے دوبارہ استعمال نہیں کیا جا سکتا۔ اس کے علاوہ، سٹوریج کے مقامات کے درمیان ڈیٹا مطابقت پذیری سے باہر رہتا ہے جب تک کہ بحالی کا طریقہ کار نہیں ہوتا ہے۔ اگر دو سے زیادہ ڈیٹا اسٹورز استعمال کیے جائیں تو حل زیادہ پیچیدہ ہو جاتا ہے۔ آخر میں، بحالی کا طریقہ کار اصل ڈیٹا ماخذ پر بوجھ ڈال سکتا ہے۔

لاگ ٹیبل کو تبدیل کریں۔

جب جدولوں کے سیٹ میں تبدیلیاں آتی ہیں (جیسے ریکارڈ ڈالنا، اپ ڈیٹ کرنا اور حذف کرنا)، تبدیلی کے ریکارڈ اسی لین دین کے حصے کے طور پر لاگ ٹیبل میں شامل کیے جاتے ہیں۔ ایک اور دھاگہ یا عمل لاگ ٹیبل سے مسلسل واقعات کی درخواست کرتا ہے اور انہیں ایک یا زیادہ ڈیٹا اسٹورز پر لکھتا ہے، اگر ضروری ہو تو، تمام اسٹورز سے ریکارڈ کی تصدیق ہونے کے بعد لاگ ٹیبل سے واقعات کو ہٹاتا ہے۔

مسائل یہ ہیں:

اس پیٹرن کو لائبریری کے طور پر لاگو کیا جانا چاہیے، اور مثالی طور پر اسے استعمال کرنے والے ایپلیکیشن کے کوڈ کو تبدیل کیے بغیر۔ پولی گلوٹ ماحول میں، ایسی لائبریری کا نفاذ کسی بھی ضروری زبان میں ہونا چاہیے، لیکن تمام زبانوں میں فعالیت اور رویے کی مستقل مزاجی کو یقینی بنانا بہت مشکل ہے۔

ایک اور مسئلہ سسٹمز میں اسکیما تبدیلیاں حاصل کرنے میں ہے جو ٹرانزیکشنل اسکیما تبدیلیوں کی حمایت نہیں کرتے [1][2]، جیسے MySQL۔ لہذا، تبدیلی کرنے کا پیٹرن (مثال کے طور پر، اسکیما میں تبدیلی) اور اسے تبدیلی کے لاگ ٹیبل میں لین دین کے طور پر ریکارڈ کرنا ہمیشہ کام نہیں کرے گا۔

تقسیم شدہ لین دین

تقسیم شدہ لین دین کو متعدد متضاد ڈیٹا اسٹورز میں لین دین کو تقسیم کرنے کے لیے استعمال کیا جا سکتا ہے تاکہ آپریشن یا تو استعمال کیے گئے تمام ڈیٹا اسٹورز کے لیے پرعزم ہو، یا ان میں سے کسی کے لیے بھی پابند نہ ہو۔

مسائل یہ ہیں:

متفاوت ڈیٹا اسٹورز کے لیے تقسیم شدہ لین دین ایک بہت بڑا مسئلہ ہے۔ اپنی فطرت کے مطابق، وہ صرف اس میں شامل نظاموں کے سب سے کم مشترک ڈینومینیٹر پر بھروسہ کر سکتے ہیں۔ مثال کے طور پر، اگر تیاری کے مرحلے کے دوران درخواست کا عمل ناکام ہو جاتا ہے تو XA لین دین عمل درآمد کو روکتا ہے۔ مزید برآں، XA تعطل کا پتہ لگانے یا پرامید کنکرنسی کنٹرول اسکیموں کی حمایت نہیں کرتا ہے۔ اس کے علاوہ، کچھ سسٹمز جیسے ElasticSearch XA یا کسی دوسرے متضاد ٹرانزیکشن ماڈل کی حمایت نہیں کرتے ہیں۔ اس طرح، مختلف ڈیٹا اسٹوریج ٹیکنالوجیز میں رائٹ ایٹمیسیٹی کو یقینی بنانا ایپلی کیشنز کے لیے ایک بہت ہی مشکل کام ہے [3]۔

ڈیلٹا

ڈیلٹا کو موجودہ ڈیٹا سنکرونائزیشن سلوشنز کی حدود کو دور کرنے کے لیے ڈیزائن کیا گیا تھا اور ساتھ ہی آن دی فلائی ڈیٹا افزودگی کو بھی قابل بناتا ہے۔ ہمارا مقصد ان تمام پیچیدگیوں کو ایپلیکیشن ڈویلپرز سے دور کرنا تھا تاکہ وہ کاروباری فعالیت کو نافذ کرنے پر پوری توجہ مرکوز کر سکیں۔ اس کے بعد ہم "مووی سرچ" کی وضاحت کریں گے، جو Netflix کے ڈیلٹا کے لیے اصل استعمال کا معاملہ ہے۔

Netflix بڑے پیمانے پر مائیکرو سروس فن تعمیر کا استعمال کرتا ہے، اور ہر مائیکرو سروس عام طور پر ایک قسم کا ڈیٹا پیش کرتی ہے۔ فلم کے بارے میں بنیادی معلومات ایک مائیکرو سروس میں موجود ہے جسے مووی سروس کہتے ہیں، اور متعلقہ ڈیٹا جیسا کہ پروڈیوسرز، اداکاروں، وینڈرز وغیرہ کے بارے میں معلومات کا انتظام کئی دیگر مائیکرو سروسز (یعنی ڈیل سروس، ٹیلنٹ سروس اور وینڈر سروس) کے ذریعے کیا جاتا ہے۔
Netflix اسٹوڈیوز کے کاروباری صارفین کو اکثر فلم کے مختلف معیارات پر تلاش کرنے کی ضرورت ہوتی ہے، یہی وجہ ہے کہ ان کے لیے فلم سے متعلق تمام ڈیٹا کو تلاش کرنے کے قابل ہونا بہت ضروری ہے۔

ڈیلٹا سے پہلے، مووی سرچ ٹیم کو مووی ڈیٹا کو انڈیکس کرنے سے پہلے متعدد مائیکرو سروسز سے ڈیٹا کھینچنے کی ضرورت تھی۔ اس کے علاوہ، ٹیم کو ایک ایسا نظام تیار کرنا تھا جو وقتاً فوقتاً دیگر مائیکرو سروسز سے تبدیلیوں کی درخواست کر کے سرچ انڈیکس کو اپ ڈیٹ کرے، چاہے اس میں کوئی تبدیلی نہ ہو۔ یہ نظام تیزی سے پیچیدہ اور برقرار رکھنا مشکل ہو گیا۔

شکل 1. ڈیلٹا میں پولنگ سسٹم
ڈیلٹا استعمال کرنے کے بعد، سسٹم کو ایک ایونٹ سے چلنے والے سسٹم میں آسان بنایا گیا جیسا کہ درج ذیل تصویر میں دکھایا گیا ہے۔ CDC (Change-Data-Capture) ایونٹس ڈیلٹا کنیکٹر کا استعمال کرتے ہوئے کیسٹون کافکا کے موضوعات پر بھیجے جاتے ہیں۔ ڈیلٹا سٹریم پروسیسنگ فریم ورک (فلنک پر مبنی) کا استعمال کرتے ہوئے بنائی گئی ڈیلٹا ایپلیکیشن کسی موضوع سے سی ڈی سی ایونٹس وصول کرتی ہے، دیگر مائیکرو سروسز کو کال کر کے انہیں افزودہ کرتی ہے، اور آخر میں افزودہ ڈیٹا کو Elasticsearch میں سرچ انڈیکس میں منتقل کرتی ہے۔ پورا عمل تقریباً حقیقی وقت میں ہوتا ہے، یعنی جیسے ہی ڈیٹا گودام میں تبدیلیاں کی جاتی ہیں، تلاش کے اشاریہ جات کو اپ ڈیٹ کر دیا جاتا ہے۔

شکل 2۔ ڈیلٹا کا استعمال کرتے ہوئے ڈیٹا پائپ لائن
مندرجہ ذیل حصوں میں، ہم ڈیلٹا کنیکٹر کے آپریشن کی وضاحت کریں گے، جو سٹوریج سے منسلک ہوتا ہے اور CDC ایونٹس کو ٹرانسپورٹ لیئر میں شائع کرتا ہے، جو کہ ایک حقیقی وقت میں ڈیٹا ٹرانسمیشن انفراسٹرکچر ہے جو CDC ایونٹس کو کافکا کے موضوعات تک پہنچاتا ہے۔ اور بالکل آخر میں، ہم ڈیلٹا سٹریم پروسیسنگ فریم ورک کے بارے میں بات کریں گے، جسے ایپلیکیشن ڈویلپر ڈیٹا پروسیسنگ اور افزودگی منطق کے لیے استعمال کر سکتے ہیں۔

CDC (Change-Data-Capture)

ہم نے ڈیلٹا کنیکٹر کے نام سے ایک سی ڈی سی سروس تیار کی ہے، جو ڈیٹا سٹور سے حقیقی وقت میں کی جانے والی تبدیلیوں کو پکڑ سکتی ہے اور انہیں ایک سلسلہ میں لکھ سکتی ہے۔ ریئل ٹائم تبدیلیاں ٹرانزیکشن لاگ اور اسٹوریج ڈمپ سے لی جاتی ہیں۔ ڈمپ استعمال کیے جاتے ہیں کیونکہ ٹرانزیکشن لاگز عام طور پر تبدیلیوں کی پوری تاریخ کو محفوظ نہیں کرتے ہیں۔ تبدیلیوں کو عام طور پر ڈیلٹا ایونٹس کے طور پر ترتیب دیا جاتا ہے، لہذا وصول کنندہ کو یہ فکر کرنے کی ضرورت نہیں ہے کہ تبدیلی کہاں سے آتی ہے۔

ڈیلٹا کنیکٹر کئی اضافی خصوصیات کو سپورٹ کرتا ہے جیسے:

• کافکا سے پہلے حسب ضرورت آؤٹ پٹ ڈیٹا لکھنے کی صلاحیت۔
• تمام میزوں، مخصوص میز، یا مخصوص بنیادی کلیدوں کے لیے کسی بھی وقت دستی ڈمپ کو چالو کرنے کی صلاحیت۔
• ڈمپ کو ٹکڑوں میں بازیافت کیا جاسکتا ہے، لہذا ناکامی کی صورت میں دوبارہ شروع کرنے کی ضرورت نہیں ہے۔
• میزوں پر تالے لگانے کی کوئی ضرورت نہیں ہے، جو اس بات کو یقینی بنانے کے لیے بہت اہم ہے کہ ڈیٹا بیس تحریری ٹریفک کو ہماری سروس کے ذریعے کبھی بھی بلاک نہ کیا جائے۔
• AWS دستیابی زونز میں بے کار مثالوں کی وجہ سے زیادہ دستیابی۔

ہم فی الحال MySQL اور Postgres کو سپورٹ کرتے ہیں، بشمول AWS RDS اور Aurora پر تعیناتیاں۔ ہم کیسینڈرا (ملٹی ماسٹر) کی بھی حمایت کرتے ہیں۔ آپ ڈیلٹا کنیکٹر کے بارے میں مزید تفصیلات یہاں حاصل کر سکتے ہیں۔ بلاگ پوسٹ.

کافکا اور ٹرانسپورٹ کی تہہ

ڈیلٹا کی ایونٹ ٹرانسپورٹ لیئر پلیٹ فارم کی میسجنگ سروس پر بنائی گئی ہے۔ Keystone.

تاریخی طور پر، Netflix پر پوسٹنگ کو لمبی عمر کے بجائے رسائی کے لیے بہتر بنایا گیا ہے (نیچے دیکھیں)۔ گزشتہ مضمون)۔ ٹریڈ آف مختلف کنارے کے منظرناموں میں ممکنہ بروکر ڈیٹا کی عدم مطابقت تھی۔ مثال کے طور پر، ناپاک لیڈر الیکشن وصول کنندہ کے ممکنہ طور پر ڈپلیکیٹ یا گمشدہ واقعات کا ذمہ دار ہے۔

ڈیلٹا کے ساتھ، ہم حاصل شدہ اسٹورز پر CDC ایونٹس کی فراہمی کو یقینی بنانے کے لیے مضبوط پائیداری کی ضمانتیں چاہتے تھے۔ اس مقصد کے لیے، ہم نے خاص طور پر ڈیزائن کردہ کافکا کلسٹر کو فرسٹ کلاس آبجیکٹ کے طور پر تجویز کیا۔ آپ نیچے دیے گئے جدول میں بروکر کی کچھ ترتیبات کو دیکھ سکتے ہیں:

کی اسٹون کافکا کلسٹرز میں، ناپاک لیڈر الیکشن عام طور پر ناشر کی رسائی کو یقینی بنانے کے لیے شامل کیا جاتا ہے۔ اس کے نتیجے میں پیغام ضائع ہو سکتا ہے اگر ایک غیر مطابقت پذیر نقل کو لیڈر کے طور پر منتخب کیا جاتا ہے۔ ایک نئے اعلیٰ دستیابی کافکا کلسٹر کے لیے، آپشن ناپاک لیڈر الیکشن پیغام کے نقصان کو روکنے کے لیے بند کر دیا گیا۔

ہم نے بھی اضافہ کیا۔ نقل کا عنصر 2 سے 3 تک اور کم از کم مطابقت پذیری کی نقلیں 1 سے 2۔ اس کلسٹر پر لکھنے والے پبلشرز کو باقی تمام لوگوں سے ایک کی ضرورت ہوتی ہے، اس بات کو یقینی بناتے ہوئے کہ 2 میں سے 3 نقلوں میں پبلشر کی طرف سے بھیجے گئے سب سے حالیہ پیغامات ہیں۔

جب ایک بروکر مثال ختم ہو جاتی ہے، تو ایک نئی مثال پرانی کی جگہ لے لیتی ہے۔ تاہم، نئے بروکر کو غیر مطابقت پذیر نقلیں پکڑنے کی ضرورت ہوگی، جس میں کئی گھنٹے لگ سکتے ہیں۔ اس منظر نامے کے لیے بحالی کے وقت کو کم کرنے کے لیے، ہم نے مقامی بروکر ڈسک کے بجائے بلاک ڈیٹا اسٹوریج (ایمیزون ایلاسٹک بلاک اسٹور) کا استعمال شروع کیا۔ جب کوئی نئی مثال ختم شدہ بروکر مثال کی جگہ لے لیتی ہے، تو یہ EBS والیوم کو منسلک کرتا ہے جو ختم شدہ مثال کے پاس تھا اور نئے پیغامات کو پکڑنا شروع کر دیتا ہے۔ یہ عمل بیک لاگ کلیئرنس کے وقت کو گھنٹوں سے منٹوں تک کم کر دیتا ہے کیونکہ نئی مثال کو اب خالی حالت سے نقل کرنے کی ضرورت نہیں ہے۔ مجموعی طور پر، علیحدہ اسٹوریج اور بروکر لائف سائیکلز بروکر سوئچنگ کے اثرات کو نمایاں طور پر کم کرتے ہیں۔

ڈیٹا ڈیلیوری گارنٹی کو مزید بڑھانے کے لیے، ہم نے استعمال کیا۔ پیغام سے باخبر رہنے کا نظام انتہائی حالات میں کسی بھی پیغام کے نقصان کا پتہ لگانے کے لیے (مثال کے طور پر، پارٹیشن لیڈر میں کلاک ڈی سنکرونائزیشن)۔

سٹریم پروسیسنگ فریم ورک

ڈیلٹا کی پروسیسنگ پرت Netflix SPaaS پلیٹ فارم کے اوپر بنائی گئی ہے، جو Netflix ماحولیاتی نظام کے ساتھ Apache Flink انضمام فراہم کرتی ہے۔ پلیٹ فارم ایک صارف انٹرفیس فراہم کرتا ہے جو ہمارے Titus کنٹینر مینجمنٹ پلیٹ فارم کے اوپر Flink جابز کی تعیناتی اور Flink کلسٹرز کے آرکیسٹریشن کا انتظام کرتا ہے۔ انٹرفیس جاب کنفیگریشنز کا بھی انتظام کرتا ہے اور صارفین کو فلنک جابز کو دوبارہ کمپائل کیے بغیر متحرک طور پر کنفیگریشن تبدیلیاں کرنے کی اجازت دیتا ہے۔

ڈیلٹا Flink اور SPaaS پر مبنی اسٹریم پروسیسنگ فریم ورک فراہم کرتا ہے جو استعمال کرتا ہے۔ تشریح پر مبنی ڈی ایس ایل (ڈومین مخصوص زبان) تکنیکی تفصیلات کو خلاصہ کرنے کے لیے۔ مثال کے طور پر، اس مرحلے کی وضاحت کرنے کے لیے جس پر بیرونی خدمات کو کال کرنے سے واقعات کو تقویت ملے گی، صارفین کو درج ذیل DSL لکھنے کی ضرورت ہے، اور فریم ورک اس کی بنیاد پر ایک ماڈل بنائے گا، جسے Flink کے ذریعے عمل میں لایا جائے گا۔

شکل 3. ڈیلٹا میں DSL پر افزودگی کی مثال

پروسیسنگ فریم ورک نہ صرف سیکھنے کے منحنی خطوط کو کم کرتا ہے، بلکہ عام آپریشنل مسائل کو حل کرنے کے لیے عام سٹریم پروسیسنگ خصوصیات جیسے ڈیڈپلیکیشن، اسکیمیٹائزیشن، اور لچک اور لچک فراہم کرتا ہے۔

ڈیلٹا سٹریم پروسیسنگ فریم ورک دو اہم ماڈیولز، DSL اور API ماڈیول اور رن ٹائم ماڈیول پر مشتمل ہے۔ DSL اور API ماڈیول DSL اور UDF (User-defined-Function) APIs فراہم کرتا ہے تاکہ صارف اپنی پروسیسنگ منطق (جیسے فلٹرنگ یا تبدیلی) لکھ سکیں۔ رن ٹائم ماڈیول ایک DSL تجزیہ کار کا نفاذ فراہم کرتا ہے جو DAG ماڈلز میں پروسیسنگ کے مراحل کی اندرونی نمائندگی کرتا ہے۔ ایگزیکیوشن جزو DAG ماڈلز کی ترجمانی کرتا ہے تاکہ اصل Flink سٹیٹمنٹس کو شروع کیا جا سکے اور بالآخر Flink ایپلیکیشن کو چلایا جا سکے۔ فریم ورک کے فن تعمیر کو مندرجہ ذیل تصویر میں دکھایا گیا ہے۔

شکل 4. ڈیلٹا سٹریم پروسیسنگ فریم ورک فن تعمیر

اس نقطہ نظر کے کئی فوائد ہیں:

• صارفین Flink یا SPaaS ڈھانچے کی تفصیلات میں جانے کے بغیر اپنی کاروباری منطق پر توجہ مرکوز کر سکتے ہیں۔
• اصلاح اس طریقے سے کی جا سکتی ہے جو صارفین کے لیے شفاف ہو، اور صارف کوڈ (UDF) میں کسی تبدیلی کی ضرورت کے بغیر غلطیوں کو دور کیا جا سکتا ہے۔
• ڈیلٹا ایپلیکیشن کے تجربے کو صارفین کے لیے آسان بنایا گیا ہے کیونکہ یہ پلیٹ فارم باکس سے باہر لچک اور لچک فراہم کرتا ہے اور مختلف قسم کے تفصیلی میٹرکس جمع کرتا ہے جنہیں الرٹس کے لیے استعمال کیا جا سکتا ہے۔

پیداوار کا استعمال

ڈیلٹا ایک سال سے پروڈکشن میں ہے اور بہت سے نیٹ فلکس اسٹوڈیو ایپلی کیشنز میں کلیدی کردار ادا کرتا ہے۔ اس نے ٹیموں کو استعمال کے معاملات جیسے کہ سرچ انڈیکسنگ، ڈیٹا اسٹوریج، اور ایونٹ سے چلنے والے ورک فلو کو نافذ کرنے میں مدد کی۔ ذیل میں ڈیلٹا پلیٹ فارم کے اعلیٰ سطحی فن تعمیر کا ایک جائزہ ہے۔

شکل 5۔ ڈیلٹا کا اعلیٰ سطحی فن تعمیر۔

اعترافات

ہم ان لوگوں کا شکریہ ادا کرنا چاہیں گے جو نیٹ فلکس پر ڈیلٹا کی تخلیق اور ترقی میں شامل تھے: ایلن وانگ، چارلس ژاؤ، جیبن یون، جوش سنائیڈر، کستوری چٹرجی، مارک چو، اولوف جوہانسن، پیوش گوئل، پرشانتھ رامداس، رگھورام اونٹی۔ سری نواسن، سندیپ گپتا، اسٹیون وو، تھرنگا گامیتھیگے، یون وانگ اور ژین زونگ سو۔

ذرائع

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

مفت ویبینار کے لیے سائن اپ کریں۔: "ایمیزون ریڈ شفٹ اسٹوریج کے لیے ڈیٹا بلڈ ٹول۔"

ماخذ: www.habr.com