แบบจำลองข้อมูลมีผลกระทบต่อความสามารถในการขยายและประสิทธิภาพในฐานข้อมูลที่เรียกว่า“ NoSQL” มากน้อยเพียงใด?

คุณไม่เคยมีการพูดคุยเกี่ยวกับฐานข้อมูลที่เรียกว่า "NoSQL" โดยไม่ต้องนำทฤษฎีบท CAP (ความสอดคล้องความพร้อมใช้งานพาร์ติชัน: เลือกสอง) ถ้าคุณต้องเลือกว่าระหว่าง MongoDB (Partition, Consistency) และ CouchDB (Availability, Partition) สิ่งแรกที่คุณต้องคิดคือ "ฉันต้องการข้อมูลที่ถูกต้องหรือต้องเข้าถึงตลอดเวลาหรือไม่"

ฐานข้อมูลใหม่เหล่านั้นถูกจัดทำขึ้นเพื่อแบ่งพาร์ติชัน แต่ถ้าฉันทำไม่ได้ล่ะ ถ้าฉันคิดว่ามันยอดเยี่ยมมากที่มีคีย์ / ค่าคอลัมน์เอกสารฐานข้อมูลใด ๆ แทนที่จะเป็นเชิงสัมพันธ์และเพิ่งสร้างเซิร์ฟเวอร์อินสแตนซ์เดียวและไม่เคยทิ้งมัน ในกรณีนั้นฉันจะไม่มีทั้งความพร้อมใช้งานและความสอดคล้องใช่ไหม MongoDB ไม่จำเป็นต้องทำซ้ำสิ่งใดดังนั้นจึงสามารถใช้งานได้ และ CouchDB จะมีแหล่งข้อมูลเพียงแหล่งเดียวดังนั้นมันจึงค่อนข้างสอดคล้องกัน

นั่นหมายความว่าในกรณีนี้ MongoDB และ CouchDB จะมีความแตกต่างเล็กน้อยในแง่ของการใช้งาน? ดียกเว้นประสิทธิภาพของหลักสูตร API และ al แต่นั่นจะเป็นการเลือกระหว่าง PostgreSQL และ MySQL มากกว่าการมีข้อกำหนดที่แตกต่างกันสองชุด

ฉันอยู่ตรงนี้หรือไม่ ฉันสามารถเปลี่ยนฐานข้อมูล AP หรือ CP เป็น AC ได้โดยไม่สร้างมากกว่าหนึ่งอินสแตนซ์หรือไม่ หรือมีบางอย่างที่ฉันขาดหายไป?

ลองถามคำถามตรงข้ามกัน ถ้าฉันใช้ฐานข้อมูลเชิงสัมพันธ์สมมติว่า MySQL และวางไว้ในการกำหนดค่าหลัก / ทาส ฉันไม่ใช้ธุรกรรม ACID หากฉันต้องการให้มีการซิงโครไนซ์การเขียนใด ๆ กับทาสทันทีนั่นจะไม่ทำให้ฐานข้อมูล CP ใช่หรือไม่ และถ้าฉันซิงโครไนซ์มันเป็นช่วงเวลาที่กำหนดไว้ล่วงหน้าและมันไม่สำคัญว่าลูกค้าอ่านข้อมูลเก่าจากทาส นั่นจะไม่ทำให้มันเป็นฐานข้อมูล AP หรือไม่? นั่นไม่ได้หมายความว่าถ้าฉันยอมแพ้กับ ACID ฉันยังคงสามารถใช้โมเดลความสัมพันธ์สำหรับฐานข้อมูลแบบแยกส่วนได้หรือไม่

ในสาระสำคัญ: ความสามารถในการปรับขนาดได้เกี่ยวกับสิ่งที่คุณพร้อมที่จะยอมแพ้ในทฤษฎีบท CAP มากกว่าแบบจำลองข้อมูลพื้นฐานหรือไม่ การมีคอลัมน์, เอกสาร, ค่าคีย์, สิ่งใดที่ช่วยเพิ่มความสามารถในการปรับขนาดได้มากกว่าโมเดลเชิงสัมพันธ์หรือไม่? เราสามารถออกแบบฐานข้อมูลเชิงสัมพันธ์ที่ออกแบบจากพื้นฐานเพื่อความทนทานต่อการแบ่งพาร์ติชันได้หรือไม่? (อาจมีอยู่แล้ว) เราสามารถทำให้กรดฐานข้อมูล NoSQL สอดคล้องกับมาตรฐานได้หรือไม่?

