วิธีเอาตัวรอดจากฐานข้อมูล SQL ในศตวรรษที่ 21: มัลติมาสเตอร์บนคลาวด์, Kubernetes และ PostgreSQL

สวัสดีชาว Khabrovsk ชั้นเรียนกลุ่มแรกของหลักสูตรเริ่มตั้งแต่วันนี้ "PostgreSQL". ในเรื่องนี้ เราอยากจะแจ้งให้คุณทราบว่าการสัมมนาผ่านเว็บแบบเปิดในหลักสูตรนี้เกิดขึ้นได้อย่างไร

В บทเรียนเปิดถัดไป เราได้พูดคุยเกี่ยวกับความท้าทายที่ฐานข้อมูล SQL เผชิญในยุคคลาวด์และ Kubernetes ในเวลาเดียวกัน เราได้พิจารณาว่าฐานข้อมูล SQL ปรับตัวและกลายพันธุ์อย่างไรภายใต้อิทธิพลของความท้าทายเหล่านี้

การสัมมนาผ่านเว็บถูกจัดขึ้น วาเลรี เบซรูคอฟ, Google Cloud Practice Delivery Manager ที่ EPAM Systems

เมื่อต้นไม้ยังเล็ก...

ก่อนอื่น เรามาจำไว้ว่าการเลือก DBMS เริ่มต้นอย่างไรเมื่อปลายศตวรรษที่ผ่านมา อย่างไรก็ตาม นี่คงไม่ใช่เรื่องยาก เพราะการเลือก DBMS ในสมัยนั้นเริ่มต้นและสิ้นสุด คำพยากรณ์.

ในช่วงปลายยุค 90 และต้นยุค 2 ไม่มีทางเลือกหลักเมื่อพูดถึงฐานข้อมูลที่ปรับขนาดได้ทางอุตสาหกรรม ใช่ มี IBM DBXNUMX, Sybase และฐานข้อมูลอื่น ๆ ที่มาและไป แต่โดยทั่วไปแล้ว พวกมันไม่ได้สังเกตเห็นได้ชัดเจนนักเมื่อเทียบกับพื้นหลังของ Oracle ดังนั้นทักษะของวิศวกรในสมัยนั้นจึงเชื่อมโยงกับทางเลือกเดียวที่มีอยู่

Oracle DBA ต้องสามารถ:

• ติดตั้ง Oracle Server จากชุดการแจกจ่าย
• กำหนดค่าเซิร์ฟเวอร์ Oracle:

• init.ora;
• Listener.ora;

- สร้าง:

• พื้นที่โต๊ะ;
• แผนงาน;
• ผู้ใช้;

— ทำการสำรองและกู้คืน;
— ดำเนินการติดตาม;
- จัดการกับคำขอที่ไม่เหมาะสม

ในขณะเดียวกัน Oracle DBA ก็ไม่มีข้อกำหนดพิเศษใดๆ:

• สามารถเลือก DBMS หรือเทคโนโลยีอื่น ๆ ที่เหมาะสมที่สุดสำหรับการจัดเก็บและประมวลผลข้อมูล
• ให้ความพร้อมใช้งานสูงและความสามารถในการขยายแนวนอน (นี่ไม่ใช่ปัญหา DBA เสมอไป)
• มีความรู้ที่ดีในสาขาวิชา โครงสร้างพื้นฐาน สถาปัตยกรรมแอปพลิเคชัน ระบบปฏิบัติการ
• โหลดและยกเลิกการโหลดข้อมูล ย้ายข้อมูลระหว่าง DBMS ที่แตกต่างกัน

โดยทั่วไปหากเราพูดถึงตัวเลือกในสมัยนั้นก็คล้ายกับตัวเลือกในร้านค้าโซเวียตในช่วงปลายยุค 80:

เวลาของเรา

แน่นอนว่าตั้งแต่นั้นเป็นต้นมา ต้นไม้ก็เติบโตขึ้น โลกก็เปลี่ยนไป และมันก็กลายเป็นแบบนี้:

