هيلو، Khabrovsk جي رهاڪن. هميشه وانگر، اسان نئين ڪورسز جي شروعات کان اڳ دلچسپ مواد حصيداري ڪرڻ جاري رکون ٿا. اڄ، خاص طور تي توهان لاء، اسان گوگل ڪلائوڊ اسپنر بابت هڪ مضمون شايع ڪيو آهي ڪورس جي شروعات سان گڏ .
اصل ۾ شايع ٿيل .
هڪ ڪمپني جي طور تي جيڪا ڪلائوڊ تي ٻڌل POS حل پيش ڪري ٿي سڄي دنيا ۾ پرچون ڪندڙن، ريسٽورنٽرز، ۽ آن لائين وڪڻندڙن لاءِ، Lightspeed ڪيترن ئي قسمن جي ڊيٽابيس پليٽ فارمن کي استعمال ڪري ٿو مختلف ٽرانزيڪشن، تجزياتي، ۽ ڳولا جي استعمال جي ڪيسن لاءِ. انهن ڊيٽابيس پليٽ فارمن مان هر هڪ جون پنهنجون طاقتون ۽ ڪمزوريون آهن. انهيءَ ڪري، جڏهن گوگل Cloud Spanner کي مارڪيٽ ۾ متعارف ڪرايو - پراعتماد خاصيتون جيڪي لاڳاپن واري ڊيٽابيس جي دنيا ۾ نه ڏٺيون ويون، جهڙوڪ لامحدود افقي اسڪيليبلٽي ۽ هڪ 99,999٪ سروس ليول معاهدو (SLA)، - اسان ان تي هٿ حاصل ڪرڻ جو موقعو نه وڃايو!
Cloud Spanner سان گڏ اسان جي تجربي جو هڪ جامع جائزو مهيا ڪرڻ لاءِ، انهي سان گڏ اسان استعمال ڪيل تشخيصي معيار، اسان هيٺ ڏنل عنوانن کي ڍڪينداسين:
- اسان جي تشخيص جو معيار
- Cloud Spanner مختصر طور تي
- اسان جي تشخيص
- اسان جا نتيجا
1. اسان جي تشخيص جو معيار
ڪلائوڊ اسپنر جي خاصيتن تي غور ڪرڻ کان اڳ، مارڪيٽ تي موجود ٻين حلن سان ان جي هڪجهڙائي ۽ اختلاف، اچو ته سڀ کان پهريان انهن بنيادي استعمال جي ڪيسن جي باري ۾ ڳالهايون جيڪي اسان جي ذهن ۾ هئا جڏهن غور ڪيو ويو ته اسان جي انفراسٽرڪچر ۾ ڪلائوڊ اسپنر کي ڪٿي لڳايو وڃي:
- متبادل جي طور تي (مقابلي) روايتي SQL ڊيٽابيس حل
- OLAP سپورٽ سان OLTP حل ڪيئن ڪجي
نوٽ: سادگي ۽ مقابلي جي آسانيءَ لاءِ، هي آرٽيڪل ڪلائوڊ اسپنر جو مقابلو ڪري ٿو MySQL جي مختلف قسمن جي GCP Cloud SQL ۽ Amazon AWS RDS حل خاندانن سان.
ڪلائوڊ اسپنر استعمال ڪندي روايتي SQL ڊيٽابيس حل جي متبادل طور
ماحول ۾ روايتي ڊيٽابيسس، جڏهن ڊيٽابيس جي سوالن جي جواب جو وقت اچي ٿو يا اڳواٽ مقرر ٿيل ايپليڪيشن حدن کان به وڌي ٿو (خاص طور تي استعمال ڪندڙن جي تعداد ۾ اضافو ۽/يا درخواستن جي ڪري)، اتي ڪيترائي طريقا آھن جوابي وقت کي گھٽائڻ لاءِ قابل قبول سطحن تائين. بهرحال، انهن مان اڪثر حل شامل آهن دستي مداخلت.
مثال طور، وٺڻ لاء پهريون قدم مختلف ڪارڪردگي سان لاڳاپيل ڊيٽابيس جي پيٽرولن کي ڏسڻ لاء آهي ۽ انهن کي بهترين ميچ ايپليڪيشن استعمال ڪيس جي نمونن کي ترتيب ڏيو. جيڪڏهن اهو ڪافي نه آهي، توهان ڊيٽابيس کي عمودي يا افقي طور تي ماپ ڪرڻ لاء چونڊي سگهو ٿا.
هڪ ايپليڪيشن کي عمودي طور تي اسڪيل ڪرڻ سان سرور جي مثال کي اپڊيٽ ڪرڻ شامل آهي، عام طور تي وڌيڪ پروسيسرز/ڪورز، وڌيڪ RAM، تيز اسٽوريج وغيره شامل ڪرڻ سان. وڌيڪ هارڊويئر وسيلن کي شامل ڪرڻ سان ڊيٽابيس جي ڪارڪردگي ۾ اضافو ٿيندو آهي، بنيادي طور تي سيڪنڊ ۾ ٽرانزيڪشن ۾ ماپي ويندي آهي، ۽ OLTP سسٽم لاءِ ٽرانزيڪشن جي دير. لاڳاپو ڊيٽابيس سسٽم (جيڪو گھڻن موضوعن وارو طريقو استعمال ڪندو آهي) جهڙوڪ MySQL پيماني تي چڱي طرح عمودي طور تي.
هن طريقي سان ڪيترائي نقصان آهن، پر سڀ کان وڌيڪ واضح آهي مارڪيٽ تي وڌ ۾ وڌ سرور سائيز. هڪ دفعو سڀ کان وڏي سرور جي مثال جي حد تائين پهچي وڃي ٿي، اتي صرف هڪ اختيار باقي آهي: افقي اسڪيلنگ.
افقي اسڪيلنگ هڪ طريقو آهي جتي وڌيڪ سرورز ڪلستر ۾ شامل ڪيا ويا آهن، مثالي طور تي ڪارڪردگي وڌائي ٿي جيئن سرورز جو تعداد شامل ڪيو ويو آهي. اڪثريت روايتي ڊيٽابيس سسٽم افقي طور تي چڱي طرح ماپ نه ڪندا آهن يا سڀني تي ماپ نه ڪندا آهن. مثال طور، MySQL غلام پڙهندڙن کي شامل ڪندي پڙهڻ جي عملن لاء افقي طور تي ماپ ڪري سگھي ٿو، پر لکڻين لاء افقي طور تي ماپ نٿو ڪري سگھي.
ٻئي طرف، ان جي فطرت جي ڪري، ڪلائوڊ اسپنر آساني سان افقي طور تي گھٽ ۾ گھٽ مداخلت سان ماپ ڪري سگھي ٿو.
مڪمل طور تي نمايان ٿيل DBMS هڪ خدمت جي طور تي مختلف زاوين کان جائزو وٺڻ گهرجي. هڪ بنياد جي طور تي، اسان ڪلائوڊ ۾ سڀ کان وڌيڪ مشهور DBMS ورتو - گوگل لاءِ، GCP Cloud SQL ۽ Amazon لاءِ، AWS RDS. اسان جي تشخيص ۾ اسان ھيٺ ڏنل ڀاڱن تي ڌيان ڏنو:
- فيچر ميپنگ: حد SQL، DDL، DML؛ ڪنيڪشن لائبريريون / ڪنيڪٽر، ٽرانزيڪشن سپورٽ، وغيره.
- ترقي جي حمايت: آسان ترقي ۽ جاچ.
- ايڊمنسٽريشن سپورٽ: مثال جو انتظام - مثال طور، اسڪيلنگ اپ/ڊائون ۽ مثالن کي اپڊيٽ ڪرڻ؛ SLA، بيڪ اپ ۽ بحالي؛ سيڪيورٽي / رسائي ڪنٽرول.
ڪلائوڊ اسپنر کي OLAP-فعال ٿيل OLTP حل طور استعمال ڪرڻ
جڏهن ته گوگل واضح طور تي دعويٰ نٿو ڪري ته ڪلائوڊ اسپنر تجزياتي پروسيسنگ لاءِ ٺهيل آهي، اهو ٻين انجڻين جهڙوڪ Apache Impala ۽ Kudu ۽ YugaByte سان ڪجهه خاصيتون شيئر ڪري ٿو، جيڪي OLAP ڪم لوڊ لاءِ ٺهيل آهن.
جيتوڻيڪ اتي صرف هڪ ننڍڙو موقعو هو ته ڪلائوڊ اسپنر ۾ هڪ مسلسل اسڪيل-آئوٽ HTAP (هائبرڊ ٽرانزيڪشنل / اينالائيٽڪس پروسيسنگ) انجڻ شامل آهي (وڌيڪ يا گهٽ) قابل استعمال OLAP فيچر سيٽ سان، اسان سوچيو ته اهو اسان جي توجه جي لائق هوندو.
انهي سان گڏ ذهن ۾، اسان هيٺ ڏنل ڀاڱن تي غور ڪيو:
- ڊيٽا لوڊ ڪرڻ، انڊيڪس ۽ ورهاڱي جي حمايت
- سوال جي ڪارڪردگي ۽ ڊي ايم ايل
2. ڪلائوڊ اسپنر مختصر ۾
گوگل اسپنر هڪ ڪلستر ٿيل تعلقي ڊيٽابيس مينيجمينٽ سسٽم (RDBMS) آهي جيڪو گوگل استعمال ڪري ٿو پنهنجي ڪيترن ئي خدمتن لاءِ. گوگل ان کي عام طور تي 2017 جي شروعات ۾ گوگل ڪلائوڊ پليٽ فارم استعمال ڪندڙن لاءِ دستياب ڪيو.
هتي ڪجھ ڪلائوڊ اسپنر خاصيتون آهن:
- انتهائي مسلسل اسپيبلبل RDBMS ڪلستر: ڊيٽا جي تسلسل کي يقيني بڻائڻ لاءِ هارڊويئر وقت جي هم وقت سازي کي استعمال ڪري ٿو.
- ڪراس-ٽيبل ٽرانزيڪشن سپورٽ: ٽرانزيڪشن ڪيترن ئي جدولن کي وڌائي سگھي ٿو - لازمي طور تي ھڪڙي ٽيبل تائين محدود نه آھي (اپاچي HBase يا Apache Kudu جي برعڪس).
- پرائمري ڪي بنياد تي ٻڌل جدول: سڀني جدولن ۾ لازمي طور تي ھڪ اعلان ڪيل پرائمري ڪي (PC) ھجڻ گھرجي، جيڪا ٽيبل ۾ گھڻن ڪالمن تي مشتمل ٿي سگھي ٿي. ٽيبلر ڊيٽا پي سي آرڊر ۾ ذخيرو ٿيل آهي، ان کي پي سي ڳولڻ لاء تمام ڪارائتو ۽ تيز بڻائي ٿو. ٻين پي سي تي ٻڌل سسٽم وانگر، لاڳو ڪرڻ لازمي طور تي اڳ ۾ ٺهيل استعمال جي ڪيسن سان ماڊل ڪيو وڃي. .
- پٽي ٿيل جدولن: جدولن ۾ هڪ ٻئي تي جسماني انحصار ٿي سگھي ٿو. ٻارن جي ٽيبل ۾ قطارون والدين جي ٽيبل ۾ قطارن سان ملائي سگهجن ٿيون. اهو طريقو رشتن جي ڳولا کي تيز ڪري ٿو جيڪي ڊيٽا ماڊلنگ جي مرحلي دوران سڃاڻپ ڪري سگھجن ٿيون، جهڙوڪ گراهڪن کي گڏ ڪرڻ ۽ انهن جي انوائسز.
- انڊيڪس: ڪلائوڊ اسپنر ثانوي انڊيڪس کي سپورٽ ڪري ٿو. انڊيڪس انڊيڪس ڪيل ڪالمن ۽ سڀني پي سي ڪالمن تي مشتمل آهي. جيڪڏهن گهربل هجي، انڊيڪس ۾ ٻيا غير انڊيڪس ٿيل ڪالمن پڻ شامل هوندا. سوالن کي تيز ڪرڻ لاءِ انڊيڪس کي والدين ٽيبل سان گڏ ڪري سگھجي ٿو. انڊيڪس تي ڪيتريون ئي پابنديون لاڳو ٿين ٿيون، جيئن انڊيڪس ۾ ذخيرو ڪيل اضافي ڪالمن جو وڌ ۾ وڌ تعداد. انهي سان گڏ، انڊيڪس ذريعي سوال شايد ٻين RDBMSs وانگر سڌو نه هجن.
"ڪلائوڊ اسپنر هڪ انڊيڪس پاڻمرادو چونڊيندو آهي صرف نادر ڪيسن ۾. خاص طور تي، ڪلائوڊ اسپنر خودڪار طريقي سان ثانوي انڊيڪس کي منتخب نه ڪندو آهي جيڪڏهن ڪو سوال ڪنهن به ڪالمن جي درخواست ڪري ٿو جيڪو محفوظ نه آهي ».
- خدمت جي سطح جو معاهدو (SLA): ھڪڙي علائقي ۾ مقرري 99,99٪ جي SLA سان؛ 99,999٪ SLA سان گڏ گھڻن علائقائي تعينات. جڏهن ته SLA پاڻ صرف هڪ معاهدو آهي ۽ ڪنهن به قسم جي ضمانت نه آهي، مان سمجهان ٿو ته گوگل تي ماڻهن وٽ ڪجهه سخت ڊيٽا آهي اهڙي مضبوط دعوي ڪرڻ لاء. (حوالن لاء، 99,999٪ مطلب آهي 26,3 سيڪنڊن جي خدمت جي دستيابي هر مهيني.)
- وڌيڪ:
نوٽ: Apache Tephra پروجيڪٽ Apache HBase ۾ بهتر ٽرانزيڪشن سپورٽ شامل ڪري ٿو (هاڻي اپاچي فينڪس ۾ بيٽا طور تي لاڳو ٿيل آهي).
3. اسان جي تشخيص
تنهن ڪري، اسان سڀ پڙهي چڪا آهيون گوگل جي دعوائن بابت ڪلائوڊ اسپنر جي فائدن جي باري ۾ - عملي طور تي لامحدود افقي اسڪيلنگ جڏهن ته اعلي استحڪام ۽ هڪ تمام اعلي SLA برقرار رکندي. جيتوڻيڪ اهي گهرجون، ڪنهن به صورت ۾، حاصل ڪرڻ انتهائي مشڪل آهن، اسان جو مقصد انهن کي رد ڪرڻ نه هو. ان جي بدران، اچو ته ٻين شين تي ڌيان ڏيون جيڪي اڪثر ڊيٽابيس استعمال ڪندڙ کي خيال رکندا آهن: برابري ۽ استعمال.
اسان Sharded MySQL جي متبادل طور Cloud Spanner جو جائزو ورتو
Google Cloud SQL ۽ Amazon AWS RDS، ڪلائوڊ مارڪيٽ ۾ سڀ کان وڌيڪ مقبول OLTP DBMSs مان، خاصيتون جو تمام وڏو سيٽ آھي. بهرحال، انهن ڊيٽابيس کي ماپڻ لاءِ هڪ واحد نوڊ جي سائيز کان ٻاهر، توهان کي ايپليڪيشن ورهاڱي کي انجام ڏيڻ جي ضرورت آهي. اهو طريقو ٻنهي ايپليڪيشنن ۽ انتظاميه لاء اضافي پيچيدگي پيدا ڪري ٿو. اسان ڏٺو ته اسپنر هڪ ئي مثال ۾ ڪيترن ئي شارڊز کي گڏ ڪرڻ جي منظرنامي ۾ ڪيئن ٺهڪي اچي ٿو ۽ ڪهڙيون خاصيتون (جيڪڏهن ڪو به آهن) کي قربان ڪرڻ جي ضرورت پوندي.
SQL، DML ۽ DDL سپورٽ، گڏوگڏ کنیکٹر ۽ لائبريريون؟
پهرين، جڏهن ڪنهن به ڊيٽابيس سان شروع ٿئي ٿي، توهان کي ڊيٽا ماڊل ٺاهڻ جي ضرورت آهي. جيڪڏهن توهان سوچيو ٿا ته توهان JDBC اسپنر کي پنهنجي پسنديده SQL ٽول سان ڳنڍي سگهو ٿا، توهان کي معلوم ٿيندو ته توهان ان سان پنهنجي ڊيٽا کي پڇي سگهو ٿا، پر توهان ان کي ٽيبل ٺاهڻ يا تبديل ڪرڻ (DDL) يا ڪنهن به داخل ڪرڻ/اپڊيٽ/ڊليٽ ڪرڻ لاءِ استعمال نٿا ڪري سگهو. آپريشنز (DML). گوگل جو سرڪاري JDBC انهن مان ڪنهن کي به سپورٽ نٿو ڪري.
"ڊرائيور في الحال DML يا DDL بيانن جي حمايت نٿا ڪن."
اسپنر دستاويزن
صورتحال GCP ڪنسول سان بهتر ناهي - توهان صرف موڪلي سگهو ٿا SELECT سوال. خوش قسمتي سان اتي ھڪڙو JDBC ڊرائيور آھي جنھن ۾ ڪميونٽي کان ڊي ايم ايل ۽ ڊي ڊي ايل جي مدد سان، ٽرانزيڪشن سميت . جڏهن ته هي ڊرائيور انتهائي مفيد آهي، گوگل جي پنهنجي JDBC ڊرائيور جي کوٽ حيرت انگيز آهي. خوشقسمتيءَ سان، گوگل پيش ڪري ٿو وسيع وسيع سپورٽ ڪلائنٽ لائبريرين لاءِ (جي آر پي سي جي بنياد تي): C#, Go, Java, node.js, PHP, Python, and Ruby.
ڪلائوڊ اسپنر ڪسٽم APIs جو لڳ ڀڳ لازمي استعمال (JDBC ۾ DDL ۽ DML جي گھٽتائي جي ڪري) نتيجن سان لاڳاپيل ڪوڊ وارن علائقن لاءِ ڪجهه حدون آهن جهڙوڪ ڪنيڪشن پول يا ڊيٽابيس بائنڊنگ فريم ورڪ (مثال طور اسپرنگ MVC). عام طور تي، جڏهن JDBC استعمال ڪري رهيا آهيو، توهان آزاد آهيو پنهنجي پسنديده ڪنيڪشن پول چونڊڻ لاءِ (مثال طور HikariCP، DBCP، C3PO، وغيره.) جيڪو آزمايل آهي ۽ سٺو ڪم ڪري ٿو. ڪسٽم اسپنر APIs جي صورت ۾، اسان کي فريم ورڪ / پابند پول / سيشن تي ڀروسو ڪرڻو پوندو جيڪي اسان پاڻ ٺاهيا آهن.
پرائمري ڪيئي (PC) سينٽرڪ ڊيزائن ڪلائوڊ اسپنر کي تمام تيز ٿيڻ جي اجازت ڏئي ٿي جڏهن PC ذريعي ڊيٽا تائين رسائي حاصل ڪري ٿي، پر ڪجهه سوالن جا مسئلا پڻ متعارف ڪرائي ٿو.
- توهان بنيادي اهم قيمت کي اپڊيٽ نٿا ڪري سگهو؛ توھان کي پھريون ڀيرو داخل ٿيڻ گھرجي اصل پي سي مان داخل ڪريو ۽ ان کي نئين قيمت سان ٻيهر داخل ڪريو. (اهو ساڳيو آهي ٻين PC تي مبني ڊيٽابيس / اسٽوريج انجڻ.)
- ڪنهن به UPDATE ۽ DELETE بيانن کي PC ۾ وضاحت ڪرڻ گهرجي جتي ڪٿي، تنهن ڪري اتي خالي نه ٿي سگھي DELETE سڀ بيان - اتي هميشه هڪ ذيلي پڇا ڳاڇا هجڻ گهرجي، مثال طور: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- خودڪار واڌارو اختيار جو فقدان يا ساڳي شيء جيڪا پي سي فيلڊ لاء ترتيب ترتيب ڏئي ٿي. ھن لاء ڪم ڪرڻ لاء، لاڳاپيل قدر ايپليڪيشن جي پاسي تي ٺاھيو وڃي.
ثانوي انڊيڪس؟
گوگل ڪلائوڊ اسپنر ثانوي انڊيڪسس لاءِ بلٽ ان سپورٽ ڪئي آهي. هي هڪ تمام سٺي خاصيت آهي جيڪا هميشه ٻين ٽيڪنالاجيز ۾ موجود ناهي. Apache Kudu في الحال ثانوي انڊيڪس کي سپورٽ نٿو ڪري، ۽ Apache HBase سڌو سنئون انڊيڪس کي سپورٽ نٿو ڪري، پر انهن کي Apache Phoenix ذريعي شامل ڪري سگھي ٿو.
Kudu ۽ HBase ۾ انڊيڪسز کي الڳ جدول جي طور تي ماڊل ڪري سگھجي ٿو پرائمري ڪنجيز جي مختلف مجموعن سان، پر پيرن ٽيبل ۽ لاڳاپيل انڊيڪس جدولن تي ڪيل عملن جي ايٽمي صلاحيت لازمي طور تي ايپليڪيشن جي سطح تي ٿيڻ گھرجي ۽ صحيح طريقي سان عمل ڪرڻ لاءِ ڪا معمولي ڳالهه نه آھي.
جيئن ته ڪلائوڊ اسپنر جائزو ۾ ذڪر ڪيو ويو آهي، ان جا انڊيڪس شايد MySQL انڊيڪس کان مختلف هجن. تنهن ڪري، خاص خيال رکڻ گهرجي جڏهن سوالن جي تعمير ۽ پروفائلنگ کي يقيني بڻائي سگهجي ته مناسب انڊيڪس استعمال ڪيو وڃي جتي ضرورت هجي.
نمائندگي؟
هڪ ڊيٽابيس ۾ هڪ تمام مشهور ۽ مفيد اعتراض آهي نظارو. اهي استعمال جي ڪيسن جي وڏي تعداد لاء ڪارائتو ٿي سگهن ٿا. منهنجا ٻه پسنديده منطقي تجزيه پرت ۽ سيڪيورٽي پرت آهن. بدقسمتي سان، Cloud Spanner نظرن جي حمايت نٿو ڪري. بهرحال، اهو صرف جزوي طور تي اسان کي محدود ڪري ٿو ڇو ته ڪالمن جي سطح تي رسائي جي اجازتن جي ڪا به گنجائش نه آهي جتي نظريا هڪ قابل عمل حل ٿي سگهي ٿي.
ڏسو Cloud Spanner دستاويزن ھڪڙي سيڪشن لاءِ جيڪو تفصيلي ڪوٽا ۽ پابنديون ()، خاص طور تي ھڪڙو آھي جيڪو ڪجھ ايپليڪيشنن لاءِ مشڪل ٿي سگھي ٿو: Cloud Spanner آئوٽ آف دي باڪس جي حد آھي وڌ ۾ وڌ 100 ڊيٽابيس في مثال جي. ظاهر آهي، اهو هڪ ڊيٽابيس لاءِ هڪ وڏي رڪاوٽ ٿي سگهي ٿو جيڪا 100 کان وڌيڪ ڊيٽابيس تائين ماپ ڪرڻ لاءِ ٺهيل آهي. خوشقسمتيءَ سان، اسان جي گوگل ٽيڪنيڪل نمائندي سان ڳالهائڻ کان پوءِ، اسان معلوم ڪيو ته اها حد گوگل سپورٽ ذريعي تقريبن ڪنهن به قدر تائين وڌائي سگهجي ٿي.
ترقي جي حمايت؟
Cloud Spanner پيش ڪري ٿو خوبصورت مهذب پروگرامنگ ٻولي سپورٽ ان جي API سان ڪم ڪرڻ لاءِ. سرڪاري طور تي سپورٽ ٿيل لائبريريون C#، Go، Java، node.js، PHP، Python ۽ Ruby جي علائقن ۾ آهن. دستاويز ڪافي تفصيلي آهي، پر جيئن ته ٻين جديد ٽيڪنالاجيز سان گڏ، ڪميونٽي تمام گهڻي مشهور ڊيٽابيس ٽيڪنالاجيز جي مقابلي ۾ تمام ننڍي آهي، جيڪا گهٽ عام استعمال جي ڪيسن يا مسئلن کي حل ڪرڻ ۾ وڌيڪ وقت گذاري سگهي ٿي.
پوء مقامي ترقي جي حمايت بابت ڇا؟
اسان کي Cloud Spanner مثال آن-پريمسس ٺاهڻ جو ڪو طريقو نه مليو آهي. سڀ کان ويجھي شيء جيڪا اسان حاصل ڪئي اها هڪ ڊاڪر تصوير هئي. ، جيڪو اصول ۾ ساڳيو آهي، پر عملي طور تي بلڪل مختلف آهي. مثال طور، CockroachDB استعمال ڪري سگھي ٿو PostgreSQL JDBC. جيئن ته ترقي وارو ماحول پيداوار جي ماحول جي جيترو ٿي سگهي ويجهو هجڻ گهرجي، ڪلائوڊ اسپنر مثالي نه آهي ڇو ته ان کي مڪمل اسپنر مثال تي ڀروسو ڪرڻ گهرجي. خرچ بچائڻ لاءِ، توھان منتخب ڪري سگھو ٿا ھڪڙي علائقي جو مثال.
انتظامي مدد؟
ڪلائوڊ اسپنر مثال ٺاهڻ تمام سادو آهي. توهان کي صرف هڪ گھڻ-علائقي يا واحد-علائقي مثال ٺاهڻ جي وچ ۾ چونڊڻ جي ضرورت آهي، علائقي (ن) ۽ نوڊس جو تعداد بيان ڪريو. هڪ منٽ کان به گهٽ وقت ۾، توهان جو مثال مٿي ۽ هلندڙ هوندو.
گوگل ڪنسول ۾ اسپنر پيج تان ڪيترائي بنيادي ميٽرڪ سڌو سنئون دستياب آهن. وڌيڪ تفصيلي نظارا Stackdriver ذريعي دستياب آهن، جتي توهان ميٽرڪ حدون ۽ الرٽ پاليسيون پڻ سيٽ ڪري سگهو ٿا.
وسيلن تائين رسائي؟
MySQL پيش ڪري ٿو وسيع ۽ تمام وڏيون سيٽنگون استعمال ڪندڙ جي اجازتن / ڪردارن لاءِ. توھان آساني سان ھڪڙي مخصوص ٽيبل تائين رسائي کي ترتيب ڏئي سگھو ٿا، يا صرف ان جي ڪالمن جو ھڪڙو ذيلي سيٽ. Cloud Spanner استعمال ڪري ٿو گوگل جو Identity & Access Management (IAM) اوزار، جيڪو صرف توھان کي اجازت ڏئي ٿو پاليسيون ۽ اجازتون مقرر ڪرڻ لاءِ تمام اعليٰ سطح تي. سڀ کان وڌيڪ گرينولر اختيار ڊيٽابيس-سطح جي قرارداد آهي، جيڪو اڪثر پيداوار جي استعمال جي ڪيسن ۾ مناسب ناهي. هي حد بندي توهان کي اسپنر وسيلن جي غير مجاز استعمال کي روڪڻ لاءِ توهان جي ڪوڊ، انفراسٽرڪچر، يا ٻئي ۾ اضافي حفاظتي اپاءَ شامل ڪرڻ تي مجبور ڪري ٿي.
بيڪ اپ؟
ان کي آسان ڪرڻ لاء، ڪلائوڊ اسپنر ۾ ڪو به بيڪ اپ نه آهي. جيتوڻيڪ گوگل جون اعليٰ SLA گهرجون ان ڳالهه کي يقيني بڻائي سگهن ٿيون ته توهان هارڊويئر يا ڊيٽابيس جي ناڪامين، انساني غلطين، ايپليڪيشن جي خرابين وغيره جي ڪري ڪو به ڊيٽا نه وڃايو. اسان سڀ اهو قاعدو ڄاڻون ٿا: اعليٰ دستيابي هڪ سائونڊ بيڪ اپ حڪمت عملي جو متبادل ناهي. في الحال، ڊيٽا کي بيڪ اپ ڪرڻ جو واحد طريقو اهو آهي ته پروگرام جي طور تي ان کي ڊيٽابيس کان الڳ اسٽوريج ماحول ڏانهن منتقل ڪيو وڃي.
ڪارڪردگي جو سوال؟
اسان ڊيٽا لوڊ ڪرڻ ۽ سوالن جي جانچ ڪرڻ لاءِ ياهو استعمال ڪيو. Cloud Serving Benchmark. هيٺ ڏنل جدول ڏيکاري ٿو YCSB ڪم لوڊ B 95٪ پڙهڻ سان 5٪ لکڻ جي تناسب سان.
* لوڊ ٽيسٽ n1-standard-32 Compute Engine (CE) (32 vCPU، 120 GB ميموري) تي هليو ويو، ۽ ٽيسٽ جو مثال ڪڏهن به ٽيسٽن ۾ ڪا رڪاوٽ نه هئي.
** ھڪڙي YCSB مثال ۾ ٿريڊن جو وڌ ۾ وڌ تعداد 400 آھي. ڪل 2400 موضوعن کي حاصل ڪرڻ لاءِ YCSB ٽيسٽ جا ڪل ڇهه متوازي مثال ھلائڻا پوندا.
معيار جي نتيجن کي ڏسندي، خاص طور تي سي پي يو لوڊ ۽ TPS جو ميلاپ، اسان واضح طور تي ڏسي سگهون ٿا ته ڪلائوڊ اسپنر اسڪيل تمام سٺو. ٿريڊز جي وڏي تعداد پاران پيدا ڪيل ڳري لوڊ ڪلائوڊ اسپنر ڪلستر ۾ نوڊس جي وڏي تعداد جي ڪري ختم ٿي وئي آهي. جڏهن ته ويڪرائي تمام گهڻي ڏسڻ ۾ اچي ٿي، خاص طور تي جڏهن 2400 ٿريڊن سان هلندي، ڪمپيوٽر انجڻ جي 6 ننڍڙن مثالن سان ٻيهر ٽيسٽ ڪرڻ ضروري ٿي سگهي ٿو وڌيڪ صحيح نمبر حاصل ڪرڻ لاءِ. هر مثال 6 متوازي ٽيسٽن سان گڏ هڪ وڏي CE مثال جي بدران هڪ YCSB ٽيسٽ هلائيندو. انهي طريقي سان، Cloud Spanner جي درخواست جي دير جي وچ ۾ فرق ڪرڻ آسان ٿي ويندو ۽ Cloud Spanner ۽ CE مثال جي وچ ۾ نيٽ ورڪ ڪنيڪشن پاران شامل ڪيل ٽيسٽ کي هلائڻ ۾.
ڪلائوڊ اسپنر OLAP جي طور تي ڪيئن ڪم ڪندو آهي؟
ورهاڱي؟
ڊيٽا کي جسماني ۽/يا منطقي طور تي آزاد حصن ۾ ورهائڻ، جنهن کي پارٽيشنز سڏيو ويندو آهي، هڪ تمام مشهور تصور آهي جيڪو اڪثر OLAP انجڻين ۾ مليو آهي. ورهاڱي خاص طور تي سوال جي ڪارڪردگي ۽ ڊيٽابيس جي برقرار رکڻ کي بهتر بڻائي سگهن ٿا. ورهاڱي جي باري ۾ وڌيڪ تفصيل سان وڃڻ لاءِ هڪ الڳ مضمون (مضمون) هوندو، تنهنڪري اچو ته صرف ورهاڱي ۽ سب-پارٽيشننگ اسڪيم جي اهميت جو ذڪر ڪريون. ڊيٽا کي ڀاڱن ۾ ٽوڙڻ جي صلاحيت ۽ اڃا به وڌيڪ ذيلي تقسيم ۾ تجزياتي سوال جي ڪارڪردگي لاء اهم آهي.
ڪلائوڊ اسپنر ورهاڱي کي سپورٽ نٿو ڪري. اهو اندروني طور تي ڊيٽا کي ورهائي ٿو جنهن کي سڏيو ويندو آهي تقسيم-s جي بنياد تي بنيادي مکيه حدن تي. ورهاڱي خودڪار طريقي سان ڪئي ويندي آهي لوڊ کي بيلنس ڪرڻ لاءِ ڪلائوڊ اسپنر ڪلسٽر ۾. ڪلائوڊ اسپنر جي هڪ تمام مفيد خصوصيت والدين جي ٽيبل جي بيس لوڊ کي ورهائڻ آهي (هڪ ٽيبل جيڪا ٻئي سان نه جڙيل آهي). اسپنر پاڻمرادو معلوم ڪري ٿو ته ڇا ان ۾ شامل آهي تقسيم ڊيٽا جيڪا ٻين جي ڀيٽ ۾ وڌيڪ پڙهي ويندي آهي تقسيم-آه، ۽ وڌيڪ علحدگيءَ جو فيصلو ڪري سگھي ٿو. اهو طريقو، وڌيڪ نوڊس هڪ درخواست ۾ شامل ٿي سگهي ٿو، جيڪو پڻ مؤثر طريقي سان وڌائي ٿو.
ڊيٽا لوڊ ڪندي؟
بلڪ ڊيٽا لاءِ ڪلائوڊ اسپنر جو طريقو ساڳيو آهي جيئن عام لوڊشيڊنگ لاءِ. وڌ ۾ وڌ ڪارڪردگي حاصل ڪرڻ لاء، توهان کي ڪجهه هدايتن جي پيروي ڪرڻ جي ضرورت آهي، جنهن ۾ شامل آهن:
- پنھنجي ڊيٽا کي پرائمري چيڪ سان ترتيب ڏيو.
- انھن کي 10 * سان ورهايونوڊس جو تعداد جدا جدا حصا.
- ڪم ڪارن جو هڪ سيٽ ٺاهيو جيڪو ڊيٽا کي متوازي ۾ لوڊ ڪري ٿو.
هي ڊيٽا لوڊ ڪندي سڀ ڪلائوڊ اسپنر نوڊس استعمال ڪري ٿو.
اسان 10M قطارن جو ڊيٽا سيٽ ٺاهڻ لاءِ YCSB ڪم لوڊ A استعمال ڪيو.
* لوڊ ٽيسٽ n1-standard-32 ڪمپيوٽ انجڻ تي هلائي وئي (32 vCPU، 120 GB ياداشت)، ۽ ٽيسٽ جو مثال ڪڏهن به ٽيسٽن ۾ ڪا رڪاوٽ نه هئي.
** سنگل نوڊ سيٽ اپ ڪنهن به پيداوار جي ڪم جي لوڊ لاء سفارش نه ڪئي وئي آهي.
جيئن مٿي ذڪر ڪيو ويو آهي، ڪلائوڊ اسپنر خودڪار طريقي سان عمل ڪري ٿو تقسيم انهن جي لوڊ جي بنياد تي، تنهن ڪري نتيجا بهتر ٿين ٿا ڪيترن ئي مسلسل ٽيسٽ ورجائي کان پوءِ. هتي پيش ڪيل نتيجا اسان کي حاصل ڪيل بهترين نتيجا آهن. مٿي ڏنل انگن کي ڏسندي، اسان ڏسي سگهون ٿا ته ڪيئن ڪلائوڊ اسپنر اسڪيل (سٺو) ڪلستر ۾ نوڊس جو تعداد وڌائي ٿو. اهي انگ جيڪي بيٺا آهن اهي انتهائي گهٽ اوسط دير وارا آهن، جيڪي مخلوط ڪم لوڊ (95٪ پڙهڻ ۽ 5٪ لکڻ) جي نتيجن سان برعڪس آهن جيئن مٿي سيڪشن ۾ بيان ڪيو ويو آهي.
اسڪيلنگ؟
ڪلائوڊ اسپنر نوڊس جو تعداد وڌائڻ ۽ گھٽائڻ ھڪڙو ڪلڪ ڪندڙ ڪم آھي. جيڪڏهن توهان ڊيٽا کي جلدي لوڊ ڪرڻ چاهيو ٿا، ته توهان پنهنجي مثال کي وڌ ۾ وڌ وڌائڻ تي غور ڪري سگهو ٿا (اسان جي صورت ۾ اهو US-EAST علائقي ۾ 25 نوڊس هو) ۽ پوءِ توهان جي عام لوڊ لاءِ اهل نوڊس جو تعداد گهٽايو جڏهن سمورو ڊيٽا ان ۾ آهي. ڊيٽابيس، 2TB / نوڊ جي حد ڏانهن اشارو ڪندي.
اسان کي هن حد جي ياد ڏياري وئي جيتوڻيڪ هڪ تمام ننڍڙو ڊيٽابيس سان. لوڊ ٽيسٽ جي ڪيترن ئي ڊوڙن کان پوء، اسان جو ڊيٽابيس سائيز ۾ 155 GB بابت هو، ۽ جڏهن 1 نوڊ مثال کي وڌايو ويو، اسان کي هيٺ ڏنل غلطي ملي ٿي:
اسان 25 کان 2 مثالن تائين ماپ ڪرڻ ۾ ڪامياب ٿي ويا، پر اسان ٻن نوڊس تي پڪاريو ويو.
ڪلائوڊ اسپنر ڪلستر ۾ نوڊس جو تعداد وڌائڻ ۽ گھٽائڻ REST API استعمال ڪندي خودڪار ٿي سگھي ٿو. اهو خاص طور تي ڪارائتو ٿي سگهي ٿو وڌندڙ سسٽم لوڊ کي گهٽائڻ لاءِ مصروف ڪم جي ڪلاڪن دوران.
OLAP سوالن جي ڪارڪردگي؟
اسان اصل ۾ هن حصي تي اسپينر جي اسان جي تشخيص ۾ هڪ اهم وقت خرچ ڪرڻ جي منصوبابندي ڪئي. ڪيترن ئي SELECT COUNTs کان پوءِ، اسان فوري طور تي محسوس ڪيو ته ٽيسٽنگ مختصر هوندي ۽ اهو اسپنر OLAP لاءِ مناسب انجڻ نه هوندو. ڪلستر ۾ نوڊس جي تعداد جي لحاظ کان، صرف 10M قطار واري ٽيبل ۾ قطارن جو تعداد چونڊڻ 55 ۽ 60 سيڪنڊن جي وچ ۾ ورتو. اضافي طور تي، ڪو به سوال جيڪو وچولي نتيجن کي ذخيرو ڪرڻ لاء وڌيڪ ميموري جي ضرورت آهي OOM غلطي سان ناڪام ٿيو.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
TPC-H سوالن لاءِ ڪجھ نمبر ڳولي سگهجن ٿا Todd Lipcon جي مضمون ۾ , slides 42 and 43. اهي انگ اسان جي پنهنجي نتيجن سان مطابقت رکن ٿا (بدقسمتي سان).
4. اسان جا نتيجا
ڪلائوڊ اسپنر جي خاصيتن جي موجوده حالت کي نظر ۾ رکندي، اهو تصور ڪرڻ مشڪل آهي ته اهو توهان جي موجوده OLTP حل لاءِ هڪ سادي متبادل آهي، خاص طور تي جڏهن توهان جون ضرورتون ان کان وڌي وڃن ٿيون. Cloud Spanner جي گھٽتائي جي چوڌاري هڪ حل ٺاهڻ ۾ وقت جو هڪ اهم مقدار خرچ ڪرڻو پوندو.
جڏهن اسان ڪلائوڊ اسپنر جو جائزو وٺڻ شروع ڪيو، اسان توقع ڪئي ته ان جي انتظامي خصوصيتن جي برابر هوندي، يا گهٽ ۾ گهٽ نه تمام پري، ٻين گوگل SQL حلن کان. پر اسان حيران ٿي وياسين بيڪ اپ جي مڪمل کوٽ ۽ وسيلن تائين رسائي تي تمام محدود ڪنٽرول. نه ذڪر ڪرڻ جو ڪو به خيال، نه مقامي ترقي وارو ماحول، اڻ سڌريل سلسلو، JDBC بغير DML ۽ DDL سپورٽ، وغيره.
پوءِ ڪٿي وڃي ٿو جيڪو ڪنهن ٽرانزيڪشنل ڊيٽابيس کي ماپڻ جي ضرورت آهي؟ مارڪيٽ تي ھڪڙو واحد حل نظر نٿو اچي جيڪو سڀني استعمال جي ڪيسن کي پورو ڪري ٿو. اتي ڪيترائي بند ۽ کليل ذريعو حل آھن (جن مان ڪجھ جو ذڪر ھن مضمون ۾ ڪيو ويو آھي)، ھر ھڪ پنھنجي پنھنجي طاقت ۽ ڪمزورين سان، پر انھن مان ڪو به SaaS کي 99,999٪ SLA ۽ اعلي استحڪام سان پيش نٿو ڪري. جيڪڏهن هڪ اعلي SLA توهان جو بنيادي مقصد آهي ۽ توهان هڪ ڪسٽم ملٽي ڪلائوڊ حل ٺاهڻ لاءِ مائل نه آهيو، ڪلائوڊ اسپنر اهو حل ٿي سگهي ٿو جيڪو توهان ڳولي رهيا آهيو. پر توهان کي ان جي سڀني حدن کان واقف ٿيڻ گهرجي.
منصفانه هجڻ لاء، Cloud Spanner صرف 2017 جي چشمي ۾ عوام لاء جاري ڪيو ويو، تنهنڪري اهو توقع ڪرڻ مناسب آهي ته ان جي موجوده نقصن مان ڪجهه آخرڪار ختم ٿي وڃن (اميد سان)، ۽ جڏهن اهي ڪندا، اهو ٿي سگهي ٿو راند بدلائيندڙ. سڀ کان پوء، Cloud Spanner گوگل لاء صرف هڪ طرفي منصوبو ناهي. گوگل ان کي ٻين گوگل پروڊڪٽس جي بنياد طور استعمال ڪري ٿو. ۽ جڏهن گوگل تازو ميگا اسٽور کي گوگل ڪلائوڊ اسٽوريج ۾ ڪلائوڊ اسپنر سان تبديل ڪيو، ان کي گوگل ڪلائوڊ اسٽوريج کي عالمي سطح تي شين جي فهرستن لاءِ انتهائي مطابقت پيدا ڪرڻ جي اجازت ڏني وئي (جيڪو اڃا تائين معاملو ناهي. ).
تنهن ڪري، اڃا به اميد آهي ... اسان کي اميد آهي.
اهو ئي سڀ ڪجهه آهي. مضمون جي ليکڪ وانگر، اسان پڻ اميد رکون ٿا، پر توهان ان بابت ڇا ٿا سوچيو؟ تبصرن ۾ لکو
اسان سڀني کي دعوت ڏيون ٿا ته اسان جو دورو ڪريو جنهن ۾ اسان توهان کي ڪورس بابت تفصيل سان ٻڌائينداسين OTUS کان.
جو ذريعو: www.habr.com