ขออภัยมันมีคำถามมากมาย แต่ฉันได้อ่านฐานข้อมูล NoSQL จำนวนมากเมื่อเร็ว ๆ นี้และดูเหมือนว่าประโยชน์ที่ใหญ่ที่สุดของการใช้พวกเขาคือพวกเขาเหมาะสมกับรูปร่างของข้อมูลของคุณมากกว่าพาร์ทิชัน CAP และการยกเลิกการปฏิบัติตาม ACID ท้ายที่สุดไม่ใช่ว่าทุกคนจะมีข้อมูลจำนวนมากซึ่งพวกเขาจำเป็นต้องแบ่งมัน มีประสิทธิภาพ / ความสามารถในการปรับขยายได้หากไม่ใช้โมเดลเชิงสัมพันธ์ก่อนที่ฉันจะคิดถึงการแบ่งพาร์ติชันข้อมูลของฉันหรือไม่?

การใช้ฐานข้อมูล NoSQL ช่วยเพิ่มความสามารถในการปรับขนาดแม้ว่าคุณจะไม่ได้แชร์ข้อมูลหรือไม่ ให้กำหนดความยืดหยุ่น หากคุณอ้างถึงความสามารถในการปรับขนาดได้เนื่องจากระบบฐานข้อมูล / แบ็กเอนด์เกี่ยวข้องกับการที่คุณมีการปรับสเกลในแนวตั้งและแนวนอนที่การปรับสเกลแนวนอนจะทำให้ข้อมูลที่ถูกตัดทอน เป็นการปรับขนาดในแนวตั้ง (เช่นการเพิ่มฮาร์ดแวร์ให้ดีขึ้น) หากคุณกำลังพูดถึงความสามารถในการปรับขนาดได้ในมุมกว้างหมายถึงความยืดหยุ่นของแอปพลิเคชันค่าข้อมูล ฯลฯ ... จากนั้นเป็นคำถามที่แตกต่างอย่างสิ้นเชิงกับจำนวนคำตอบ และเช่นเดียวกับที่คุณพูดถึงมันมักจะเกิดขึ้นกับสิ่งที่คุณทำกับข้อมูลและวิธีการจัดเก็บ ผมขอนำทุกอย่างมาที่นี่ด้วยคำแถลงว่าในกรณีส่วนใหญ่คุณควรใช้ RDBMS และ NoSQL ควรเติมช่องของ ต่อไปนี้เป็นคำอธิบายของอินสแตนซ์เฉพาะที่ฐานข้อมูล NoSQL จะเป็นประโยชน์มากขึ้นเมื่อได้รับข้อกำหนดเฉพาะและเราสามารถละเว้นการปรับสเกลในแนวนอนได้

ยกตัวอย่างเช่นแนวคิดที่ว่าคุณกำลังสร้างระบบจัดเก็บไฟล์บนคลาวด์ที่คล้ายกับ google ไดรฟ์ดรอปบ็อกซ์หรือกล่อง แต่แทนที่จะใช้ระบบไฟล์จริงคุณตัดสินใจว่ามันจะมีประโยชน์มากกว่าสำหรับคุณในการจำลองระบบไฟล์ ตอนนี้คุณมีปัญหาเพราะตัวแบบข้อมูลของคุณเป็นโครงสร้างแบบต้นไม้ซึ่งจะไม่มีประสิทธิภาพอย่างน่ากลัวใน RDBMS (แม้ว่าจะมีความจริงที่ว่าทุกอย่างถูกจัดทำดัชนี) เพราะตอนนี้คุณมีตารางคอลัมน์ 3 คอลัมน์ที่มีชื่อผู้ใช้และผู้ปกครอง ผู้ใช้เป็น foreign key ไปยังตารางผู้ใช้และ Parent คือการอ้างอิงตัวเอง foreign key null (nullable เนื่องจากไดเรกทอรีรากไม่สามารถมี parent) ดังนั้นคีย์หลักคืออะไร? ในกรณีนี้มันเป็นคีย์ผสมในทุกคอลัมน์ ... ซึ่งทำให้ผู้ปกครองเป็นศัตรูที่เลวร้ายที่สุดของเรา