ตลาด DBMS ก็เปลี่ยนไปเช่นกัน ดังที่เห็นได้ชัดเจนจากรายงานล่าสุดจาก Gartner:

และที่นี่ควรสังเกตว่าคลาวด์ซึ่งความนิยมเพิ่มขึ้นได้ครอบครองโพรงของพวกเขาแล้ว หากเราอ่านรายงานของ Gartner ฉบับเดียวกัน เราจะเห็นข้อสรุปดังต่อไปนี้:

1. ลูกค้าจำนวนมากอยู่บนเส้นทางสู่การย้ายแอปพลิเคชันไปยังระบบคลาวด์
2. เทคโนโลยีใหม่ๆ ปรากฏขึ้นครั้งแรกในระบบคลาวด์ และไม่ใช่ความจริงที่ว่าเทคโนโลยีเหล่านี้จะย้ายไปยังโครงสร้างพื้นฐานที่ไม่ใช่ระบบคลาวด์
3. รูปแบบการกำหนดราคาแบบจ่ายตามการใช้งานกลายเป็นเรื่องปกติไปแล้ว ทุกคนต้องการจ่ายเฉพาะสิ่งที่พวกเขาใช้และนี่ไม่ใช่เทรนด์ แต่เป็นเพียงการแสดงข้อเท็จจริง

อะไรตอนนี้?

วันนี้เราทุกคนอยู่ในคลาวด์ และคำถามที่เกิดขึ้นสำหรับเราคือคำถามที่ต้องเลือก และเป็นเรื่องใหญ่ แม้ว่าเราจะพูดถึงเฉพาะตัวเลือกเทคโนโลยี DBMS ในรูปแบบภายในองค์กรก็ตาม นอกจากนี้เรายังมีบริการการจัดการและ SaaS ดังนั้นการเลือกจึงยากขึ้นทุกปี

นอกจากคำถามที่ต้องเลือกแล้วยังมี ปัจจัยจำกัด:

• ราคา. เทคโนโลยีหลายอย่างยังคงต้องเสียค่าใช้จ่าย
• ทักษะ. หากเรากำลังพูดถึงซอฟต์แวร์เสรี คำถามเรื่องทักษะก็เกิดขึ้น เนื่องจากซอฟต์แวร์เสรีต้องการความสามารถเพียงพอจากผู้ที่ปรับใช้และดำเนินการ
• การทำงาน. บริการบางอย่างที่มีอยู่ในระบบคลาวด์และสร้างขึ้น แม้กระทั่งบน Postgres เดียวกัน ก็ยังมีคุณสมบัติเหมือนกับ Postgres On-premises นี่เป็นปัจจัยสำคัญที่ต้องทราบและทำความเข้าใจ นอกจากนี้ ปัจจัยนี้มีความสำคัญมากกว่าความรู้เกี่ยวกับความสามารถที่ซ่อนอยู่ของ DBMS เดียว

สิ่งที่คาดหวังจาก DA/DE ในตอนนี้:

• มีความเข้าใจในสาขาวิชาและสถาปัตยกรรมแอปพลิเคชันเป็นอย่างดี
• ความสามารถในการเลือกเทคโนโลยี DBMS ที่เหมาะสมอย่างถูกต้องโดยคำนึงถึงงานที่ทำอยู่
• ความสามารถในการเลือกวิธีการที่เหมาะสมที่สุดสำหรับการใช้เทคโนโลยีที่เลือกในบริบทของข้อ จำกัด ที่มีอยู่
• ความสามารถในการถ่ายโอนและโยกย้ายข้อมูล
• ความสามารถในการนำไปใช้และดำเนินการโซลูชั่นที่เลือก

ตัวอย่างด้านล่าง อิงตาม GCP แสดงให้เห็นว่าการเลือกเทคโนโลยีอย่างใดอย่างหนึ่งสำหรับการทำงานกับข้อมูลทำงานอย่างไรขึ้นอยู่กับโครงสร้างของมัน:

