کیسینڈرا۔ اگر آپ صرف اوریکل جانتے ہیں تو کیسے مرنا نہیں ہے۔

ارے حبر۔

میرا نام Misha Butrimov ہے، میں آپ کو Cassandra کے بارے میں کچھ بتانا چاہوں گا۔ میری کہانی ان لوگوں کے لیے کارآمد ہو گی جنہوں نے کبھی NoSQL ڈیٹا بیس کا سامنا نہیں کیا ہے - اس میں نفاذ کی بہت سی خصوصیات اور خرابیاں ہیں جن کے بارے میں آپ کو جاننے کی ضرورت ہے۔ اور اگر آپ نے اوریکل یا کسی اور متعلقہ ڈیٹا بیس کے علاوہ کچھ نہیں دیکھا تو یہ چیزیں آپ کی جان بچائیں گی۔

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

وہ اور کیا اچھی ہے؟ یہ بہت ساری درخواستوں کو سنبھالنے کے بارے میں ہے۔ لیکن بہت کچھ کتنا ہے؟ فی سیکنڈ 10، 20، 30، 40 ہزار درخواستیں زیادہ نہیں ہیں۔ ریکارڈنگ کے لیے فی سیکنڈ 100 ہزار درخواستیں - بھی۔ ایسی کمپنیاں ہیں جنہوں نے کہا کہ وہ فی سیکنڈ 2 ملین درخواستیں رکھتی ہیں۔ انہیں شاید اس پر یقین کرنا پڑے گا۔

اور اصولی طور پر، کیسینڈرا کو متعلقہ اعداد و شمار سے ایک بڑا فرق ہے - یہ ان سے بالکل مماثل نہیں ہے۔ اور یہ یاد رکھنا بہت ضروری ہے۔

ایک جیسی نظر آنے والی ہر چیز یکساں کام نہیں کرتی

ایک بار ایک ساتھی میرے پاس آیا اور پوچھا: "یہاں ایک CQL کیسینڈرا استفسار کی زبان ہے، اور اس میں ایک منتخب بیان ہے، اس میں کہاں ہے، اس میں ہے اور ہے۔ میں خط لکھتا ہوں اور یہ کام نہیں کرتا۔ کیوں؟" کیسینڈرا کو رشتہ دار ڈیٹا بیس کی طرح برتاؤ کرنا پرتشدد خودکشی کرنے کا بہترین طریقہ ہے۔ اور میں اس کی تشہیر نہیں کر رہا ہوں، یہ روس میں ممنوع ہے۔ آپ صرف کچھ غلط ڈیزائن کریں گے۔

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

اس کی وجہ یہ ہے کہ کیسینڈرا ایک ہائبرڈ ڈیٹا بیس ہے: یہ بیک وقت کلیدی قدر فراہم کرتا ہے اور ڈیٹا کو وسیع کالموں میں اسٹور کرتا ہے۔ جاوا یا کوٹلن میں، اسے اس طرح بیان کیا جا سکتا ہے:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

یعنی ایک نقشہ جس میں ترتیب شدہ نقشہ بھی ہو۔ اس نقشے کی پہلی کلید Row کلید یا پارٹیشن کی ہے - پارٹیشننگ کلید۔ دوسری کلید، جو پہلے سے ترتیب شدہ نقشے کی کلید ہے، کلسٹرنگ کلید ہے۔

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

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

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

اس معاملے میں بنیادی کلید ایک کالم پر مشتمل ہوتی ہے، اور یہ تقسیم کرنے والی کلید بھی ہے۔

ہمارے صارفین کی کارکردگی کیسے ہوگی؟ کچھ ایک نوڈ پر جائیں گے، کچھ دوسرے میں، اور کچھ تیسرے پر جائیں گے۔ نتیجہ ایک عام ہیش ٹیبل ہے، جسے نقشہ بھی کہا جاتا ہے، جسے Python میں ڈکشنری بھی کہا جاتا ہے، یا کلیدی قدر کا ایک سادہ ڈھانچہ جس سے ہم تمام اقدار کو پڑھ سکتے ہیں، کلید کے ذریعے پڑھ سکتے ہیں اور لکھ سکتے ہیں۔

منتخب کریں: جب فلٹرنگ مکمل اسکین میں بدل جائے، یا کیا نہ کیا جائے۔