ทีนี้ลองคิดดูว่าคุณจะเก็บมันไว้ในที่เก็บเอกสารได้อย่างไร แทนที่จะต่อสู้กับข้อมูลคุณสามารถทำงานกับมันและเก็บไว้เป็นโครงสร้างต้นไม้ซึ่งจะช่วยลดเวลาในการพัฒนาของคุณและลดค่าบำรุงรักษา หากคุณกำลังลดค่าใช้จ่ายไม่อนุญาตให้มีความยืดหยุ่นที่แตกต่างกันใช่หรือไม่ นอกจากนี้ในตัวอย่างนี้คุณกำลังสร้างระบบอย่างถูกต้องตั้งแต่เริ่มต้นซึ่งควรให้ความยืดหยุ่นกับแอปพลิเคชันมากขึ้น ขณะนี้ฉันกำลังใช้งานบนเซิร์ฟเวอร์เดียวโดยใช้ MongoDB ซึ่งตามที่คุณอธิบายให้ฉันแบบพร้อมใช้งานที่สอดคล้องซึ่งไม่แตกต่างจากการดูความแตกต่างของ MySQL หรือ Postgres

ด้วย MongoDB เป็นอย่างน้อยคุณสามารถกำหนดจำนวนเซิร์ฟเวอร์ที่คุณต้องการสื่อสารด้วยเพื่อให้แบบสอบถามประสบความสำเร็จใช่คุณสามารถแปลงเป็นรูปแบบที่สอดคล้องและพร้อมใช้งานถ้าคุณบอกคำสั่งทั้งหมดเพื่อสื่อสารกับอินสแตนซ์เซิร์ฟเวอร์ทั้งหมด

ดังนั้นฉันคิดว่าคุณมีสิทธิ์ในที่นั้นมีประโยชน์มากในการจัดเก็บข้อมูล มีหลายสิ่งที่ไม่สอดคล้องกับโมเดลเชิงสัมพันธ์ที่เหมาะสมกับโมเดลอื่น ๆ (เป็นอีกตัวอย่างสั้น ๆ Amazon ใช้รูปแบบฐานข้อมูลกราฟสำหรับเครื่องมือการแนะนำผลิตภัณฑ์ของพวกเขา)

ฉันเข้าใจคำถามของคุณถูกต้องหรือไม่

แก้ไข: ข้อมูลเพิ่มเติมจะช้าลงหรือไม่ ใช่. มันจะช้าลงเท่าไหร่? ฉันมีประสบการณ์ไม่เพียงพอที่จะให้คำตอบที่เพียงพอ คีย์ / ค่า: เป็นตารางการค้นหาที่มีข้อมูลจำนวนมากที่เกี่ยวข้องกับคีย์การค้นหา นี่จะเป็นไปอย่างรวดเร็วจริง ๆ เพราะคุณสามารถค้นหาสิ่งต่าง ๆ ด้วยกุญแจเท่านั้น คอลัมน์ / ตระกูล: ที่เก็บคีย์ / ค่าที่มีโครงสร้างมากขึ้น คุณสามารถสืบค้นตามคอลัมน์ได้เท่านั้นดังนั้นควรเร็วเกินไป เอกสาร: สกีมาสไตล์การรวม ที่นี่คุณจะต้องการรวมข้อมูลที่คล้ายกันเข้าด้วยกัน การทำให้เป็นปกติคือโอเคและคาดว่าสำหรับฐานข้อมูลประเภทนี้ ขึ้นอยู่กับว่าคุณทำการเขียนหรืออ่านจำนวนมากคุณสามารถจัดระเบียบข้อมูลของคุณเพื่อที่จะได้รับการกระจายไปทั่วหลายเศษเพื่อกระจายการเขียนหรืออ่านออก (โปรดทราบว่าคุณสามารถสร้างวิธีการแบบผสมผสานที่ดีสำหรับทั้งสอง จำเป็นต้องเลือกการปรับให้เหมาะสมสำหรับอย่างใดอย่างหนึ่ง) กราฟ: จุดแข็งของอันนี้คือมันสามารถสร้างและทำลายความสัมพันธ์ได้อย่างรวดเร็วจริงๆ หากคุณมีข้อมูลบางส่วนที่คุณมีความสัมพันธ์ซึ่งจำเป็นต้องเปลี่ยนแปลงระหว่างข้อมูล (คิดว่าเครื่องมือแนะนำบางอย่าง) คุณควรใช้สิ่งนี้

วิธีที่คุณจัดเก็บข้อมูลในฐานข้อมูลใด ๆ เหล่านี้จะมีผลต่อประสิทธิภาพ (คล้ายกับความจริงที่ว่าถ้าคุณจัดเก็บข้อมูลไม่ถูกต้องใน RDBMS บางตัวจะมีผลต่อประสิทธิภาพ) ดังนั้นเพื่อให้ชัดเจนยิ่งขึ้น: คุณจำเป็นต้องรู้ว่าระบบฐานข้อมูลใดที่คุณควรใช้รวมถึงวิธีการจัดเก็บข้อมูลในระบบฐานข้อมูลนั้น