โปรดทราบว่า PostgreSQL ไม่รวมอยู่ในสคีมา และนี่เป็นเพราะมันซ่อนอยู่ภายใต้คำศัพท์เฉพาะ คลาวด์ SQL. และเมื่อเราไปถึง Cloud SQL เราจำเป็นต้องตัดสินใจอีกครั้ง:

ควรสังเกตว่าตัวเลือกนี้ไม่ชัดเจนเสมอไป ดังนั้นนักพัฒนาแอปพลิเคชันจึงมักถูกชี้นำโดยสัญชาตญาณ

รวม:

1. ยิ่งคุณไปไกลเท่าไร คำถามที่ต้องเลือกก็จะยิ่งกดดันมากขึ้นเท่านั้น และแม้ว่าคุณจะดูเฉพาะ GCP บริการที่มีการจัดการ และ SaaS การกล่าวถึง RDBMS บางส่วนจะปรากฏเฉพาะในขั้นตอนที่ 4 เท่านั้น (และมี Spanner อยู่ใกล้ๆ) นอกจากนี้ ตัวเลือกของ PostgreSQL จะปรากฏในขั้นตอนที่ 5 และถัดจากนั้นก็ยังมี MySQL และ SQL Server นั่นก็คือ มีทุกอย่างมากมายแต่คุณต้องเลือก.
2. เราต้องไม่ลืมเกี่ยวกับข้อจำกัดที่อยู่เบื้องหลังการล่อลวง โดยพื้นฐานแล้วใครๆ ก็อยากได้ประแจ แต่มันมีราคาแพง ด้วยเหตุนี้ คำขอทั่วไปจึงมีลักษณะดังนี้: “โปรดทำให้เราเป็น Spanner แต่สำหรับราคาของ Cloud SQL แล้ว คุณคือมืออาชีพ!”

เราควรทำอย่างไร?

โดยไม่อ้างว่าเป็นความจริงขั้นสูงสุด สมมติว่า:

เราจำเป็นต้องเปลี่ยนแนวทางการเรียนรู้ของเรา:

• ไม่มีประโยชน์ในการสอนแบบที่ DBA เคยสอนมาก่อน
• ความรู้เกี่ยวกับผลิตภัณฑ์เดียวไม่เพียงพออีกต่อไป
• แต่การรู้หลายสิบในระดับหนึ่งนั้นเป็นไปไม่ได้

คุณจำเป็นต้องรู้ไม่เพียงแต่และไม่ใช่จำนวนผลิตภัณฑ์เท่านั้น แต่ยังรวมถึง:

• กรณีการใช้งานแอปพลิเคชัน
• วิธีการปรับใช้ที่แตกต่างกัน
• ข้อดีและข้อเสียของแต่ละวิธี
• ผลิตภัณฑ์ที่คล้ายคลึงและเป็นทางเลือกเพื่อให้เป็นทางเลือกที่เหมาะสมและเหมาะสมที่สุด และไม่ได้สนับสนุนผลิตภัณฑ์ที่คุ้นเคยเสมอไป

คุณต้องสามารถย้ายข้อมูลและเข้าใจหลักการพื้นฐานของการรวมเข้ากับ ETL ได้

กรณีจริง

ในอดีตที่ผ่านมา มีความจำเป็นต้องสร้างแบ็กเอนด์สำหรับแอปพลิเคชันบนมือถือ เมื่อถึงเวลาเริ่มดำเนินการ แบ็กเอนด์ได้รับการพัฒนาแล้วและพร้อมสำหรับการใช้งาน และทีมพัฒนาใช้เวลาประมาณสองปีในโครงการนี้ งานต่อไปนี้ถูกตั้งค่า:

• สร้าง CI/ซีดี;
• ทบทวนสถาปัตยกรรม
• นำมันทั้งหมดไปใช้งาน

