هي حبر.
منهنجو نالو Misha Butrimov آهي، مان توهان کي Cassandra بابت ٿورو ٻڌائڻ چاهيان ٿو. منهنجي ڪهاڻي انهن لاءِ ڪارآمد هوندي جن کي ڪڏهن به NoSQL ڊيٽابيسس جو سامنا نه ٿيو آهي - ان ۾ تمام گهڻيون خاصيتون ۽ خاميون آهن جن بابت توهان کي ڄاڻڻ جي ضرورت آهي. ۽ جيڪڏهن توهان Oracle يا ڪنهن ٻئي تعلقي ڊيٽابيس کان سواءِ ٻيو ڪجهه نه ڏٺو آهي، اهي شيون توهان جي زندگي بچائينديون.
Cassandra بابت ڇا سٺو آهي؟ اهو هڪ NoSQL ڊيٽابيس آهي جنهن ۾ ناڪاميءَ جي هڪ نقطي کان سواءِ ٺهيل آهي جيڪا چڱيءَ ريت ماپي ٿي. جيڪڏهن توهان کي ڪجهه ڊيٽابيس لاءِ ٻه ٽيرا بائيٽ شامل ڪرڻ جي ضرورت آهي، توهان صرف انگن ۾ نوڊس شامل ڪريو. ان کي وڌايو ٻئي ڊيٽا سينٽر ڏانهن؟ ڪلستر ۾ نوڊس شامل ڪريو. پروسيس ٿيل آر پي ايس وڌايو؟ ڪلستر ۾ نوڊس شامل ڪريو. اهو پڻ مخالف سمت ۾ ڪم ڪري ٿو.
ٻيو ڇا هوءَ سٺي آهي؟ اهو ڪيترن ئي درخواستن کي سنڀالڻ بابت آهي. پر ڪيترو ڪيترو آهي؟ في سيڪنڊ 10، 20، 30، 40 هزار درخواستون گهڻو نه آهن. رڪارڊنگ لاءِ في سيڪنڊ 100 هزار درخواستون - پڻ. اهي ڪمپنيون آهن جن چيو ته اهي 2 ملين درخواستون في سيڪنڊ رکن ٿيون. انهن کي شايد يقين ڪرڻ گهرجي.
۽ اصول ۾، Cassandra تعلقي ڊيٽا کان هڪ وڏو فرق آهي - اهو انهن سان گڏ ساڳيو ناهي. ۽ اهو ياد رکڻ تمام ضروري آهي.
نه هر شيءِ جيڪا ساڳي نظر اچي ٿي ساڳي ڪم ڪري ٿي
هڪ دفعي هڪ ساٿي مون وٽ آيو ۽ پڇيو: ”هتي هڪ CQL Cassandra سوال جي ٻولي آهي، ۽ ان ۾ هڪ چونڊ بيان آهي، اهو ڪٿي آهي، اهو آهي ۽. مان خط لکندو آهيان ۽ اهو ڪم نٿو ڪري. ڇو؟". Cassandra جو علاج ڪرڻ هڪ تعلقي ڊيٽابيس وانگر تشدد جي خودڪشي ڪرڻ جو بهترين طريقو آهي. ۽ مان ان کي فروغ نه ڏئي رهيو آهيان، اهو روس ۾ ممنوع آهي. توهان صرف ڪجهه غلط ڊزائن ڪنداسين.
مثال طور، هڪ گراهڪ اسان وٽ اچي ٿو ۽ چوي ٿو: ”اچو هڪ ڊيٽابيس ٺاهي ٽي وي سيريز لاءِ، يا هڪ ڊيٽابيس ڊاريڪٽري لاءِ. اسان وٽ اتي کاڌ خوراڪ يا ان ۾ ٽي وي سيريز ۽ اداڪارن جي فهرست هوندي. اسان خوشيءَ سان چوندا آهيون: ”اچو ته هلون! بس ٻه بائيٽ موڪليو، ٻه نشانيون ۽ توهان مڪمل ڪيو، هر شي تمام جلدي ۽ معتبر طريقي سان ڪم ڪندي. ۽ سڀ ڪجهه ٺيڪ آهي جيستائين گراهڪ اچن ۽ چون ته گهريلو عورتون به سامهون واري مسئلي کي حل ڪري رهيون آهن: انهن وٽ پروڊڪٽس جي هڪ فهرست آهي، ۽ اهي ڄاڻڻ چاهين ٿيون ته هو ڪهڙي کاڌ خوراڪ ڪرڻ چاهين ٿا. تون مري ويو آهين.
اهو ئي سبب آهي ته Cassandra هڪ هائبرڊ ڊيٽابيس آهي: اهو گڏوگڏ هڪ اهم قدر مهيا ڪري ٿو ۽ وسيع ڪالمن ۾ ڊيٽا محفوظ ڪري ٿو. جاوا يا ڪوٽلن ۾، اهو هن طرح بيان ڪري سگهجي ٿو:
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
اهو آهي، هڪ نقشو جنهن ۾ پڻ ترتيب ڏنل نقشو شامل آهي. هن نقشي جي پهرين ڪنجي آهي Row Key يا Partition Key - Partitioning Key. ٻي ڪي، جيڪا اڳ ۾ ئي ترتيب ڏنل نقشي جي ڪنجي آهي، ڪلسترنگ ڪيڏي آهي.
ڊيٽابيس جي ورڇ کي واضع ڪرڻ لاءِ، اچو ته ٽي نوڊس ٺاھيون. هاڻي توهان کي سمجهڻ جي ضرورت آهي ته ڊيٽا کي نوڊس ۾ ڪيئن ٺهڪندڙ ڪجي. ڇاڪاڻ ته جيڪڏهن اسان هر شيءِ کي هڪ ۾ وجهي سگهون ٿا (رستي سان، اتي هڪ هزار، ٻه هزار، پنج ٿي سگهي ٿو - جيترو توهان چاهيو ٿا)، اهو حقيقت ۾ ورهائڻ بابت ناهي. تنهن ڪري، اسان کي هڪ رياضياتي فنڪشن جي ضرورت آهي جيڪو هڪ نمبر واپس آڻيندو. صرف هڪ انگ، هڪ ڊگهو انٽ جيڪو ڪجهه حد تائين گر ٿيندو. ۽ اسان لاءِ، ھڪڙو نوڊ ھڪڙي حد لاءِ ذميوار ھوندو، ٻيو - ٻئي لاءِ، nth - nth لاءِ.
هي نمبر هڪ هيش فنڪشن استعمال ڪندي ورتو ويو آهي، جيڪو لاڳو ڪيو ويندو آهي جنهن کي اسين پارٽيشن ڪي سڏيندا آهيون. ھي اھو ڪالم آھي جنھن کي پرائمري ڪيئي ھدايت ۾ بيان ڪيو ويو آھي، ۽ ھي اھو ڪالم آھي جيڪو نقشي جي پھرين ۽ سڀ کان وڌيڪ بنيادي ڪنجي ھوندو. اهو طئي ڪري ٿو ته ڪهڙو نوڊ ڪهڙي ڊيٽا حاصل ڪندو. Cassandra ۾ ھڪڙي ٽيبل ٺاھي وئي آھي لڳ ڀڳ ساڳي نحو سان جيئن SQL ۾:
CREATE TABLE users (
user_id uu id,
name text,
year int,
salary float,
PRIMARY KEY(user_id)
)
هن صورت ۾ پرائمري چيڪ هڪ ڪالمن تي مشتمل آهي، ۽ اهو پڻ ورهاڱي واري ڪيچ آهي.
اسان جا صارف ڪيئن ڪارڪردگي ڪندا؟ ڪي ھڪ نوڊ ڏانھن ويندا، ڪي ٻئي ڏانھن، ۽ ڪي ٽئين ڏانھن. نتيجو هڪ عام هيش ٽيبل آهي، جنهن کي نقشي جي نالي سان پڻ سڃاتو وڃي ٿو، جنهن کي پٿون ۾ ڊڪشنري طور پڻ سڃاتو وڃي ٿو، يا هڪ سادي Key Value structure جنهن مان اسان سڀ قدر پڙهي سگهون ٿا، ڪيئي ذريعي پڙهي ۽ لکي سگهون ٿا.
چونڊيو: جڏهن فلٽرنگ کي مڪمل اسڪين ۾ تبديل ڪرڻ جي اجازت ڏيو، يا ڇا نه ڪيو وڃي
اچو ته ڪجهه چونڊ بيان لکون: select * from users where, userid = . اهو ظاهر ٿئي ٿو جهڙوڪ Oracle ۾: اسان لکندا آهيون چونڊيو، بيان ڪريو شرطون ۽ سڀ ڪجهه ڪم ڪري ٿو، صارفين ان کي حاصل ڪندا آهن. پر جيڪڏھن توھان چونڊيو، مثال طور، ھڪڙو صارف ھڪڙو مخصوص سال جي ڄمڻ سان، Cassandra شڪايت ڪري ٿو ته اھو درخواست کي پورو نٿو ڪري سگھي. ڇاڪاڻ ته هوءَ ڪجهه به نه ڄاڻيندي آهي ته اسان ڄمڻ جي سال بابت ڊيٽا ڪيئن ورهائي سگهون ٿا - هن وٽ صرف هڪ ڪالم آهي جنهن کي ڪيئي طور ظاهر ڪيو ويو آهي. پوءِ هوءَ چوي ٿي، ”ٺيڪ آهي، مان اڃا به اها درخواست پوري ڪري سگهان ٿي. شامل ڪريو فلٽرنگ جي اجازت ڏيو." اسان ھدايت شامل ڪريو، سڀ ڪجھ ڪم ڪري ٿو. ۽ هن وقت ڪجهه خوفناڪ ٿئي ٿو.
جڏهن اسان ٽيسٽ ڊيٽا تي هلون ٿا، سڀ ڪجهه ٺيڪ آهي. ۽ جڏهن توهان پيداوار ۾ هڪ سوال تي عمل ڪيو، جتي اسان وٽ آهي، مثال طور، 4 ملين رڪارڊ، پوء هر شيء اسان لاء تمام سٺو ناهي. ڇو ته فلٽرنگ کي اجازت ڏيو هڪ هدايت آهي جيڪا Cassandra کي اجازت ڏئي ٿي ته هن ٽيبل مان سڀني ڊيٽا کي گڏ ڪري سڀني نوڊس، سڀني ڊيٽا سينٽرن (جيڪڏهن انهن مان ڪيترائي هن ڪلستر ۾ آهن)، ۽ صرف پوء ان کي فلٽر ڪريو. هي مڪمل اسڪين جو هڪ اينالاگ آهي، ۽ شايد ئي ڪو به ان سان خوش ٿئي.
جيڪڏهن اسان کي صرف ID ذريعي صارفين جي ضرورت آهي، اسان ان سان ٺيڪ ٿينداسين. پر ڪڏهن ڪڏهن اسان کي ٻين سوالن کي لکڻ ۽ چونڊ تي ٻيون پابنديون لاڳو ڪرڻ جي ضرورت آهي. تنهن ڪري، اسان کي ياد آهي: هي سڀ هڪ نقشو آهي جنهن ۾ هڪ ورهاڱي جي ڪنجي آهي، پر ان جي اندر هڪ ترتيب ڏنل نقشو آهي.
۽ هن وٽ هڪ ڪنجي به آهي، جنهن کي اسين ڪلسترنگ ڪي چئون ٿا. هي ڪنجي، جنهن ۾، موڙ ۾، اسان جي چونڊيل ڪالمن تي مشتمل آهي، جنهن جي مدد سان Cassandra سمجهي ٿو ته ڪيئن ان جي ڊيٽا جسماني طور تي ترتيب ڏنل آهي ۽ هر نوڊ تي واقع ٿيندي. يعني ڪجهه Partition Key لاءِ، Clustering Key توهان کي ٻڌائي ٿي ته ڊيٽا کي هن وڻ ۾ ڪيئن ڌڪيو وڃي، ان کي ڪهڙي جاءِ وٺي ويندي.
ھي واقعي ھڪڙو وڻ آھي، ھڪڙو موازنہ صرف اتي سڏيو ويندو آھي، جنھن ڏانھن اسان ھڪڙي مخصوص ڪالمن جي ھڪڙي سيٽ کي ھڪڙي اعتراض جي صورت ۾ منتقل ڪندا آھيون، ۽ اھو پڻ ڪالمن جي ھڪڙي فهرست جي طور تي بيان ڪيو ويندو آھي.
CREATE TABLE users_by_year_salary_id (
user_id uuid,
name text,
year int,
salary float,
PRIMARY KEY((year), salary, user_id)
پرائمري ڪيچ جي هدايت تي ڌيان ڏيو؛ ان جو پهريون دليل (اسان جي صورت ۾، سال) هميشه آهي ورهاڱي جي ڪنجي. اهو هڪ يا وڌيڪ ڪالمن تي مشتمل ٿي سگهي ٿو، اهو مسئلو ناهي. جيڪڏهن اتي ڪيترائي ڪالم آهن، ان کي ٻيهر بریکٹ ۾ هٽائڻ جي ضرورت آهي ته جيئن ٻولي پري پروسيسر سمجهي ته هي پرائمري ڪيئي آهي، ۽ ان جي پويان باقي سڀئي ڪالمن ڪلسترنگ ڪيئي آهن. انهي صورت ۾، انهن کي ترتيب ڏيڻ واري ترتيب ۾ منتقل ڪيو ويندو جنهن ۾ اهي ظاهر ٿيندا آهن. اھو آھي، پھريون ڪالم وڌيڪ اھم آھي، ٻيو گھٽ اھم آھي، وغيره. اسان ڪيئن لکندا آهيون، مثال طور، ڊيٽا ڪلاس لاءِ فيلڊس برابر آهن: اسان فيلڊ کي لسٽ ڪريون ٿا، ۽ انهن لاءِ اسين لکون ٿا ته ڪهڙا وڏا آهن ۽ ڪهڙا ننڍا آهن. Cassandra ۾، اهي آهن، نسبتا ڳالهائڻ، ڊيٽا ڪلاس جا شعبا، جن تي ان لاءِ لکيل برابري لاڳو ڪئي ويندي.
اسان ترتيب ڏيو ۽ پابنديون لاڳو ڪيون
توهان کي ياد رکڻ جي ضرورت آهي ته ترتيب ترتيب (نزول، چڙهڻ، جيڪو به) ساڳئي وقت مقرر ڪيو ويو آهي جڏهن ڪيچ ٺاهي وئي آهي، ۽ ان کي بعد ۾ تبديل نٿو ڪري سگهجي. اهو جسماني طور تي طئي ڪري ٿو ته ڊيٽا ڪيئن ترتيب ڏني ويندي ۽ اهو ڪيئن محفوظ ڪيو ويندو. جيڪڏھن توھان کي تبديل ڪرڻ جي ضرورت آھي ڪلسترنگ ڪيچ يا ترتيب ترتيب ڏيو، توھان کي ھڪڙو نئون جدول ٺاھيو ۽ ان ۾ ڊيٽا کي منتقل ڪرڻو پوندو. اهو هڪ موجود سان ڪم نه ڪندو.
اسان پنهنجي ٽيبل کي صارفين سان ڀريو ۽ ڏٺو ته اهي هڪ انگ ۾ ٿي ويا، پهرين ڄمڻ جي سال طرفان، ۽ پوء هر نوڊ تي تنخواه ۽ صارف جي ID جي اندر. هاڻي اسان پابنديون لاڳو ڪندي چونڊ ڪري سگهون ٿا.
اسان جو ڪم ڪندڙ هڪ ٻيهر ظاهر ٿئي ٿو where, and، ۽ اسان صارفين کي حاصل ڪندا آهيون، ۽ هر شيء ٻيهر ٺيڪ آهي. پر جيڪڏهن اسان ڪوشش ڪريون ته ڪلسٽرنگ ڪيئي جو فقط هڪ حصو، ۽ هڪ گهٽ اهم، ته پوءِ ڪئسينڊرا فوري طور تي شڪايت ڪندو ته اها اسان جي نقشي ۾ اها جاءِ نه ڳولي سگهي ٿي، جتي هي اعتراض، جنهن ۾ اهي شعبا آهن، نال موازنہ ڪندڙ لاءِ، ۽ هي هڪ. اهو صرف مقرر ڪيو ويو هو، - جتي هو بيٺو آهي. مون کي هن نوڊ مان سڀ ڊيٽا ٻيهر ڪڍڻو پوندو ۽ ان کي فلٽر ڪرڻو پوندو. ۽ اھو ھڪڙو اينالاگ آھي مڪمل اسڪين ھڪڙي نوڊ اندر، اھو خراب آھي.
ڪنهن به غير واضح صورتحال ۾، هڪ نئين ٽيبل ٺاهيو
جيڪڏهن اسان چاهيون ٿا ته صارفين کي ID، يا عمر، يا تنخواه طرفان، اسان کي ڇا ڪرڻ گهرجي؟ ڪجھ به نه. صرف ٻه ٽيبل استعمال ڪريو. جيڪڏهن توهان کي ٽن مختلف طريقن سان صارفين تائين پهچڻ جي ضرورت آهي، اتي ٽي ٽيبل هوندا. اهي ڏينهن گذري ويا جڏهن اسان اسڪرو تي خلا بچايو. هي سڀ کان سستو ذريعو آهي. اهو جواب وقت جي ڀيٽ ۾ تمام گهٽ خرچ ڪري ٿو، جيڪو صارف لاءِ نقصانڪار ٿي سگهي ٿو. اهو صارف لاءِ 10 منٽن جي ڀيٽ ۾ هڪ سيڪنڊ ۾ ڪجهه حاصل ڪرڻ لاءِ وڌيڪ خوشگوار آهي.
اسان سٺي نموني ۽ قابل اعتماد طريقي سان هلائڻ جي صلاحيت لاءِ غير ضروري جاءِ ۽ غير معمولي ڊيٽا جو واپار ڪندا آهيون. سڀ کان پوء، حقيقت ۾، هڪ ڪلستر جيڪو ٽن ڊيٽا سينٽرن تي مشتمل آهي، جن مان هر هڪ پنج نوڊس آهن، ڊيٽا جي تحفظ جي قابل قبول سطح سان (جڏهن ڪجھ به نه وڃائجي)، مڪمل طور تي هڪ ڊيٽا سينٽر جي موت کان بچڻ جي قابل آهي. ۽ باقي ٻن مان هر هڪ ۾ ٻه وڌيڪ نوڊس. ۽ صرف هن کان پوء مسئلا شروع ٿي. هي هڪ تمام سٺو بيڪار آهي، اهو ڪجهه اضافي ايس ايس ڊي ڊرائيو ۽ پروسيسرز جي قيمت آهي. تنهن ڪري، Cassandra استعمال ڪرڻ لاء، جيڪو ڪڏهن به SQL ناهي، جنهن ۾ ڪو به تعلق نه آهي، غير ملڪي چابيون، توهان کي ڄاڻڻ جي ضرورت آهي سادي ضابطن.
اسان توهان جي درخواست مطابق سڀڪنھن شيء کي ڊزائين. بنيادي شيء ڊيٽا نه آهي، پر ايپليڪيشن ان سان ڪيئن ڪم ڪرڻ وارو آهي. جيڪڏهن ان کي مختلف طريقن سان مختلف ڊيٽا حاصل ڪرڻ جي ضرورت آهي يا ساڳئي ڊيٽا مختلف طريقن سان، اسان کي ان کي اهڙي طريقي سان رکڻ گهرجي جيڪا ايپليڪيشن لاءِ آسان هجي. ٻي صورت ۾، اسان مڪمل اسڪين ۾ ناڪام ٿينداسين ۽ ڪئاسندرا اسان کي ڪو به فائدو نه ڏيندو.
ڊيٽا کي غير معمولي ڪرڻ جو معمول آهي. اسان عام فارمن جي باري ۾ وساريندا آهيون، اسان وٽ هاڻي لاڳاپو ڊيٽابيس نه آهي. جيڪڏهن اسان ڪنهن شيءِ کي 100 ڀيرا هيٺ رکون ٿا ته اها 100 ڀيرا هيٺ ڪري ٿي. اهو اڃا به سستو آهي روڪڻ کان.
اسان ورهاڱي لاءِ ڪنجيون چونڊون ٿا ته جيئن اهي عام طرح ورهائجن. اسان نٿا چاهيون ته اسان جي چابين جو هيش هڪ تنگ رينج ۾ اچي. يعني مٿي ڏنل مثال ۾ جنم جو سال خراب مثال آهي. وڌيڪ واضح طور تي، اهو سٺو آهي ته اسان جي استعمال ڪندڙن کي عام طور تي سال جي ڄمڻ سان ورهايو وڃي، ۽ خراب آهي جيڪڏهن اسان 5 هين گريڊ جي شاگردن بابت ڳالهائي رهيا آهيون - اتي ورهاڱي تمام سٺو نه ٿيندو.
Clustering Key جي ٺاھڻ واري مرحلي ۾ ھڪ ڀيرو ترتيب ڏيڻ کي چونڊيو ويو آھي. جيڪڏهن ان کي تبديل ڪرڻ جي ضرورت آهي، اسان کي اسان جي ٽيبل کي مختلف چيڪ سان تازه ڪاري ڪرڻو پوندو.
۽ سڀ کان اهم شيءِ: جيڪڏهن اسان کي ساڳي ڊيٽا کي 100 مختلف طريقن سان ٻيهر حاصل ڪرڻ جي ضرورت آهي، ته پوءِ اسان وٽ 100 مختلف ٽيبل هوندا.
جو ذريعو: www.habr.com