ความท้าทาย
ฉันทราบว่ามีวิธีปฏิบัติเช่นเพิ่มเฉพาะวัตถุฐานข้อมูลเช่นตารางและคอลัมน์ไม่เคยแก้ไขหรือลบออก
ที่ บริษัท หนึ่งที่ฉันทำงานอยู่หน้าต่างของข้อมูลดิบที่มีค่าเท่ากับประมาณ 6 เดือนและกิน 10 TB จากนั้นข้อมูลจะถูกประมวลผลในรูปแบบ RDBMS ซึ่งมีค่าใช้จ่ายข้อมูลที่สามารถใช้งานได้ 6 TB ซึ่งคิดเป็นข้อมูลประมาณ 10 ปี ประเด็นก็คือในระดับการปฏิบัติประเภทนี้ก็ไม่ได้เกิดขึ้นจริง การจัดเก็บมีราคาแพง - อาจเป็นค่าใช้จ่ายในการคำนวณที่ยิ่งใหญ่ที่สุด นี่เป็นความท้าทายที่น่าสนใจหลายประการ:
- การสำรองข้อมูล - ปลั๊กอิน innodb นั้นยอดเยี่ยมและทั้งหมด แต่เวลาในการสำรองข้อมูลบนข้อมูลจำนวนมากนั้นไม่สามารถนำไปใช้ได้จริง
- คืนเวลา - สำหรับชุดข้อมูลขนาดใหญ่ - โดยเฉพาะอย่างยิ่งถ้าคุณต้องการการจำลองแบบให้ทันหลังจากการคืนค่ากลับสู่สถานะการดำเนินการอาจใช้เวลาหลายวันหรือหลายสัปดาห์
- การสร้าง / การสร้างอินสแตนซ์ใหม่ - บ่อยครั้งที่งานที่คุณอาจทำในการพัฒนา / ทดสอบเกี่ยวข้องกับงาน ETL (แยก, แปลงและโหลด) บนชุดข้อมูลของคุณ ต้องมีการตรวจสอบความถูกต้องโดยใช้หน่วยทดสอบ QA แต่ต้องทำในลักษณะที่ไม่ทำลายเพื่อให้ชุดข้อมูลการผลิตดั้งเดิมถูกเก็บรักษาไว้ ในขณะที่เกิดภัยพิบัติคุณอาจยินดีที่จะจัดการกับเวลาในการเรียกคืนที่ยาวนานในการทำความเข้าใจว่าการสำรองข้อมูลเป็นนโยบายการประกันและความตั้งใจคือการหลีกเลี่ยงพวกเขาเวิร์กโฟลว์การพัฒนา DevOps ต้องการให้คุณสามารถทำการกู้คืนหรือ สำเนาข้อมูลของคุณเป็นประจำ (อาจวันละหลายครั้ง)
- ความจุ - การวนรอบข้อมูลจำนวนมากในระดับที่ฉันเพิ่งอธิบายนั้นอาจเป็น I / O อย่างเข้มข้น ไม่เพียงคุณต้องจัดการกับปัญหาที่อธิบายไว้ในข้อ 1-3 แต่คุณต้องทำในลักษณะที่ไม่ทำให้ระบบขัดข้องหรือประสิทธิภาพการทำงานช้าลงสำหรับระบบการผลิตของคุณ
ในขณะที่ข้อพิจารณาข้างต้นอาจไม่เกี่ยวข้องกับเครื่องชั่งขนาดเล็ก แต่เครื่องชั่งที่มีขนาดใหญ่ แต่ปัญหาเหล่านี้กลายเป็นปัญหาใหญ่ ซึ่งหมายความว่าเป็นสิ่งสำคัญอย่างยิ่งที่คุณต้องกำหนดความต้องการของคุณและคาดการณ์ขนาดของชุดข้อมูลของคุณ
การกำหนดข้อกำหนด
ดังนั้นคุณต้องกำหนดข้อกำหนดหลายประการ:
- RTO - RTO หรือ Restore Time Objective สำหรับการสำรองข้อมูลเป็นหนึ่งในไดรเวอร์ที่สำคัญที่สุดของโซลูชันการสำรองฐานข้อมูล ในขณะที่ในตอนแรกมันอาจจะไม่เกี่ยวข้องกับปัญหาอื่น ๆ ส่วนใหญ่มันจะมีความเกี่ยวข้องอย่างมากเมื่อคุณถามว่า "จะเกิดอะไรขึ้นถ้าฉันใช้โซลูชันสำรองของฉันสำหรับการสร้างหรือสร้างอินสแตนซ์ใหม่?" ฉันจะครอบคลุมเทคนิคบางอย่างสำหรับการทำเช่นนั้นในส่วนถัดไป
- RPO - RPO หรือจุดคืนค่าจุดประสงค์สำหรับการสำรองข้อมูลกำหนด A) ไกลแค่ไหนที่คุณสามารถกู้คืน (นาที, ชั่วโมง, วัน, สัปดาห์, เดือนหรือปี) B) ช่วงเวลาการสำรองข้อมูลที่ระดับที่แตกต่างกันและ C) . ตัวอย่างเช่นสำหรับฐานข้อมูลอีเมลการสำรองข้อมูลระดับข้อความ - การกู้คืนอีเมลที่เฉพาะเจาะจง - มักจะหา ในทำนองเดียวกันคุณอาจพบว่าข้อมูลในช่วงสองสามวันนั้นไร้ประโยชน์อย่างสมบูรณ์ - ดังนั้นจึงไม่มีจุดคืนค่าปี
- ขนาดของชุดข้อมูลของคุณ - นี่เป็นสิ่งสำคัญเพราะสำหรับฐานข้อมูล 1MB RTO ของคุณอาจประสบความสำเร็จได้ด้วยผลิตภัณฑ์สำรองและโซลูชันส่วนใหญ่ สำหรับฐานข้อมูล 10TB คุณจะพบว่าการสำรองข้อมูลระดับแถวเต็มไปยังเทป LTO 3 อาจไม่สามารถบรรลุ RTO ของคุณและอาจรบกวน RPO ของคุณเนื่องจากการสำรองข้อมูลเริ่มเกินกว่าหน้าต่างสำรองของคุณ คุณไม่สามารถทำ mysqldump กับชุดข้อมูลขนาดใหญ่นี้ได้อย่างแน่นอน แต่อาจจะไปกับฐานข้อมูล 1MB ได้
- ความสอดคล้องของฐานข้อมูล - สิ่งสุดท้ายที่สร้างความแตกต่างอย่างมากในการปรับใช้อย่างต่อเนื่องความน่าเชื่อถือของไซต์การปรับขนาดและความพร้อมใช้งานสูงเมื่อทำงานกับฐานข้อมูลคือความต้องการของคุณ มีสามประเภทพื้นฐาน: ความสอดคล้องทันทีความสอดคล้อง Just-In-Time (JIT) และความมั่นคงในที่สุด
นอกเหนือจากข้อควรพิจารณาที่สำคัญข้างต้นคุณยังต้องพิจารณาข้อกำหนดเกี่ยวกับสิทธิ์ใช้งานและการสนับสนุน (โอเพ่นซอร์สหรือแหล่งข้อมูลปิดการสนับสนุนในบ้านการสนับสนุนจากบุคคลที่สามหรือการสนับสนุนผู้ขาย) ข้อกำหนดของแอปพลิเคชัน / ภาษา แอปของคุณรวบรวมหรือไม่คุณมีสิทธิ์เข้าถึงซอร์สโค้ดหรือไม่คุณสามารถคอมไพล์ใหม่หรือให้ผู้ขายได้หรือไม่หรือใช้กับภาษาที่ตีความหรือไม่) ข้อกำหนดทางการเมือง (องค์กรของคุณเชื่อถือ Oracle เท่านั้นหรือไม่พวกเขาเกลียด Oracle ? พวกเขาไม่เชื่อถือ MySql คุณรู้สึกอย่างไรเกี่ยวกับ MariaDB หรือ Postgres?) และเอ็นจิ้นฐานข้อมูล (innoDB? MyISAM? Blackhole? NDB Cluster Spider?) และข้อกำหนดด้านประวัติศาสตร์หรือความเข้ากันได้ (เราใช้ PL / SQL มานานครึ่งปี สร้างขึ้นในเครื่องยนต์ oracle! เราจะส่งต่อไปยัง MariaDB ได้อย่างไร!?)
ทุกสิ่งเหล่านี้ (อย่างมีนัยสำคัญ) ส่งผลกระทบต่อเครื่องมือที่มีให้สำหรับคุณ
ตัวเลือกบางอย่างสำหรับการจัดการข้อมูลภายใน
หมายเหตุ: ข้อมูลต่อไปนี้จะไม่ครบถ้วนสมบูรณ์และผู้ใช้ SE อื่น ๆ ควรพูดสอดด้วยคำแนะนำเพิ่มเติม
ด้วยการพิจารณาโดยทั่วไปให้ฉันใช้เทคนิคและเทคโนโลยีบางอย่างสำหรับการพูดถึงข้างต้น ก่อนอื่นให้ถามตัวคุณเองว่าคุณจำเป็นต้องใช้ RDBMS จริง ๆ หรือไม่หรือข้อมูลที่ไม่มีโครงสร้างกับ Hadoop, CouchDB หรือแม้แต่ Object Oriented Storage (อย่างรวดเร็ว) เป็นตัวเลือก
ประการที่สองพิจารณาการค้นหาโซลูชันที่ใช้ระบบคลาวด์ สิ่งนี้ทำให้บางคนปวดหัวและส่งมอบปัญหาที่ซับซ้อนให้กับบุคคลที่มีคุณสมบัติสูง (และมีค่าใช้จ่าย) อย่างไรก็ตามในระดับคุณจะพบว่าสิ่งนี้กินเข้าไปในงบประมาณของคุณ (ผู้ให้บริการคลาวด์ทำกำไรได้ในระดับนี้และในระดับหนึ่งคุณสามารถที่จะจ้างผู้เชี่ยวชาญเหล่านี้ได้ด้วยตนเอง) หรือหากคุณทำงานภายใต้ความปลอดภัยหรือการเมือง ข้อกำหนด (อ่าน: เราไม่สามารถทำคลาวด์ได้) ให้พิจารณา NFS / FibreChannel Filer แบบผสม ไฟล์เหล่านี้ส่วนใหญ่เช่น NetApp, Pure Storage และ Tegile สนับสนุนเทคนิคการจับภาพและการโคลนตามเดลต้าซึ่งมีประโยชน์มากสำหรับ A) การสำรองข้อมูล, B) การกู้คืนการสำรองข้อมูลและ C) การสร้างการสำรองข้อมูลใหม่
ณ จุดนี้ฉันต้องทราบว่าฉันไม่ใช่ผู้เชี่ยวชาญด้านการสำรองและจัดเก็บข้อมูลดังนั้นจึงมีบางส่วนของปัญหานี้ที่ฉันไม่สามารถแก้ไขได้ก่อนที่จะย้ายไปยังปัญหาอื่น ๆ (และทุ่งหญ้าสีเขียว)
แต่ที่ถูกกล่าวว่าผลิตภัณฑ์เหล่านี้ช่วยให้คุณสามารถถ่ายภาพที่แตกต่างกันภายใต้ฐานข้อมูลของคุณ คุณจะต้องสคริปต์ "ตารางล็อคพร้อมล็อคการอ่าน" อย่างเต็มรูปแบบบนหนึ่งในอินสแตนซ์ฐานข้อมูลของคุณ (แนะนำให้ใช้แบบอ่านอย่างเดียว) และทิ้งตำแหน่ง binlog หรือ GTID ของคุณ แต่สำหรับไฟล์เหล่านี้เมื่อคุณทำแล้วคุณจะสามารถ เพื่อใช้ snaps เหล่านี้เพื่อสร้างอินสแตนซ์ใหม่ของฐานข้อมูลของคุณ คุณจะต้องวาง binlogs ในพาร์ติชันแยกต่างหากและใส่เฉพาะข้อมูลฐานข้อมูลของคุณในพาร์ทิชันเหล่านี้ เมื่อคุณทำเช่นนั้นคุณจะสามารถโคลนพาร์ติชั่นเหล่านี้ (บน NetApps สิ่งนี้รู้ว่าเป็น " FlexClone "
นี่เป็นเพราะสำหรับแต่ละบล็อกอ่านไฟล์จะต้องตรวจสอบว่าข้อมูลที่อยู่ในสแนปช็อตดั้งเดิมหรือในเดลต้า สำหรับเล่ม / ร้านค้าที่มีสแนปชอตหลายรายการอาจต้องตรวจสอบหลายครั้ง คุณสามารถเอาชนะสิ่งนี้ได้โดยการรีเฟรชข้อมูล (หมายถึงทิ้งสแน็ปช็อตของคุณและโคลนอีกครั้งเป็นระยะ ๆ - ซึ่งอาจเกิดขึ้นตามธรรมชาติและเป็นอินทรีย์สำหรับสภาพแวดล้อมในการปรับใช้ที่ดีอย่างต่อเนื่อง) หรือโดยการแยกวอลุ่มอย่างถาวร ) ซึ่งจะใช้เวลาสักครู่ในการแก้ไขเดลตาอย่างถาวรและสร้างโวลุ่มใหม่และแยกทั้งหมด
โคลนเดลต้าเหล่านี้มีประโยชน์เพิ่มเติมในการลดความต้องการพื้นที่เก็บข้อมูลโดยรวมของคุณ - คุณสามารถวางไข่โคลนหรืออินสแตนซ์ของข้อมูลฐานข้อมูลการผลิตหลายอย่างเพื่อทำการพัฒนาทดสอบและตรวจสอบความถูกต้อง หากคุณเก็บรักษาชุดข้อมูลขนาดใหญ่ไว้เพียงชุดเดียวรวมถึง deltas ขนาดเล็ก (ที่มีแนวโน้มว่าจะเป็น) คุณจะลดต้นทุนการจัดเก็บโดยรวมและการปล่อยทิ้ง
เคล็ดลับเพียงอย่างเดียวที่นี่คือสิ่งนี้อาจไม่ใช่วิธีการสำรองข้อมูลเต็มรูปแบบเนื่องจาก "การสำรองข้อมูล" ยังคงอยู่ในไฟล์ของคุณ สำหรับสิ่งนี้คุณอาจต้องใช้บางสิ่งบางอย่างที่ NetApp เรียกว่า Snap Mirror ซึ่งจะสะท้อนข้อมูล (โดยใช้เทคโนโลยี rsync-style) ระหว่าง filers และแม้กระทั่ง datacenters หรือใช้วิธีการสำรองข้อมูลแบบบูรณาการบางชนิดซึ่งสามารถสำรองข้อมูลลงเทป ดิ้นโคลน
อย่างไรก็ตามสิ่งนี้มีข้อบกพร่องสำคัญหนึ่งประการ: ข้อมูลทั้งหมดของคุณ - การทดสอบและการทดสอบยังคงใช้ I / O ในตัวกรองและหัวจัดเก็บข้อมูลเดียวกัน ในการหลีกเลี่ยงปัญหานี้ให้พิจารณาสร้างอินสแตนซ์ฐานข้อมูลทาสบนไฟล์ตัวที่สองซึ่งอาจเป็นจุดเริ่มต้นสำหรับคุณทดสอบและ / หรือตัวกรอง dev หรือลองใช้ตัวควบคุมการส่งมอบ load balancer / applcation สำหรับชั้นแอปพลิเคชันของคุณ สภาพแวดล้อมการทดสอบ (และ / หรือ dev) สิ่งนี้มีประโยชน์เพิ่มเติมในการขว้างปริมาณการใช้ผลิตภัณฑ์ที่สภาพแวดล้อม QA / ทดสอบของคุณก่อนที่จะส่งเสริมการผลิตสำหรับปัญหาที่อาจไม่สังเกตเห็นได้ทันที จากนั้นคุณสามารถตรวจสอบบันทึกข้อผิดพลาดตามปริมาณการใช้งานจริงและพฤติกรรมของผู้ใช้
สิ่งนี้ควรอนุญาตให้คุณใช้สคริปต์สองสามตัวเพื่อวางไข่แบบเป็นโปรแกรมและทำลายชุดข้อมูล (และขนาดใหญ่) ทั้งหมดเพื่อใช้กับวิธีการปรับใช้อย่างต่อเนื่อง
ความยืดหยุ่นและความพร้อมใช้งานสูง
ในขณะที่คุณถามเกี่ยวกับการใช้งานอย่างต่อเนื่องเป็น DevOps conserned ที่มีมากกว่าเพียงแค่การใช้งานอย่างต่อเนื่อง - ดังนั้นฉันจะไปรวมบิตบางอย่างเกี่ยวกับความซ้ำซ้อนความยืดหยุ่นและความพร้อมใช้งานสูง
ฉันพูดถึง JIT ทันทีและในที่สุดความสอดคล้อง นี่คือสิ่งที่เอ็นจิ้น RDBMS ที่หลากหลายเข้ามาความสอดคล้องในที่สุดนั้นค่อนข้างง่ายโดยเพียงกำหนดค่าการจำลองแบบอะซิงโครนัสแบบวงกลม สิ่งนี้สามารถทำให้เกิดการชนกันอย่างไรก็ตาม * (ถ้าแอปพลิเคชันของคุณเลเยอร์อัปเดตข้อมูลในด้านหนึ่งของคลัสเตอร์และอีกด้านหนึ่งของคลัสเตอร์ก่อนที่การจำลองจะเสร็จสมบูรณ์?) เพื่อความสอดคล้องทันทีให้ดูที่ Galera คลัสเตอร์ ทำให้เกิดปัญหาความยืดหยุ่น (คุณจะทำซ้ำไปยังไซต์ Disaster Recovery หรือโหลดบาลานซ์ทางภูมิศาสตร์โดยไม่เกิดความล่าช้าอย่างมีนัยสำคัญเนื่องจากความล่าช้าในการเลเยอร์เครือข่าย?) คุณยังสามารถดูว่าคุณสามารถทำซ้ำแบบซิงโครนัสภายในศูนย์ข้อมูล แต่นี่ดูเหมือนจะเลวร้ายที่สุดของทั้งสองโลก
อย่างไรก็ตามโดยทั่วไป Poeple ส่วนใหญ่ไม่ต้องการการจำลองแบบซิงโครนัสอย่างสมบูรณ์ - โดยปกติจะต้องการเฉพาะสภาพแวดล้อมการเขียนสูงที่เฉพาะเจาะจง (และแปลกใหม่) ที่จำเป็นต้องใช้ multi-master พร้อมกับการแบ่งตาราง แอพส่วนใหญ่สามารถจัดการกับ Just-In-Time ที่สอดคล้องกันโดยใช้พร็อกซีฐานข้อมูล ตัวอย่างเช่นScaleArcจะตรวจสอบสถานะการจำลองแบบและติดตามการเขียนที่เพิ่งไป (เพื่อส่งคำขออ่าน subesquent จนกว่าการจำลองแบบจะเกิดขึ้น) เพื่อให้ความสอดคล้อง Just-In-Time และลักษณะที่ปรากฏของความสอดคล้องของฐานข้อมูล ScaleArc สามารถใช้งานร่วมกับ Postgres, MySQL, MariaDB, Oracle และ MSSQL และสามารถใช้นิพจน์ทั่วไปเพื่อสร้าง / แบ่งพาร์ติชันฐานข้อมูลของคุณสำหรับแอปพลิเคชันที่ไม่สามารถใช้คีย์ shard ได้ นอกจากนี้ยังมี REST API ที่แข็งแกร่งสำหรับซอฟต์แวร์การจัดการการกำหนดค่าของคุณเพื่อโต้ตอบกับ - และทีมสนับสนุนของพวกเขาโดดเด่น
ในทำนองเดียวกันคุณอาจต้องการพิจารณาทางเลือกฟรีMaxScale ที่พัฒนาโดยทีม MariaDB สำหรับ MariaDB มันขาด GUI และคุณสมบัติการแคชบางส่วนของ ScaleArc อย่างไรก็ตาม
ในที่สุดผ้าของ MySQL (และในคลัสเตอร์ของ MySQL เท่านั้น - ถ้าคุณสามารถจ่ายได้มาก RAM) เป็นศักยภาพอื่น ๆ - โดยเฉพาะอย่างยิ่งกับพร็อกซีใหม่ของ MySQL สิ่งนี้สามารถจัดเตรียมความสามารถในการปรับขนาดและความซ้ำซ้อนให้กับสภาพแวดล้อมของคุณ
Postgres และ Oracle ควรมีคุณสมบัติการจำลองแบบและการแบ่งส่วนที่คุณต้องการ แต่ ScaleArc จะจับคู่ได้ดีถ้าคุณต้องการพร็อกซี
ในท้ายที่สุด peices ทั้งหมดเหล่านี้รวมอยู่ในสภาพแวดล้อมที่มีความยืดหยุ่นสูงซึ่งเหมาะสำหรับการปรับใช้และการพัฒนาอย่างต่อเนื่องหากคุณไม่สามารถใช้สภาพแวดล้อมแบบคลาวด์ได้อย่างง่ายดายและให้ผู้ให้บริการคลาวด์ของคุณจัดการกับปัญหาข้างต้น