ตัวแอปพลิเคชันนั้นเป็นไมโครเซอร์วิส และโค้ด Python/Django ได้รับการพัฒนาตั้งแต่เริ่มต้นและใน GCP โดยตรง สำหรับกลุ่มเป้าหมาย สันนิษฐานว่าจะมีสองภูมิภาค - สหรัฐอเมริกาและสหภาพยุโรป และมีการกระจายการรับส่งข้อมูลผ่าน Global Load Balancer ภาระงานและภาระงานการประมวลผลทั้งหมดทำงานบน Google Kubernetes Engine

ในส่วนของข้อมูลมี 3 โครงสร้าง คือ

• การจัดเก็บเมฆ;
• พื้นที่เก็บข้อมูล;
• คลาวด์ SQL (PostgreSQL)

บางคนอาจสงสัยว่าทำไม Cloud SQL ถึงถูกเลือก? เพื่อบอกความจริง คำถามดังกล่าวทำให้เกิดการหยุดชะงักอย่างเชื่องช้าในช่วงไม่กี่ปีที่ผ่านมา - มีความรู้สึกว่าผู้คนเริ่มเขินอายกับฐานข้อมูลเชิงสัมพันธ์ แต่ถึงกระนั้นพวกเขาก็ยังคงใช้งานมันต่อไป ;-)

ในกรณีของเรา Cloud SQL ถูกเลือกด้วยเหตุผลดังต่อไปนี้:

1. ตามที่กล่าวไว้ แอปพลิเคชันได้รับการพัฒนาโดยใช้ Django และมีแบบจำลองสำหรับการแมปข้อมูลถาวรจากฐานข้อมูล SQL ไปยังอ็อบเจ็กต์ Python (Django ORM)
2. ตัวเฟรมเวิร์กเองก็รองรับรายการ DBMS ที่ค่อนข้างจำกัด:

• PostgreSQL;
• มาเรียดีบี ;
• มายเอสคิวแอล;
• ออราเคิล;
• SQLite

ดังนั้น PostgreSQL จึงถูกเลือกจากรายการนี้โดยสังหรณ์ใจ (จริงๆ แล้วไม่ใช่ Oracle ที่จะเลือก)

สิ่งที่หายไป:

• แอปพลิเคชันถูกปรับใช้ใน 2 ภูมิภาคเท่านั้น และแอปพลิเคชันที่ 3 ปรากฏในแผน (เอเชีย)
• ฐานข้อมูลตั้งอยู่ในภูมิภาคอเมริกาเหนือ (ไอโอวา);
• ในส่วนของลูกค้ามีความกังวลเกี่ยวกับความเป็นไปได้ การเข้าถึงล่าช้า จากยุโรปและเอเชียและ การหยุดชะงัก อยู่ในการให้บริการ ในกรณีที่มีการหยุดทำงานของ DBMS

แม้ว่า Django จะสามารถทำงานกับฐานข้อมูลหลาย ๆ แบบขนานและแบ่งออกเป็นการอ่านและการเขียนได้ แต่ก็มีการเขียนในแอปพลิเคชันไม่มากนัก (มากกว่า 90% กำลังอ่าน) และโดยทั่วไปและโดยทั่วไปหากสามารถทำได้ อ่านแบบจำลองของฐานหลักในยุโรปและเอเชียนี่จะเป็นวิธีแก้ปัญหาประนีประนอม แล้วมันมีอะไรซับซ้อนขนาดนั้นล่ะ?

