สวัสดี Khabrovites ตามเนื้อผ้า เรายังคงแบ่งปันเนื้อหาที่น่าสนใจในช่วงก่อนเริ่มหลักสูตรใหม่ วันนี้เราได้แปลบทความเกี่ยวกับ Google Cloud Spanner ให้คุณโดยเฉพาะ ซึ่งตรงกับการเปิดตัวหลักสูตร .
เผยแพร่ครั้งแรกใน .
ในฐานะบริษัทที่ให้บริการโซลูชั่น POS บนคลาวด์ที่หลากหลายสำหรับผู้ค้าปลีก ภัตตาคาร และผู้ค้าออนไลน์ทั่วโลก Lightspeed ใช้แพลตฟอร์มฐานข้อมูลหลายประเภทสำหรับกรณีการใช้งานธุรกรรม การวิเคราะห์ และการค้นหาที่หลากหลาย แต่ละแพลตฟอร์มฐานข้อมูลเหล่านี้มีจุดแข็งและจุดอ่อนของตัวเอง ดังนั้น เมื่อ Google เปิดตัว Cloud Spanner สู่ตลาด คุณลักษณะที่มีแนวโน้มว่าจะไม่มีให้เห็นในโลกของฐานข้อมูลเชิงสัมพันธ์ เช่น ความสามารถในการปรับขนาดในแนวนอนไม่จำกัดและข้อตกลงระดับบริการ (SLA) 99,999% เราไม่สามารถปล่อยให้โอกาสที่จะมีเธออยู่ในมือของเรา!
เพื่อให้ภาพรวมที่ครอบคลุมเกี่ยวกับประสบการณ์ของเรากับ Cloud Spanner รวมถึงเกณฑ์การประเมินที่เราใช้ เราจะครอบคลุมหัวข้อต่อไปนี้:
- เกณฑ์การประเมินของเรา
- Cloud Spanner สรุป
- การประเมินของเรา
- การค้นพบของเรา
1. เกณฑ์การประเมินของเรา
ก่อนที่จะลงลึกถึงรายละเอียดเฉพาะของ Cloud Spanner ความเหมือนและความแตกต่างของโซลูชันอื่นๆ ในตลาด ก่อนอื่นเรามาพูดถึงกรณีการใช้งานหลักที่เรานึกถึงเมื่อพิจารณาว่าจะใช้ Cloud Spanner ในโครงสร้างพื้นฐานของเราที่ใด:
- เป็นการแทนที่โซลูชันฐานข้อมูล SQL แบบดั้งเดิม (ที่มีอยู่ทั่วไป)
- เป็นโซลูชัน OLTP ที่เปิดใช้งาน OLAP
หมายเหตุ: เพื่อความสะดวกในการเปรียบเทียบ บทความนี้เปรียบเทียบ Cloud Spanner กับ MySQL ของตระกูลโซลูชัน GCP Cloud SQL และ Amazon AWS RDS
การใช้ Cloud Spanner แทนโซลูชันฐานข้อมูล SQL แบบเดิม
ในสภาพแวดล้อม เก่าแก่ ฐานข้อมูล เมื่อเวลาตอบสนองสำหรับการสืบค้นฐานข้อมูลเข้าใกล้หรือแม้กระทั่งเกินเกณฑ์แอปพลิเคชันที่กำหนดไว้ล่วงหน้า (สาเหตุหลักมาจากการเพิ่มขึ้นของจำนวนผู้ใช้และ/หรือคำขอ) มีหลายวิธีในการลดเวลาตอบสนองให้อยู่ในระดับที่ยอมรับได้ อย่างไรก็ตาม วิธีแก้ปัญหาเหล่านี้ส่วนใหญ่เกี่ยวข้องกับการแทรกแซงด้วยตนเอง
ตัวอย่างเช่น ขั้นตอนแรกที่ต้องทำคือการดูการตั้งค่าฐานข้อมูลที่เกี่ยวข้องกับประสิทธิภาพต่างๆ และปรับแต่งให้ตรงกับรูปแบบสถานการณ์การใช้งานแอปพลิเคชันมากที่สุด หากไม่เพียงพอ คุณสามารถเลือกปรับขนาดฐานข้อมูลในแนวตั้งหรือแนวนอนได้
การปรับขนาดแอปพลิเคชันทำให้เกิดการอัปเดตอินสแตนซ์ของเซิร์ฟเวอร์ โดยทั่วไปโดยการเพิ่มโปรเซสเซอร์/คอร์, RAM มากขึ้น, พื้นที่เก็บข้อมูลที่เร็วขึ้น ฯลฯ การเพิ่มทรัพยากรฮาร์ดแวร์มากขึ้นส่งผลให้ประสิทธิภาพของฐานข้อมูลเพิ่มขึ้น โดยวัดเป็นหลักในธุรกรรมต่อวินาที และเวลาแฝงของธุรกรรมสำหรับระบบ OLTP ระบบฐานข้อมูลเชิงสัมพันธ์ (ที่ใช้วิธีการแบบหลายเธรด) เช่น MySQL ปรับขนาดได้ดีในแนวตั้ง
มีข้อเสียหลายประการสำหรับแนวทางนี้ แต่สิ่งที่ชัดเจนที่สุดคือขนาดเซิร์ฟเวอร์สูงสุดในตลาด เมื่อถึงขีดจำกัดอินสแตนซ์เซิร์ฟเวอร์ที่ใหญ่ที่สุด จะเหลือเพียงเส้นทางเดียว: ขยายขนาดออก
Scale-out เป็นแนวทางที่เพิ่มเซิร์ฟเวอร์ให้กับคลัสเตอร์เพื่อเพิ่มประสิทธิภาพในเชิงเส้นตามอุดมคติเมื่อมีการเพิ่มเซิร์ฟเวอร์มากขึ้น ส่วนใหญ่ เก่าแก่ ระบบฐานข้อมูลปรับขนาดได้ไม่ดีหรือไม่ปรับขนาดเลย ตัวอย่างเช่น MySQL สามารถปรับขนาดสำหรับการอ่านโดยการเพิ่มตัวอ่านที่เป็นทาส แต่ไม่สามารถปรับขนาดสำหรับการเขียนได้
ในทางกลับกัน เนื่องจากธรรมชาติของ Cloud Spanner จึงสามารถปรับขนาดในแนวนอนได้อย่างง่ายดายโดยมีการแทรกแซงน้อยที่สุด
ฟีเจอร์ครบครัน DBMS เป็นบริการ จะต้องได้รับการประเมินจากมุมมองที่แตกต่างกัน โดยพื้นฐานแล้ว เราได้ใช้ DBMS ที่ได้รับความนิยมมากที่สุดในระบบคลาวด์ สำหรับ Google, GCP Cloud SQL และสำหรับ Amazon, AWS RDS ในการประเมินของเรา เรามุ่งเน้นไปที่หมวดหมู่ต่อไปนี้:
- การแมปคุณลักษณะ: ขอบเขต SQL, DDL, DML; ไลบรารีการเชื่อมต่อ/ตัวเชื่อมต่อ การสนับสนุนธุรกรรม และอื่นๆ
- การสนับสนุนการพัฒนา: ความง่ายในการพัฒนาและการทดสอบ
- การสนับสนุนการดูแลระบบ: การจัดการอินสแตนซ์ เช่น การปรับขนาดขึ้น/ลง และการอัปเกรดอินสแตนซ์ SLA การสำรองและการกู้คืน ความปลอดภัย / การควบคุมการเข้าถึง
การใช้ Cloud Spanner เป็นโซลูชัน OLTP ที่เปิดใช้งาน OLAP
แม้ว่า Google จะไม่ได้ระบุอย่างชัดเจนว่า Cloud Spanner มีไว้สำหรับการวิเคราะห์ แต่จะใช้แอตทริบิวต์บางอย่างร่วมกันกับเครื่องมืออื่นๆ เช่น Apache Impala & Kudu และ YugaByte ที่ออกแบบมาสำหรับปริมาณงาน OLAP
แม้ว่าจะมีโอกาสเพียงเล็กน้อยที่ Cloud Spanner จะรวมเอ็นจิ้น HTAP (การประมวลผลธุรกรรม/การวิเคราะห์แบบไฮบริด) ที่ปรับขนาดออกอย่างสม่ำเสมอพร้อมชุดคุณลักษณะ OLAP ที่ใช้งานได้ (มากหรือน้อย) เราคิดว่าสิ่งนี้ควรค่าแก่ความสนใจของเรา
ด้วยเหตุนี้ เราจึงพิจารณาหมวดหมู่ต่อไปนี้:
- รองรับการโหลดข้อมูล ดัชนี และการแบ่งพาร์ติชั่น
- ประสิทธิภาพการค้นหาและ DML
2. Cloud Spanner สรุป
Google Spanner เป็นระบบจัดการฐานข้อมูลเชิงสัมพันธ์แบบคลัสเตอร์ (RDBMS) ที่ Google ใช้สำหรับบริการต่างๆ ของตนเอง Google เผยแพร่ต่อสาธารณะสำหรับผู้ใช้ Google Cloud Platform ในต้นปี 2017
ต่อไปนี้คือแอตทริบิวต์ Cloud Spanner บางส่วน:
- คลัสเตอร์ RDBMS ที่ปรับขนาดได้และสอดคล้องกันสูง: ใช้การซิงโครไนซ์เวลาของฮาร์ดแวร์เพื่อให้แน่ใจว่าข้อมูลมีความสอดคล้องกัน
- รองรับธุรกรรมข้ามโต๊ะ: ธุรกรรมสามารถครอบคลุมหลายตาราง - ไม่จำเป็นต้องจำกัดเพียงตารางเดียว (ไม่เหมือนกับ Apache HBase หรือ Apache Kudu)
- ตารางที่ใช้คีย์หลัก: ตารางทั้งหมดต้องมีคีย์หลัก (PC) ที่ประกาศไว้ ซึ่งอาจประกอบด้วยคอลัมน์ตารางหลายคอลัมน์ ข้อมูลแบบตารางถูกจัดเก็บไว้ในลำดับของพีซี ซึ่งทำให้การค้นหาบนพีซีมีประสิทธิภาพและรวดเร็วมาก เช่นเดียวกับระบบที่ใช้พีซีอื่นๆ การดำเนินการต้องจำลองตามกรณีการใช้งานที่คาดคิดมาก่อนเพื่อให้บรรลุผลสำเร็จ .
- ตารางแบบแถบ: ตารางสามารถมีการอ้างอิงทางกายภาพซึ่งกันและกัน แถวของตารางรองสามารถจับคู่กับแถวของตารางหลักได้ แนวทางนี้ช่วยเพิ่มความเร็วในการค้นหาความสัมพันธ์ที่สามารถกำหนดได้ในขั้นตอนการสร้างแบบจำลองข้อมูล ตัวอย่างเช่น เมื่อรวมลูกค้าและใบแจ้งหนี้เข้าด้วยกัน
- ดัชนี: Cloud Spanner รองรับดัชนีรอง ดัชนีประกอบด้วยคอลัมน์ที่จัดทำดัชนีและคอลัมน์พีซีทั้งหมด ทางเลือก ดัชนียังสามารถมีคอลัมน์อื่นๆ ที่ไม่ได้จัดทำดัชนี ดัชนีสามารถแทรกสลับกับตารางหลักเพื่อเพิ่มความเร็วในการสืบค้น มีการใช้ข้อจำกัดหลายประการกับดัชนี เช่น จำนวนคอลัมน์เพิ่มเติมสูงสุดที่สามารถจัดเก็บไว้ในดัชนี นอกจากนี้ การสืบค้นผ่านดัชนีอาจไม่ตรงไปตรงมาเหมือนใน RDBMS อื่นๆ
“Cloud Spanner จะเลือกดัชนีโดยอัตโนมัติในกรณีที่หายากเท่านั้น โดยเฉพาะอย่างยิ่ง Cloud Spanner จะไม่เลือกดัชนีรองโดยอัตโนมัติหากการสืบค้นขอคอลัมน์ใดๆ ที่ไม่ได้จัดเก็บไว้ในนั้น '
- ข้อตกลงระดับการให้บริการ (SLA): การปรับใช้ภูมิภาคเดียวด้วย SLA 99,99%; การปรับใช้หลายภูมิภาคด้วย SLA 99,999% แม้ว่า SLA เองจะเป็นเพียงข้อตกลงและไม่ได้รับประกันใดๆ ทั้งสิ้น แต่ฉันเชื่อว่าคนของ Google มีข้อมูลบางอย่างที่ยากต่อการอ้างสิทธิ์ที่หนักแน่นเช่นนี้ (สำหรับการอ้างอิง 99,999% หมายถึงการหยุดให้บริการ 26,3 วินาทีต่อเดือน)
- เพิ่มเติมได้ที่:
หมายเหตุ: โครงการ Apache Tephra เพิ่มการรองรับธุรกรรมขั้นสูงให้กับ Apache HBase (ตอนนี้ยังใช้งานใน Apache Phoenix เป็นรุ่นเบต้า)
3. การประเมินของเรา
เราทุกคนได้อ่านคำชี้แจงของ Google เกี่ยวกับประโยชน์ของ Cloud Spanner - การปรับขนาดตามแนวนอนแทบไม่มีขีดจำกัด ในขณะที่ยังคงรักษาความสม่ำเสมอสูงและ SLA ที่สูงมาก แม้ว่าการอ้างสิทธิ์เหล่านี้เป็นเรื่องยากมากที่จะประสบความสำเร็จ แต่เป้าหมายของเราไม่ใช่การหักล้างพวกเขา ให้เน้นไปที่สิ่งอื่นๆ ที่ผู้ใช้ฐานข้อมูลส่วนใหญ่สนใจแทน: ความเท่าเทียมกันและความสามารถในการใช้งาน
เราให้คะแนน Cloud Spanner แทน Sharded MySQL
Google Cloud SQL และ Amazon AWS RDS สองฐานข้อมูล OLTP ที่ได้รับความนิยมสูงสุดในตลาดคลาวด์ มีชุดคุณลักษณะขนาดใหญ่มาก อย่างไรก็ตาม ในการปรับขนาดฐานข้อมูลเหล่านี้ให้เกินขนาดของโหนดเดียว คุณต้องทำการแยกแอปพลิเคชัน วิธีการนี้สร้างความซับซ้อนเพิ่มเติมสำหรับทั้งแอปพลิเคชันและการดูแลระบบ เรามาดูกันว่า Spanner เหมาะกับสถานการณ์ของการรวมชาร์ดหลายรายการไว้ในอินสแตนซ์เดียวอย่างไร และคุณสมบัติใด (ถ้ามี) ที่อาจต้องเสียสละ
รองรับ SQL, DML และ DDL รวมถึงตัวเชื่อมต่อและไลบรารีหรือไม่
ขั้นแรก เมื่อเริ่มต้นด้วยฐานข้อมูลใดๆ คุณต้องสร้างแบบจำลองข้อมูล หากคุณคิดว่าคุณสามารถเชื่อมต่อ JDBC Spanner กับเครื่องมือ SQL ที่คุณชื่นชอบได้ คุณจะพบว่าคุณสามารถสืบค้นข้อมูลของคุณได้ แต่คุณไม่สามารถใช้เพื่อสร้างตารางหรืออัปเดต (DDL) หรือการแทรก/อัปเดต/ลบใดๆ การดำเนินงาน (DML) JDBC อย่างเป็นทางการของ Google ไม่รองรับเช่นกัน
"ไดรเวอร์ไม่รองรับคำสั่ง DML หรือ DDL"
เอกสารประแจ
สถานการณ์ไม่ดีขึ้นด้วยคอนโซล GCP - คุณสามารถส่งได้เฉพาะข้อความค้นหา SELECT โชคดีที่มีไดรเวอร์ JDBC พร้อมรองรับ DML และ DDL จากชุมชนรวมถึงการทำธุรกรรม . แม้ว่าไดรเวอร์นี้จะมีประโยชน์อย่างมาก แต่การไม่มีไดรเวอร์ JDBC ของ Google เองก็น่าประหลาดใจ โชคดีที่ Google ให้การสนับสนุนไลบรารีไคลเอนต์ที่ค่อนข้างกว้าง (ขึ้นอยู่กับ gRPC): C#, Go, Java, node.js, PHP, Python และ Ruby
การใช้ API แบบกำหนดเองของ Cloud Spanner ที่เกือบจะเป็นข้อบังคับ (เนื่องจากไม่มี DDL และ DML ใน JDBC) ส่งผลให้เกิดข้อจำกัดบางประการสำหรับส่วนที่เกี่ยวข้องของโค้ด เช่น การรวมการเชื่อมต่อหรือเฟรมเวิร์กการผูกฐานข้อมูล (เช่น Spring MVC) โดยทั่วไป เมื่อใช้ JDBC คุณมีอิสระที่จะเลือกพูลการเชื่อมต่อที่คุณชื่นชอบ (เช่น HikariCP, DBCP, C3PO เป็นต้น) ซึ่งผ่านการทดสอบและใช้งานได้ดี ในกรณีของ API ของ Spanner แบบกำหนดเอง เราต้องใช้ frameworks/binding/session pools ที่เราสร้างขึ้นเอง
การออกแบบที่เน้นคีย์หลัก (PC) ช่วยให้ Cloud Spanner ทำงานได้รวดเร็วมากเมื่อเข้าถึงข้อมูลผ่านพีซี แต่ยังแนะนำปัญหาการสืบค้นบางอย่างอีกด้วย
- คุณไม่สามารถอัปเดตค่าของคีย์หลักได้ ก่อนอื่นคุณต้องลบรายการ PC เดิมและใส่ใหม่ด้วยค่าใหม่ (สิ่งนี้คล้ายกับโปรแกรมฐานข้อมูล/หน่วยเก็บข้อมูลที่เน้นพีซีอื่นๆ)
- คำสั่ง UPDATE และ DELETE ใดๆ จะต้องระบุพีซีใน WHERE ดังนั้นจึงไม่สามารถเว้นว่างคำสั่ง DELETE ทั้งหมดได้ - ต้องมีเคียวรีย่อยเสมอ ตัวอย่างเช่น UPDATE xxx WHERE id IN (SELECT id FROM table1)
- ไม่มีตัวเลือกการเพิ่มอัตโนมัติหรือสิ่งที่คล้ายกันซึ่งกำหนดลำดับสำหรับฟิลด์พีซี เพื่อให้ใช้งานได้ ต้องสร้างค่าที่สอดคล้องกันในฝั่งแอ็พพลิเคชัน
ดัชนีรอง?
Google Cloud Spanner รองรับดัชนีรองในตัว นี่เป็นคุณสมบัติที่ดีมากที่ไม่มีในเทคโนโลยีอื่นเสมอไป ขณะนี้ Apache Kudu ไม่รองรับดัชนีรองเลย และ Apache HBase ไม่รองรับดัชนีโดยตรง แต่สามารถเพิ่มผ่าน Apache Phoenix
ดัชนีใน Kudu และ HBase สามารถสร้างแบบจำลองเป็นตารางแยกต่างหากที่มีส่วนประกอบของคีย์หลักต่างกัน แต่การดำเนินการในระดับปรมาณูของการดำเนินการในตารางพาเรนต์และตารางดัชนีที่เกี่ยวข้องจะต้องดำเนินการในระดับแอปพลิเคชันและไม่ใช่เรื่องเล็กน้อยในการดำเนินการอย่างถูกต้อง
ตามที่กล่าวไว้ในการตรวจสอบ Cloud Spanner ดัชนีอาจแตกต่างจากดัชนี MySQL ดังนั้น ต้องใช้ความระมัดระวังเป็นพิเศษในการสร้างคิวรีและการทำโปรไฟล์เพื่อให้แน่ใจว่ามีการใช้ดัชนีที่ถูกต้องเมื่อจำเป็น
การเป็นตัวแทน?
วัตถุที่นิยมและมีประโยชน์ในฐานข้อมูลคือมุมมอง พวกมันมีประโยชน์สำหรับกรณีการใช้งานจำนวนมาก รายการโปรดสองรายการของฉันคือเลเยอร์นามธรรมเชิงตรรกะและเลเยอร์ความปลอดภัย ขออภัย Cloud Spanner ไม่รองรับการดู อย่างไรก็ตาม สิ่งนี้จำกัดเราเพียงบางส่วนเท่านั้น เนื่องจากไม่มีความละเอียดระดับคอลัมน์สำหรับสิทธิ์การเข้าถึง ซึ่งมุมมองสามารถเป็นวิธีแก้ปัญหาที่ยอมรับได้
ดูเอกสารประกอบของ Cloud Spanner สำหรับส่วนรายละเอียดโควต้าและขีดจำกัด () มีสิ่งหนึ่งที่อาจเป็นปัญหาได้สำหรับบางแอปพลิเคชัน: Cloud Spanner ที่แกะกล่องมีฐานข้อมูลสูงสุด 100 ฐานข้อมูลต่ออินสแตนซ์ เห็นได้ชัดว่านี่อาจเป็นอุปสรรค์สำคัญสำหรับฐานข้อมูลที่ออกแบบมาเพื่อปรับขนาดฐานข้อมูลมากกว่า 100 รายการ โชคดีที่หลังจากพูดคุยกับตัวแทนด้านเทคนิคของ Google แล้ว เราพบว่าขีดจำกัดนี้สามารถเพิ่มมูลค่าได้เกือบทุกค่าผ่านทางฝ่ายสนับสนุนของ Google
สนับสนุนการพัฒนา?
Cloud Spanner ให้การสนับสนุนภาษาโปรแกรมที่ค่อนข้างดีสำหรับการทำงานกับ API ไลบรารีที่รองรับอย่างเป็นทางการอยู่ในพื้นที่ของ C#, Go, Java, node.js, PHP, Python และ Ruby เอกสารมีรายละเอียดค่อนข้างมาก แต่เช่นเดียวกับเทคโนโลยีล้ำสมัยอื่นๆ ชุมชนมีขนาดเล็กมากเมื่อเทียบกับเทคโนโลยีฐานข้อมูลยอดนิยมส่วนใหญ่ ซึ่งอาจส่งผลให้ใช้เวลามากขึ้นกับกรณีการใช้งานหรือปัญหาทั่วไปที่น้อยลง
แล้วการสนับสนุนการพัฒนาท้องถิ่นล่ะ?
เราไม่พบวิธีสร้างอินสแตนซ์ Cloud Spanner ภายในองค์กร สิ่งที่ใกล้เคียงที่สุดที่เราได้รับคืออิมเมจนักเทียบท่า ซึ่งหลักการคล้ายกันแต่ปฏิบัติต่างกันมาก ตัวอย่างเช่น CockroachDB สามารถใช้ PostgreSQL JDBC เนื่องจากสภาพแวดล้อมการพัฒนาควรใกล้เคียงกับสภาพแวดล้อมการใช้งานจริงมากที่สุด Cloud Spanner จึงไม่เหมาะเนื่องจากคุณต้องพึ่งพาอินสแตนซ์ Spanner แบบเต็ม เพื่อประหยัดค่าใช้จ่าย คุณสามารถเลือกอินสแตนซ์ภูมิภาคเดียวได้
สนับสนุนการบริหาร?
การสร้างอินสแตนซ์ Cloud Spanner ทำได้ง่ายมาก คุณเพียงแค่ต้องเลือกระหว่างการสร้างอินสแตนซ์แบบหลายภูมิภาคหรือแบบภูมิภาคเดียว ระบุภูมิภาคและจำนวนโหนด ในเวลาน้อยกว่าหนึ่งนาที อินสแตนซ์จะเริ่มทำงาน
มีเมตริกเบื้องต้นหลายรายการในหน้า Spanner ใน Google Console โดยตรง มีมุมมองที่ละเอียดมากขึ้นผ่าน Stackdriver ซึ่งคุณสามารถตั้งค่าเกณฑ์เมตริกและนโยบายการแจ้งเตือนได้ด้วย
เข้าถึงแหล่งข้อมูล?
MySQL ให้การตั้งค่าสิทธิ์/บทบาทของผู้ใช้ที่กว้างขวางและละเอียดมาก คุณสามารถปรับแต่งการเข้าถึงตารางใดตารางหนึ่ง หรือแม้แต่เพียงส่วนย่อยของคอลัมน์ได้อย่างง่ายดาย Cloud Spanner ใช้เครื่องมือ Google Identity & Access Management (IAM) ซึ่งอนุญาตให้คุณกำหนดนโยบายและสิทธิ์ในระดับที่สูงมากเท่านั้น ตัวเลือกที่ละเอียดที่สุดคือสิทธิ์ระดับฐานข้อมูล ซึ่งไม่เหมาะกับกรณีการผลิตส่วนใหญ่ ข้อจำกัดนี้บังคับให้คุณเพิ่มมาตรการรักษาความปลอดภัยเพิ่มเติมให้กับโค้ด โครงสร้างพื้นฐาน หรือทั้งสองอย่างเพื่อป้องกันการใช้ทรัพยากร Spanner โดยไม่ได้รับอนุญาต
สำรองข้อมูล?
พูดง่ายๆ คือไม่มีการสำรองข้อมูลใน Cloud Spanner แม้ว่าข้อกำหนด SLA ระดับสูงของ Google จะรับประกันได้ว่าข้อมูลของคุณจะไม่สูญหายเนื่องจากความล้มเหลวของฮาร์ดแวร์หรือฐานข้อมูล ข้อผิดพลาดของมนุษย์ ข้อบกพร่องของแอปพลิเคชัน ฯลฯ เราทุกคนทราบกฎนี้: ความพร้อมใช้งานสูงไม่สามารถทดแทนกลยุทธ์การสำรองข้อมูลอัจฉริยะได้ ในปัจจุบัน วิธีเดียวในการสำรองข้อมูลคือการสตรีมทางโปรแกรมจากฐานข้อมูลไปยังสภาพแวดล้อมการจัดเก็บข้อมูลแยกต่างหาก
ประสิทธิภาพของแบบสอบถาม?
เราใช้ Yahoo! เพื่อโหลดข้อมูลและทดสอบข้อความค้นหา เกณฑ์มาตรฐานการให้บริการคลาวด์ ตารางด้านล่างแสดงเวิร์กโหลด B YCSB ที่มีอัตราส่วนการอ่าน 95% ต่อการเขียน 5%
* การทดสอบโหลดดำเนินการบน n1-standard-32 Compute Engine (CE) (32 vCPU, หน่วยความจำ 120 GB) และอินสแตนซ์ทดสอบไม่เคยเป็นปัญหาคอขวดในการทดสอบ
** จำนวนเธรดสูงสุดในอินสแตนซ์ YCSB หนึ่งรายการคือ 400 โดยรวมแล้ว การทดสอบ YCSB แบบขนานทั้งหมด 2400 อินสแตนซ์ต้องเรียกใช้เพื่อให้ได้เธรดทั้งหมด XNUMX รายการ
เมื่อพิจารณาจากผลการวัดประสิทธิภาพ โดยเฉพาะอย่างยิ่งการรวมกันของโหลด CPU และ TPS เราจะเห็นได้อย่างชัดเจนว่า Cloud Spanner ปรับขนาดได้ค่อนข้างดี การโหลดขนาดใหญ่ที่สร้างโดยเธรดจำนวนมากจะถูกชดเชยด้วยโหนดจำนวนมากในคลัสเตอร์ Cloud Spanner แม้ว่าเวลาแฝงจะดูค่อนข้างสูง โดยเฉพาะอย่างยิ่งเมื่อรันที่ 2400 เธรด แต่อาจจำเป็นต้องทดสอบซ้ำกับ 6 อินสแตนซ์ที่เล็กกว่าของเครื่องมือคำนวณเพื่อให้ได้ตัวเลขที่แม่นยำยิ่งขึ้น แต่ละอินสแตนซ์จะเรียกใช้การทดสอบ YCSB หนึ่งรายการแทนอินสแตนซ์ CE ขนาดใหญ่หนึ่งรายการที่มีการทดสอบคู่ขนานกัน 6 รายการ ซึ่งช่วยให้แยกความแตกต่างระหว่างความล่าช้าของคำขอ Cloud Spanner และความล่าช้าที่เพิ่มโดยการเชื่อมต่อเครือข่ายระหว่าง Cloud Spanner และอินสแตนซ์ CE ที่เรียกใช้การทดสอบได้ง่ายขึ้น
Cloud Spanner ทำหน้าที่เป็น OLAP อย่างไร
การแบ่งพาร์ติชัน?
การแบ่งข้อมูลออกเป็นส่วนทางกายภาพและ/หรืออิสระทางตรรกะ เรียกว่า พาร์ติชัน เป็นแนวคิดที่ได้รับความนิยมอย่างมากซึ่งพบได้ในเครื่องมือ OLAP ส่วนใหญ่ พาร์ติชันสามารถปรับปรุงประสิทธิภาพการสืบค้นและการบำรุงรักษาฐานข้อมูลได้อย่างมาก การเจาะลึกเพิ่มเติมเกี่ยวกับการแบ่งพาร์ติชันจะเป็นบทความแยกต่างหาก ดังนั้นเราจะพูดถึงความสำคัญของการมีรูปแบบการแบ่งพาร์ติชันและการแบ่งพาร์ติชันย่อย ความสามารถในการแยกข้อมูลออกเป็นพาร์ติชันและยิ่งเป็นพาร์ติชันย่อยเป็นกุญแจสำคัญในประสิทธิภาพของการค้นหาเชิงวิเคราะห์
Cloud Spanner ไม่รองรับพาร์ติชันต่อตัว โดยจะแยกข้อมูลภายในออกเป็นที่เรียกว่า แยก-s ขึ้นอยู่กับช่วงคีย์หลัก การแบ่งพาร์ติชันจะทำโดยอัตโนมัติเพื่อให้โหลดบนคลัสเตอร์ Cloud Spanner สมดุล คุณลักษณะที่มีประโยชน์มากของ Cloud Spanner คือการแบ่งโหลดฐานของตารางพาเรนต์ (ตารางที่ไม่ได้แทรกซ้อนกับตารางอื่น) ประแจจะตรวจหาโดยอัตโนมัติหากมี แยก ข้อมูลที่อ่านบ่อยกว่าข้อมูลในส่วนอื่นๆ แยก-อา และอาจตัดสินใจแยกทางกันต่อไป ดังนั้น โหนดจำนวนมากขึ้นสามารถมีส่วนร่วมในคำขอ ซึ่งจะเพิ่มปริมาณงานได้อย่างมีประสิทธิภาพ
กำลังโหลดข้อมูล?
วิธี Cloud Spanner สำหรับข้อมูลจำนวนมากจะเหมือนกับการอัปโหลดปกติ เพื่อให้ได้ประสิทธิภาพสูงสุด คุณต้องปฏิบัติตามหลักเกณฑ์บางประการ ได้แก่:
- จัดเรียงข้อมูลของคุณตามคีย์หลัก
- หารด้วย 10*จำนวนโหนด แต่ละส่วน
- สร้างชุดงานของผู้ปฏิบัติงานที่โหลดข้อมูลพร้อมกัน
การโหลดข้อมูลนี้ใช้โหนด Cloud Spanner ทั้งหมด
เราใช้เวิร์กโหลด A YCSB เพื่อสร้างชุดข้อมูล 10M แถว
* การทดสอบโหลดดำเนินการบนกลไกประมวลผล n1-standard-32 (32 vCPU, หน่วยความจำ 120 GB) และอินสแตนซ์ทดสอบไม่เคยเป็นปัญหาคอขวดในการทดสอบ
** ไม่แนะนำให้ตั้งค่า 1 โหนดสำหรับปริมาณงานการผลิตใดๆ
ตามที่กล่าวไว้ข้างต้น Cloud Spanner ประมวลผลการแยกโดยอัตโนมัติตามโหลด ดังนั้นผลลัพธ์จะดีขึ้นหลังจากการทดสอบซ้ำติดต่อกันหลายครั้ง ผลลัพธ์ที่นำเสนอนี้เป็นผลลัพธ์ที่ดีที่สุดที่เราได้รับ เมื่อดูตัวเลขด้านบน เราจะเห็นว่า Cloud Spanner ปรับขนาด (เช่นกัน) เมื่อจำนวนโหนดในคลัสเตอร์เพิ่มขึ้นอย่างไร ตัวเลขที่โดดเด่นคือเวลาแฝงเฉลี่ยที่ต่ำมาก ซึ่งแตกต่างจากผลลัพธ์จากปริมาณงานแบบผสม (อ่าน 95% และเขียน 5%) ตามที่อธิบายไว้ในส่วนด้านบน
ขูดหินปูน?
การเพิ่มและลดจำนวนของโหนด Cloud Spanner นั้นทำได้เพียงคลิกเดียว หากคุณต้องการโหลดข้อมูลอย่างรวดเร็ว คุณอาจต้องพิจารณาการบูสต์อินสแตนซ์ให้สูงสุด (ในกรณีของเราคือ 25 โหนดในภูมิภาคสหรัฐอเมริกา-ตะวันออก) แล้วจึงลดจำนวนโหนดที่เหมาะสมสำหรับการโหลดปกติของคุณหลังจากข้อมูลทั้งหมด ในฐานข้อมูล โดยคำนึงถึงขีดจำกัด 2 TB/โหนด
เราได้รับการเตือนถึงขีดจำกัดนี้แม้ว่าจะมีฐานข้อมูลที่เล็กกว่ามากก็ตาม หลังจากรันการทดสอบโหลดหลายครั้ง ฐานข้อมูลของเรามีขนาดประมาณ 155 GB และเมื่อลดขนาดลงเป็นอินสแตนซ์ 1 โหนด เราพบข้อผิดพลาดต่อไปนี้:
เราสามารถลดขนาดจาก 25 เหลือ 2 อินสแตนซ์ แต่เราติดอยู่ที่โหนดสองโหนด
การเพิ่มและลดจำนวนโหนดในคลัสเตอร์ Cloud Spanner สามารถทำได้โดยอัตโนมัติโดยใช้ REST API สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับการลดภาระที่เพิ่มขึ้นในระบบในช่วงเวลาที่มีงานยุ่ง
ประสิทธิภาพของแบบสอบถาม OLAP?
เดิมทีเราวางแผนที่จะอุทิศเวลามากในการประเมิน Spanner ในส่วนนี้ หลังจาก SELECT COUNTs ไม่กี่ครั้ง เราก็รู้ทันทีว่าการทดสอบจะสั้นและ Spanner จะไม่เป็นเครื่องมือที่เหมาะสมสำหรับ 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 , สไลด์ 42 และ 43 ตัวเลขเหล่านี้สอดคล้องกับผลลัพธ์ของเราเอง (ขออภัย)
4. การค้นพบของเรา
จากสถานะปัจจุบันของคุณลักษณะของ Cloud Spanner จึงยากที่จะมองว่าเป็นการแทนที่โซลูชัน OLTP ที่มีอยู่อย่างง่าย โดยเฉพาะอย่างยิ่งเมื่อความต้องการของคุณเติบโตเร็วกว่านั้น จะต้องใช้เวลาจำนวนมากในการสร้างโซลูชันสำหรับข้อบกพร่องของ Cloud Spanner
เมื่อเราเริ่มประเมิน Cloud Spanner เราคาดหวังว่าฟีเจอร์การจัดการจะเทียบเท่าหรืออย่างน้อยก็ไม่ไกลจากโซลูชัน Google SQL อื่นๆ แต่เรารู้สึกประหลาดใจที่ไม่มีการสำรองข้อมูลอย่างสมบูรณ์และการควบคุมการเข้าถึงทรัพยากรที่จำกัดมาก ไม่ต้องพูดถึงว่าไม่มีมุมมอง ไม่มีสภาพแวดล้อมการพัฒนาแบบโลคัล ลำดับที่ไม่รองรับ JDBC ที่ไม่รองรับ DML และ DDL และอื่นๆ
จะไปที่ไหนสำหรับคนที่ต้องการปรับขนาดฐานข้อมูลการทำธุรกรรม? ดูเหมือนจะไม่มีโซลูชันเดียวในตลาดที่เหมาะกับทุกกรณีการใช้งาน มีโซลูชันแบบโอเพ่นซอร์สแบบปิดและแบบเปิดจำนวนมาก (ซึ่งบางส่วนจะกล่าวถึงในบทความนี้) ซึ่งแต่ละแบบก็มีจุดแข็งและจุดอ่อนของตัวเอง แต่ไม่มีโซลูชันใดเสนอ SaaS ที่มี SLA 99,999% และความสม่ำเสมอในระดับสูง หาก SLA สูงเป็นเป้าหมายหลักของคุณ และคุณไม่ต้องการสร้างโซลูชันของคุณเองสำหรับระบบคลาวด์หลายระบบ Cloud Spanner อาจเป็นโซลูชันที่คุณต้องการ แต่คุณควรตระหนักถึงข้อจำกัดทั้งหมดของมัน
พูดตามตรง Cloud Spanner เปิดตัวสู่สาธารณะในฤดูใบไม้ผลิปี 2017 เท่านั้น ดังนั้นจึงสมเหตุสมผลที่จะคาดหวังว่าข้อบกพร่องบางอย่างในปัจจุบันอาจหายไปในที่สุด (หวังว่า) และเมื่อเป็นเช่นนั้น ก็อาจเป็นตัวเปลี่ยนเกมได้ ท้ายที่สุด Cloud Spanner ไม่ใช่แค่โครงการเสริมสำหรับ Google Google ใช้เป็นพื้นฐานสำหรับผลิตภัณฑ์อื่นๆ ของ Google และเมื่อ Google เพิ่งแทนที่ Megastore ใน Google Cloud Storage ด้วย Cloud Spanner มันทำให้ Google Cloud Storage มีความสอดคล้องกันอย่างมากสำหรับรายการวัตถุในระดับโลก (ซึ่งยังไม่เป็นเช่นนั้น ).
ดังนั้นยังมีความหวัง ... เราหวังว่า
นั่นคือทั้งหมด เช่นเดียวกับผู้เขียนบทความ เรายังหวังต่อไป แต่คุณคิดอย่างไรเกี่ยวกับเรื่องนี้ เขียนในความคิดเห็น
ขอเชิญทุกท่านมาเยี่ยมชม ซึ่งเราจะบอกรายละเอียดเกี่ยวกับหลักสูตรให้คุณทราบ จาก OTUS
ที่มา: will.com