آئیے کچھ منتخب بیان لکھتے ہیں: select * from users where, userid = . یہ اوریکل کی طرح پتہ چلتا ہے: ہم سلیکٹ لکھتے ہیں، شرائط کی وضاحت کرتے ہیں اور سب کچھ کام کرتا ہے، صارفین کو مل جاتا ہے۔ لیکن اگر آپ، مثال کے طور پر، پیدائش کے ایک مخصوص سال والے صارف کو منتخب کرتے ہیں، تو Cassandra شکایت کرتی ہے کہ وہ درخواست کو پورا نہیں کر سکتا۔ کیونکہ وہ اس بارے میں کچھ بھی نہیں جانتی ہے کہ ہم کس طرح پیدائش کے سال کے بارے میں ڈیٹا تقسیم کرتے ہیں - اس کے پاس کلید کے طور پر صرف ایک کالم اشارہ کیا گیا ہے۔ پھر وہ کہتی ہے، "ٹھیک ہے، میں اب بھی اس درخواست کو پورا کر سکتی ہوں۔ فلٹرنگ کی اجازت شامل کریں۔" ہم ہدایت شامل کرتے ہیں، سب کچھ کام کرتا ہے۔ اور اس وقت کچھ خوفناک ہوتا ہے۔

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

اگر ہمیں صرف ID کے ذریعہ صارفین کی ضرورت ہے تو ہم اس کے ساتھ ٹھیک ہوں گے۔ لیکن بعض اوقات ہمیں دوسرے سوالات لکھنے اور انتخاب پر دیگر پابندیاں عائد کرنے کی ضرورت ہوتی ہے۔ لہذا، ہمیں یاد ہے: یہ تمام نقشہ ہے جس میں تقسیم کی کلید ہے، لیکن اس کے اندر ایک ترتیب شدہ نقشہ ہے۔

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

یہ واقعی ایک درخت ہے، وہاں ایک موازنہ کرنے والا صرف کہا جاتا ہے، جس سے ہم کالموں کا ایک مخصوص سیٹ کسی چیز کی شکل میں پاس کرتے ہیں، اور اسے کالموں کی فہرست کے طور پر بھی بیان کیا جاتا ہے۔

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

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

ہم چھانٹیں اور پابندیاں لگاتے ہیں۔

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

ہم نے اپنی میز کو صارفین سے بھر دیا اور دیکھا کہ وہ پہلے پیدائش کے سال کے حساب سے، اور پھر تنخواہ اور صارف کی شناخت کے لحاظ سے ہر نوڈ کے اندر ایک انگوٹھی میں گر گئے۔ اب ہم پابندیاں لگا کر منتخب کر سکتے ہیں۔

ہمارا کام کرنے والا دوبارہ ظاہر ہوتا ہے۔ where, andاور ہمیں صارفین ملتے ہیں، اور سب کچھ پھر سے ٹھیک ہو جاتا ہے۔ لیکن اگر ہم کلسٹرنگ کلید کا صرف ایک حصہ استعمال کرنے کی کوشش کریں گے، اور ایک کم اہم، تو کیسینڈرا فوراً شکایت کرے گی کہ اسے ہمارے نقشے میں وہ جگہ نہیں مل سکتی جہاں یہ آبجیکٹ، جس میں null comparator کے لیے یہ فیلڈز ہیں، اور یہ ایک یہ ابھی سیٹ کیا گیا تھا، - جہاں وہ پڑا ہے۔ مجھے اس نوڈ سے تمام ڈیٹا دوبارہ نکال کر فلٹر کرنا پڑے گا۔ اور یہ ایک نوڈ کے اندر فل اسکین کا اینالاگ ہے، یہ برا ہے۔

کسی بھی غیر واضح صورتحال میں، ایک نیا ٹیبل بنائیں

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

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

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

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

ہم تقسیم کے لیے کلیدوں کا انتخاب کرتے ہیں تاکہ وہ عام طور پر تقسیم ہوں۔ ہم نہیں چاہتے کہ ہماری چابیاں ایک تنگ رینج میں پڑ جائیں۔ یعنی اوپر دی گئی مثال میں پیدائش کا سال ایک بری مثال ہے۔ مزید واضح طور پر، یہ اچھا ہے اگر ہمارے صارفین کو عام طور پر پیدائش کے سال کے حساب سے تقسیم کیا جائے، اور برا ہے اگر ہم 5ویں جماعت کے طلباء کے بارے میں بات کر رہے ہیں - وہاں کی تقسیم بہت اچھی نہیں ہوگی۔

کلسٹرنگ کی تخلیق کے مرحلے پر چھانٹنا ایک بار منتخب کیا جاتا ہے۔ اگر اسے تبدیل کرنے کی ضرورت ہے، تو ہمیں اپنے ٹیبل کو ایک مختلف کلید کے ساتھ اپ ڈیٹ کرنا پڑے گا۔

اور سب سے اہم بات: اگر ہمیں ایک ہی ڈیٹا کو 100 مختلف طریقوں سے بازیافت کرنے کی ضرورت ہے، تو ہمارے پاس 100 مختلف میزیں ہوں گی۔

ماخذ: www.habr.com