ปัญหาคือลูกค้าไม่ต้องการเลิกใช้บริการที่ได้รับการจัดการและ Cloud SQL และความสามารถของ Cloud SQL ในปัจจุบันยังมีจำกัด Cloud SQL รองรับ High Availability (HA) และ Read Replica (RR) แต่ RR เดียวกันได้รับการรองรับในภูมิภาคเดียวเท่านั้น เมื่อสร้างฐานข้อมูลในภูมิภาคอเมริกาแล้ว คุณไม่สามารถสร้างแบบจำลองการอ่านในภูมิภาคยุโรปโดยใช้ Cloud SQL ได้ แม้ว่า Postgres เองจะไม่ได้ป้องกันคุณจากการทำเช่นนี้ก็ตาม การโต้ตอบกับพนักงานของ Google ไม่ได้ช่วยอะไรเลยและจบลงด้วยคำมั่นสัญญาในรูปแบบที่ว่า "เรารู้ปัญหาและกำลังดำเนินการอยู่ สักวันหนึ่งปัญหาจะได้รับการแก้ไข"

หากเราแสดงรายการความสามารถของ Cloud SQL สั้นๆ จะมีลักษณะดังนี้:

1. ความพร้อมใช้งานสูง (HA):

• ภายในภูมิภาคเดียว
• ผ่านการจำลองแบบดิสก์
• ไม่ได้ใช้เอ็นจิ้น PostgreSQL
• สามารถควบคุมอัตโนมัติและด้วยตนเองได้ - เฟลโอเวอร์/เฟลแบ็ค;
• เมื่อทำการสลับ DBMS จะไม่สามารถใช้งานได้เป็นเวลาหลายนาที

2. อ่านแบบจำลอง (RR):

• ภายในภูมิภาคเดียว
• สแตนด์บายร้อน
• การจำลองแบบสตรีมมิ่ง PostgreSQL

นอกจากนี้ตามธรรมเนียมแล้วเมื่อเลือกเทคโนโลยีคุณจะต้องเจอกับบางอย่างอยู่เสมอ ข้อ จำกัด:

• ลูกค้าไม่ต้องการสร้างเอนทิตีและใช้ IaaS ยกเว้นผ่าน GKE
• ลูกค้าไม่ต้องการปรับใช้ PostgreSQL/MySQL แบบบริการตนเอง
• โดยทั่วไปแล้ว Google Spanner ค่อนข้างเหมาะสมหากไม่ได้ราคา แต่ Django ORM ไม่สามารถใช้งานได้ แต่เป็นสิ่งที่ดี

เมื่อพิจารณาถึงสถานการณ์ ลูกค้าได้รับคำถามติดตามผล: “คุณสามารถทำสิ่งที่คล้ายกันเพื่อให้เหมือนกับ Google Spanner แต่ยังทำงานร่วมกับ Django ORM ได้หรือไม่”

ตัวเลือกโซลูชันหมายเลข 0

สิ่งแรกที่เข้ามาในใจ:

• อยู่ภายใน CloudSQL;
• จะไม่มีการจำลองแบบในตัวระหว่างภูมิภาคในรูปแบบใดๆ
• พยายามแนบแบบจำลองกับ Cloud SQL ที่มีอยู่โดย PostgreSQL
• เปิดตัวอินสแตนซ์ PostgreSQL ที่ไหนสักแห่ง แต่อย่างน้อยก็อย่าแตะต้องต้นแบบ

อนิจจาปรากฎว่าไม่สามารถทำได้เนื่องจากไม่มีการเข้าถึงโฮสต์ (อยู่ในโครงการอื่นโดยสิ้นเชิง) - pg_hba และอื่น ๆ และยังไม่มีการเข้าถึงภายใต้ superuser

ตัวเลือกโซลูชันหมายเลข 1

หลังจากการไตร่ตรองเพิ่มเติมและคำนึงถึงสถานการณ์ก่อนหน้านี้ แนวความคิดก็เปลี่ยนไปบ้าง:

• เรายังคงพยายามคงอยู่ภายใน CloudSQL แต่เรากำลังเปลี่ยนไปใช้ MySQL เนื่องจาก Cloud SQL โดย MySQL มีต้นแบบภายนอก ซึ่ง:

