اهي چون ٿا ته زندگي ۾ هر شيء گهٽ ۾ گهٽ هڪ ڀيرو ڪوشش ڪرڻ جي قابل آهي. ۽ جيڪڏهن توهان لاڳاپا DBMSs سان ڪم ڪرڻ لاء استعمال ڪيو ٿا، پوء اهو عمل ۾ NoSQL سان واقف ٿيڻ جي قابل آهي، سڀ کان پهريان، گهٽ ۾ گهٽ عام ترقي لاء. هاڻي، هن ٽيڪنالاجي جي تيز رفتار ترقي جي ڪري، هن موضوع تي ڪيترائي متضاد رايا ۽ گرم بحث مباحثا آهن، جيڪي خاص طور تي دلچسپي وڌائين ٿا.
جيڪڏهن توهان انهن سڀني تڪرارن جي بنياد تي غور ڪيو، توهان ڏسي سگهو ٿا ته اهي غلط طريقي جي سبب پيدا ٿين ٿا. اهي جيڪي NoSQL ڊيٽابيس استعمال ڪن ٿا بلڪل جتي انهن جي ضرورت آهي مطمئن آهن ۽ هن حل مان سڀ فائدا حاصل ڪن ٿا. ۽ تجربا ڪندڙ جيڪي هن ٽيڪنالاجي تي ڀروسو ڪن ٿا هڪ علاج جي طور تي جتي اهو هرگز لاڳو ناهي، مايوس ٿي ويا آهن، خاص فائدي حاصل ڪرڻ کان سواءِ تعلقي ڊيٽابيس جي طاقت کي وڃائي ڇڏيو.
مان توهان کي ٻڌايان ٿو ته اسان جي تجربي جي باري ۾ هڪ حل لاڳو ڪرڻ جي باري ۾ Cassandra DBMS جي بنياد تي: اسان کي ڇا منهن ڏيڻو پيو، اسان ڪيئن مشڪل حالتن مان نڪتاسين، ڇا اسان NoSQL استعمال ڪرڻ مان فائدو حاصل ڪرڻ جي قابل هئاسين ۽ جتي اسان کي اضافي ڪوششون/فنڊ سيڙپ ڪرڻا هئا. .
شروعاتي ڪم اهو آهي ته هڪ سسٽم ٺاهي جيڪو ڪنهن قسم جي اسٽوريج ۾ ڪال رڪارڊ ڪري.
هن نظام جي آپريٽنگ اصول هيٺ ڏنل آهي. ان پٽ ۾ فائلون شامل آھن ھڪڙي مخصوص ڍانچي سان جيڪي ڪال جي ڍانچي کي بيان ڪري ٿي. ايپليڪيشن وري يقيني بڻائي ٿي ته هي جوڙجڪ مناسب ڪالمن ۾ ذخيرو ٿيل آهي. مستقبل ۾، محفوظ ڪيل ڪالون استعمال ڪيون وينديون ٽريفڪ جي استعمال تي معلومات ڏيکاريندڙن لاءِ (چارج، ڪال، بيلنس جي تاريخ).
اهو بلڪل واضح آهي ته انهن ڇو ڪيو Cassandra - هوء هڪ مشين گن وانگر لکي ٿي، آساني سان اسپيبلبل، ۽ غلطي برداشت ڪندڙ آهي.
تنهن ڪري، اهو آهي جيڪو تجربو اسان کي ڏنو
ها، هڪ ناڪام نوڊ هڪ سانحو ناهي. هي آهي Cassandra جي غلطي رواداري جو جوهر. پر هڪ نوڊ زنده ٿي سگهي ٿو ۽ ساڳئي وقت ڪارڪردگي ۾ متاثر ٿيڻ شروع ٿئي ٿو. جيئن اهو نڪتو، اهو فوري طور تي سڄي ڪلستر جي ڪارڪردگي کي متاثر ڪري ٿو.
Cassandra توهان جي حفاظت نه ڪندو جتي Oracle توهان کي پنهنجي رڪاوٽن سان بچايو. ۽ جيڪڏهن درخواست جي ليکڪ هن کي اڳ ۾ ئي نه سمجهي، پوء ٻيڻو جيڪو ڪئاسندرا لاء آيو آهي اصل کان وڌيڪ خراب ناهي. هڪ دفعو اها پهچندي، اسان ان کي داخل ڪنداسين.
IB سخت ناپسند ڪيو مفت Cassandra دٻي کان ٻاهر: صارف جي عملن جي ڪا به لاگنگ ناهي، حقن جو ڪو فرق ناهي. ڪالن بابت معلومات کي ذاتي ڊيٽا سمجهيو ويندو آهي، جنهن جو مطلب آهي ته ان کي ڪنهن به طريقي سان درخواست/تبديل ڪرڻ جي سڀني ڪوششن کي ايندڙ آڊيٽنگ جي امڪان سان لاگ ان ٿيڻ گهرجي. انهي سان گڏ، توهان کي مختلف استعمال ڪندڙن لاء مختلف سطحن تي الڳ حقن جي ضرورت کان آگاهي ٿيڻ جي ضرورت آهي. هڪ سادو آپريشن انجنيئر ۽ هڪ سپر منتظم جيڪو آزاديءَ سان پوري ڪي اسپيس کي حذف ڪري سگهي ٿو مختلف ڪردار، مختلف ذميواريون ۽ صلاحيتون آهن. رسائي جي حقن جي اهڙي تفاوت کان سواء، ڊيٽا جي قيمت ۽ سالميت فوري طور تي سوال ۾ اچي ويندي، ڪنهن به استحڪام جي سطح جي ڀيٽ ۾.
اسان اهو خيال نه رکيو ته ڪالن کي مختلف حالتن لاءِ سنجيده تجزياتي ۽ وقتي نموني جي ضرورت آهي. جيئن ته چونڊيل رڪارڊن کي پوءِ ختم ڪيو وڃي ۽ ٻيهر لکيو وڃي (ڪم جي حصي جي طور تي، اسان کي لازمي طور تي ڊيٽا کي اپڊيٽ ڪرڻ جي عمل کي سپورٽ ڪرڻ گهرجي جڏهن ڊيٽا شروعاتي طور تي اسان جي لوپ ۾ غلط داخل ٿي وئي هئي)، ڪئاسندرا هتي اسان جو دوست ناهي. Cassandra هڪ ٻير جي ڪناري وانگر آهي - اهو آسان آهي ته شين ۾ رکڻ لاء، پر توهان ان ۾ شمار نٿا ڪري سگهو.
اسان کي آزمائشي زونن ۾ ڊيٽا منتقل ڪرڻ ۾ مسئلو پيش آيو (ٽيسٽ ۾ 5 نوڊس بمقابله 20 پروم ۾). هن معاملي ۾، ڊمپ استعمال نه ٿو ڪري سگهجي.
ڪيسندرا ڏانهن لکڻ واري ايپليڪيشن جي ڊيٽا اسڪيما کي اپڊيٽ ڪرڻ سان مسئلو. هڪ رولبڪ هڪ عظيم قبرون پٿر پيدا ڪندو، جيڪو غير متوقع طريقن سان پيداوار جي نقصان جي ڪري سگھي ٿو.. Cassandra رڪارڊنگ لاءِ بهتر آهي، ۽ لکڻ کان اڳ گهڻو نه سوچيندي آهي، ان ۾ موجود ڊيٽا سان ڪو به آپريشن به رڪارڊنگ آهي. اهو آهي، غير ضروري کي حذف ڪرڻ سان، اسان صرف اڃا به وڌيڪ رڪارڊ پيدا ڪنداسين، ۽ انهن مان صرف ڪجهه قبرن سان نشان لڳل هوندا.
وقت ختم ٿيڻ وقت داخل ٿيڻ. Cassandra رڪارڊنگ ۾ خوبصورت آهي، پر ڪڏهن ڪڏهن ايندڙ وهڪري هن کي خاص طور تي حيران ڪري سگهي ٿي. اهو تڏهن ٿئي ٿو جڏهن ايپليڪيشن ڪيترن ئي رڪارڊن جي چوڌاري چڪر ڪرڻ شروع ڪري ٿي جيڪا ڪنهن سبب جي ڪري داخل نه ٿي ڪري سگهجي. ۽ اسان کي هڪ حقيقي DBA جي ضرورت پوندي جيڪو سست سوالن لاءِ gc.log، سسٽم ۽ ڊيبگ لاگز جي نگراني ڪندو، ڪمپيڪشن جي انتظار ۾ ميٽرڪس.
هڪ ڪلستر ۾ ڪيترائي ڊيٽا مرڪز. ڪٿي پڙهڻ ۽ ڪٿي لکڻ؟
شايد پڙهڻ ۽ لکڻ ۾ ورهايل آهي؟ ۽ جيڪڏهن ائين آهي ته، لکڻ يا پڙهڻ لاء درخواست جي ويجهو ڊي سي هجڻ گهرجي؟ ۽ ڇا اسان هڪ حقيقي تقسيم دماغ سان ختم نه ڪنداسين جيڪڏهن اسان غلط مستقل مزاجي جي سطح کي چونڊيو؟ اتي ڪيترائي سوال آھن، گھڻا اڻڄاتل سيٽنگون، امڪان جيڪي توھان واقعي سان ٽڪرائڻ چاھيو ٿا.
اسان ڪيئن فيصلو ڪيو
نوڊ کي ٻوڙڻ کان روڪڻ لاءِ، SWAP کي بند ڪيو ويو. ۽ هاڻي، جيڪڏهن ميموري جي کوٽ آهي، نوڊ کي هيٺ وڃڻ گهرجي ۽ وڏي gc pauses پيدا نه ڪرڻ گهرجي.
تنهن ڪري، اسان هاڻي ڊيٽابيس ۾ منطق تي ڀروسو نه ڪندا آهيون. ايپليڪيشن ڊولپرز پاڻ کي ٻيهر تربيت ڏئي رهيا آهن ۽ فعال طور تي انهن جي پنهنجي ڪوڊ ۾ احتياط ڪرڻ شروع ڪري رهيا آهن. ڊيٽا اسٽوريج ۽ پروسيسنگ جي مثالي واضح علحدگي.
اسان DataStax کان سپورٽ خريد ڪيو. باڪس ٿيل Cassandra جي ترقي اڳ ۾ ئي بند ٿي چڪي آهي (آخري انجام فيبروري 2018 ۾ هو). ساڳئي وقت، Datastax پيش ڪري ٿو شاندار خدمت ۽ موجوده IP حلن لاءِ وڏي تعداد ۾ تبديل ٿيل ۽ ترتيب ڏنل حل.
مان اهو پڻ نوٽ ڪرڻ چاهيان ٿو ته Cassandra چونڊ سوالن لاءِ تمام آسان ناهي. يقينا، CQL صارفين لاء هڪ وڏو قدم آهي (Trift جي مقابلي ۾). پر جيڪڏهن توهان وٽ سمورا ادارا آهن جيڪي اهڙين آسان شموليت جا عادي آهن، ڪنهن به فيلڊ ذريعي مفت فلٽرنگ ۽ سوالن جي اصلاح جي صلاحيتون، ۽ اهي ادارا شڪايتون ۽ حادثا حل ڪرڻ لاءِ ڪم ڪري رهيا آهن، ته پوءِ ڪئسينڊرا جو حل انهن لاءِ دشمني ۽ بيوقوف لڳي ٿو. ۽ اسان اهو فيصلو ڪرڻ شروع ڪيو ته اسان جي ساٿين کي ڪيئن نموني ٺاهڻ گهرجي.
اسان ٻن آپشنن تي غور ڪيو، پھرئين آپشن ۾، اسان ڪالون نه رڳو C* ۾ لکون ٿا، پر آرڪائيو ٿيل Oracle ڊيٽابيس ۾ پڻ. صرف، C* جي برعڪس، هي ڊيٽابيس صرف موجوده مهيني لاءِ ڪالن کي اسٽور ڪري ٿو (ڪيس ريچارج ڪرڻ لاءِ ڪافي ڪال اسٽوريج جي کوٽائي). هتي اسان فوري طور تي هيٺيون مسئلو ڏٺو: جيڪڏهن اسان هم وقت سازي سان لکندا آهيون، ته پوءِ اسان فاسٽ انسرشن سان لاڳاپيل C* جا سڀئي فائدا وڃائي ويهندا آهيون؛ جيڪڏهن اسان هڪجهڙائي سان لکندا آهيون، ته ڪا به گارنٽي ناهي ته سڀئي ضروري ڪالون Oracle ۾ اچي ويون. اتي ھڪڙو پلس ھو، پر ھڪڙو وڏو: آپريشن لاءِ ھڪڙو ئي واقف PL/SQL ڊولپر رھندو آھي، يعني اسين عملي طور تي ”Facade“ جي نموني کي لاڳو ڪندا آھيون. ھڪڙو متبادل اختيار. اسان هڪ ميکانيزم تي عمل ڪريون ٿا جيڪو C* مان ڪالز کي لوڊ ڪري ٿو، ڪجهه ڊيٽا کي بهتر ڪرڻ لاءِ Oracle ۾ لاڳاپيل جدولن مان ڪڍي ٿو، نتيجن جي نمونن کي شامل ڪري ٿو ۽ اسان کي نتيجو ڏئي ٿو، جيڪو اسان پوءِ ڪنهن نه ڪنهن طريقي سان استعمال ڪريون ٿا (رول واپس، ورجائي، تجزيو، تعريف). ڪنس: اهو عمل ڪافي گھڻن قدمن وارو آهي، ۽ ان کان علاوه، آپريشن جي ملازمن لاء ڪو به انٽرفيس ناهي.
آخر ۾، اسان ٻئي اختيار تي آباد ٿيا. Apache Spark مختلف جار مان نموني لاء استعمال ڪيو ويو. ميڪانيزم جو جوهر گهٽجي ويو آهي جاوا ڪوڊ، جيڪو استعمال ڪندي مخصوص ڪنجيون (سبسڪرائبر، ڪال جو وقت - سيڪشن ڪيز)، C* مان ڊيٽا ڪڍندو آهي، انهي سان گڏ ڪنهن ٻئي ڊيٽابيس مان بهتري لاءِ ضروري ڊيٽا. جنهن کان پوءِ اهو انهن کي پنهنجي ياداشت ۾ شامل ڪري ٿو ۽ نتيجو ٽيبل ۾ ڏيکاري ٿو. اسان چمڪ مٿان هڪ ويب چهرو ٺاهيو ۽ اهو ڪافي استعمال لائق نڪتو.
جڏهن صنعتي ٽيسٽ ڊيٽا کي اپڊيٽ ڪرڻ جو مسئلو حل ڪيو، اسان ٻيهر غور ڪيو ڪيترن ئي حل. ٻئي منتقلي Sstloader ذريعي ۽ امتحان واري علائقي ۾ ڪلستر کي ٻن حصن ۾ ورهائڻ جو اختيار، جن مان هر هڪ متبادل طور تي ساڳئي ڪلستر سان تعلق رکي ٿو پروموشنل هڪ سان، اهڙيء طرح ان جي طرفان طاقتور ٿي رهيو آهي. ٽيسٽ کي اپڊيٽ ڪرڻ وقت، ان کي تبديل ڪرڻ جي رٿابندي ڪئي وئي هئي: امتحان ۾ ڪم ڪندڙ حصو صاف ۽ پيداوار ۾ داخل ٿيو، ۽ ٻيو الڳ الڳ ڊيٽا سان ڪم ڪرڻ شروع ٿئي ٿو. تنهن هوندي، ٻيهر سوچڻ کان پوء، اسان وڌيڪ معقول طور تي ڊيٽا جو جائزو ورتو جيڪو منتقلي جي قابل هو، ۽ محسوس ڪيو ته ڪالون پاڻ کي ٽيسٽ لاء هڪ متضاد ادارو آهي، جلدي ٺاهي وئي جيڪڏهن ضروري هجي، ۽ اهو پروموشنل ڊيٽا سيٽ آهي جنهن جي منتقلي لاء ڪا قيمت ناهي. ٽيسٽ. اتي ڪيترائي ذخيرا شيون آھن جيڪي ھلڻ جي قابل آھن، پر اھي لفظي طور تي ھڪڙي ٽيبل آھن، ۽ تمام ڳري نه آھن. تنهن ڪري اسان هڪ حل جي طور تي، اسپارڪ ٻيهر بچاء ۾ آيو، جنهن جي مدد سان اسان لکيو ۽ فعال طور تي ٽيبل جي وچ ۾ ڊيٽا جي منتقلي لاء هڪ اسڪرپٽ استعمال ڪرڻ شروع ڪيو، پروم-ٽيسٽ.
اسان جي موجوده مقرري واري پاليسي اسان کي اجازت ڏئي ٿي ته ڪم ڪرڻ جي بغير رول بيڪ. پرومو کان اڳ، اتي هڪ لازمي ٽيسٽ رن آهي، جتي هڪ غلطي ايتري قيمتي ناهي. ناڪامي جي صورت ۾، توهان هميشه ڪري سگهو ٿا ڪيس اسپيس کي ڇڏي ڏيو ۽ شروع کان پوري اسڪيم کي رول ڪريو.
Cassandra جي مسلسل دستيابي کي يقيني بڻائڻ لاء، توهان کي هڪ ڊي بي جي ضرورت آهي ۽ نه رڳو هن کي. هرڪو جيڪو ايپليڪيشن سان ڪم ڪري ٿو اهو سمجهڻ گهرجي ته موجوده صورتحال کي ڪٿي ۽ ڪيئن ڏسڻ گهرجي ۽ بروقت طريقي سان مسئلن جي تشخيص ڪيئن ڪجي. هن کي ڪرڻ لاءِ، اسان فعال طور تي استعمال ڪريون ٿا DataStax OpsCenter (انتظاميه ۽ ڪم لوڊ جي نگراني)، Cassandra ڊرائيور سسٽم ميٽرڪس (سي* کي لکڻ لاءِ ٽائم آئوٽ جو تعداد، سي* کان پڙهڻ لاءِ ٽائم آئوٽ جو تعداد، وڌ ۾ وڌ دير، وغيره)، آپريشن جي نگراني پاڻ ايپليڪيشن جو، Cassandra سان ڪم ڪري رهيو آهي.
جڏهن اسان پوئين سوال جي باري ۾ سوچيو، اسان محسوس ڪيو ته اسان جو بنيادي خطرو ڪٿي آهي. اهي ڊيٽا ڊسپلي فارم آهن جيڪي ڊيٽا کي ظاهر ڪن ٿا ڪيترن ئي آزاد سوالن کان اسٽوريج تائين. هن طريقي سان اسان ڪافي غير متضاد معلومات حاصل ڪري سگهون ٿا. پر اهو مسئلو صرف ايترو ئي لاڳاپيل هوندو جيڪڏهن اسان صرف هڪ ڊيٽا سينٽر سان ڪم ڪيو. تنهن ڪري هتي سڀ کان وڌيڪ معقول شيء آهي، يقينا، ٽئين پارٽي جي ايپليڪيشن تي ڊيٽا پڙهڻ لاء هڪ بيچ فنڪشن ٺاهي، جيڪا يقيني بڻائي سگهندي ته ڊيٽا هڪ وقت ۾ ملي ٿي. جيئن ته ڪارڪردگي جي لحاظ کان پڙهڻ ۽ لکڻ ۾ ورهائڻ لاء، هتي اسان کي خطري کان روڪيو ويو آهي ته ڊي سي جي وچ ۾ ڪنيڪشن جي ڪجهه نقصان سان، اسان ٻن ڪلسترن سان ختم ڪري سگهون ٿا جيڪي هڪ ٻئي سان مڪمل طور تي متضاد آهن.
نتيجي طور، في الحال EACH_QUORUM لکڻ لاءِ مستقل مزاجي جي سطح تي، پڙهڻ لاءِ - LOCAL_QUORUM
مختصر تاثرات ۽ نتيجا
آپريشنل سپورٽ ۽ وڌيڪ ترقي جي امڪانن جي نقطي نظر کان نتيجو حل جو جائزو وٺڻ لاء، اسان اهو سوچڻ جو فيصلو ڪيو ته اهڙي ترقي ڪٿي لاڳو ٿي سگهي ٿي.
ساڄي پاسي کان، پوءِ پروگرامن لاءِ ڊيٽا اسڪورنگ جيئن ”ادا ڪريو جڏهن اهو آسان هجي“ (اسان معلومات کي C* ۾ لوڊ ڪريون ٿا، اسپارڪ اسڪرپٽ استعمال ڪندي حساب ڪتاب)، دعوائن جي حساب سان ايريا جي لحاظ سان گڏ ڪرڻ، ڪردارن کي محفوظ ڪرڻ ۽ صارف جي رسائي جي حقن جي حساب سان حساب ڪرڻ. ميٽرڪس
جئين توهان ڏسي سگهو ٿا، ذخيرو وسيع ۽ مختلف آهي. ۽ جيڪڏھن اسان NoSQL جي حامي/مخالف جي ڪيمپ کي چونڊينداسون، ته پوءِ اسان حمايت ڪندڙن ۾ شامل ٿي وينداسين، ڇو ته اسان کي اسان جا فائدا مليا، ۽ بلڪل اُتي جتي اسان توقع ڪئي ھئي.
جيتوڻيڪ دٻي کان ٻاهر Cassandra آپشن حقيقي وقت ۾ افقي اسڪيلنگ جي اجازت ڏئي ٿو، بلڪل بي دردي سان سسٽم ۾ ڊيٽا وڌائڻ جي مسئلي کي حل ڪرڻ. اسان ڪال ايگريگيٽس کي الڳ سرڪٽ ۾ ڳڻڻ لاءِ هڪ تمام تيز لوڊ ميڪانيزم کي منتقل ڪرڻ جي قابل هئاسين، ۽ ايپليڪيشن اسڪيما ۽ منطق کي به الڳ ڪري، ڊيٽابيس ۾ ئي ڪسٽم نوڪريون ۽ شيون لکڻ جي خراب مشق کان نجات حاصل ڪري رهيا هئاسين. اسان کي چونڊڻ ۽ ترتيب ڏيڻ جو موقعو مليو، رفتار وڌائڻ لاءِ، اسان ڪهڙن ڊي سيز تي حساب ڪتاب ڪنداسين ۽ ڪهڙن تي ڊيٽا رڪارڊ ڪنداسين، اسان پاڻ کي انفرادي نوڊس ۽ مجموعي طور تي ڊي سي ٻنهي جي حادثن جي خلاف بيمه ڪيو.
اسان جي فن تعمير کي نون منصوبن تي لاڳو ڪرڻ، ۽ اڳ ۾ ئي ڪجهه تجربو آهي، آئون فوري طور تي مٿي بيان ڪيل nuances کي اڪائونٽ ۾ رکڻ چاهيان ٿو، ۽ ڪجهه غلطين کي روڪڻ، ڪجهه تيز ڪنڊن کي صاف ڪرڻ، جيڪي شروعات ۾ نه ٿي سگهيا.
مثال طور، بروقت طريقي سان Cassandra جي تازه ڪارين جي ٽريڪ رکوڇاڪاڻ ته ڪجھ مسئلا جيڪي اسان کي مليا آهن اهي اڳ ۾ ئي سڃاتل ۽ طئي ٿيل هئا.
پاڻ کي ڊيٽابيس ۽ اسپارڪ کي ساڳي نوڊس تي نه رکو (يا قابل اجازت وسيلن جي استعمال جي مقدار کي سختي سان ورهايو)، ڇاڪاڻ ته اسپارڪ توقع کان وڌيڪ OP کائي سگهي ٿو، ۽ اسان جلدي حاصل ڪنداسين مسئلو نمبر 1 اسان جي لسٽ مان.
پروجيڪٽ جي جاچ واري مرحلي تي نگراني ۽ آپريشنل صلاحيت کي بهتر بڻايو. شروعات ۾، اسان جي حل جي سڀني امڪاني صارفين کي جيترو ٿي سگهي حساب ۾ وٺو, ڇاڪاڻ ته اهو آهي جيڪو ڊيٽابيس جي جوڙجڪ آخرڪار انحصار ڪندو.
ممڪن اصلاح لاءِ نتيجو سرڪٽ کي ڪيترائي ڀيرا گھمايو. منتخب ڪريو ڪھڙا فيلڊ سيريل ڪري سگھجن ٿا. سمجھو ته اسان کي ڪھڙي اضافي جدولن کي ٺاھڻ گھرجي ته جيئن سڀ کان وڌيڪ صحيح ۽ بھترين حساب ۾ ورتو وڃي، ۽ پوءِ درخواست تي گھربل معلومات مهيا ڪريو (مثال طور، اھو فرض ڪري ته اسين ھڪ ئي ڊيٽا کي مختلف جدولن ۾ محفوظ ڪري سگھون ٿا، حساب ۾ مختلف ٽوٽل اپائن کي نظر ۾ رکندي. مختلف معيار، اسان پڙهي سگھون ٿا سي پي يو وقت پڙهڻ جي درخواستن لاءِ).
خراب ناهي فوري طور تي TTL ڳنڍڻ ۽ پراڻي ڊيٽا کي صاف ڪرڻ لاء مهيا ڪريو.
جڏهن Cassandra کان ڊيٽا ڊائون لوڊ ايپليڪيشن منطق کي FETCH اصول تي ڪم ڪرڻ گهرجي، انهي ڪري ته سڀئي قطارون هڪ ڀيرو ميموري ۾ لوڊ نه ٿين، پر بيچ ۾ چونڊيل آهن.
اهو تجويز ڪيل حل تي منصوبي کي منتقل ڪرڻ کان اڳ مشورو ڏنو ويو آهي سسٽم جي غلطي رواداري کي چيڪ ڪريو حادثو ٽيسٽ جو سلسلو جاري ڪندي، جهڙوڪ هڪ ڊيٽا سينٽر ۾ ڊيٽا جو نقصان، هڪ خاص عرصي دوران خراب ٿيل ڊيٽا جي بحالي، ڊيٽا سينٽرن جي وچ ۾ نيٽ ورڪ ختم ٿيڻ. اهڙا تجربا نه رڳو پيش ڪيل فن تعمير جي فائدن ۽ نقصانن جو جائزو وٺڻ جي اجازت ڏين ٿا، پر انهن کي هلائڻ وارا انجنيئرن لاء سٺو گرم اپ مشق پڻ فراهم ڪن ٿا، ۽ حاصل ڪيل مهارت غير ضروري کان پري هوندي جيڪڏهن سسٽم جي ناڪامي پيداوار ۾ ٻيهر پيش ڪيو وڃي.
جيڪڏهن اسان نازڪ معلومات سان ڪم ڪريون ٿا (جهڙوڪ بلنگ لاءِ ڊيٽا، سبسڪرائبر قرض جي حساب سان)، ته پوءِ اهو انهن اوزارن تي ڌيان ڏيڻ جي قابل آهي جيڪي DBMS جي خاصيتن جي ڪري پيدا ٿيندڙ خطرن کي گهٽائي ڇڏيندا. مثال طور، nodesync utility (Datastax) استعمال ڪريو، ترتيب ۾ ان جي استعمال لاءِ هڪ بهترين حڪمت عملي ٺاهي استحڪام جي خاطر، Cassandra تي وڌيڪ لوڊ نه ڪريو ۽ ان کي استعمال ڪريو صرف مخصوص جدولن لاءِ مخصوص مدت ۾.
زندگي جي ڇهن مهينن کان پوء Cassandra کي ڇا ٿيندو؟ عام طور تي، ڪو به غير حل ٿيل مسئلا نه آهن. اسان ڪنهن به سنگين حادثن يا ڊيٽا جي نقصان جي اجازت نه ڏني. ها، اسان کي ڪجهه مسئلن جي معاوضي جي باري ۾ سوچڻو هو جيڪي اڳ ۾ پيدا نه ٿيا هئا، پر آخر ۾ اهو اسان جي تعميراتي حل کي گهڻو بادل نه ڪيو. جيڪڏهن توهان چاهيو ٿا ۽ ڪجهه نئين ڪوشش ڪرڻ کان ڊپ نه آهيو، ۽ ساڳئي وقت تمام گهڻو مايوس نه ٿيڻ چاهيو، پوء حقيقت لاء تيار ٿي وڃو ته ڪجھ به مفت ناهي. توھان کي سمجھڻو پوندو، دستاويزن ۾ ڳولھيو ۽ پنھنجي انفرادي ريڪ کي گڏ ڪرڻو پوندو پراڻو ورثي حل جي ڀيٽ ۾، ۽ ڪو به نظريو توھان کي اڳ ۾ نه ٻڌائيندو ته ڪھڙو ريڪ توھان جو انتظار ڪري رھيو آھي.
جو ذريعو: www.habr.com