ในการอภิปรายเกี่ยวกับฐานข้อมูล NoSQL vs SQL บางครั้งฉันได้ยินว่า บริษัท ต้องการใช้ฐานข้อมูลแบบไม่มี schema ของ schemaless เนื่องจากเป็นปัญหาในการโยกย้ายสคีมาเป็นเวอร์ชันใหม่ แต่นั่นเป็นปัญหาใหญ่จริง ๆ เมื่อทำการอัพเกรด ฐานข้อมูลเชิงสัมพันธ์นั้นแย่สำหรับการดำเนินการดังกล่าวหรือไม่?
ฉันอ่านโพสต์บล็อกนี้ในบล็อก MongoDB: ทำไมต้อง Schemaless
คำตอบ:
เพียงเพราะฐานข้อมูล NoSql ของคุณไม่มีสคีมาในแง่ดั้งเดิมไม่ได้หมายความว่าไม่มีสคีมาแบบลอจิคัลที่คุณต้องจัดการเมื่อมีการเปลี่ยนแปลง ในกรณีของแอปทั่วไปที่ใช้ MongoDb รหัสของคุณน่าจะเป็นไปได้ที่จะคาดว่าฟิลด์ของวัตถุ json จะทำงานในบางวิธี หากคุณเปลี่ยนพฤติกรรมดังกล่าวคุณอาจต้องอัปเดตข้อมูลที่มีอยู่แล้วในฐานข้อมูล ตอนนี้ด้วย RDBMS แบบดั้งเดิมนี่เป็นปัญหาที่แก้ไขได้ส่วนใหญ่ - คุณแค่ต้องเปลี่ยนตารางพื้นฐาน แต่ด้วยฐานข้อมูล NoSQL ที่ใหม่นี้คุณมีการตัดสินใจหรือไม่คุณเขียนสคริปต์เพื่อลบล้างและอัปเดตวัตถุทั้งหมดของคุณหรือไม่ หรือคุณเพิ่มรหัสเพื่อแปลงระหว่างเวอร์ชันในทันที? ถ้าเป็นเช่นนั้นคุณสนับสนุนวัตถุ v1 นานเท่าไหร่ ตลอดกาล? จนถึง v3?
ฉันจะเพิ่มว่าตัวอย่างที่ใช้ในการโพสต์บล็อก MongoDb นั้นเรียบง่ายเล็กน้อยและเป็นกรณีที่ง่ายมากที่จะจัดการหากคุณมีกระบวนการอัปเดตที่ดีไม่ว่า RDBMS จะเป็นอย่างไร การเพิ่มเขตข้อมูลไม่ค่อยทำให้เจ็บปวด มันคือเมื่อคุณตัดสินใจที่จะแยกNameฟิลด์ของคุณFirstNameและLastNameสิ่งที่น่าตื่นเต้น
แต่นั่นเป็นปัญหาใหญ่จริง ๆ เมื่อทำการอัพเกรด
มันสามารถ
บางองค์กรมีความไม่เป็นระเบียบและทำงานได้ไม่ดีในการโยกย้ายสคีมา
"วันหยุดสุดสัปดาห์การย้ายถิ่น" หยุดเซิร์ฟเวอร์ สำรองและส่งออกข้อมูลทั้งหมด สร้างสคีมาใหม่ (บ่อยครั้งโดยการแก้ไขสคีมาที่มีอยู่) โหลดข้อมูลซ้ำหรือพยายามปรับโครงสร้างให้เข้าที่
"Tweaking ต่อเนื่อง" ปรับเปลี่ยนตารางตามขอบเขตที่ SQL อนุญาต โดยไม่ต้องติดตามลำดับของ ALTER ที่ดำเนินการ ไม่มีทางที่จะกลับไปเป็นเวอร์ชันสกีมาก่อนหน้า หากจำเป็นให้สร้างตารางใหม่จากตารางที่มีอยู่หวังว่าจะปรับแอปพลิเคชันทั้งหมดเพื่อใช้ตารางใหม่ แต่ - ขาดการประกันคุณภาพที่ดี - ออกจากตารางเก่าแทนที่ "ในกรณี"
"Full Panic" เพียงป้องกันการแก้ไขสคีมา ทำให้เหม็นใหญ่ รับความเสี่ยงได้สูงเกินไป บล็อกความพยายามทั้งหมดในทิศทางนี้ ใช้ตัวประกันสกีมาจนกระทั่งถูกบังคับให้นำวิธีการที่เหมาะสมมาใช้
ฐานข้อมูลเชิงสัมพันธ์นั้นแย่สำหรับการดำเนินการดังกล่าวหรือไม่?
สคีมาใด ๆ เป็นความเจ็บปวดในการโยกย้าย
ปัญหาที่ใหญ่ที่สุดไม่ใช่ทางเทคนิค
มันเป็นความหมาย
เหตุผลหลักประการหนึ่งสำหรับการเปลี่ยนสคีมาคือสคีมาก่อนหน้านั้นไม่ตรงกับโดเมนปัญหาได้เป็นอย่างดี เนื่องจากความหมายมีการเปลี่ยนแปลงฐานข้อมูล (และแอปพลิเคชัน) จึงจำเป็นต้องเปลี่ยนแปลง บางครั้งสิ่งเหล่านี้เป็นการเปลี่ยนแปลงที่ลึกซึ้งซึ่งต้องมีการคิดใหม่เกี่ยวกับวิธีที่แอปพลิเคชันทำงานกับข้อมูล
การแก้ไขความหมายของฐานข้อมูลอาจเป็นเรื่องยากมาก
สิ่งที่คนทำแทนการเปลี่ยนแปลงสคีเป็นเพียงการใช้สคีมาในทางที่ผิด พวกเขาเริ่มต้นการโหลดข้อมูลผิดไปยังเขตข้อมูลที่มีอยู่เพราะพวกเขาสามารถ ฟิลด์ "ความคิดเห็น" ก็เริ่มมีข้อมูลการจัดการลูกค้าที่สำคัญตามมาด้วย "//" ตามด้วยความคิดเห็นจริง ที่เติบโตต้องมีชิ้นส่วนของข้อมูล "ฟิลด์ 1 - ฟิลด์ 2 // ความคิดเห็น" ผู้ใช้มีสเปรดชีตที่ดึงข้อมูลเพิ่มเติมนี้จากช่องแสดงความคิดเห็นเพราะซอฟต์แวร์แอปพลิเคชัน "ของจริง" มีสคีมาเป็นเรื่องยากที่จะเปลี่ยนแปลงว่าฝ่ายไอทีปฏิเสธที่จะเปลี่ยนแปลง
เราอัปเกรดฐานข้อมูลการผลิตเพิ่มตารางและคอลัมน์ (nullable) โดยไม่มีปัญหา แอปพลิเคชั่นรุ่นก่อนหน้านี้ทำงานได้ดีกับฐานข้อมูลที่อัปเกรด แต่พวกเขาไม่ได้อ้างอิงสิ่งใหม่ เราหลีกเลี่ยงการลบตารางหรือคอลัมน์หรือเปลี่ยนแปลงวิธีการจัดเก็บข้อมูลที่มีอยู่แม้ว่าในกรณีนี้เราจำเป็นต้องสร้างสคริปต์การแปลงที่เหมาะสม ไม่ว่าฐานข้อมูลของคุณจะมี schema ที่ปลอดภัยประเภทประกาศหรือไม่การเปลี่ยนแปลงในโครงสร้างข้อมูลจำเป็นต้องมีการแปลงข้อมูลและการอัพเกรดแอปพลิเคชันเพื่อโต้ตอบกับโครงสร้างใหม่
มันขึ้นอยู่กับ.
ก่อนอื่นถ้าคุณมีฐานข้อมูลขนาดใหญ่มากที่ประกอบไปด้วยหลาย ๆ เครื่องทุกอย่าง (ไม่ใช่แค่การอัพเดทฐานข้อมูล) จะต้องเจ็บปวด (ไม่ว่าคุณจะวางแผนไว้ล่วงหน้าเท่าใดก็ตาม)
ข้อสองการอัปเดตฐานข้อมูลไม่ได้เป็นเพียงแค่ฐานข้อมูล แต่ยังขึ้นอยู่กับระบบที่ใหญ่กว่าซึ่งฐานข้อมูลเป็นส่วนหนึ่ง นอกจากนี้ยังรวมถึงการปรับใช้ฐานข้อมูล (เซิร์ฟเวอร์ฐานข้อมูลจำนวนมากศูนย์ข้อมูลหลายแห่งการตั้งค่ามาสเตอร์ทาส ฯลฯ )
ความเจ็บปวดสามารถปลดเปลื้องได้ด้วยการออกแบบโครงสร้างของระบบให้คุณโดยที่พวกเขาทุกคนมี 'การรับรู้' ของเหตุการณ์การเปลี่ยนแปลง DB schema ซึ่งหมายความว่าทั้งระบบควรมีความอดทนต่อการเปลี่ยนแปลงของสคีมาและสามารถตอบสนองต่อมันได้อย่างมีสติ
คุณสามารถตรวจสอบยูทิลิตี้ที่พัฒนาโดย Facebookเพื่อจัดการกับการอัพเดต MySQL schema
นอกจากนี้ยังมีแนวปฏิบัติที่เป็นมาตรฐานเช่นเปลี่ยนคุณเป็นมาสเตอร์แบบอ่านอย่างเดียวทำการเปลี่ยนแปลงทาสหรือสำเนาการพัฒนาเป็นต้น
ไม่ว่าในกรณีใดการมีการสำรองข้อมูลเต็มรูปแบบและชุดทดสอบที่ครอบคลุมนั้นเป็นสิ่งที่ต้องทำ เท่านั้นคุณสามารถทำการเปลี่ยนแปลงใด ๆ อย่างมั่นใจและปลอดภัย