— เป็นพร็อกซีสำหรับ MySQL ภายนอก
- ดูเหมือนอินสแตนซ์ MySQL;
- คิดค้นขึ้นเพื่อการย้ายข้อมูลจากคลาวด์อื่นหรือภายในองค์กร

เนื่องจากการตั้งค่าการจำลองแบบ MySQL ไม่จำเป็นต้องเข้าถึงโฮสต์ โดยหลักการแล้วทุกอย่างทำงานได้ แต่ไม่เสถียรมากและไม่สะดวก และเมื่อเราไปไกลกว่านี้ มันก็น่ากลัวอย่างยิ่ง เพราะเราปรับใช้โครงสร้างทั้งหมดด้วย Terraform และทันใดนั้น ปรากฏว่าต้นแบบภายนอกไม่ได้รับการสนับสนุนจาก Terraform ใช่ Google มี CLI แต่ด้วยเหตุผลบางอย่าง ทุกอย่างทำงานอยู่ที่นี่บางครั้ง บางครั้งมันก็ถูกสร้างขึ้น บางครั้งก็ไม่ได้ถูกสร้างขึ้น อาจเป็นเพราะ CLI ได้รับการประดิษฐ์ขึ้นเพื่อการย้ายข้อมูลภายนอก ไม่ใช่สำหรับการจำลอง

จริงๆ แล้ว ณ จุดนี้เห็นได้ชัดว่า Cloud SQL ไม่เหมาะเลย อย่างที่พวกเขาพูดเราทำทุกสิ่งที่เราทำได้

ตัวเลือกโซลูชันหมายเลข 2

เนื่องจากเป็นไปไม่ได้ที่จะอยู่ภายในเฟรมเวิร์ก Cloud SQL เราจึงพยายามกำหนดข้อกำหนดสำหรับโซลูชันประนีประนอม ข้อกำหนดกลายเป็นดังต่อไปนี้:

• ทำงานใน Kubernetes การใช้ทรัพยากรและความสามารถสูงสุดของ Kubernetes (DCS, ... ) และ GCP (LB, ... );
• ขาดบัลลาสต์จากสิ่งที่ไม่จำเป็นจำนวนมากในคลาวด์เช่นพร็อกซี HA
• ความสามารถในการรัน PostgreSQL หรือ MySQL ในภูมิภาค HA หลัก ในภูมิภาคอื่น ๆ - HA จาก RR ของภูมิภาคหลักพร้อมสำเนา (เพื่อความน่าเชื่อถือ)
• หลายนาย (ฉันไม่ต้องการติดต่อเขา แต่มันไม่สำคัญมาก)

.
จากข้อเรียกร้องเหล่านี้หน้าDBMS และตัวเลือกการผูกที่เหมาะสม:

• MySQL กาเลรา;
• แมลงสาบDB;
• เครื่องมือ PostgreSQL

:
- pgpool-II;
— ปาโตรนี

MySQL กาเลรา

เทคโนโลยี MySQL Galera ได้รับการพัฒนาโดย Codership และเป็นปลั๊กอินสำหรับ InnoDB ลักษณะเฉพาะ:

• อาจารย์หลายคน;
• การจำลองแบบซิงโครนัส
• อ่านจากโหนดใด ๆ
• บันทึกไปยังโหนดใด ๆ
• กลไก HA ในตัว
• มีแผนภูมิ Helm จาก Bitnami

แมลงสาบ

ตามคำอธิบาย สิ่งนั้นระเบิดได้อย่างแน่นอนและเป็นโปรเจ็กต์โอเพ่นซอร์สที่เขียนด้วยภาษา Go ผู้เข้าร่วมหลักคือ Cockroach Labs (ก่อตั้งโดยผู้คนจาก Google) DBMS เชิงสัมพันธ์นี้เดิมทีได้รับการออกแบบมาให้มีการกระจาย (โดยมีมาตราส่วนแนวนอนนอกกรอบ) และทนทานต่อข้อผิดพลาด ผู้เขียนจากบริษัทได้สรุปเป้าหมายของ "การผสมผสานฟังก์ชันการทำงานของ SQL ที่หลากหลายเข้ากับการเข้าถึงแนวนอนที่คุ้นเคยกับโซลูชัน NoSQL"

โบนัสที่ดีคือการรองรับโปรโตคอลการเชื่อมต่อหลังความก้าวหน้า

เพจพูล

นี่คือส่วนเสริมของ PostgreSQL ซึ่งเป็นเอนทิตีใหม่ที่เข้าควบคุมการเชื่อมต่อทั้งหมดและประมวลผลการเชื่อมต่อเหล่านั้น มีโหลดบาลานเซอร์และพาร์เซอร์ของตัวเอง ซึ่งได้รับอนุญาตภายใต้ใบอนุญาต BSD มันให้โอกาสมากมาย แต่ก็ดูค่อนข้างน่ากลัวเนื่องจากการมีอยู่ของสิ่งใหม่อาจกลายเป็นที่มาของการผจญภัยเพิ่มเติมได้

ผู้มีพระคุณ

นี่เป็นสิ่งสุดท้ายที่ดวงตาของฉันจ้องมองและเมื่อมันปรากฏออกมาก็ไม่ไร้ประโยชน์ Patroni เป็นยูทิลิตี้โอเพ่นซอร์ส ซึ่งโดยพื้นฐานแล้วคือ Python daemon ที่ช่วยให้คุณรักษาคลัสเตอร์ PostgreSQL โดยอัตโนมัติด้วยการจำลองประเภทต่างๆ และการสลับบทบาทอัตโนมัติ สิ่งนี้กลายเป็นเรื่องที่น่าสนใจมาก เพราะมันเข้ากันได้ดีกับลูกบาศก์และไม่แนะนำเอนทิตีใหม่ใด ๆ

สุดท้ายคุณเลือกอะไร?

ทางเลือกไม่ใช่เรื่องง่าย:

1. แมลงสาบ - ไฟ แต่มืด
2. MySQL กาเลรา - ก็ไม่เลวเลยมันถูกใช้ในหลาย ๆ ที่ แต่เป็น MySQL
3. เพจพูล — มีเอนทิตีที่ไม่จำเป็นมากมาย การบูรณาการแบบพอดูได้กับคลาวด์และ K8
4. ผู้มีพระคุณ - การผสานรวมที่ยอดเยี่ยมกับ K8 โดยไม่มีเอนทิตีที่ไม่จำเป็น ผสานรวมกับ GCP LB ได้เป็นอย่างดี

ดังนั้นทางเลือกจึงตกเป็นของ Patroni

ผลการวิจัย

ถึงเวลาที่จะสรุปสั้น ๆ ใช่แล้ว โลกของโครงสร้างพื้นฐานด้านไอทีมีการเปลี่ยนแปลงไปอย่างมาก และนี่เป็นเพียงจุดเริ่มต้นเท่านั้น และหากเมื่อก่อนคลาวด์เป็นเพียงโครงสร้างพื้นฐานประเภทอื่น ตอนนี้ทุกอย่างก็แตกต่างออกไป นอกจากนี้ นวัตกรรมในระบบคลาวด์ยังปรากฏอยู่ตลอดเวลา จะปรากฏขึ้น และบางทีอาจปรากฏเฉพาะบนคลาวด์เท่านั้น และเมื่อนั้นด้วยความพยายามของสตาร์ทอัพเท่านั้นที่จะถูกถ่ายโอนไปยัง On-premises

สำหรับ SQL นั้น SQL จะใช้งานได้ ซึ่งหมายความว่าคุณจำเป็นต้องรู้ PostgreSQL และ MySQL และสามารถทำงานร่วมกับสิ่งเหล่านี้ได้ แต่ที่สำคัญกว่านั้นคือต้องสามารถใช้งานได้อย่างถูกต้อง

ที่มา: will.com